I just got back from the outstanding Open FSharp conference where I got to reconnect with and meet a bunch of people I’ve followed or with whom I’ve worked on various OSS projects. I’m energized, excited to contribute, etc. Yet, in the midst of the conference, the first tweets eventually leading up to Henrik Feldt‘s post appeared. I was and continue to be really sad about what he’s going through, and it took the edge off my enthusiasm (but only a little). Henrik has been a huge contributor and work horse in the community and created some incredibly valuable libraries. He’s also great to work with in OSS, and I am going to miss his presence.
However, I cannot agree with Henrik’s conclusions about the community. I do recognize he’s expressing some valid emotional turmoil. I have no problem with the abundance of options the community explores and think it’s a sign of a healthy community. I also think the catalyst to his decision is mostly based on misunderstanding, but I reserve the right to change my mind; I’m basing this exclusively on Twitter and a blog post and haven’t actually spoken to Henrik. I have spoken to several others in the past who saw their projects more or less hijacked by Microsoft. Henrik mentioned several of these: MonoRail, OpenWrap, etc. The project leads faced animosity and/or apathy from Microsoft as their projects were replaced and ideas taken without recognition of the work they had done or much inclusion in the process.
It’s important to remember, though, that wasn’t the Microsoft of today. Also, not all parts of Microsoft worked that way. I had the pleasure of working on an advisory board that helped Microsoft eventually release ASP.NET Web API. It was a lot of fun, and the Microsoft people involved were very conscious that what they were doing could ultimately replace some other frameworks and wanted to make sure everyone with similar offerings was able to be heard and offer input. I find the Microsoft of today works, generally, more like that, and I’ve often had very good interactions with them.
In the midst of that advisory project, I started working on OWIN with a bunch of the other advisory team members and a few people from Microsoft who wanted to be involved because they liked the idea. Most people don’t realize OWIN was fully conceptualized and developed by the community. I’ve presented on the evolution of OWIN in the past (original / more recent), and I always find people are surprised by this. Another surprise is how we landed on a
Func<IDictionary<string, object>, Task> as the primary abstraction. (The short answer is that all framework maintainers are picky about syntax and wouldn’t budge and also didn’t want a common dependency). Microsoft fully embraced it and gave it life, which was very exciting. We, the community, successfully engaged Microsoft and saw them adopt a substantial change to their technology platform.
Then things began unraveling. Issues with
IAppBuilder created a strain that led to misunderstandings and hurt feelings. The close ties we had formed working together on OWIN frayed, and Microsoft eventually became quiet even as we formed the first OWIN management team post-release. The ideas for ASP.NET Core were forming around this time, and those of us who were working closely on OWIN assumed ASP.NET Core would use OWIN as the core abstraction. It wasn’t, and there is a very good reason for this: performance.
Microsoft wants a fast platform for web projects. Their customers want a fast platform. Their customers, on the whole, don’t care about abstractions that let them compose things in sometimes bizarre ways, e.g. Nancy + Web API + Auth0 + enter-framework-here. OWIN, for all its good of no common dependencies and very simple and open protocol, also involves a lot of boxing and unboxing. There’s no type checking. It’s really not ideal. And I find no fault in Microsoft choosing a different direction. They followed a lot of the same style used in OWIN, and they made sure to support OWIN, which I still think is fair and fantastic. It would certainly be nice had they made sure all their newer security middleware “just worked” on OWIN, as well, but even their old security middleware often failed to adhere correctly to the OWIN spec, working only on the Microsoft.Owin libraries. To their further credit, they introduced Assembly Neutral Interfaces in early versions of ASP.NET Core to avoid having shared dependencies, but these eventually had to be scrapped.
I think Microsoft has and continues to improve its relationship with its community. The F# team, for example, is simply fantastic. I’ve enjoyed working with the ASP.NET team. Sure, there are some groups that have had more problematic relationships, but on the whole, I give Microsoft an A.
I mentioned some friction amongst the community members working on OWIN above. Much like that project, I’ve found the same sort of friction in the F# community while trying to find a common abstraction layer for web projects. In short, it didn’t happen. Here’s my own analysis, and I agree reserve the right to change my mind. I think people have very limited time and resources as it is, and they are doing their best to try things and share them. In some cases, e.g. Henrik, those solutions pick up steam and become popular. In the case of Suave, the syntax became more popular than the whole library, and some wanted to have the best of both great syntax and a fast server with extensions supported by a broader community. As a member of the other side of the spectrum, someone who has shared a lot of stuff but found much lower uptake, I don’t have a problem with that. I’ve even abandoned projects in order to help out with others I thought had more uptake. Maybe I’m an anomaly. (I doubt it.) I recall being asked on occasion to abandon my stuff and contribute to a framework so that there would be only one. I didn’t, in part b/c I don’t like the notion of there being only one option, but also because I enjoyed following my own experiments at that time and didn’t like the design of that other library. (I changed my mind later.)
That’s a long way of saying I don’t think we need to have only one solution. This isn’t Highlander. I realize there’s value in having a single, blessed solution as it’s easier for newcomers. However, in that case we should all just work on whatever Microsoft is doing. So I don’t buy it. I also appreciate that different people want different things, and as this is all OSS, while I often find some differences silly or frustrating (GitLink “porting” SourceLink in C# b/c they didn’t like F#), I have a hard time with getting mad at people for rebuilding tooling to meet their needs.
No grade here, just an ask: please, please, please ask maintainers about changes or use of their libraries. Since the catalyst here involves Giraffe and Suave, had Dustin first asked Henrik about changes to allow him to run the Suave syntax directly on Kestrel, perhaps there would be no issue here. Most likely, Henrik would not have wanted to make the move, but I never found him fundamentally opposed to separating Suave’s framework from the server. It just wasn’t a priority for him. I looked into it once but didn’t have the time to do it. That may not have satisfied everything Dustin wanted, but at least they would have had the conversation. Maybe they did. I haven’t spoken with Dustin either; I’m generalizing.
It always helps to ask first.
I feel for Henrik. I’m sure I would feel as frustrated were I in his position. Actually, I don’t know if I could fully understand. I don’t support an eighth (probably a lot less) of the libraries he’s created and maintains. I never had the opportunity to pour so much into a library only to see a nearly exact replica succeed, and in the same language and runtime, no less. I’m very sorry to lose such a valuable and prolific member of the community from OSS work.
Yet I understand why Giraffe exists, and I agree with Isaac Abraham that choice is important. I don’t use Suave at work right now b/c I ran into trouble migrating onto the Suave server. It’s not insurmountable; I just didn’t have the time to work out the kinks, and it isn’t critical to our software. I’d love to use the Suave syntax, and having the ability to migrate pieces and when time permits would have been welcome.
I’m also full of hope for the future of F#. Open FSharp was full of great presentations, conversations, and workshops. Many new people are entering the community and bringing their enthusiasm and ideas. We celebrated a new batch of Community for F# Heroes, and we had a great turnout in terms of nominations and voting. If that’s a good metric, then I’m seeing a lot of positive momentum in the F# community right now.
The future is bright.