8 ms·

I think it is important to realize that the .NET OSS ecosystem is not something that has been around for a long time. In the F# community, it truly started work

I think it is important to realize that the .NET OSS ecosystem is not something that has been around for a long time. In the F# community, it truly started working as an "OSS ecosystem" only a couple of years ago - and the rest of .NET is following - and I'd say it is only starting to really exist now. Although .NET has been around for ages, people are only learning what OSS means and I think the F# community is leading the way here. 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 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 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 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 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.

edwinnathaniel 11y ago
Probably it's heading toward where niche ecosystem/platform is today: Haskell, Erlang. But with less uptake because the similar audiences/users of those platforms are less likely to touch Microsoft... (even if they're reaching cross-platforms)
marpstar 11y ago
Maybe this is why I'm loving F# more and more as I continue to dive in. I write C# at my day job, but there really is more interesting OSS development going on in F#. The community seems very approachable and I find myself actually wanting to contribute.
deet 11y ago
Indeed. And it's very possible that the .NET OSS ecosystem will grow dramatically soon, once its core components, compilers, and build tools finish being open sourced and become stable on non-Windows platforms. 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.
- Gibbon1 11y ago
  I've rolled this around a bit and have come down on the side that there are two factors at work. 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.
- fr0styMatt2 11y ago
  I think the status of the development tools has/had a lot to do with it. As a .NET developer, it's always been unclear until a few years ago as to how you could get the free tools and what you could do with them. 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.
nl 11y ago
Sorry, but that is a nonsense excuse. 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 http://springframework.net/news.html
- AdieuToLogic 11y ago
  > The (now abandoned) Spring.NET project 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.
  - batou 11y ago
    It slowly fell behind. I made the mistake of using it for a product pre-MVC. When MVC came along they jumped the shark and we ended up ripping it out and replacing bits with Autofac and some light weight abstractions we put together ourselves.
- amadeusw 11y ago
  While I agree with you that Microsoft was getting in the way of the ecosystem, I believe that since last year this is no longer the case. 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.
shoo 11y ago
At my last job we ported the build scripts to FAKE and afterwards many people (everyone?) felt that it had been a mistake. There were probably a few reasons for this: 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.
highmastdon 11y ago
What I'm seeing in all these comments is that there should be a better OSS ecosystem in the .NET community. I think the problem here is that we're trying to compare the Java OSS ecosystem with the .NET Framework community. Essentially .NET isn't the language here. 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.

edwinnathaniel 11y ago

Probably it's heading toward where niche ecosystem/platform is today: Haskell, Erlang. But with less uptake because the similar audiences/users of those platforms are less likely to touch Microsoft... (even if they're reaching cross-platforms)

marpstar 11y ago

Maybe this is why I'm loving F# more and more as I continue to dive in. I write C# at my day job, but there really is more interesting OSS development going on in F#. The community seems very approachable and I find myself actually wanting to contribute.

deet 11y ago

Indeed. And it's very possible that the .NET OSS ecosystem will grow dramatically soon, once its core components, compilers, and build tools finish being open sourced and become stable on non-Windows platforms. 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.

Gibbon1 11y ago
I've rolled this around a bit and have come down on the side that there are two factors at work. 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.
fr0styMatt2 11y ago
I think the status of the development tools has/had a lot to do with it. As a .NET developer, it's always been unclear until a few years ago as to how you could get the free tools and what you could do with them. 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.

nl 11y ago

Sorry, but that is a nonsense excuse. 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 http://springframework.net/news.html

AdieuToLogic 11y ago
> The (now abandoned) Spring.NET project 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.
- batou 11y ago
  It slowly fell behind. I made the mistake of using it for a product pre-MVC. When MVC came along they jumped the shark and we ended up ripping it out and replacing bits with Autofac and some light weight abstractions we put together ourselves.
amadeusw 11y ago
While I agree with you that Microsoft was getting in the way of the ecosystem, I believe that since last year this is no longer the case. 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.

shoo 11y ago

At my last job we ported the build scripts to FAKE and afterwards many people (everyone?) felt that it had been a mistake. There were probably a few reasons for this: 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.

highmastdon 11y ago

What I'm seeing in all these comments is that there should be a better OSS ecosystem in the .NET community. I think the problem here is that we're trying to compare the Java OSS ecosystem with the .NET Framework community. Essentially .NET isn't the language here. 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.