Goodbye NancyFX, Hello F#!

As some of you may already know, NancyFX has been archived 11 years after its first commit. You can read the announcement here for further information but I will never forget what I learnt from this codebase, the community around it and most especially the people involved with it. I am very proud and honoured to have been involved with it and a massive thank you to Andreas Håkansson for teaching me plenty via the 1:1 Skype calls we had in the early days. As many of you also know I created Carter which in my mind was Nancy v2 but sat on top of ASP.NET Core with the same approaches as Nancy, offering many things a web framework should have. The usage of Carter has steadily increased which is good to know people value similar things we achieved with Nancy. However, paradoxically I have had a feeling brewing for sometime that this effort is almost futile.

My Feelings On .NET OSS

Many will argue “I can’t believe it took you that long” but I think more recently many more have come to similar thoughts. One example being from Jeremy Miller who states:

Try not to compete against some kind of tool from Microsoft itself. That’s just a losing proposition 95% of the time. And maybe realize upfront that the price of a significant success in .Net OSS means that Microsoft will eventually write their own version of whatever it is you’ve done.

If you don’t already know, in the last 12 months or so Microsoft have openly discussed and in some cases released alternatives to Automapper, Identity Server and Proxy Kit whilst using their large PR and marketing machine to tout “Microsoft loves OSS”. The one thing is clear and you should pause, think and accept the fact that Microsoft is a BUSINESS! Their fundamental goal is to make money.

Now you could argue why don’t they contribute to OSS libraries rather than embrace, extend, and extinguish these libraries but I think their counter argument is “we need to support our solutions for 15 years+”. So instead of forking a library, using the code at that point in time and if required adapt it for their needs whilst also very publicly stating “we love OSS and thanks to library X” they look at the code, create their own repo and slowly copy the code/solution to the problem and then state “look what we’ve released, isn’t it awesome, go try it out in Azure!”.

The question you now have to ask yourself if you are a OSS library author is “what’s in it for me”. We have travelled through many years of people writing libraries under the guise of I just love to write code and make it available. The side effect of that is they are doing so for free. There is nothing to stop you releasing your code so people can view it but still impose a licence which allows the author to benefit financially for this. In these times gone by, everyone was releasing things for free so if you were the one to stand out and say I’m going to charge for my stuff people would have looked at you funny.

There are very few success stories here, there is ServiceStack and Identity Server that managed to succeed in the .NET space but I believe the time has come where we as authors must all unite and start charging for our code. Even if you love writing the code and making it available there is absolutely nothing wrong with getting some cash for it. You could offer a licence that allowed some usage of your code for free but once you hit X then you need to pay. If all successful libraries started charging money it potentially limits Microsoft’s EEE approach. If you are a business now paying for support to library X and Microsoft comes along and says “hey look what we’ve released to Azure and it costs Y” then you would ask yourself, I’m already paying X for library X why should I pay Y for Y and hopefully that doubt will limit Microsoft’s EEE approach and keep a vibrant ecosystem in .NET. At the moment people pay to use Microsoft’s libraries because they pay Azure fees and get support for it.

Change The Tide

Changing the .NET ecosystem has to be a united front from authors to start charging for their libraries otherwise you will hit fragmentation, potentially a worse ecosystem and still allowing Microsoft to wheel out their clones. There is always going to be businesses that pay for Microsoft support no matter what because no-one got fired for choosing Microsoft but if we can start changing people’s minds about paying for things I believe this will benefit everyone.

What we also need is a platform to allow this kind of thing, something that handles payments, contracts, information on support and contact information etc and I know there is Bytepack that allows this for non .NET packages but hopefully it’s only a matter of time until they do or someone else comes up with this platform. The App Store is a great example that could work here, imagine a Nuget App Store where you can download/purchase packages, I think the concept of a try before you buy would work extremely well here. If we could have this Nuget App Store that offered authors the ability to sell their packages, setup the ability to support their packages, provide contracts to buyers and some sort of support system for people that had bought the package who now seeks support using it we could be onto a winner.

Before you think I’m a mad man with these ideas I’d also like to link to a great blog post by Aaron Stannard which is titled “The New Rules for Playing in Microsoft’s Open Source Sandbox”. Here Aaron responds to the debacle that was WinGet, Microsoft’s new package manager for Windows that ripped off an existing package called AppGet.

OSS developer fills a hole in the Windows ecosystem, Microsoft offers him a job to work on this kind of product inside the company, ghosts him, releases their competing product which appears to have borrowed heavily from his designs, doesn’t attribute original developer’s work, Internet gets mad.

A couple of great points he makes is:

