7 ms·

In .NET, open source does not beget open source

49 points by bvanderveen 15y ago

mmcconnell1618 15y ago
You make some great points about the difficulties in running a cross-platform .NET project as open source. However, I think the cross-platform difficulties are only a small part. Open-source is very new to many Microsoft developers. Just getting participation in .NET projects that are Windows only is difficult (but not impossible). Many Microsoft developers have had years of "training" that open-source == buggy and has support issues just like many non-MS developers have been "taught" that .NET is a legal trap so don't touch it. I think the perception has been changing in recent years and open-source .NET is now well accepted in some circles. As the trend grows I think you'll start to see better cross-platform tools and support for your package management and testing problems. Who knows, JavaScript might just become so dominant that open-source .NET never reaches its full potential.
- kermitthehermit 15y ago
  The problem is that some people still remember some of the stories about how Microsoft blackmailed some hardware vendors to stop shipping devices with Linux and how they sued companies which sell Android based devices. Because of that reason, it's not that hard to imagine a scenario where Microsoft got "stabby" and wanted a piece of someone's cake. node.js / python / php / ruby (with all of their frameworks) are far better choices than .net. At least they're backed by a lot of people and they all seem to be doing fine. They're pretty much the same across distributions / OSes / architectures from the point of view of development and of the delpoyment (to some extent). I played with the nancy framework when I was considering an alternative to python for a small web service which required high rps / server resources. Needless to say, I decided to stick to python due to the lack of instructions for compiling on Linux and deploying on mono.
  - rbanffy 15y ago
    > remember some of the stories about how Microsoft blackmailed some hardware vendors to stop shipping devices with Linux and how they sued companies which sell Android based devices. Sadly, this is not limited to the past. Microsoft is using patent extortion to get a couple bucks for every Android device sold.
- bvanderveen 15y ago
  You're right, there are certainly cultural barriers to overcome as well, although I just focused on tooling problems in this article. I agree with your statement about JavaScript. Microsoft was wise to commit resources to making Windows a first-class development environment for Node. There are many compelling reasons for .NET developers to move to that platform.
kiloaper 15y ago
The only major project that comes to mind using Mono on multiple platforms for a biggish open source project is OpenSimulator (http://opensimulator.org/wiki/Build_Instructions http://opensimulator.org/wiki/Build_Instructions). I wonder how they overcome those issues.
gm 15y ago
I disagree with the point of the article. I think This is more of a platform gripe ("I hate it that this stuff is unfamiliar to me!") than an actually valid argument. The same could be said for someone learning Linux for the first time, writing about how difficult it is to get X project compiling, or starting a project from scratch. Vi, Emacs, no IDE, dependencies, make, cross platform incompatibilities, etc are all gripes that could be said of any OSS project of decent size. All with an equally good sob story about just how hard things are to do. It boils down to the fact that learning new stuff is hard and inconvenient because in the environment you have just spent X years developing on it's so easy. Which is a fair enough point, just don't mislabel or misattribute it. EDIT: Also the headline makes no sense. Platforms don't beget open source. People and open source licenses do. If it does not exist, create it and share it. Is that not the whole point of OSS?
- MartinCron 15y ago
  There is an odd dynamic here, where having a non-cross platform tool (such as NuGet) seems inferior to not having that tool at all. I do a lot of .NET development and haven't played around with Mono at all yet. This article makes me want to try and see how many of my assumptions (nUnit, TeamCity, Visual Studio) don't translate.
  - gm 15y ago
    Hmm, you sure NuGet is not cross platform? It's open source, btw, so people have a chance to fix if they do not like. But the NuGet FAQ (http://docs.nuget.org/docs/start-here/nuget-faq http://docs.nuget.org/docs/start-here/nuget-faq) says this: >Does NuGet support Mono? >The command-line application (nuget.exe) builds and runs >under Mono and allows you to create packages in Mono.
    - MartinCron 15y ago
      You're probably right, the author of the original post seemed to rule out NuGet because it didn't work for him.
- kermitthehermit 15y ago
radicalbyte 15y ago
No comparison against Java? That would be the obvious point to compare, given that it's the most comparible to .Net. Yet he has only listed dynamic (and mainly interpreted/"scripting") languages. A few points: 1) GAC Deployment of 3rd Party Libraries For many libraries it isn't required. Many libraries are fine with simply shipping the DLL. Sure, a lot of the Microsoft libraries/frameworks do require a GAC deploy, but that's to be expected. They've pretty much been designed for clicky-clicky "developers". Coders tend to avoid these like the plague : as should you too. 2) Testing nUnit works fine on both Mono and Visual Studio. What's the problem with using it? That you want to integrate with TFS? If so then your problem's clear.
- gm 15y ago
  FWIW, the MS world has a lot of hard-core scary-smart coders. And GAC deployment does not have much to do with clicky stuff. GAC has to with with DLL hell, and you need to jump through some extra hoops to deploy there (ie, http://support.microsoft.com/kb/324168 http://support.microsoft.com/kb/324168). Or maybe you intended something else in your comment, but I missed it. Is the GAC inferior (since you put the word developers in quotes) because it allows the programmer to find references without searching through folders? Sorry, I just miss the point of the comment.
  - radicalbyte 15y ago
    The original article was complaining about the requirement to GAC deploy libraries and being hard to test: my reply was that it's often not required. Microsoft's own products being a prominent exception (think Entity Framework, Workflow and System.Globalization). The Microsoft World is split into two camps: a) The kind who like using the drag-and-drop tools and having all of their code generated for them. these are generally the less technical crowd. b) The engineer type, the type who know what SOLID means know when to use (and not to use) a range of patterns. They're often proficient in several languages. This crowd tends to be more technical, and more critical of the products Microsoft build on top of the CLR. I'm in the second camp (and I guess that the vast majority of MS HNers are too). The first camp are common referred to (and refer to themselves) as "Microsoft developers".. and they're by far the largest (but least vocal) group.
