gortok
commented
3 years ago First off, I want to say that I'm gratified to see this document meet the light of day. There are lots of corporate environments where the mere existence of that document would be threatening, and I'm glad to see that isn't the case at Microsoft.
I'm also glad to see that people at Microsoft recognizes that the number one problem facing a robust .NET eco-system is Microsoft themselves.
This is not a value judgment. Lots of companies have embraced a closed-ecosystem model and it has done well for them. Apple, to name a very large example. Adobe has also done this, and failed in quite a few different ways; with ColdFusion and ActionScript, most notably, and Adobe Flash not far behind.
Developer ecosystems need the same three things that a fire needs:
- Oxygen (the ability to flourish)
- Heat (momentum)
- Fuel (contributors)
If you take away any one of those; the eco-system starts to falter; and before long, it will fail.
But let's take a step back and describe what I mean when I say a "robust .NET eco-system".
An eco-system is robust when it is self-sustaining; when it is viable for new life; and when and when there is balance to the forces within it. (Not being an ecologist I'm probably missing some key terminology; but for our purposes this will do).
For .NET, this means that there are competing options for potential adopters to chose (whether those adopters are enterprises, SMBs, or individual developers) the libraries and frameworks are able to sustain themselves; whether that's through Open Source and its succession model; or a commercial model, or a combination of the two (I maintain that 'sponsorship' by a singular corporate entity is not 'self-sustaining'), and the general attitude of the community contributes to growth instead of decline.
There are commercial .NET libraries and frameworks; though far less on the framework side than the library side. Open source wise, it is common for Microsoft (by their own admission) to rewrite instead of contribute. The rewrite effectively becomes a 'replace' once the library is released, as is the case with Newtonsoft.Json.
Newtonsoft.Json is a good representative example of an issue with taking the oxygen out of the room. James Newton-King started at Microsoft in March of 2018. In October of 2018, System.Text.Json (hereafter STJ) was announced. By November of 2019, the latest (and possibly last) release of NewtonSoft.Json (NJ) was published, and there haven't been any releases since then, and only 9 commits.
I think it's wonderful that JNK works at Microsoft and that Microsoft hired him. I also think it's wonderful that System.Text.Json exists; but the dual effect of hiring JNK and announcing STJ caused an undesirable side effect: the appearance that NJ is done.
Now, that may be true; but commercial entities do not like it when software has no momentum, because that means they aren't likely to get any support; but since STJ is new and shiny and from Microsoft, they'll just ditch NJ for STJ. This may or may not be a problem; but what it will do is lend further credence to the "Embrace Extend Extinguish" perception Microsoft has, even if it's not warranted.
There are two other ways to handle this that build momentum in the .NET ecosystem; the path taken does not build momentum or give the ecosystem the ability to flourish.
- Acquire Newtonsoft.Json from JNK and make it available under the .NET foundation
- JNK passes on the torch to another maintainer
Given the lack of momentum on NJ, I wouldn't recommend that any developer or business adopt it. (I'm ignoring turning it into a commercial product; since this isn't the place for that discussion; but there are other avenues open)
Some teams from Microsoft may rightfully claim that they do not have the ability to acquire software; and you're right, you probably don't -- but people outside of Microsoft don't make the distinction between the teams at Microsoft; and that means that someone in Microsoft needs to be at a high enough level to sign off on an acquisition and to 'mind the store' when it comes to being empowered to 'do the right thing' to maintain a healthy eco-system. If someone at Microsoft doesn't already have that job and the requisite budget authority, they should -- especially since it's a 1.5 Trillion dollar company.
There are other examples, of course; like AppGet/Winget debacle, or further back OpenWrap and Nuget clashed. And there are likely others I've forgotten about. I'm still bummed out about XNA though, and glad Monogame picked it up.
In order for there to be a healthy eco-system, Microsoft needs to add to the momentum, and not use its status to suck the oxygen out of the room. Not every problem needs to be solved by Microsoft; and Microsoft solving every problem instead of contributing to solutions that already solve that problem hurts the community and hurts an already fragile ecosystem.
This may mean that Microsoft points its customers to third party solutions; or that Microsoft acquires those third party solutions instead of competing at the cost of free; which sends a giant signal that says "Don't develop anything that Microsoft has the manpower and time to write themselves", which makes it difficult for both open source and commercial software to flourish on .NET.
Bottom line: Whatever actions you take as "Microsoft" will either improve the eco-system or hurt it. Remember the three things an eco-system needs, and act accordingly.
Aaronontheweb
ericsampson
cartermp
NickCraver
sbwalker
RLittlesII
Some personal thoughts/feedback on the initial Growing the .NET Ecosystem document...
Observation: The document appears to have a high level hypothesis and a number of supporting arguments…
Hypothesis: Customers demand features from Microsoft because they do not trust third party solutions. This results in negative consequences to the .NET ecosystem.
Supporting Arguments ( ie. reasons why customers do not trust third party solutions ):
Some of the topics above do resonate with me; however, I do question if the hypothesis is in fact the root problem. I question it because there is plenty of evidence from the past 2 decades that customers do trust third party solutions.
So if customers do trust third party solutions, then what is hampering the growth and innovation in the third party .NET ecosystem? I believe the document touches on some of these issues already – especially in the “Critical opinions on the Microsoft OSS ecosystem” section. As an independent software developer who created a commercial open source company, I am intimately familiar with some of these challenges. I personally believe the bigger issue is not a lack of trust by customers of third party solutions, but a lack of trust of Microsoft by the potential creators of third party solutions in the ecosystem. The fear of Microsoft “eating its own young”, employing the 3E strategy ( Embrace, Extend, Extinguish ), and creating downward pricing pressure in the market are all barriers to entry for the third party ecosystem.
The other problem when it comes to trust that I have seen is Microsoft’s unwillingness to trust third party solutions and make official endorsements or recommendations to customers. Perhaps this is for reasons of legal liability. And some of the arguments in this document seem to be solutions specifically designed to try and solve this problem. Improving product quality, providing support, ensuring provenance between source code and binary, and ensuring cross platform support all appear to be items that are more important for Microsoft to reduce risk than they are for actual customers. I am sure customers would appreciate these items to some degree as well, but third party solution maintainers will view these as heavy handed requirements being imposed upon them. This was partly the problem with the original Maturity Ladder as well… and anything which appears to reduce freedom is not going to be well accepted.
The following diagram attempts to explain the challenges I outlined above. Each arrow represents a trust relationship and the color signifies its strength ( ie. green = strong, yellow = neutral, red = weak ). And like I said earlier, this is my personal opinion on the current state of .NET. Other folks will certainly have different perspectives. This is exactly why collaboration will be crucial in solving some of these challenges.