In .NET, open source does not beget open source(bvanderveen.com)
bvanderveen.com
In .NET, open source does not beget open source
http://bvanderveen.com/a/dot-net-open-source-does-not-beget-open-source/
13 comments
> I think This is more of a platform gripe ("I hate it that this stuff is unfamiliar to me!") than an actually valid argument
It actually went to great lengths to demonstrate how hard it is to do cross-platform development with .NET. The article describes the problems of having IDEs that rewrite makefiles in incompatible ways.
> The same could be said for someone learning Linux for the first time
Makefiles usually work. You may need to install some library through your package manager or build it yourself, but, then, you are a programmer, not an icon-dragger.
> It boils down to the fact that learning new stuff is hard and inconvenient
While learning new stuff can be hard or inconvenient, it has nothing to do with the problem the article describe. The article describe the problem of not having a clean cross-platform workflow programmers running Visual Studio and Mono Develop can use to seamlessly collaborate on the same codebase, something that's really easy for just about anything else.
It actually went to great lengths to demonstrate how hard it is to do cross-platform development with .NET. The article describes the problems of having IDEs that rewrite makefiles in incompatible ways.
> The same could be said for someone learning Linux for the first time
Makefiles usually work. You may need to install some library through your package manager or build it yourself, but, then, you are a programmer, not an icon-dragger.
> It boils down to the fact that learning new stuff is hard and inconvenient
While learning new stuff can be hard or inconvenient, it has nothing to do with the problem the article describe. The article describe the problem of not having a clean cross-platform workflow programmers running Visual Studio and Mono Develop can use to seamlessly collaborate on the same codebase, something that's really easy for just about anything else.
The article describe the problem of not having a clean cross-platform workflow programmers running Visual Studio and Mono Develop can use to seamlessly collaborate on the same codebase, something that's really easy for just about anything else.
This sort of non-conventional workflow has traditionally been a problem with Microsoft's developer tools. If you go too far outside the use cases they have designed for, the tools start to work against you.
I've noticed a reversal in this trend with things like ASP.NET MVC and Entity Framework. The people I know at Microsoft developer tools seem to "get it" and want to make things that are more ecosystem-friendly and less prescriptive.
This particular case (using heterogeneous tools on different platforms to work on the same codebase) isn't just difficult on .NET. Lots of people feel your pain.
This sort of non-conventional workflow has traditionally been a problem with Microsoft's developer tools. If you go too far outside the use cases they have designed for, the tools start to work against you.
I've noticed a reversal in this trend with things like ASP.NET MVC and Entity Framework. The people I know at Microsoft developer tools seem to "get it" and want to make things that are more ecosystem-friendly and less prescriptive.
This particular case (using heterogeneous tools on different platforms to work on the same codebase) isn't just difficult on .NET. Lots of people feel your pain.
And my point is, again, that the same can be said for platforms in the OSS world. Portability is a bitch. It's only gotten easier lately because there are less platforms to support (or how many of us code stuff so it compiles and runs seamlessly in Solaris as well?)
So if the point is to have stuff run both in Windows and Linux, then yeah, portability is a bitch.
As to makefiles usually work, they do indeed, but after potentially a lot of debugging. I've been through that myself. But the point is, .NET project files, they usually work too.
About your last paragraph, I'll just repeat what I said before: The post could have been a how-to, had it been written in the spirit of open source. It was not, though, and so it was more of a complain post.
It's all good, though. Someone will find the article and the how-to part out, which overall is a good thing.
So if the point is to have stuff run both in Windows and Linux, then yeah, portability is a bitch.
As to makefiles usually work, they do indeed, but after potentially a lot of debugging. I've been through that myself. But the point is, .NET project files, they usually work too.
About your last paragraph, I'll just repeat what I said before: The post could have been a how-to, had it been written in the spirit of open source. It was not, though, and so it was more of a complain post.
It's all good, though. Someone will find the article and the how-to part out, which overall is a good thing.
"Makefiles usually work"
1. _usually_: if you have the same system, yes. However, try building stuff on a different OS (say SunOS) and/or CPU, and that 'usually' becomes 'more often than not', at best.
2. Have you read such makefiles recently? Portable ones, especially, are not ones one writes in an afternoon (not even when using a meta- or meta-meta makefile).
1. _usually_: if you have the same system, yes. However, try building stuff on a different OS (say SunOS) and/or CPU, and that 'usually' becomes 'more often than not', at best.
2. Have you read such makefiles recently? Portable ones, especially, are not ones one writes in an afternoon (not even when using a meta- or meta-meta makefile).
> You may need to install some library through your package manager or build it yourself
This is why I like systems like rpmbuild with yum, which declare not only how to invoke the build tools but which versions will be needed (as well as build-time and run-time libraries) so they can be fetched automatically.
This is why I like systems like rpmbuild with yum, which declare not only how to invoke the build tools but which versions will be needed (as well as build-time and run-time libraries) so they can be fetched automatically.
>It actually went to great lengths to demonstrate how hard it is to do cross-platform development with .NET.
Being cross-platform has nothing to do with being open source. They are totally orthogonal. The article conflates both of them.
Being cross-platform has nothing to do with being open source. They are totally orthogonal. The article conflates both of them.
Open source stuff is often ported to other architectures because it's open source. The point here is using microsoft tools makes that difficult... though I'm not sure why anyone would find that surprising.
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.
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.
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) 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.
>Does NuGet support Mono? >The command-line application (nuget.exe) builds and runs >under Mono and allows you to create packages in Mono.
You're probably right, the author of the original post seemed to rule out NuGet because it didn't work for him.
Actually, if it's too complicated to do something like just setting up that build and maintaining it for two platforms (development and, possibly, deployment), it's also very likely a lot of people will stick to something which requires less effort.
The argument is very sound. The idea that licenses and people are what drive open source but that's just one aspect of it. The ability to pick up the code and get to work with minimal hassle can make or break an open source project. If I have to rewrite half the code just to get things working on my system and begin building on the original source then why don't I just start from scratch anyway? Obviously everyone's mileage may vary and there's bound to be a few issues with any project but when they're so common and similar to what the author describes then his point is validated.
I've always known Windows to be notorious for making me jump through hoops to get simple, common development tools working. The author mentions Ruby, Python, Perl, and Node (I'd also add Apache, Nginx and PHP) as examples that more or less "just work" on any platform... But not Windows. You have to jump through hoops and use alternative software or (very different) methods to get these things working and it's a huge pain and doesn't help promote open source as the frustration of getting something to work is enough for someone to give up.
I'm not a Windows hater and I don't want to start a whole Win v. Linux v. Mac argument. The reasons for things being like this on Windows (please excuse me if I'm stating the obvious) is that, first, Windows has a very different heritage from every alternative OS. Secondly, Microsoft has a long history of trying to keep users and developers hooked on their platform. As a programmer if you learned on Windows then switching to another OS for development can be a challenge. Depending on the programmer that challenge may be enough to keep you on Windows as its the path of least resistance to you.
I can't completely blame them however. If in an alternate universe Windows had a Unix heritage along with other popular OSes and Linux was the odd man out then we'd be saying the same things about Linux distros that we say about Windows now. I prefer every OS but Windows for a lot of reasons one of which is the same as the reason why my hypothetical programmer chooses Windows over other platforms. On any Linux or OS X machine I have a development environment up and running smoothly in a short time with minimal glitches but Windows makes things very hard for me. So while they're trying to keep current devs locked in they also make non-Win devs locked out.
I've always known Windows to be notorious for making me jump through hoops to get simple, common development tools working. The author mentions Ruby, Python, Perl, and Node (I'd also add Apache, Nginx and PHP) as examples that more or less "just work" on any platform... But not Windows. You have to jump through hoops and use alternative software or (very different) methods to get these things working and it's a huge pain and doesn't help promote open source as the frustration of getting something to work is enough for someone to give up.
I'm not a Windows hater and I don't want to start a whole Win v. Linux v. Mac argument. The reasons for things being like this on Windows (please excuse me if I'm stating the obvious) is that, first, Windows has a very different heritage from every alternative OS. Secondly, Microsoft has a long history of trying to keep users and developers hooked on their platform. As a programmer if you learned on Windows then switching to another OS for development can be a challenge. Depending on the programmer that challenge may be enough to keep you on Windows as its the path of least resistance to you.
I can't completely blame them however. If in an alternate universe Windows had a Unix heritage along with other popular OSes and Linux was the odd man out then we'd be saying the same things about Linux distros that we say about Windows now. I prefer every OS but Windows for a lot of reasons one of which is the same as the reason why my hypothetical programmer chooses Windows over other platforms. On any Linux or OS X machine I have a development environment up and running smoothly in a short time with minimal glitches but Windows makes things very hard for me. So while they're trying to keep current devs locked in they also make non-Win devs locked out.
<quote>The author mentions Ruby, Python, Perl, and Node (I'd also add Apache, Nginx and PHP) as examples that more or less "just work" on any platform... But not Windows. You have to jump through hoops and use alternative software or (very different) methods to get these things working</quote>
This is a very 21st-century perspective, in that all of these non-Windows platforms are basically Unix. If you look at the platforms that existed in the early 90s -- things like MVS, VMS, TOPS-20, OS/400 -- these were even less Unix-like than Windows was. Windows is an anomaly only because it's the last non-Unix OS standing.
This is a very 21st-century perspective, in that all of these non-Windows platforms are basically Unix. If you look at the platforms that existed in the early 90s -- things like MVS, VMS, TOPS-20, OS/400 -- these were even less Unix-like than Windows was. Windows is an anomaly only because it's the last non-Unix OS standing.
Right, that's exactly my point. I'm not criticizing Windows for being Windows but just pointing out why working with it is so frustrating. You restated part of my point very well when you said Windows is an anomaly because it's the last non-Unix OS standing. As for it being a very 21st century view, well, yeah it is. I'm talking about how things are done now. The platforms of the 90's are pointless to even consider as no one is using them anymore. You could get really technical and point out some enthusiasts using BeOS and some other 90's OSes but for the most part they're dead.
> these were even less Unix-like than Windows was
Heck, compare MS-DOS to NT-derived Windows. You only get directories beginning in MS-DOS 2.0 and you never get something comparable to fork().
Heck, compare MS-DOS to NT-derived Windows. You only get directories beginning in MS-DOS 2.0 and you never get something comparable to fork().
"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.
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.
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.
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.
.NET has NuGet. You yourself mention it, then throw it out as "It's not there yet." If you're going to play that game, you have to at least explain what about NuGet is lacking.
Currently, NuGet:
Currently, NuGet:
* Is trivial to use
* Can be set up on your own box for private packages
* Has a pretty huge collection of packages
* Avoids jamming libraries in your SCM
* And pertinent to this article: works fine in Mono
You left out another feature: Nuget is well integrated into powershell, for automating its actions.
Does it work in Linux?
Yes: since at least around October or so, NuGet.exe (the command line) works just fine under Mono in Linux. This is all you need to create and install NuGet packages. MonoDevelop does not yet have integration equivalent to VisualStudio's, but that's not a big deal.
Yes, but you may have to start it with:
mono --runtime=v4.0 NuGet.exe
You can also create a NuGet.exe.config file (put it in the same directory as NuGet.exe) to the same effect:
Also, you may need a fairly recent version of Mono to run NuGet; there was a bug in Mono that prevented NuGet from running, which was fixed only a few months ago.
mono --runtime=v4.0 NuGet.exe
You can also create a NuGet.exe.config file (put it in the same directory as NuGet.exe) to the same effect:
<configuration>
<startup>
<supportedRuntime version="v4.0" />
</startup>
</configuration>
Also, you may need a fairly recent version of Mono to run NuGet; there was a bug in Mono that prevented NuGet from running, which was fixed only a few months ago.
.Net has Nuget, and that's the truth of it. If it's not good enough for you, you'll have to make a case for new features, and either implement them or wait for someone else to.
What features are you lacking?
What features are you lacking?
nuget is still messy compared to maven/leiningen/rubygems, some features are lacking such as:
- a system-wide repository
- an easy way to integrate with .csproj builds so that building in VS will pull up necessary libs. Yes, i know there's the new auto-install feature in NuGet 1.6 but it's still not as easy as with other tools, and it requires the .nuget folder with nuget.exe in it, and i prefer people to have nuget.exe directly in their PATH anyway.
- a simple way to build from the command line and in VS easily (I know this might not be feasible because VS doesn't let you do everything). For example i could just edit a bunch of dependencies in one file (not a csproj + a package.config, even if a tool does it for me it's messy) and compile it in one command or in VS.
- better management of "internal" NuGet packages within a company (NuGet.Server is not so great to use although it works-ish), NuGet hasn't really been design for large-scale use unlike maven, and this is clearly showing here. It's more of a little tool to get exernal libs.
In general NuGet should mavenize itself a little bit (it can't gemify itself since you'll also want to compile stuff, so imitating bundler/gem isn't enough).
And i do love NuGet, i push it everywhere i can trust me :) it's one of the greatest .NET project at the moment.
- a system-wide repository
- an easy way to integrate with .csproj builds so that building in VS will pull up necessary libs. Yes, i know there's the new auto-install feature in NuGet 1.6 but it's still not as easy as with other tools, and it requires the .nuget folder with nuget.exe in it, and i prefer people to have nuget.exe directly in their PATH anyway.
- a simple way to build from the command line and in VS easily (I know this might not be feasible because VS doesn't let you do everything). For example i could just edit a bunch of dependencies in one file (not a csproj + a package.config, even if a tool does it for me it's messy) and compile it in one command or in VS.
- better management of "internal" NuGet packages within a company (NuGet.Server is not so great to use although it works-ish), NuGet hasn't really been design for large-scale use unlike maven, and this is clearly showing here. It's more of a little tool to get exernal libs.
In general NuGet should mavenize itself a little bit (it can't gemify itself since you'll also want to compile stuff, so imitating bundler/gem isn't enough).
And i do love NuGet, i push it everywhere i can trust me :) it's one of the greatest .NET project at the moment.
I agree that Nuget is a young tool, with potential. But already it has made a good difference. I hope it gets the features that we want.
> Wrong. Test framework is either a dependency library or a tool and MUST be included under \lib or \tools folder
Opinions differ on this, and anyone who says that their way (and their folder names) is the only right way for all circumstances is not seeing the whole picture.
I've also seen a script as part of the build that updates/regenerates the nuget libraries folder. The only drawback is when there's an update and you're not on the net it will fail.
Opinions differ on this, and anyone who says that their way (and their folder names) is the only right way for all circumstances is not seeing the whole picture.
I've also seen a script as part of the build that updates/regenerates the nuget libraries folder. The only drawback is when there's an update and you're not on the net it will fail.
Does NuGet support local repository a'la Maven? (setting up your own Maven remote but local within company network type of repository)
NuGet supports that. It's quite easy. http://docs.nuget.org/docs/creating-packages/hosting-your-ow...
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.
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.
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.
you are wrong, imbecil la puta que te pario
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.
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.
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.
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.
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.
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.
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.
> 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.
Sadly, this is not limited to the past. Microsoft is using patent extortion to get a couple bucks for every Android device sold.
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.
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.
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.
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.
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). I wonder how they overcome those issues.
[deleted]
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.
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.
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.
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). 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.
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). 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.
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.
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.
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.
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.
Fair.
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.
Completely agree.....idiot....pelele...la puta que te re pario
If opensource is hosted on a private TFS server, does it make a sound?
Who said anything about a private server? Why the snark?
Enema enema.Enema enema
Who posted this NOOB .net blog post?
If you don't know how to do this, find someone who does.
If you don't know how to do this, find someone who does.
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?