Microsoft WebsiteSpark, or the True Price of Closed Source Software
A couple of weeks ago Microsoft launched its WebsiteSpark initiative in an effort to gain some inroads into the market share of the open-source web development stack. The Redmont giant, however, has got it wrong again. The thing is, people choose open source not only because the initial licensing costs are lower, but because it provides certain types of benefits that closed-source simply cannot provide, no matter at what cost.
Recently I had to do some hacking on a .NET web project I'd worked on several months ago. I lost one full day of my precious time struggling with an inane problem related to the way .NET works with configuration files in multiple projects within the same assembly. Which reminded me why closed source software can be such a painful experience:
You cannot ask about it. While most aspects of the platform are pretty well documented, every now and then (and always more often then you expect) you end up working with some niche or very new technology that is not very well documented. And when you get stuck with closed source software you get stuck big time. The docs are scarce and not very comprehensible, and make not mention of that specific issue that is bugging you. Since this is closed source software, the only people who really grok it are those who wrote it, and if they are silent, suddenly there is no info in the forums and the mailing lists are dead. Closed source drastically limits the potential number of experts in a given technology - this number is based on the resources and priorities of the developing company and not on the relative importance of the technology itself.
You cannot see it, and you cannot debug it. You know something is going wrong, you are probably not passing the correct parameter or have failed to allocate some resource, but you can never know. Everything is as documented, everything should work fine, but it does not. And there is no error message or it is useless. That library you are using is like a big black hole - it sucks in your input, returning nothing, and you have absolutely no idea why.
You cannot fix it. Sometimes inheritance is not good enough. You need that one extra feature but there is no sane way to add it to the existing library. You end up writing your own library from scratch just because of that one issue.
Admittedly, such issues do not arise that often. But based on my experience, a) they arise more often then when working with open source tools, and b) they take vastly more time to resolve then when working with open source tools. Perl was my first programming language. At one point in my development as a perl programmer, I started to realize that perl's libraries on CPAN are not perfect at all - even in the most widely used ones I would discover bugs and essential missing features. I was frustrated at first that I have to struggle to read through source code when the documentation is lacking. I was frustrated that I had to write patches for problems that I felt others should have fixed already. It was not until I stated doing serious programming in C# that I realized that commercial closed source development tools, despite the financial backing that they have, suffer from these same issue, and you are even more frustrated that you cannot even read through the source code or submit patches.
Microsoft's profits come from selling licenses for the OS and Visual Studio, it gets no direct earnings from .NET itself. If they really want to appeal to open source developers, they should act bold and open up the source of as much of the .NET stack as possible.