• Incentivize users to care about your project and not just what the project does for them.
• Take OSS sustainability seriously: build a profitable business around your project if you care about long-term viability.

As I stated previously, as an ecosystem we need to be unified in this approach. Granted it will not happen overnight but we need to start this ball rolling, otherwise we keep going down the same path giving stuff away for free whilst one company makes billions of dollars off the back of your work. We have to change people’s minds about paying for libraries and support because we are at a point where it is farcical, for example this is a tweet about buying something and Igal joking that Krzysztof could afford the $1000 if he just waited 15 years from the money he might make from his F# OSS contributions. I’m not picking on Igal here but this is a perfect illustration of how thousands of people and more importantly businesses see OSS. “It’s free and we can run our businesses using it and if we have any issues they have slack channels that will give support also for free!” (for more context feel free to see here)

Things in this area must change and I hope and I believe they will but this will be a slow change so whilst that is happening I will be concentrating more of my efforts elsewhere. I will continue to maintain Carter for now and hopefully when we have platforms ready for buying licences and support for .NET OSS libraries I will try it’s luck there.

Refocusing My Energy

So where will I focus now…….? The answer is F#!

I previously toyed with F# a few years back by using FAKE as a build tool but I didn’t get on with it. This was down to a few personal reasons and in no way a reflection on FAKE. We were a C# and JS shop so trying to learn how it worked whilst trying to get things shipped constantly didn’t allow me the time to truly understand what was going on. It also wasn’t truly F#, it’s a DSL over F# so you’re trying to learn two things on limited time and also a build script is one of those things that once it works you rarely touch it so on the occasions I did have to touch it I had forgotten how it worked and we were back to square one. However, more recently with constant Microsoft and OSS drama mentioned above and C# language features being rolled out far too quickly for me to have time to use and learn the new features I was reading more tweets from F# users and slowly coming to the conclusion that it was a community of people that had more control over their environment and had a real passion for what they were doing. With this control they seemed to have defined ways of doing things rather than what appears to be C#’s stance these days of having 10 different ways of doing something. When C# 9 was announced I read a few tweets with one stating that if they were learning C# these days how would you know what idiomatic C# was due to the numerous ways of doing things. Learning C# today is much harder I would imagine that learning it 15+ years ago when I did. In fact this picture below from Konrad Konkosa sums it up nicely:

Even today as I write this blog post I came across a reddit post titled “Tired of .Net’s bloat, hidden magic and constant changes. Is Golang for me?” so I feel like it’s not just me having these thoughts but also looking at tweets about this reddit post I see people with a similar mindset

I have been doing C# for 15+ years and I’m finding it hard to keep up with the language and so I started reading blog posts and watching videos about F# and started to enjoy reading the code people had written. The first link I would highly recommend is “Introduction to Functional Programming in F#“by Ian Russell which is a 10+ series of blog posts walking you through syntax etc whilst solving a business domain problem. It has been very important in my learning of F# so I can’t recommend it enough! I was also part of a .NET DDD/Event Sourcing Slack team that had a F# channel that I started to ask very noob questions in and luckily got a lot of help from. There’s lots of YouTube videos and Pluralsight videos out there, some which I have watched and learnt from.

As I’ve continued this journey over the last couple of months, I’ve made comments to others about F# and how things are done there and I’ve had in reply “oh, you’re becoming one of them”. I knew exactly what they meant too and I don’t think anyone can argue that F# does seem to have an air of elitism and/or segregation around it away from C# for example and so I did chuckle that people had made those comments. In fact in a recent F# conference Don Syme (F# language author) addressed this point and asked the community to tweet nice things, be positive, one negative tweet can undo 100 positive ones. As I reflect on F#’s perception in this regard it reminds me of stances I took when Nancy development was in full flow. As new things arrived in ASP.NET and discussions took place I often reacted with “Nancy has had that for ages”, “Wonder where the ASP.NET team got that idea” and it’s very easy to do when you have worked hard on things of your own or been a part of a smaller community where certain things have been the norm for a big fan-fair to come along from Microsoft to announce their new wonderful features have arrived. It grates somewhat and I think these reactions are quite visible amongst some F# people and to be honest I can understand where they are coming from.

