The (now abandoned) Spring.NET project[1] was started in 2004, not too long after (Java) Spring started.

It's easy to criticize Java Spring, but it's a good example of a long-lived successful Open Source project. It's also easy to argue that Spring isn't as useful in .NET as in Java.

But I can pull up many, may other examples (the .NET Lucene port etc).

My point is that the .NET OSS ecosystem is NOT a new thing, but it keeps getting killed off. The typical example is that a .NET project starts to solve a problem, gets it 30-40% solved, then Microsoft releases a project that solves a different 30-40% but sucks all the oxygen out of the ecosystem.

[1] http://springframework.net/news.html

I tried, and couldn't find exact date when Microsoft officially endorsed Newtonsoft.Json as THE way to handle json in .net. But I believe that this happened just last year. Look, in 2011 Scott Hanselman blogged about this library [1] and the comments (esp. the first one) are pretty interesting. Here, .NET tried to solve a problem and community did a better job, and just recently Microsoft recognized it.

It's been abandoned? (serious question) That really is too bad. It was a solid project used on several .NET projects in which I participated "back in the day."

BTW, I completely agree with your summary point. There appears to be a cultural rejection of .NET OSS projects.

The article accused people using .NET of not choosing to work on hard problems. I suspect that's it's the other way around. People working on hard problems have chosen other tools that they felt were more appropriate or effective at the time.

For example, if people doing hard things felt that a Linux hosting environment was most suitable for their solving hard problem, that basically ruled out .NET. Once .NET applications can be safely, reliably run on Linux, the case for using .NET becomes much stronger.

1. Just plain Microsoft Hate. Couple of times someones asked me about what language to use for some GUI that messes with a database and does some other thing, running on Windows and 'maybe Linux' I tell them that C#/.net was made for that kind of thing. And they recoil in horror as if they just realized that I'm Satan. Then they go off and mess around with QT/C++ for a week before giving up.

2. C# has good inter-op with C/C++ libraries. So if there is an open source widget in C/C++ you need you can usually just build it as a dll with some wrapper magic and reference those in your project.

I'm specifically talking about Visual Studio here.

So there was always this perceived barrier to entry, even if it wasn't true -- for example with C++ I know I can just grab a linux box and have gcc and use it. With .NET, until recently it was -- pay for Visual Studio? Use the free version but it's only an express version so can I use it commercially? Use MonoDevelop which is alright but doesn't feel quite as nice under Windows?

Now that we have an official toolset on Linux and the licensing behind Visual Studio seems a hell of a lot less confusing, I think we'll see the community grow.

There is also the hate thing; but I'd counter that with the observation that there's also a lot of Java-hate out there too. They aren't seen as "hacker's languages" but "ewww yuck big bank enterprise-y languages". So I don't know.

They're seen as "Languages this evil SOB of a company owns and who knows if it could decide to patent something and enforce it against me".

As in, patent law is complex. Guarantees sound more like marketing of the used-car-dealer and sawdust-transmission variety than actual known-good documents like the GPL, which is, after all, founded on copyright law. Copyright law seems simpler: You own specific files, not abstract hand-wavey ideas. You can't use copyright law to go after someone for the unforgivable sin of coming up with the same idea a bit after, or a bit before, you did.

(Edited to add: Before you accuse me of FUD, tell me how I could know I'm not spreading FUD without becoming an IP law expert first.)

So:

.Net is Microsoft's ecosystem.

Java is Oracle's ecosystem.

Which company is less likely to find a loophole in whatever guarantee they've pledged and use it to squash me like a gnat?

Now that you mention Intellectual Property, I wonder.... Does the fact that .NET is used in big enterprises and big enterprises tend to have strict employee side-work exclusion clauses or "we own everything you do" clauses also play a part in slowing down the .NET OSS ecosystem?

1. we wanted to split the build scripts across multiple files, as we had multiple builds sharing common parts of a build process, and the only way of doing that with F# seemed to be writing a bunch of scripts that #load-ed each other. This was unpleasant.

2. at the time FAKE tried to kill processes it launched at the end of a build, but this was not implemented terribly well, so if you ran multiple FAKE builds in parallel on the same Windows box there was a fair chance they'd start trying to murder each other, and you'd end up having builds fail for no reason. This was fun to debug. IIRC FAKE was trying to track processes using process ids, but these get recycled...

3. we weren't using F# for anything else in the business, so having the build scripts in F# meant even less people wanted anything to do with them.

Here's a Q&A with myself that I wrote at the time about the #load-ing stuff:

Q1. do you recommend constructing build systems out of many .fsx scripts that #load each other?

A1. no. the #load mechanism of f# scripts is lamentable, in that it does not like you #load-ing something twice, yet no mechanism like #pragma once or #define / #ifndef is provided.

Q2. couldn't you work around that problem by not making your "library" .fsx scripts #load anything, and write a top-level "main" .fsx script that #loads all transitive dependencies exactly once in the correct order?

A2. yes. yet that sounds strangely similar to what you might wish a build system to do for you.

edit: and now I'm reminded of something else, that isn't to do with FAKE, just another fun windows parallel build interaction thing: you run a couple of builds on a windows box using jenkins. in each build, you use msbuild to compile some visual studio project. msbuild launches some mspdbsrv process that is cleverly shared between msbuild processes. then the first jenkins build finishes, and jenkins cleverly kills all processes launched by the build, including mspdbsrv, while the second build is still using it. hurray for interactions between two different pieces of clever software! at least this one is fixable by setting environment variables telling msbuild not to do this once you figure out what is going on.

I think that the main problem is that developers stick to what's given in the .NET framework, instead of building awesome things outside that.