by berberich on 7/23/15, 2:14 PM with 207 comments
by mdpm on 7/23/15, 5:04 PM
There's a different philosophy in the open source world - python, perl, c - none really have 'de facto' answers to persistence, logging, services, etc so There's a plethora of approaches and libraries for any needs. MS provides EF, so you have to defend any alternate solution to business; it's perceived as risky. Even using tools not of MS origin, despite no close surrogate from the 'official' tools (ala Redis, 3rd party libs) is something you have to find approval for. MS tooling is automatically excluded from this. This isn't great for MS either, because they now have to produce these 'ideal' libraries, and the strength of their platform is now judged by library implementations.
I'm really not sure what the solution to this problem is unless they really get to sponsoring projects with effort, money, and tooling. They have programs in place for this, and I can see there's a lot of outreach going on for this reason.
by tpetricek on 7/23/15, 5:01 PM
There are definitely interesting hard problems that are being solved in the F# community. For some larger and fully open source projects that exist out there check out:
* http://www.m-brace.net - A fantastic library for doing interactive cloud computation that takes a slightly different approach than Spark (think "cloud monad" :-))
* http://fslab.org - A nicely integrated collection of data science libraries with fantastic data access features and R integration (supported by OSS community and a finance company)
* http://websharper.com - An open source library for doing web programming that has a pretty unique integration of client-side programming (translated to JS) with server-side programming
* Also, I would like to mention FAKE, Paket and ProjectScaffold (http://fsprojects.github.io/ProjectScaffold) which enable the community build OSS libraries with smooth build process and great documentation.
Is it impressive compared with longer and more established OSS communities? Maybe not. But those are all things that happened over the last 2 years. It's enough to make me feel that the F# and .NET ecosystems are heading in a good direction.
by vdnkh on 7/23/15, 3:53 PM
by batou on 7/23/15, 4:51 PM
Right because yes there could be a ton more open source solutions out there. Also right because most of them are either shit, commercial or abandonware. This is a big problem. We imported a lot of stuff and found it was mostly crap (Nservicebus, justsaying come to mind)
Also wrong because a massive portion of what we do is a solved problem on .net. There's not a whole load of stuff to reinvent.
What I'd like to point out though is name me one platform I can build stuff for desktop, mobile, web, embedded, plugged into office applications, deployed by a single click from the web, deployed to single machines, deployed to thousands of workstations, will talk to just about anything under the sun from REST, SOAP, WS-*, databases, spreadsheets, document models, message queues, serial ports, pipes, TCP channels, has a request broker and distributed object model and has several data access methods from ORM, SQL, table gateway abstraction and has very decent tooling, provisioning, integrated deployment, testing, profiling and backwards compatibility going back 20 years all out of the box with no glue required?
On top of that there's support which is actually very good for everything above.
Nope there's only one and Java doesn't come close.
by daxfohl on 7/23/15, 4:06 PM
Perhaps MS should just kill off all these frameworks and force the community to drive them.
by mythz on 7/23/15, 5:51 PM
You just need to look at the NuGet package statistics to see how pervasive this is in .NET: https://www.nuget.org/stats/packages
Out of the top 50 projects, the only packages I see that aren't prescribed defaults shipped in VS.NET Templates are:
- NUnit & NUnitTestAdapter
- Moq
- AutoMapper
- log4net
NUnit and log4net were originally ported from Java and defined their respective categories in .NET which MS's NIH alternatives aren't able to match (e.g. they don't run on Mono).MS doesn't offer anything comparable to Moq or AutoMapper which explains their success.
Reasons why from my 2012 Interview on .NET OSS: http://www.infoq.com/articles/interview-servicestack-2
> The .NET platform is like no other; Microsoft has PR channels, Evangelists, MVP Award programs and control over VS.NET that commands a strong influence over .NET mindshare where they're seen as the authoritative voice for the .NET ecosystem to most developers. Historically they've only used their influence to validate their own libraries and frameworks which has contributed to many .NET companies being reluctant to deviate from Microsoft's prescribed technology stacks and explore alternative solutions.
This also explains why the .NET Ecosystem is slow at adopting popular technologies (prevalent in other platforms) where they don't gain traction until MS PR validates them, inc: MVC, Testing, NoSQL, MQ's, etc.
by JamesBarney on 7/23/15, 4:44 PM
The the larger problem is one of self-selection. C# devs are not alone in not contributing to opens source software. The vast majority of devs don't make meaningful contributions to OSS. It's just the the few people who get really stoked about open source software and love making a positive contribution to world through software have been turned off by Microsoft's behavior for the last 10-15 years. So they never entered the .NET/C# world to begin with.
The second is incentives. Java shops are much more comfortable with open source then .NET shops. Open source is still terrifying to many enterprise customers, and a lot of .NET shops. And the incentives besides making a positive contribution to the world [0] for contributing to OSS are it looks good on your resume, maybe you could consult on it, and getting to be paid to work on your own OSS project. But with most customers not using OSS the developers don't get a lot of personal benefits from it.
The third is how bug fixing your favorite OSS acts like a gateway drugs. In the past .NET devs wouldn't have very much experience with any OSS. If they found a bug in their favorite framework they would report it. End of story. Everything they used was closed source MS stack. But if they were working with Java(and probably working on an OSS library) they could dive into that library and make the fix themselves. Now that all of the core libraries for MS are being open sourced many more devs will start to get familiar with what it's like to be able to make a change to library or framework you use on a daily basis. And hopefully some will catch the OSS bug.
I think this will change. As Microsoft pushes more OSS, enterprise customers will see it as less scary. Devs who are into OSS might start considering .Net as an option. And finally devs will start to get a taste of what it's like to get to fix a bug on a framework or library that 1000's of people use.
[0] -see point 1 why people who wanna make a positive contribution to world through open source software shy away from being .net developers
by cbsmith on 7/23/15, 3:39 PM
by hokkos on 7/23/15, 3:44 PM
by sremani on 7/23/15, 3:42 PM
by platz on 7/23/15, 3:48 PM
by mcguire on 7/23/15, 10:48 PM
The licenses for their operating systems have always acted to make farms of Windows machines rare. Until fairly recently, the administration approach made it painful. Microsoft had good support for client-server systems, but you did it their way, which wasn't "reactive".
Here's a quick question: Anyone know of any networking/distributed system developments that came out of a Microsoft environment?
by ams6110 on 7/23/15, 11:02 PM
I'm reaching for a word that means "an example which is almost exactly the opposite of the concept it's used to illustrate" -- incongruous?
by blakeyrat on 7/23/15, 9:57 PM
I frankly:
1) don't know what that is, and
2) can't even imagine what it could consist of other than a few lines of code exercising System.Net.Sockets.
by AngusMcQuarrie on 7/23/15, 4:51 PM
by bliti on 7/23/15, 9:56 PM
by skc on 7/24/15, 9:01 AM
I'm a C# dev and I keep close tabs on the plethora of tools that become the new cool thing in OSS for other platforms, and maybe it's a case that I don't work on interesting things...but I've never found myself hindered by C#/.Net.
In any case, the major OSS tools out there do have .Net ports that are actively maintained, perhaps only the bleeding edge stuff is slow on the uptake.
by Asbostos on 7/24/15, 7:15 AM
by zamalek on 7/24/15, 7:13 AM
I've got Murmur3 for you [1] - you can stream into it if that interests you at all. Here's my unit tests [2] (which are arguably the hard part because the reference tests are strange).
I agree with your article, though, a lot needs to be done. E.g. Frustrated with the lack of a .Net diffing lib I went and wrote one based on patience diff [3] and the best I've gotten is one issue. Nobody seems interested in solving problems like the ones you are talking about.
[1]: https://gist.github.com/jcdickinson/4bda826eb2e3f58e38c4 [2]: http://stackoverflow.com/questions/14747343/murmurhash3-test... [3]: https://github.com/jcdickinson/difflib
by reubenbond on 7/24/15, 10:03 AM
I wonder, though why it became stagnant so soon and never gained momentum. I'm don't know, but I have a theory. The team were using some tech which was semi-secret at the time, which they weren't allowed to talk about: Service Fabric (known as Windows Fabric at the time). Fabric was in use in projects like Lync Server and Service Bus Server, but no one could talk openly about it.
How can you develop an open-source distributed system without being able to mention the framework which makes it all possible? Fabric handles ActorFx' high availability, service discovery, code distribution/upgrades, and their state replication. It's pretty difficult... Forum posts asking what this fabric thing was went unanswered and the people who may have been interested in ActorFx just moved on.
Regarding Orleans, there were probably a couple of internal actor frameworks in use at some large .NET houses, but they were never released to the public. I think it was more of a cultural issue than a lack of devs: .NET devs weren't used to sharing code.
Things are getting better. The community around Orleans is great (come join us on Gitter! https://gitter.im/dotnet/orleans) and the ecosystem as a whole feels to be gaining momentum.
by jtwebman on 7/23/15, 6:00 PM
by achr2 on 7/23/15, 4:30 PM
by macintux on 7/23/15, 4:19 PM
by AdeptusAquinas on 7/23/15, 9:39 PM
If the whole pool of developers world wide was considered as a big pie, and a certain section of that do these 'hard problems', the solution is to market to them the strengths of .NET. Advocating other parts of the pie who build enterprise apps and who already use .NET that they should suddenly start writing actor systems 'for the good of the framework's OSS cred' seems silly.
by JustSomeNobody on 7/23/15, 3:48 PM
While there are exceptions, the .Net community hasn't ever really been about OSS.
by Olivier26 on 7/24/15, 9:37 AM
by mcintyre1994 on 7/23/15, 6:04 PM
by PretzelFisch on 7/23/15, 9:37 PM
by UK-AL on 7/23/15, 3:53 PM
by bargl on 7/23/15, 9:29 PM
I ran into this when working for the government, CSC, and another company. They developed some cool stuff but just didn't want to share...
by MichaelGG on 7/23/15, 4:37 PM
Don't blame Microsoft? Ha, OK. MS is responsible for gimping the .net environment to Windows with no technical reason. I'm a bit of an MS fanboy but I'll admit deploying on Windows is a pain in the ass. Shit, it's just now they're getting around to "Windows Server Nano'. OpenVZ's been around for a long time, and MS just steadfastly ignored containers as long as they could. Or DRBD - 2015, and MS ships nothing like this. Everything is commercial 3rd party stuff.
Or look at SSH support. It's just now they decided to add that, despite wanting to do it internally for a while. WinRM is annoying but that didn't stop them from leaving it as the only option. And before that? Deployment was what, exposing smb shares?
Or look at IIS. It's 2015, IIS has no real reverse proxy (ARR is a terrible joke), and nginx only runs with limitations on Windows. Why is that? And FFS, they're making you upgrade the OS to have HTTP2, and this whole time, you've not been able to use SPDY. I've seen .net/win shops add Linux just for nginx/SPDY, then realize the grass is greener... Not to mention every other thing, like Elasticsearch - Linux is the OS of choice for deployment, so why bother dealing with it on Windows?
.NET was designed from the beginning to be cross platform and cross language. The first book I read on targeting the CLR was for Component Pascal! The CLR design is far better than the JVM. And around that time, MS had a version of .net running on BSD. They chose to ignore developers and thus everyone flocked to the JVM. This is entirely MS's fault. They could have destroyed Java (or at least started an arms race). The JVM was built solely for Java the language, with no thought for running other languages the CLR was designed explicitly with this in mind, yet almost no langs target the CLR. Explain that without blaming MS.
Even now, they have F#, which is essentially better than C# in every way. How do they promote it? By fucking up features in Visual Studio so things don't quite work. By downplaying it as a language for "scientific" and "financial" work. This is the team that brought generics to .net; without them they'd probably have Java's lameass erasure model. And it looks like MS just grudgingly throws a bit of F# support out as a bone. They don't get it. Instead MS focuses on their line-of-business "Mort" developers. (The kind that can pump out useless, scammy crap to get the Windows Store numbers up, or contribute to more licenses.) They're focused on ops that suit companies that run AD and Exchange. Excellent solutions for those companies; no real focus on others. I'm sure it's been a great win for immediate licenses, but they shouldn't be surprised they lost the war. (And note that via BizSpark, they're giving this stuff away and still can't make it stick.)
And it's not their fault people don't rush to implement code that will possibly only work on Windows? Ha!
(MS has finally shifted to being open towards Linux because they wanna sell overpriced VMs on Azure. And by overpriced, I mean 2x or more of GCE's cost, with none of the perf benefits. And note this was not MS's first choice. They wanted Azure to be a lock-in PaaS, and only when they realised customers didn't want to deal with that mess did they go after IaaS and start "embracing" open source and Linux.)
I apologize for the rant, but I do blame MS for doing all they can to drive developers and ops away from Windows, .Net's only officially supported platform, and thus away from .Net.
by lectrick on 7/23/15, 3:58 PM
I know the latter is a downvotable attitude, and I apologize because it's very unlike me, but it is one of my few sore points, and this comes from years of web developer hell dealing with IE, years of working at places which only considered solutions that Microsoft invented, years of dealing with Microsoft BS left and right.
Before you downvote- If you honestly consider yourself a developer who cares about their craft and career, I want you to read these 2 books- https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar and http://www.paulgraham.com/hackpaint.html (yes, I just plugged a pg book on HN... It's part of why I'm here, actually!). And THEN come back and try to downvote me.
by FloNeu on 7/24/15, 10:50 AM
by jimmcslim on 7/23/15, 9:48 PM
by therealmarv on 7/23/15, 4:50 PM
by taylodl on 7/24/15, 2:41 AM
are why people took Java seriously and used it to solve hard problems.
by jerven on 7/23/15, 3:39 PM
by platz on 7/23/15, 3:39 PM
by WorldWideWayne on 7/23/15, 5:58 PM
To the mods here: Didn't think to change this one, did you?
by mshenfield on 7/23/15, 3:43 PM
by bigdubs on 7/23/15, 3:43 PM
Having what reads as a very angry and negative blogpost about the state of .net oss isn't really helping.
Contributing software is though, and that really should have been the focus of the post, not how weak and terrible .net oss is.
Be the change you seek.
by mkesper on 7/23/15, 3:46 PM
Well, Microsoft itself created a whole ecosystem of the proprietary lock-in type. Only very recently they seem to jump on the open source bandwagon. And don't hold your breath for a free software MS office...