January 23, 2020

The Next Decade of .NET Open Source

Why the recent pessimism about .NET's future is totally misplaced

Over the past week there’s been a ton of chatter about the state of the .NET ecosystem and, more specifically, as to whether or not its OSS ecosystem is healthy and sustainable over the long term.

I won’t bother with the details, but the substantive criticisms amount to:

  1. If you build a popular OSS technology in .NET Microsoft will simply cannibalize it and roll it into a 1st party feature (i.e. Entity Framework cannibalizing NHibernate, built-in DI in ASP.NET Core, etc;)
  2. .NET users are still overwhelmingly Microsoft-centric - i.e. if Microsoft told its users to store all of their passwords in plain text at least 30% of them would blindly do it because Microsoft said so without considering any second opinions;
  3. The .NET ecosystem doesn’t built anything “cool” - there’s no innovation here and thus no real way to attract fresh ideas and younger talent to the ecosystem; and
  4. There’s no way to build an OSS business in .NET.

On this blog I’ve loudly voiced my concerns about this viability of .NET as an ecosystem over the years - and here’s how that position has evolved over time (take note of the dates and titles):

Date Blog Post
July 3, 2014 “The Profound Weakness of the .NET OSS Ecosystem”
May 26, 2016 ”.NET Core is Boiling the Ocean”
May 13, 2017 ”.NET Core is Probably Fine”
June 1, 2017 “The Coming .NET Renaissance”

Notice the trend from negative to positive.

That’s because the .NET ecosystem has changed in the following ways, many of which were unthinkable in 2014:

  1. .NET and C# are now the lingua franca video game development technologies thanks to the efforts of Unity3D;
  2. Visual Studio, SQL Server, and many other proprietary Microsoft technologies are now cross-platform rather than Windows-only;
  3. .NET is now truly a cross-platform development environment as a result of .NET Core;
  4. Microsoft now releases updates to its core runtime and platform technologies (.NET Core, ASP.NET, etc) at regular, frequent intervals rather than its historical 2-3 year release cycles;
  5. .NET Core is now capable of performing as an infrastructure development framework, rather than just an application development framework, thanks to the renewed focus on performance (i.e. see “ASP.NET Core: Saturating 10GbE at 7+ million request/s” from a year ago);
  6. The rate of innovation with C# itself has increased - from roughly one release every 3 years to 5 releases in the past two years;
  7. And most importantly, .NET developers consuming third party OSS is now routine, not the extraordinary act of risk-taking / deviating from blessed Microsoft heresy that it once was.

If you want to take these improvements in the .NET ecosystem for granted and fart out snarky screeds on Twitter, good for you, I guess.

Room for Improvement

There’s still a lot of room for improvement in the .NET ecosystem, to be sure.

Here, as I see it, are major outstanding issues facing our community in order of importance:

End-User Adoption is Still “Redmond by Default”

.NET users need to culturally normalize the idea of adopting non-Microsoft .NET solutions when those third party technologies are better on the merits.

Some examples:

The status quo is still very much “you can’t get fired if you pick Microsoft” and this results in a dearth of idea and supplier diversity in the ecosystem. It’s one of the reasons why .NET was an intellectual ghetto back in 2014 - and it will turn into one again if end-users don’t change their attitudes.

Notice I’ve been clear about picking third party alternatives when they are better for your use case than Microsoft’s. That’s the only way this can work - non-Microsoft OSS publishers have to win on the merits of their output and appeal to the self-interest of the users.

This also means that .NET OSS publishers have to follow professional product and project management standards - you don’t get to release breaking changes every month and dismiss subsequent user complaints with “well, I use SemVer so you should have known!” The idea behind the .NET Foundation Maturity Ladder (well intentioned but flawed) proposal was to show non-Microsoft OSS projects what the best practices are to help encourage and foster wide adoption.

Third party .NET projects would be wise to start following suit because ultimately this end-user cultural problem is really about risk management, not technology choice. Companies stick to Microsoft technologies not because they’re good but because they’re safe:

If you want to see third party technology stand on its own two legs in the .NET ecosystem, that is the quality standard you have to meet - and if your project competes with Microsoft that’s the quality standard you have to surpass. Throwing a project up on Github with a default README ain’t gonna cut it - better start booking up on DocFx and API Approvals.

Pervasive “Not Invented Here” Culture at Microsoft

Microsoft contributes to ecosystem issues through their own product development and evangelism activities, but they’ve tried to speak to those issues through initiatives like the aforementioned .NET Foundation Maturity Ladder.

I say this as an ex-Microsoft employee, a long time Microsoft fan, and a heavy participant in the .NET OSS ecosystem: Microsoft’s product culture mandates they control everything down the stack. They’re the most risk averse company of all in the entire ecosystem, when it comes to considering third party technologies, and they will only deviate from that strategy when they realize they’re playing from behind.

Microsoft’s “Not Invented Here” culture is so strong that other product groups within Microsoft may not adopt technologies produced by a different internal group.