iso8859-1 15y ago
Isn't this pretty much what the GPL was designed to solve? Stallman had to make sure the derivatives were open-source to make GNU going. If he used the MIT license, people wouldn't have felt the need to try and build something that could compete. But because they knew their rights were protected they had a chance against the reigning.
recoiledsnake 15y ago
What has this got to do with open source? Imagine a open source project hosted on Team Foundation Server and the contributors all using Visual Studio. Is that project any less "open source" than other open source projects? Why will that .NET project beget something that is not open source? Doesn't make any sense. The article should be titled something like "Cross-platform development of .NET is hard". And then go on to talk about how that can be a hurdle for open source development.
- bvanderveen 15y ago
  Fair.
  - sriramk 15y ago
    Completely agree. To use a different analogy, this is like writing ObjC code using XCode and talking about how hard it is to compile outside the Apple world of tools (perhaps using GNUStep). It is no less open source.
    - aaaaaaaaaaa 15y ago
      Completely agree.....idiot....pelele...la puta que te re pario
- lucisferre 15y ago
  If opensource is hosted on a private TFS server, does it make a sound?
  - recoiledsnake 15y ago
    Who said anything about a private server? Why the snark?
WheelsUpper 15y ago
Who posted this NOOB .net blog post? If you don't know how to do this, find someone who does.
hkarthik 15y ago
OSS authors that write apps in C++ have complained about nearly the exact same problems and often ignore Windows completely for many of the same reasons. I think the only viable approach for cross platform OSS on .NET is to take a Mono-first approach and then package for Windows developers in a subsequent step using NuGet. It's kind of a backwards approach by targeting 10% of the market first then later targeting the 90%, but it's likely the only way to ensure cross platform OSS when you choose to use .NET. That being said, I don't miss .NET at all. Dip your toe in other frameworks, you'll find it's much more conducive to OSS work.
- MartinCron 15y ago
  It's not really backwards to tackle the hard problems first to prove they can be solved, but it is counter-intuitive. Thanks for this tip.
  - aaaaaaaaaaa 15y ago
    you are wrong, imbecil la puta que te pario
- zem 15y ago
  yep, I was bitten by that when trying to port a (fortunately rather small) ocaml program to windows. needed a bit of rewriting to replace dependencies that simply didn't work under windows. of course, the rewritten code was perfectly cross-platform.
