May 26, 2016

.NET Core is Boiling the Ocean

Do they know what the hell they're doing?

I get asked regularly in the Akka.NET Gitter Chat and elsewhere about “when will Akka.NET support .NET Core?”

TL;DR; .NET Core

Part of the issue I’ll address here is that .NET Core means different things to different people and there hasn’t been clear messaging on that from Microsoft as far as I know, so I’ll summarize how it’s relevant to me, Petabridge, and Akka.NET.

.NET Core is about decoupling .NET from Windows. Allowing it to run in non-Windows environments without having to install a giant 400mb set of binaries.

This will allow .NET to run in containers on Linux and lots of other places it can’t today and presents a very exciting opportunity for those of us in the server-side .NET development space to start taking advantage of modern DevOps and deployment tools.

Because let’s face it: deployment tooling built specifically for Windows is complete and utter dogshit compared to the what’s available everywhere else. Even the Windows versions of tools like Chef are pitiful imitations of the real thing. Windows Server is the red headed step child of server operating systems and even .NET developers are increasingly united in resenting its necessity in our day-to-day lives. .NET Core should liberate us from that.

New Week, New Story

My answer to this question for the better part of a year has been “whenever .NET Core is stable enough for us to use.” I had originally imagined that .NET Core would be “released” in a stable form this year, 2016.

Now I no longer have any certainty with anything in regard to .NET Core, because the roadmap has been changing rapidly.

Two weeks ago the .NET Core team abandoned the new project.json format for managing projects / dependencies and are reverting back to the MSBuild .csproj format, for reasons I understand and am ultimately sympathetic to.

I hated the thought of having to port the 80-something .csproj files in the core Akka.NET repo to a new format, because it’s trivial tedious bullshit that offers no upside and a lot of downside for our development and release processes. So kudos for that.

But in a public meeting with the community yesterday, the following bombs were dropped:

Update: Miguel de Icaza pointed out that WebAssembly support will actually be for Mono and not .NET Core, which leaves me with even more questions. So Mono is going to still be a thing? Are there going to be competing efforts between .NET Core and Mono for x-plat .NET developer support? Who knows? Miguel seems confident that their team’s communication has been sufficiently clear on this point. I disagree.

You can read the full Slack transcript on that thread, but the summary made by Jose Fajardo is excellent.

After going through this a second time, I’m left asking…. “so what do my projects and my business need to be doing with regard to .NET Core today?”

At this rate I’m fairly confident that even the .NET Core team themselves would answer with:

¯_(ツ)_/¯

Ship Dates and Boiling the Ocean

I’m left with the impression that .NET Core is trying to do everything at once: static linking, new tooling, support for 3D games, web applications, cross-platform desktop applications, browser-based apps, and anything else that could be aptly labeled under the masthead of “panacea for .NET developers.”

There’s a term for this, “boiling the ocean,” and ironically Immo Landwerth, one of the PMs in charge of .NET Core, claims this is precisely what his team is trying to avoid:

Immo Landwerth on not boiling the ocean

Link to the original Tweet

Upon reading yesterday’s announcements, I’m left with the impression that the parts of .NET that aren’t being changed in .NET Core are in the minority.

Here’s the thing: the vision that Miguel and Immo paint for .NET’s role in the future is compelling. .NET everywhere?! YESSSSSSSSSSSS!

But you know what I and every other .NET developer have to deal with outside of the bubble in Redmond? Setting ship dates and expectations with our own users, management, and stakeholders.

The .NET Core team has done a fucking awful job at everything in regard to expectations management around .NET Core. It would be a disservice to amateurs to call their PR efforts “amateurish;” manic and frantic would be better terms.

As an ex-Microsoft employee I hate myself for saying this, but Immo and friends should consider going through Microsoft PR before they make any promises with end-users. They’ve proven to be too wildly inconsistent and too ready to make promises about software that isn’t on terra firma yet. Look at the damage Microsoft can do when they fuck up expectations with .NET developers.

.NET developers are betting their careers and livelihoods on .NET Core, and I genuinely don’t see Scott Hanselman, Damian Edwards, David Fowl, Immo Landwerth, Miguel de Icaza, or any other public-facing figure in the .NET Core efforts genuinely taking into the account the real impact resetting expectations with .NET developers can have in terms of lost business, missed opportunities, or possibly even getting fired. If you’re of the opinion that I’m over-blowing the impact of honoring expectations can have on something as big as platform choice, then you should read the post I linked in the previous paragraph. People lose their jobs and lose customers over less.

Case in point: after yesterday’s announcements I’m wondering if the .NET Core roadmap is even valid anymore. We had talked about starting work on Akka.NET for .NET Core in 2016. As of today, I’m thinking that .NET Core probably won’t be ready until much later than that.

And here’s where the rubber meets the road: if I start promising tools and features to end-users based on what’s been promised by the .NET Core team and .NET Core changes direction and pulls the rug out from under me, then I effectively screw up my users’ and customers’ timelines.

I can’t have that, and I’m fortunate enough to be in a position where I can and am choosing not to. I’m sticking with .NET 4.5.2 until .NET Core is solid.

Not everyone else is - what about the .NET developers who have to explain to management that they can’t ship a .NET app on Linux until next year, and all of the effort they spent on RC1 is going down the shitter? “Oh well, they shouldn’t have used an RC - screw them?”

Update: this is from the Event Store team:

@Aaronontheweb great summary. @jageall has now ported @GetEventStore three times to different core CLRs that will never ship. Screw that.
— James Nugent (@jen20) May 26, 2016

Suggestions

I have a lot of sympathy for David and company - I know it can be tough working on such an important project out in public. So here’s what I would suggest:

Stop. Stop boiling the Ocean. WebAssembly, Unity Support - that’s all great. And they can wait. WebAssembly isn’t even supported by any browsers yet and Unity3D already works cross platform. Meanwhile, your users are overwhelmingly ASP.NET developers and they’re stuck with Windows Server.
Don’t mention anything not on the current .NET Core roadmap. Seriously, don’t even bring up WebAssembly or anything else until you’ve shipped something on this roadmap first. Everything that’s happened in the past two weeks has totally undermined the confidence I had in .NET Core’s near-term arrival, and I’m not alone in that camp. I’m wondering if this roadmap is even accurate anymore.
Get PR training. Using the term “pay to play” to describe the cost of running extra NuGet packages shipping as part of .NET Core is not going to be interpreted generously by anyone who’s done business with Microsoft before. Have some self-awareness, and in lieu of that get a PR person involved. Obviously, extra NuGet packages that are included in an application will incur extra disk / memory / CPU overhead - you don’t need to appropriate a term that means “money changing hands” to explain this.

I love the direction .NET is going in and I’m genuinely excited for it, but the .NET Core team desperately needs some finesse when it comes to communicating with end-users. I’ve struggled with this issue myself - I’ve missed our own roadmap dates and deadlines and been called to task for it. It’s hard.

But this is Microsoft - they have hundreds of thousands of developers who’ve staked their careers on the future of .NET. They can and should do better.

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..

Follow @Aaronontheweb