> 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.
.NET Core exists side-by-side the full .NET Framework. You can use the .NET Framework now, and into the future. Newer versions of ASP.NET and Entity Framework have adopted the "Core" moniker but they run on both platforms.
For example, Microsoft.EntityFrameworkCore [1] ships the necessary bits for:
* .NETFramework 4.5.1 (full "Desktop" framework)
* .NETCore 5.0 and .NETStandard 1.3 (the "Core" framework)
If you plan your timelines around pre-release software (that's what .NET Core is) then Microsoft is not to blame.
For what it's worth, I'm not a fan of what happened with Release Candidate 1 [2] but I would NEVER place a dependency on pre-production software coming out of Microsoft.
OP here. I'll re-paste what I wrote in reply to a similar comment on Reddit.
When I wrote that, I was thinking like a business owner whose technology is rooted in .NET. Not like a developer working on a single project. I invite you to step into my shoes for a moment.
I expect that .NET Core (or any platform, really) will be able to deliver $X worth of value to my business in N months and set business plans accordingly. I invest my team's time, some capital, and maybe other resources like hardware into pursuing the value on that platform. Z months in, where Z < N, all of those plans are upset by a sudden direction change. Now I have to make a choice: my previous costs are all sunk, but any future investments I make into .NET Core - are they also at risk of being sunk also? Should I keep investing into .NET Core? Am I risking some portion of my business' future profits by not pursuing something else instead?
I've, correctly, judged .NET Core to be a poor investment of my business' resources right now because the risk of my plans around it being upset is not just high, but higher than expected. Releasing RC2 and then reneging on it is pretty exceptional.
You as an individual developer are effectively making the same choice that I am as a business owner when you invest your time and energy into .NET. Could that time be better spent elsewhere in a way that would increase your value?
Does this explanation help explain my reasoning at all? Please let me know.
Just because the technology is early doesn't mean it's a bad idea to invest in it if you think the impact for your business will be huge. That's just another risk you have to take into account and quantify. For what my company does specifically .NET Core could be transformational for us, so I'm quite excited for a future where I can rely on it. But my confidence that we'll be there sooner rather than later has been shaken.
And no, the pre-release line doesn't really apply here. When you release RC2 with a Golive license and publicly state "you can be confident to use it in Production and we will support you" only to backtrack on it (days, weeks?) later then that's on Microsoft.
I think your comment is confusing RC1 with RC2. RC1 was a debacle. And their go live license was not particularly generous [1]:
> Starting with the RC1, we are including a “Go Live” license ... [the] duration of this license for the RC1 last until the next release candidate or the completed release of ASP.NET 5 (called an RTM release) that is currently scheduled for Q1 2016.
So if you did choose to use RC1 in a production environment, you'd be unsupported as soon as the next RC or RTM occurred. You'd need to spend time upgrading your projects. Which means you're taking a gamble on the size of changes between RC1 and the next release.
> And no, the pre-release line doesn't really apply here. When you release RC2 with a Golive license and publicly state "you can be confident to use it in Production and we will support you" only to backtrack on it (days, weeks?) later then that's on Microsoft.
Where did they do that? Does .NET Core even have an RC2 or an RC1? Are you talking about ASP.NET Core? Where did they backtrack on the Golive license on ASP.NET Core RC2?
I don't think Microsoft has ever announced a release date for .NET Core, so why you were confident it would release at a particular point is confusing to me.
There's also never been a release date for ASP.NET Core. Certainly, RC2 took a lot longer than you would reasonably extrapolate from the speed between betas and RC1, but I don't see much support for the rest of your post in any announcements I've ever read.
> I don't think Microsoft has ever announced a release date for .NET Core, so why you were confident it would release at a particular point is confusing to me.
The expectations that were casually set by members of the team at talks, on Twitter, on Podcasts, and so forth all indicated that .NET Core's arrival was imminent. The bulk of my criticism has been that their communication strategy on its readiness has not been carefully managed. Therein lies the problem.
Think you can dot-net your "begging for social shares toolbar" the core outta the reading area? It's dot-netting the first word of every line and totally un-core.
Responded to you in Disqus. Should be disabled on mobile already by default. Added a second setting that disables it on screens less than 600px wide. Pain in the ass, sorry about that.
Microsoft's .NET is the only ecosystem where "component vendors" are a thing. I don't understand how people can buy and rely on proprietary "components".
Such components - I use Developer Express components - greatly accelerate development time and offer extra functionality out of the box. None of my clients care one white about open source, they just want their products developed quickly.
It's in addition too, open source components. If people want the commercial support, fast bug fixes and other benefits you get by buying these components why not?
All this does is changes the "core" library for CoreCLR to be renamed from "mscorlib" to "System.Private.Corelib" -- this has an important function, now the .NET team can add more backward compat features (missing types and methods) to mscorlib for those who want to use it.
If your library or product doesn't want to use it, you don't need to.
.NET Core doesn't become more bloated, it says beautiful and Core.
If you want to point out specific issues as a positive for the future of .NET Core (and that looks like a good one), it's only fair to include ones showing the negatives right now. This is why the best answer at the moment is "wait and see":
boil the ocean
tv. to waste one’s time attempting to do the impossible.
(see also plowing water.) You’re wasting my time. You
might as well be boiling the ocean.
One could also use the original meaning of Vaporware:
Vaporware
"Vaporware" was coined by a Microsoft engineer in 1982 to
describe the company's Xenix operating system. It became
popular among writers in the Industry as a way to
describe products they felt took too long to be released.
InfoWorld magazine editor Stewart Alsop helped popularize
it by lampooning Bill Gates with a Golden Vaporware award
for the late release of his company's first version of
Windows in 1985.
I've been using Microsoft APIs for about twenty years now. When a new MS technology comes out, I've learned that:
alpha and 1.0 - for experimentation only
2.0 - OK for internal tools
3.0+ - ready for production
This has been true going all the way back to mfc through asp.net, mvc, etc.
2.0 and even 1.0 might work in production, but you end up with the problem of having a bunch of production code that needs updated to the newer 3.0+ api changes which ends up being significant.
The worst open source projects are more social than engineering -- then manage to waste the positive energy by mis-communicating. Unfortunately Microsoft seems to be threading that needle. And I simply cannot believe the documentation situation. It's like they forgot that's the one thing they're great at.
Likewise the BashOnWindows stuff is just... tragic. Reading the threads it's obvious that they have people with little Linux experience working on it. Naturally, basic developer scenarios simply don't work because Microsoft devs are testing their own stuff while learning basic Linux commands for the first time. And posts from program managers saying things like "yeah, I guess we should have targeted Debian instead of Ubuntu, we kinda woulda got both for free" don't inspire confidence.
I thought that 'boiling the ocean' might be a reference to exponential economic growth [1], but apparently it has more common meaning.
"Alright, the Earth has only one mechanism for releasing heat to space, and that’s via (infrared) radiation. We understand the phenomenon perfectly well, and can predict the surface temperature of the planet as a function of how much energy the human race produces. The upshot is that at a 2.3% growth rate (conveniently chosen to represent a 10× increase every century), we would reach boiling temperature in about 400 years.
IMO people should stop whining and just wait. Do you really think it's that easy to just re-write .NET features to .NET core? You do realise that they also need to make sure it works on Mono (Linux, Mac) as well?
I salute MS at their efforts and am very excited. Yes, we are waiting now for at least a year but whining does not help. If you want to help then make some PR's instead.
Also, nobody is pulling the rug from anyone, you will be able to use MVC6 with regular .NET, just remove .NET Core from dependencies and you're set.
IF you, as a technical lead, are building a product which is shipping in 2016 and decide to build it on something like .Net Core then you DESERVE to get sacked.
You're a leader, you are responsible for doing the risk assessment.
Do you build your product on a platform which is been in development for 18 months; which is an ambitious rewrite, and which is planned to have the first RTM in the second half of the year?
You're lying to yourself if you say that you're working in the best interests of your employers if you say yes. You're being irresponsible. You're doing CV-driven-development.
As a leader you're an experienced developer: you know that shipping dates are unreliable at best. We know that version 1 of anything is simply a starting point. You know that building a platform is extremely risky.
This is exactly why I chose not to immediately start using .Net Core. Sure, the tech is great, but it is bound to be delayed. No way am I betting 6-9 months of a team of 10 developers on that.
Can I ask an honest question? How much of this "churn" is due to them feeling their way through this for the first time in public. Privately, we would have never even heard about this.
I've been very critical of them deciding to call RC12 an RC because of the amount of breaking changes that have occurred up through beta (and now even between RC1 and RC2). I am typically met with apologists that tell me it's me who is wrong, despite that fact that the rest of the industry doesn't break their software (typically) between release candidates.
In the end, about two years from now, I suspect that this won't be an issue. I truly don't think there is malicious intent here on the part of Microsoft, I just don't think they put as much planning into this effort as they should have. They are also beginning to alienate their new-found open source followers by making decisions behind closed doors. They really need to be careful here...
I honestly think a lot of the problems come down to naming: their betas were alphas and their RCs definitely were not release candidates - they were betas.
Microsoft has always been terrible with versioning and though things seem to be improving there's still a long way to go.
I waited for years for Microsoft to get their .NET story straight once more, after the uncertainty generated regarding .NET's future during Windows 8 development and launch. Meanwhile, innumerous projects and libraries were deprecated by Microsoft .NET teams in favor of half-hearted attempts at replacements.
After noticing the tendency described on the article, of development & deployment tools and techniques first appearing on the open-source community, and taking years to appear in the Microsoft scenario, usually as imperfect clones with a small community around them, I decided to solve my personal conundrum by going straight to the source of that innovation process.
I've since switched to Linux instead of Windows Server, JVM instead of .NET, and Scala instead of C# and I'm pretty happy with that stack.
I love where .Net Core is going but I rather agree with this. I'd like.Net Core to ship. The more scope that is added, the less likely this will be to take off. And I really want it to succeed. Ship less but ship sooner please!
Microsoft always does this. And I hate it! When they have a new direction, Microsoft brings 10,000 developers to bear on the problem from every angle. Once progress is made in the new direction, their thousands of MVPs and evangelists are instructed to write an articles about the big new thing and nothing else.
That's why I can't avoid articles about .NET Core and fucking Azure these days. I don't use either and I probably won't until .NET Core has been stable for a year - and even then, I'll probably only use it for Windows-based work since I don't trust Microsoft on Linux. When I use Linux, I want to use the truly Unix-based tools that everybody else on Linux is using. When in Rome, you know... (I'll probably never use Azure because I've never liked the way Microsoft runs service-based businesses.)
Now Linux on Windows (as in "Bash" on Windows or Ubuntu on Windows)...that is one thing I'm looking forward to. It would be nice to be able to shutdown my constantly running Ubuntu Server VM.
> .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.
It means an attempt to do something so so impossibly difficult that you might as well be trying to boil the ocean. I believe a definition was linked to in the article.
I brought up the comparison because I've seen it in wayyyy too many tech articles lately.
.NET Core exists side-by-side the full .NET Framework. You can use the .NET Framework now, and into the future. Newer versions of ASP.NET and Entity Framework have adopted the "Core" moniker but they run on both platforms.
For example, Microsoft.EntityFrameworkCore [1] ships the necessary bits for:
* .NETFramework 4.5.1 (full "Desktop" framework)
* .NETCore 5.0 and .NETStandard 1.3 (the "Core" framework)
If you plan your timelines around pre-release software (that's what .NET Core is) then Microsoft is not to blame.
For what it's worth, I'm not a fan of what happened with Release Candidate 1 [2] but I would NEVER place a dependency on pre-production software coming out of Microsoft.
[1] https://www.nuget.org/packages/Microsoft.EntityFrameworkCore
[2] https://news.ycombinator.com/item?id=11649578