Microsoft’s little decision is a big mistake

Anyone that knows me knows that I have been a supporter and adopter of Microsoft technologies for decades.  I prefer not to use the word “fan”, because I’m an active participant, not a passive onlooker.  I’ve attended almost every Microsoft developer conference since 1993, back when it was called PDC.  I’ve built small and large software on Microsoft technologies my entire career.  I built a framework on top of Microsoft VBA.  I started a company with a former Microsoft employee.  I’ve contributed to Open Source Microsoft projects.  I’ve built an e-commerce platform on .NET and IIS that has transacted over $1B and has endured the tests of time.  My license plate used to be CEESHRP!  My ties to Microsoft have been a big part of my career path.  I understand how Microsoft works, and I understand what .NET is and what it’s not.  I’ve heard from countless Microsoft naysayers, and defended Microsoft for decades.  It’s been a tireless fight – and I’m not ready to give it up.

.NET is often misunderstood.  It’s doesn’t only run with “expensive Windows licensing” and it is definitely not a big and slow monolith.  It is a mature framework that runs on the big 3 (Windows, OS X, Linux) operating systems and is behind the fantastic cross-platform mobile app product, Xamarin.  .NET has been cross-platorm for a while, and with the efforts of Mono, even runs on iOS and Android.  .NET is indeed portable.

And recently, Microsoft did something really bold – they decided to open source .NET.  From its mature and reliable lineage, .NET Core was born.  Finally, the .NET Framework will be truly native, truly open source.  The community can contribute to it and make it even better than it already is.  This was a big move, a big announcement, and part of the “new Microsoft” that new CEO Satya Nadella has been building.  The Microsoft developer community was buzzing with excitement over this.  The rest of the developer community – a bit skeptical.  After decades of closed source, these transitions take time.  They don’t happen overnight.  This was the beginning of something really, really right.

Flash forward from the announcement to today, about 18 months later.  .NET Core is turning out to be AWESOME.  I ported a few of my projects to RC2 easily, and one of the best parts about the experience was this very simple, project.json file that is at the root directory of every project.  This file basically tells .NET Core which dependencies to include and how to output the result of a compile.  It’s simple, it’s easy to read, and it’s aligned with the way many, many open source projects work.  Open Source developers are used to this – a product, and a config file.  Config, run, modify config, run again.  Get it right, tweak, tune, rinse, test, push, deploy – REPEAT.  This is the way we work.

Microsoft built this cool command line interface for the .NET Core Framework – the CLI.  It’s what makes .NET Core as simple as:


$ dotnet new
$ dotnet restore
$ dotnet run

These commands use the project.json file and figure out what to do with code. What to do with all the C# and F# files that make up your project.  Simple, elegant, and easy to understand and read.  Everyone working with .NET Core has gotten used to it.  It’s part of what makes .NET Core the “new Microsoft”.  I was planning on blogging and extolling the virtues of .NET Core and how fun it was.  But then something disappointing happened…

This week, I saw a tweet announcing a new blog post from the .NET Team, and was excited to see what’s new.

Changes to project.jsonhttps://t.co/Lytqwa7ID4

— .NET Team (@dotnet) May 23, 2016

I thought, “Uh, what’s this…?”. In reading this post, I had to consider for a second if this was April 1st and they were joking.  I wish it was.  So now, instead of doing a deep-dive on .NET Core goodness, I ask Microsoft…

Dear Microsoft,

This is it.  This is your chance to go head-to-head with Node.js and all the developers using Javascript and cobbling together libraries.  This is your chance to grow .NET into an amazing cross-platform, open ecosystem.  This is the opportunity, right now, with .NET Core to build something the community will get behind.  This is your chance for a new generation of programmers to be exposed to all the amazing ideas and methodologies you’ve spent decades building.  It’s this.  It’s this simple, little thing, this ONE file, this root of the beginnings of an idea that often starts with “Hello” and ends with “World”.  It’s the thing that keeps it simple – like Go, which doesn’t even require a project file at all.

This decision you announced this week will be perceived as going back to unreadable XML .csproj throws the simplicity out the proverbial window, and will ruin all that you have built with the tooling around .NET Core.  It won’t kill it, but it will severely limit it.  It will turn people off and they will miss out.  Tooling matters – a lot.  I imagine that you felt the need to do this because to support complicated projects, the project.json structure would handcuff you.  Maybe that’s true, or maybe it’s not, but either way, I see 4 solutions:

Option 1: Keep project.json, work around the complex projects, and make it work.  Simple, or complex, depending on the size of the project.  One file.

Option 2: Support BOTH project.json and myproject.csproj, and if both exist for the same project, display warnings or errors, and/or have different output assembly root targets for each project type.

Option 3: Stick to this decision to abandon project.json, and watch .NET Core grow slowwwwwly, and watch new frameworks rise up and pass you.

Option 4: Get Forked.  The community outside Microsoft decides that this issue is forkworthy, forks the CLI, and preserves what has been built so far for project.json while keeping up with the rest of the runtime changes.

Option 3 is the beginning of the end.  You may not see it now, but it will hurt you long-term.  It will absolutely fuel the flames of the bad stigma Microsoft has in the open source community.
Option 4 is a question of Why?  Why have two factions with different goals?  That didn’t work out for io.js and Node.js, and it won’t work here either.  It will spark mistrust, resentment, and the product will suffer.  I really hope this doesn’t happen.

I hope you decide to do the right thing and re-think this.  Your long-term respect, adoption, and company growth are at stake.  It may seem like a small decision now, but it’s these small decisions that have large impact.  Look back on your own incredible history.  Look within and you’ll find the answer right in front of you.

Sincerely,

Brett

This tweet should not exist.  I hope they make it right.