And thus, we’re left with an original pre-Satya criticism of Microsoft that has only become worse as a result their rapid release, OSS approach to .NET: anything that becomes popular in the .NET ecosystem will, eventually, be offered as a first party option by Microsoft if it addresses a big enough audience.

I came up with a list of specific examples, but opted to leave them off of this post as it will inevitably lead to pigeon holing and finger pointing.

So instead I will demonstrate the problem with a theoretical question instead:

If I developed and OSSed under a commercially-friendly license a faster, low-level networking platform than ASP.NET’s Project Bedrock, let’s call it “Project X” with a 10 year commercial commitment from my company to support it, what’s most likely to happen? Pick one.

  1. Project X’s architecture and changes over time would be “introduced” into Project Bedrock eventually;
  2. ASP.NET Core would take a dependency on Project X like any other user; or
  3. ASP.NET Core would take a dependency on Project X if and only if they could become a co-contributor to the repository,

If you picked any option other than 1, congratulations - I would love to visit your reality sometime. I expect anyone, including people who actively work at Microsoft, to pick that option overwhelmingly. Why? Because it gives Microsoft what it ultimately wants: total control and freedom over the release cycle of their products. Having to wait for a third party like Project X to push an update so they can, in turn update their projects like any other normal user, probably isn’t be something they can accept no matter how high the quality.

And thus we have the NIH cycle, born from a very good intention to deliver really high quality tools to their users, but inevitably resulting in the unintentional destruction of ecosystem diversity along the way.

There are only two ways this will change:

  1. Microsoft decides that maintaining a healthy third party OSS ecosystem is in its own best interests and decides to change its practices to support that - but in order for it to do that, there needs to be some cultural changes in the way .NET OSS is developed outside of Redmond.
  2. Or users can address the first item on this list and push for those third party solutions to be supported over Microsoft’s own because the third party ones are, in some way, objectively better for significant cohorts of users.

Lack of Inspiring, Well-Maintained Third Party OSS

Of all of the criticisms leveled at the .NET ecosystem, this is the weakest argument - because .NET Core is a new phenomenon and it will take ~5-6 years for its effects to seep into the output of the greater OSS ecosystem.

.NET Core is now capable of delivering infrastructure-grade OSS projects, which are the type of notable projects that inspire a lot of confidence in the ecosystem’s health as a whole. Think of Apache Foundation or Cloud Native Computing Foundation-level projects. But these projects are born out of necessity, not someone’s hobby. They take time to develop and there has to be a compelling reason to develop them in .NET. Until recently with the major performance gains and cross-platform capabilities made possible in .NET Core those reasons were largely lacking. This is now changing.

Right now, you can look at the landscape of .NET OSS and see there are infrastructure projects that are alive and healthy: web frameworks, distributed actor frameworks, socket server libraries, messaging systems, databases, and even cryptocurrencies like Neo. But we pale in comparison to ecosystems like Go, Java, and so on. That will change with time.

Sustainability

Every ecosystem deals with this issue - how to make the OSS ecosystem “sustainable.” If you’ll pardon my brevity here, this is a developer’s way of asking “how can I get paid for the work I do on OSS so I don’t have to donate free hours to it all the time?” without trying to sound like a capitalist.

I’m going to address this in a subsequent post, having done this successfully for five years and counting, so please subscribe.

Update: this post is now live here: “How to Build Sustainable Open Source Software Projects.”

Outlook

But one point that bears repeating from earlier: the way .NET developers manage their OSS projects needs to professionalize in order for the ecosystem to shift towards something more open, creative, and professional.

As I said earlier:

This also means that .NET OSS publishers have to follow professional product and project management standards - you don’t get to release breaking changes every month and dismiss subsequent user complaints with “well, I use SemVer so you should have known!”

If there’s a category of Twitter theater I can do without, it’s other .NET OSS maintainers bitching about Microsoft or how bad the ecosystem is. You’re the biggest part of the problem.

If third party developers in the ecosystem deliver sustainable, professional-grade OSS over the next few years the cultural issues with the ecosystem will head on a course to resolve themselves.

Microsoft is doing a lot of the work of filling in the gaps in the ecosystem right now because many of the third party technologies aren’t actively maintained or supported by a reliable party. The NIH criticisms are still valid, because they will still do that in cases where there are viable third party technologies, but not for all of them.

I’m very optimistic about the next 10 years of .NET because things are already trending in the right direction and at a much faster pace than they have, historically.

As Scott Hanselman showed off on his blog recently, we are going to have .NET running EVERYWHERE before we know it. This means there will be lots of creative, fun, and profitable opportunities for .NET developers to innovate to grow with the same communities they’ve been working within for years… And maybe we’ll all find some new ones too.

So, if you want to pitch in and help create the type of .NET ecosystem you want to see.. Create a Github account, learn how to use it with professional best practices, and find a way to make existing tools better for you or create some new ones.

Discussion, links, and tweets

I'm the CTO and founder of Petabridge, where I'm making distributed programming for .NET developers easy by working on Akka.NET, Phobos, and more..