jroseattle 15y ago
While the title of the article is true, the content doesn't really support the idiom. Lack of familiarity with tools and utilities seems to be the theme here. It would help if MonoDevelop and Visual Studio played well together, but they don't. Portability across platforms with .Net isn't easy, that's for sure. For OSS .net projects I've been involved with, we've made conscious decisions about code distribution. Those included unit tests (we chose nUnit) and builds (VS sln files). Did we forego all those mono developers? Well, yes and no. Yes, in theory; no, in terms of anyone who was using our code in a Mono environment. To bridge the gap, we rolled a MonoDevelop project file, and put up some info about it on our wiki. To date, we never had anyone ask for build assistance in Mono. While I get the sentiment, it's not nearly as big a problem as getting .Net developers engaged in more OSS projects.
jimbobimbo 15y ago
"Ignore for a second that MonoDevelop and Visual Studio will fight over the formatting of those files, stomp on each other changes, and add garbage that’s meaningless to the other. A VS- or MD-generated .csproj will be default import some target definitions called" Manual or unrecognized changes in project XML files will be preserved by (at least) Visual Studio - this is "by design" behavior. If MonoDevelop discard unrecognized constructions, this must be a bug. "Microsoft.CSharp.targets. Uh oh, what’s that? Where does that live on my system? What does it do? What package do I have to install to get that?" MSBuild. "Well, I don’t want to include that DLL in source control because checking binaries into source control is a no-no." Wrong. Test framework is either a dependency library or a tool and MUST be included under \lib or \tools folder, under the name that contains version information (say, "nunit-1.2.3"). Another way is to add library code as an external dependency and build it every time, but I think this is overkill in this particular situation. Bottom line: by keeping 3rd-party dependencies (libs or tools) local you will be getting people up to speed in no time as opposed to having to maintain detailed instruction on where to get software and how to install it. "Pretty nice! I have separate commands for msbuild and xbuild to build the .csproj files that my IDE understands, but hey, just an implementation detail, right?" Or maybe you could create an environment variable / macro that would perform all required substitution and make your build code easier to maintain. "Doing it in Ruby is a heck of a lot easier than using the ZIP task in MSBuild and I don’t have to worry about cross-platform issues." I think this pretty much summarizes the article: new set of tools + unfamiliar environment = lots of grief. About me: I maintain pretty large Windows-only project with tons of dependencies on 3rd-party .NET and COM binaries; support one-command builds into multiple release configuration, automatic versioning and hourly builds on Hudson. It took a couple of weeks in total to setup everything, but in Quick Start document I have only instructions on how to install Visual Studio and checkout latest code. Another project is an ASP.NET MVC project, where my build script in addition to building the thing, uploads binaries and content onto separate servers and does some admin stuff over SSH. I mean, know your tools, as usual.
- hello_moto 15y ago
  Regarding dependencies: Ruby has Gems Node has npm Java has Maven .NET has ____ I don't argue too much about checking binaries into source control but other development environments have probably smoother situation compare to .NET when it comes to 3rd-party libraries. NuGet is close but not quite there yet. Regarding Build: MSBuild is akin to that of Ant in Java. Considering that many of Java developers either have moved or are moving to use Maven, it's quite clear that .NET is lagging behind. Correct me if I'm wrong, even Clojure leiningen is very similar to Maven. There's some truth to his grief. Even if you're familiar with .NET tools, other platforms provide better experience.
deleted 15y ago
[deleted]
aaaaaaaaaaa 15y ago
Enema enema.Enema enema
teyc 15y ago
Read the article carefully. This guy has a point. Zipfs law applies to software stacks. There is always a leader , the second and third place drops off exponentially. So, in .NET, the leader is obviously MS with its tooling. However, these tools aren't as lightweight for someone who came from Ruby and command line tools. While scripting is possible, one has to patch together the information from various sources. @jimbobimbo has said that it is possible to script. But it took him weeks. There is no obvious .NET stack (by stack I mean Build, Test, Deploy) that champions lightweight systems. VS writes tools for software stacks. Not quick dirty scripts. This is the only thing they get paid big $$$ for. However, it is not actually what the customer wants. The customer wants a solid runtime, easy to debug stacks and fast turnaround. I believe NuGet is a step in the right direction, usable from both Powershell and VS Shell. However, it is going to take another generation before MS starts to understand how to make the rest of their infrastructure scriptable.

