Some believed it was: they argued all that was changed was the format of the project file and the drama associated with it was excessive. They also pointed out that all the goodness of
project.jsonwould be ported to the familiar yet different
*.csproj. I call this group the loyalists:
@palantirza @terrajobst @tourismgeek @aliostad I'm amazed that you picked a technology based on the format of the project file.— Isaac Abraham (@isaac_abraham) May 12, 2016
On the other hand, some were upset by the return of the
msbuildto the story of .NET development. This portion of the community were arguing that +15-year-old
msbuilddoes not have a place in the modern development. They have been celebrating death of this technology not knowing it was never really dead - I call them msbuild-antagnoists. The first group (loyalists), on the other hand, were flagging that the msbuild would be improved and the experience would be modernised.
That PR replacing MSBuild with Make doesn’t seem so foolish now does it?— Colin Scott (@AbstractCode) May 11, 2016
Now there were another group of people were frustrated that this decision had been made despite the community feedback and solely based on the feedback of “some customers” behind the closed doors. I call them OSS-apologetics and their main issue was the seemingly lack of weight of the community feedback when it comes to the internal decisions that Microsoft takes as a commercial enterprise - especially in the light of the fact that
project.jsonwas announced almost 2 years ago and it was very late to change it.
@terrajobst @tourismgeek @isaac_abraham @aliostad And there it is: yeah, it's not REALLY OSS, and the community doesn't matter.— Palantir (@palantirza) May 12, 2016
Now there were yet another group that had invested time and effort (==money?) in building projects and tooling (some of which commercial) and they felt that the rug has been pulled from underneath them and all those hours gone to waste - for the lack of a better phrase I call them loss-bearers. And they were even more upset to see that their loss was accounted as a learning process:
Obviously there is not a great answer for them but it is usually said that it is a very minor part of the whole community who have been living on the bleeding edge and knew it could be coming any minute, as mentioned on the stand-up:I always tell developers not to worry when their code gets thrown away. Learning is the most important thing.— David Fowler (@davidfowl) May 11, 2016
But I do not think any of the above captures the essence of what has been happening recently. I am on the belief that this decision along with the previous disrupting ones have been important and shrewd business decisions to save the day and contain losses for Mircosoft as a commercial platform - and no one can blame Microsoft for doing that.
I had warned times and times again that the huge amount of change in the API and tooling and no easy migration path will result in dividing the community into a niche progressive #DotNetCore minority and the mainstream commercial majority who would stay on .NET Fx and need years (not months) to move on to #DotNetCore - if at all. And this potentially will create a Python-vs-3-like divide in the community.
@jeremydmiller @Cranialstrain @demisbellot fragmentation (some staying with 4.5 for long time) and then demise of .Net as we know it.— Ali Kheyrollahi (@aliostad) July 27, 2015
The cross from the old .NET to the new #DotNetCore (seemingly similar on the surface yet wildly different at heart) would not be dissimilar to the cross between VB6 to .NET. And what makes it worse is that unlike then, there are many viable alternatives OSS stacks (back then there was only Java and C/C++). This could have meant that the mainstream majority might in fact decide to try an altogether different platform.
So Microsoft as a business entity had to step in and albeit late, fix the few yet key mistakes made at the start and alongside the project during the last 2 years:
- ASP.NET team to make platform/language decisions and implement features with clever tricks rather the .NET Fx baking such features in the framework itself. An example was Assembly Neutral Interfaces.
- Ignoring the importance upgrade path for the existing projects and customers
- Inconsistent, confusing and ever changing layering of the stack
- Poor and conflicting scheduling messages
- Using Silverlight’s CoreCLR for ASP.NET resulting in dichotomy of the runtime, something that as far as I know has no parallel in any other language/platform. In the most recent slides I do not see CoreCLR being mentioned anymore yet it might be there. If it is, it will stay a technical debt to be paid later.
- Perhaps had ASP.NET team not pushed the envelope this far by single-handedly crusading to bring modern ideas and courageous undertakings such as cross-platform, we would be having .NET 5 now instead of #DotNetCore.
- By carrying baggage from the past (msbuild), Microsoft is extending the lifespan its stacks which in the short term will be beneficial to the corporate but since it is not a clean break, in the long term results in dispersion of the community and a need for another redeux.