That being said, I knew what I was getting into so I tried to walk gently and not go in guns blazing and was rewarded significantly. After joining the F# Software Foundation slack team and joining various channels I could see a large community of people discussing what they were working on, asking questions on how to do things and helping beginners without any ivory tower pointing and laughing. They were very welcoming and really helped me along my journey and answered all the noob questions I had for them without any hint of “christ, this guy is dumb” responses. I was jubilant that the perception that some may have, myself included had was incorrect. These people were very proud of what they were working on. From attending F# Conf, it was clear that Don is a well respected and clearly clever guy in this community but is trying to drive F# via the community. In fact the same day I came across TaskBuilder, a third party library that interop’s with .NET Tasks (F# had an async implementation in it before C# had async/await/Task) I found that F# is using this third party library’s code and design and porting it into F# itself and pointing back at the original author’s contributions and giving him the due respect he deserves. At that point in time with everything that I’ve discussed above I was in, this seemed like a good place to be. I’ve gone on to learn more and enjoy what I’ve found but also hit the usual learning curve you experience when coming across new things. You go from a state of “Ah, I get this, yay me!” to “WTAF is this doing, god I’m a dumbass, why don’t I understand it”.

The F# Tooling Gap

Now I’m not going to say F# is perfect and it’s the silver bullet you’ve been waiting for (because the last five silver bullets haven’t worked out as you thought they would) because coming from C# there are some issues that may annoy you and this is around tooling. I have tried various languages throughout my career but the one thing C# has done well compared to other languages is tooling. I develop software on MacOS (that might change to Linux soon) and to write code in F# you basically have two choices, VSCode or Jetbrains Rider. VSCode uses a plugin called Ionide and Rider also has a F# plugin. I know Rider well from C# and whilst I have fired up Ionide for some things I have decided to stick with Rider however things are not rosy. There are many features in Rider that you get for free with C# but don’t appear in F# plugins, yet! One example I first spotted was XML documentation. When starting out as a noobie, documentation is key however, when I was looking at Giraffe the XML docs didn’t work in Rider because the docs were written in Markdown which worked fine for Ionide so we instantly had a non standard approach. After speaking to Krzysztof Cieślak he said that early on he made the wrong decision in advocating Markdown and in fact Ionide does support the traditional XML documentation. Good stuff I thought, let me just take a look at Giraffe and see if I can swap markdown to XML. Well that was a bigger task than I had hoped but it needed to be done so people can benefit in both editors and one PR later it was done!

So I open up Rider to view my lovely new docs and facepalm, Rider doesn’t render XML docs properly for F#! Over to YouTrack I go and file an issue for Eugene Auduchinok who is the main man behind F# support in Rider.

Next up is intellisense, F# simply doesn’t have as much support as C#. As much as some see intellisense as a crutch I find it massively useful for learning and productivity. Let see an example, in C# if you have an argument that requires a Func or Action you can press Ctrl+Space and Rider will offer to create an inline implementation or create a method for you. It’s a simple example but this doesn’t exist in F# no matter what IDE you use. Over to YouTrack I went and I kept going back and I’ve probably become Eugene’s most favourite person to hate but I love the tooling you get in C# and would love to see that in F# to make the development experience better for everyone. Another example is analyzers. I chose Npgsql.Fsharp to do some coding against a database with and helpfully it has an analyzer to validate the sql you write, the types you use for parameters and many other things but this only works in VSCode and not Rider but on the flip side Rider has many of it’s own analyzers that won’t work in VSCode. Now I guess this isn’t a F# issue, more of an IDE issue but it’s just an interesting spot when coming to a new language how things aren’t always seamless. Another thing that I also rely on heavily is decompiled third party code or Sourcelink-ed code where you can debug the actual source code not a decompiled version. This seems to work in Rider but not in VSCode however, using the File Member navigation in Rider for downloaded source code doesn’t work. Suffice to say I have been bombarding YouTrack with lots of issues and have raised an issue for Ionide too and would encourage others to do the same so we can all benefit but tooling does seem to be an issue at present, not enough to make it unbearable and I guess a lot of the issues I log could be argued are cosmetic but who doesn’t like a bit of cosy fluffy IDE support!

My Future

I have so far enjoyed coding in F# and enjoyed reading other people’s code in F# and I look forward to where this path takes me. In fact I am happy to announce that as of July 1st 2020 I will be starting a new job at SoftwarePark initially working on a team writing F#! I am lucky to join this company as there are a few friends already working there and who I have worked with in the past but also I get to work alongside Ian Russell whose blog series I mentioned above helped me tremendously getting started in F#. SoftwarePark is a company based in Austria whose employees work remotely across Europe and share the same core beliefs I do about writing software and I very much look forward to this new journey working with them and the fine folks already employed there. However, please just pause, take a moment and spare a thought for Ian who will now have to put up with me 8 hours a day asking the most ridiculous questions!

Anyhow, there we have it. In summary:

• We need to monetise our work in .NET
• Develop platforms that allow projects to thrive.
• Prevent Microsoft from “adopting” OSS so much that they are the ones that make lots of money.
• C# has become a large bucket of syntax
• Goodbye NancyFX and hello F#!