49 points by bvanderveen 15y ago

You make some great points about the difficulties in running a cross-platform .NET project as open source. However, I think the cross-platform difficulties are only a small part. Open-source is very new to many Microsoft developers. Just getting participation in .NET projects that are Windows only is difficult (but not impossible). Many Microsoft developers have had years of "training" that open-source == buggy and has support issues just like many non-MS developers have been "taught" that .NET is a legal trap so don't touch it. I think the perception has been changing in recent years and open-source .NET is now well accepted in some circles. As the trend grows I think you'll start to see better cross-platform tools and support for your package management and testing problems. Who knows, JavaScript might just become so dominant that open-source .NET never reaches its full potential.

kermitthehermit 15y ago
The problem is that some people still remember some of the stories about how Microsoft blackmailed some hardware vendors to stop shipping devices with Linux and how they sued companies which sell Android based devices. Because of that reason, it's not that hard to imagine a scenario where Microsoft got "stabby" and wanted a piece of someone's cake. node.js / python / php / ruby (with all of their frameworks) are far better choices than .net. At least they're backed by a lot of people and they all seem to be doing fine. They're pretty much the same across distributions / OSes / architectures from the point of view of development and of the delpoyment (to some extent). I played with the nancy framework when I was considering an alternative to python for a small web service which required high rps / server resources. Needless to say, I decided to stick to python due to the lack of instructions for compiling on Linux and deploying on mono.
- rbanffy 15y ago
  > remember some of the stories about how Microsoft blackmailed some hardware vendors to stop shipping devices with Linux and how they sued companies which sell Android based devices. Sadly, this is not limited to the past. Microsoft is using patent extortion to get a couple bucks for every Android device sold.
bvanderveen 15y ago
You're right, there are certainly cultural barriers to overcome as well, although I just focused on tooling problems in this article. I agree with your statement about JavaScript. Microsoft was wise to commit resources to making Windows a first-class development environment for Node. There are many compelling reasons for .NET developers to move to that platform.

kiloaper 15y ago

The only major project that comes to mind using Mono on multiple platforms for a biggish open source project is OpenSimulator (http://opensimulator.org/wiki/Build_Instructions http://opensimulator.org/wiki/Build_Instructions). I wonder how they overcome those issues.

gm 15y ago

I disagree with the point of the article. I think This is more of a platform gripe ("I hate it that this stuff is unfamiliar to me!") than an actually valid argument. The same could be said for someone learning Linux for the first time, writing about how difficult it is to get X project compiling, or starting a project from scratch. Vi, Emacs, no IDE, dependencies, make, cross platform incompatibilities, etc are all gripes that could be said of any OSS project of decent size. All with an equally good sob story about just how hard things are to do. It boils down to the fact that learning new stuff is hard and inconvenient because in the environment you have just spent X years developing on it's so easy. Which is a fair enough point, just don't mislabel or misattribute it. EDIT: Also the headline makes no sense. Platforms don't beget open source. People and open source licenses do. If it does not exist, create it and share it. Is that not the whole point of OSS?

MartinCron 15y ago
There is an odd dynamic here, where having a non-cross platform tool (such as NuGet) seems inferior to not having that tool at all. I do a lot of .NET development and haven't played around with Mono at all yet. This article makes me want to try and see how many of my assumptions (nUnit, TeamCity, Visual Studio) don't translate.
- gm 15y ago
  Hmm, you sure NuGet is not cross platform? It's open source, btw, so people have a chance to fix if they do not like. But the NuGet FAQ (http://docs.nuget.org/docs/start-here/nuget-faq http://docs.nuget.org/docs/start-here/nuget-faq) says this: >Does NuGet support Mono? >The command-line application (nuget.exe) builds and runs >under Mono and allows you to create packages in Mono.
  - MartinCron 15y ago
    You're probably right, the author of the original post seemed to rule out NuGet because it didn't work for him.
kermitthehermit 15y ago

radicalbyte 15y ago

No comparison against Java? That would be the obvious point to compare, given that it's the most comparible to .Net. Yet he has only listed dynamic (and mainly interpreted/"scripting") languages. A few points: 1) GAC Deployment of 3rd Party Libraries For many libraries it isn't required. Many libraries are fine with simply shipping the DLL. Sure, a lot of the Microsoft libraries/frameworks do require a GAC deploy, but that's to be expected. They've pretty much been designed for clicky-clicky "developers". Coders tend to avoid these like the plague : as should you too. 2) Testing nUnit works fine on both Mono and Visual Studio. What's the problem with using it? That you want to integrate with TFS? If so then your problem's clear.

