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.
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.
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.
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).
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.
Being cross-platform has nothing to do with being open source. They are totally orthogonal. The article conflates both of them.
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.
>Does NuGet support Mono? >The command-line application (nuget.exe) builds and runs >under Mono and allows you to create packages in Mono.
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.
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.
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().
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?