A recent flare-up of chronic drama in .NET OSS has got me re-thinking the prevailing diagnosis & cure for our ecosystem woes. For context, the prevailing diagnosis & suggested cure goes something like this:

Anytime Microsoft introduces common abstractions / libraries that overlap with current OSS offerings, .NET developers will abandon relevant OSS libraries en-mass to adopt Microsoft’s “lowest common denominator” offerings. To avoid cannibalizing the ecosystem, Microsoft must abstain from participating in any areas occupied by existing OSS libraries.

This worldview is almost canon in some corners of the ecoystem. No matter how much Microsoft’s engineers plead their innocence or try to tiptoe around old wounds, some folks just never seem to put the pitchforks down. This is disappointing because these corners of the ecosystem (heavily populated by long time oss authors & other contributors) are my favorite parts. And also because i’ve come to believe this worldview is likely the wrong one.

It’s important to note that the observed symptoms are mostly accurate. Microsoft’s releases do tend to snuff out relevant OSS libraries (RIP all the awesome DI containers). And over the years, some of Microsoft’s responses to valid OSS author concerns have been less than stellar.

Flawed Diagnosis

At the core of the prevailing diagnosis is a belief that .NET developers adopt Microsoft libraries (instead of OSS ones) for irrational reasons such as fear, a lack of sophistication or a mistaken belief in the quality of Microsoft’s efforts. Even worse, some proponents of this diagnosis ascribe no motives at all to this behavior, all the while insisting it will occur, as if .NET developers writ large are some sort of submissive horde of lemmings.

Now, I’m sure some .NET developers choose Microsoft’s libraries for the clearly bad reasons and non-reasons above, but believing that this is the mainstream opinion among .NET developers seems both uncharitable and simplistic.

What the prevailing diagnosis fails to explain is why. Why do .NET developers make the choices they do? The diagnosis fails to consider any systemic, structural or rational reasons for the choices of millions of .NET developers. It encourages those who believe it to see themselves as a much smaller, more sophisticated and highly beset upon cohort of .NET developers who must spring into action to defend the fragile ecosystem from Microsoft’s machinations. It’s an unfortunate framing of the issues that has mired some of the smartest & most passionate contributors to the ecosystem in recurring dust-ups for a decade.

We have to find a way to get past this framing. There are likely systemic, structural & social factors that contribute to the behaviors we see in the ecosystem and the sooner we start looking for other answers, the better.

Ineffective Cure

My gripe with the recommended cure (that Microsoft abstain) is simple: it has not worked. A decade later, Microsoft’s library releases have grown inexorable & even more OSS libraries have faded away while wide swathes of .NET developers (rightly) cheer on general progress in the ecosystem. Things haven’t even worked out when Microsoft has attempted to leave gaps for OSS libraries to fill (IdentityServer) or when it tried to support OSS (.NET Foundation).

And it kind of makes sense that this cure doesn’t work. Dominant participants in ecosystems don’t just stop participating because smaller participants ask them to. Dominant participants leverage their dominance in business, in the arts, in politics and yes, in open source. Multi-trillion dollar companies, willingly or unwillingly, knowingly or unknowingly will have an outsize impact on any ecosystems they participate in. And not participating is not an option for them. We need to find solutions that aren’t contrary to social & corporate history.

This is bad medicine. Not only is the cure ineffective, it comes with side effects: a blind spot. This diagnosis & cure have everything you need for a compelling distraction: an authoritarian empire, a small group of democracy loving rebels, conflicts over idealogy & governance etc. We all love that movie, but this isn’t the only way to frame the issues.

Thought Experiments

Much to my dissatisfaction, I don’t have any easy answers here. What I do have is growing conviction that there are more answers out there. Here are some things I am mulling over to get past the current frame:

  • What are some potential, rational reasons .NET developers choose Microsoft libraries over OSS?
  • How does commoditization affect OSS projects? What happens to commoditized products elsewhere?
  • Is the .NET ecosystem structurally different from other tech ecosystems?
  • Are .NET developers truly more irrational than other developers?
  • How do systems with dominate participants encourage innovation & disruption?
  • How can we blunt or diffuse platform power when it is overly concentrated in some participants?
  • In what ways are OSS projects different in .NET versus other tech ecosystems?
  • In what ways are OSS maintainers different in .NET versus other tech ecosystems?
  • What can we do to get wider OSS adoption in enterprises tha tuse .NET?
  • How can we turn the widespread usage of .NET in the enterprise into an advantage for the whole ecosystem?
  • Does .NET need more features in the box ala Rails & Laravel or does it need fewer?
  • How can .NET OSS projects that want to monetize do so more effectively?
  • How can we improve discovery of new .NET OSS projects?
  • How can we get more opinions from the 90+% of .NET developers who don’t blog or tweet or maintain OSS libraries?
  • How do Microsoft’s incentives in .NET OSS negatively or positively affect the ecosystem? How can we better align those incentives?
  • What advantages does the .NET ecosystem have over other ecosystems?
  • How can we collectively improve our messaging to developers outside of the .NET ecosystem?