gm 15y ago
FWIW, the MS world has a lot of hard-core scary-smart coders. And GAC deployment does not have much to do with clicky stuff. GAC has to with with DLL hell, and you need to jump through some extra hoops to deploy there (ie, http://support.microsoft.com/kb/324168 http://support.microsoft.com/kb/324168). Or maybe you intended something else in your comment, but I missed it. Is the GAC inferior (since you put the word developers in quotes) because it allows the programmer to find references without searching through folders? Sorry, I just miss the point of the comment.
- radicalbyte 15y ago
  The original article was complaining about the requirement to GAC deploy libraries and being hard to test: my reply was that it's often not required. Microsoft's own products being a prominent exception (think Entity Framework, Workflow and System.Globalization). The Microsoft World is split into two camps: a) The kind who like using the drag-and-drop tools and having all of their code generated for them. these are generally the less technical crowd. b) The engineer type, the type who know what SOLID means know when to use (and not to use) a range of patterns. They're often proficient in several languages. This crowd tends to be more technical, and more critical of the products Microsoft build on top of the CLR. I'm in the second camp (and I guess that the vast majority of MS HNers are too). The first camp are common referred to (and refer to themselves) as "Microsoft developers".. and they're by far the largest (but least vocal) group.

iso8859-1 15y ago

Isn't this pretty much what the GPL was designed to solve? Stallman had to make sure the derivatives were open-source to make GNU going. If he used the MIT license, people wouldn't have felt the need to try and build something that could compete. But because they knew their rights were protected they had a chance against the reigning.

recoiledsnake 15y ago

What has this got to do with open source? Imagine a open source project hosted on Team Foundation Server and the contributors all using Visual Studio. Is that project any less "open source" than other open source projects? Why will that .NET project beget something that is not open source? Doesn't make any sense. The article should be titled something like "Cross-platform development of .NET is hard". And then go on to talk about how that can be a hurdle for open source development.

bvanderveen 15y ago
Fair.
- sriramk 15y ago
  Completely agree. To use a different analogy, this is like writing ObjC code using XCode and talking about how hard it is to compile outside the Apple world of tools (perhaps using GNUStep). It is no less open source.
  - aaaaaaaaaaa 15y ago
    Completely agree.....idiot....pelele...la puta que te re pario
lucisferre 15y ago
If opensource is hosted on a private TFS server, does it make a sound?
- recoiledsnake 15y ago
  Who said anything about a private server? Why the snark?

WheelsUpper 15y ago

Who posted this NOOB .net blog post? If you don't know how to do this, find someone who does.

hkarthik 15y ago

OSS authors that write apps in C++ have complained about nearly the exact same problems and often ignore Windows completely for many of the same reasons. I think the only viable approach for cross platform OSS on .NET is to take a Mono-first approach and then package for Windows developers in a subsequent step using NuGet. It's kind of a backwards approach by targeting 10% of the market first then later targeting the 90%, but it's likely the only way to ensure cross platform OSS when you choose to use .NET. That being said, I don't miss .NET at all. Dip your toe in other frameworks, you'll find it's much more conducive to OSS work.

MartinCron 15y ago
It's not really backwards to tackle the hard problems first to prove they can be solved, but it is counter-intuitive. Thanks for this tip.
- aaaaaaaaaaa 15y ago
  you are wrong, imbecil la puta que te pario
zem 15y ago
yep, I was bitten by that when trying to port a (fortunately rather small) ocaml program to windows. needed a bit of rewriting to replace dependencies that simply didn't work under windows. of course, the rewritten code was perfectly cross-platform.

jroseattle 15y ago

