I just ran across an interesting article by Allen Holub on Open Source, and some qualms he's developing over it:
My most recent experiences with Tomcat demonstrate my dilemma. The newest version of Tomcat was just plain broken. It didn't load and run custom tags correctly, for example. Though I could (in fact did) go to an earlier version, the fact that Tomcat wasn't subjected to even rudimentary regression testing is disturbing.
The next issue is one of documentation and developer attitude. I wanted to use a local-configuration-file mechanism that's pushed heavily in the documentation (context.xml), and I was deploying from the development directory using the Ant build.xml file that's shipped with Tomcat. This process simply doesn't work.
I started with the documentation to find a solution. Tomcat's documentation is virtually unusable, though. It's a hodgepodge of inadequate .html files. There's no way to print it. There's no real organizational principle, index or search mechanism. A lot of the documentation is written by developers for other developers, so it is sketchy at best, and incomprehensible to a new user.
This isn't surprising. A lot of the necessary, but "drudgery" related tasks for a software project simply don't get done unless someone is paying for them (either explicitly or implicitly). Documentation is one of the best examples - and before you point to Eclipse or Apache - look at the well funded foundations that back those projects - someone is paying for that drudge work. The same thing applies to usability related tasks (build procedures, UI, etc) - once the lead developer(s) have a system that works, they tend to stop - it's no longer an interesting problem, so it falls by the wayside. In a funded effort, you end up with complaints coming in that might affect revenue - so the problems tend to get addressed
Note that funding is separate from licensing - this isn't a failure of Open Source per se. It's endemic to Open Source simply because most Open Source projects are not funded. Allen hits the punch line here:
The bottom line is that you have to do a lot of work to use an open-source product like Tomcat. You have to test new versions rigorously; you have to compensate for inadequate documentation by using a high-volume mailing list that may or may not provide an answer in a day or two; you have to trust amateurish code, which you can't really repair yourself because your version will no longer be "standard." Even if you could repair the code, progress on your real project would slow down.
All of these problems translate directly to wasted time and wasted money. The Tomcat team has no incentive to fix any of this because they're not being paid and have no market pressure on them to improve quality or provide real customer support. I know that the open-source party line is that third parties will step up to fill these gaps, but then you're paying for the software, aren't you? So much for the price advantage.
There's a danger there even to funded open source efforts that Allen doesn't address - I wrote about that here. To summarize, take an open product of significant scale - JBoss, for example. You can buy service and support from the company itself, but getting the product itself is free. There's nothing stopping another entity from setting up support for that product at a lower price - and at lower cost. The JBoss group has to carry the cost of both developers and of support staff - a third party need only carry the cost of support. In a non-open licensed product, the vendor can still recover their costs via license sales, even if their support gets cannibalized. What's the Open Source vendor going to do in that case? I rather suspect that they'll get blown out of the water.
There's no free lunch for this stuff - if you expect to get everything for free, you might want to ask yourself why your company doesn't give its products away.