While the title of the article is true, the content doesn't really support the idiom. Lack of familiarity with tools and utilities seems to be the theme here. It would help if MonoDevelop and Visual Studio played well together, but they don't. Portability across platforms with .Net isn't easy, that's for sure. For OSS .net projects I've been involved with, we've made conscious decisions about code distribution. Those included unit tests (we chose nUnit) and builds (VS sln files). Did we forego all those mono developers? Well, yes and no. Yes, in theory; no, in terms of anyone who was using our code in a Mono environment. To bridge the gap, we rolled a MonoDevelop project file, and put up some info about it on our wiki. To date, we never had anyone ask for build assistance in Mono. While I get the sentiment, it's not nearly as big a problem as getting .Net developers engaged in more OSS projects.

jimbobimbo 15y ago

"Ignore for a second that MonoDevelop and Visual Studio will fight over the formatting of those files, stomp on each other changes, and add garbage that’s meaningless to the other. A VS- or MD-generated .csproj will be default import some target definitions called" Manual or unrecognized changes in project XML files will be preserved by (at least) Visual Studio - this is "by design" behavior. If MonoDevelop discard unrecognized constructions, this must be a bug. "Microsoft.CSharp.targets. Uh oh, what’s that? Where does that live on my system? What does it do? What package do I have to install to get that?" MSBuild. "Well, I don’t want to include that DLL in source control because checking binaries into source control is a no-no." Wrong. Test framework is either a dependency library or a tool and MUST be included under \lib or \tools folder, under the name that contains version information (say, "nunit-1.2.3"). Another way is to add library code as an external dependency and build it every time, but I think this is overkill in this particular situation. Bottom line: by keeping 3rd-party dependencies (libs or tools) local you will be getting people up to speed in no time as opposed to having to maintain detailed instruction on where to get software and how to install it. "Pretty nice! I have separate commands for msbuild and xbuild to build the .csproj files that my IDE understands, but hey, just an implementation detail, right?" Or maybe you could create an environment variable / macro that would perform all required substitution and make your build code easier to maintain. "Doing it in Ruby is a heck of a lot easier than using the ZIP task in MSBuild and I don’t have to worry about cross-platform issues." I think this pretty much summarizes the article: new set of tools + unfamiliar environment = lots of grief. About me: I maintain pretty large Windows-only project with tons of dependencies on 3rd-party .NET and COM binaries; support one-command builds into multiple release configuration, automatic versioning and hourly builds on Hudson. It took a couple of weeks in total to setup everything, but in Quick Start document I have only instructions on how to install Visual Studio and checkout latest code. Another project is an ASP.NET MVC project, where my build script in addition to building the thing, uploads binaries and content onto separate servers and does some admin stuff over SSH. I mean, know your tools, as usual.

hello_moto 15y ago
Regarding dependencies: Ruby has Gems Node has npm Java has Maven .NET has ____ I don't argue too much about checking binaries into source control but other development environments have probably smoother situation compare to .NET when it comes to 3rd-party libraries. NuGet is close but not quite there yet. Regarding Build: MSBuild is akin to that of Ant in Java. Considering that many of Java developers either have moved or are moving to use Maven, it's quite clear that .NET is lagging behind. Correct me if I'm wrong, even Clojure leiningen is very similar to Maven. There's some truth to his grief. Even if you're familiar with .NET tools, other platforms provide better experience.

deleted 15y ago

[deleted]

aaaaaaaaaaa 15y ago

Enema enema.Enema enema

teyc 15y ago

Read the article carefully. This guy has a point. Zipfs law applies to software stacks. There is always a leader , the second and third place drops off exponentially. So, in .NET, the leader is obviously MS with its tooling. However, these tools aren't as lightweight for someone who came from Ruby and command line tools. While scripting is possible, one has to patch together the information from various sources. @jimbobimbo has said that it is possible to script. But it took him weeks. There is no obvious .NET stack (by stack I mean Build, Test, Deploy) that champions lightweight systems. VS writes tools for software stacks. Not quick dirty scripts. This is the only thing they get paid big $$$ for. However, it is not actually what the customer wants. The customer wants a solid runtime, easy to debug stacks and fast turnaround. I believe NuGet is a step in the right direction, usable from both Powershell and VS Shell. However, it is going to take another generation before MS starts to understand how to make the rest of their infrastructure scriptable.