March 25, 2003
Business and Open Source: the talk continues
Seems like "Andy":http://linuxintegrators.com/hl30/blog/technology/?permalink=great+Anti-FUD.html is picking up on the blogversation being held between "Wiki":http://users.skynet.be/rikvanbruggen/index.html, "Werner":http://www.shiftat.com/blog/page/werner/20030324#opensource_and_business_ethics_the and "myself":http://blogs.cocoondev.org/stevenn/archives/000808.html.
As soon as I read Wiki's post, I knew I was assumed to do a step-by-step rebuttal, but had no time to actually do it since I wanted to commit some little patches to "an open source project I'm involved in":http://xml.apache.org/forrest/. And I believe that's exactly the point in understanding open source: you have to experience it before you can come up with a decent justification, and once you are experiencing it, you don't feel the need anymore to defend it since there are always "more pressing issues to spend your time on":http://cvs.apache.org/viewcvs.cgi/xml-forrest/src/resources/forrest-shbat/forrest.build.xml.diff?r1=1.58&r2=1.59. :-)
All-in-all, while Andy claims Werner is coming up with some great anti-FUD, I'm pretty sure Werner can do better: both Wiki and Werner are focussing too much on the _cost aspect_. And while admittedly, open source can lower TCO, adopting open source in your organization just for lowering costs might be a 'negative choice', i.e. a choice with only negative arguments. One of the first times I met "this wonderful person":http://radio.weblogs.com/0116284/, who now has become my business partner, he taught me a lesson about negative choices - they won't last. If you choose for something, be prepared to come up with some positive, non-anti arguments. And to be honest, choosing open source only because of the cost aspect, is a very good example of making the right decision with the wrong arguments. It's my firm belief that the aspect of cost really is a problem of the commercial tools vendors, who have to earn back the huge marketing/sales costs only with the sale of licenses and support contracts. Getting rid of this marketing/sales budget, which often surpasses that of R&D, might bring the equation back into balance. Looking at a typical product organisation, you see the developers (who aren't necesseraly better than that bunch of open source hackers, but could be) being shielded from the outside world by multiple layers of insulation: product managers, pre-sales consultants, sales and support people, marketing bunnies, and so on. All of these people need to get paid (there's nothing wrong with that, of course). Funny enough, if you have a _real_ problem with your commercial tool, and the vendor cares enough about you, your question will tunnel through all these layers of insultation, back to the developer in the center of the onion. Also, that developer is surrounded with testers, UI specialists, and various other people which you typically won't find as much in an open source project. So there's a good reason why commercial tools are typically more expensive than open source projects, but that reason is just plain boring: "more fluff and less stuff":http://www.nofluffjuststuff.com/.
In the end, open source projects might be more realistic in what they promise: what you see is what you get, nothing more and nothing less. I'm really worried when I see SLAs sticked upon commercial sales contracts which I'm pretty sure nobody is capable of living up to.
Anyhow, let's get back to "Wiki's points":http://users.skynet.be/rikvanbruggen/index.html... and again, almost all of them are based on interpretation, and of course both sides have the eloquent people explaining they are right. So I'm not going to spend time on these, as I'm not as eloquent in this language as I'd like to be. One anti-OSS point strikes me however: _"How do I know that this OSS software is as compliant with the open standards that are on the market?"_. Knowing Wiki (who is a great guy BTW) IRL, I'm pretty sure he refers to "this":http://www.sys-con.com/Java/articlenews.cfm?id=1930, since it is an issue he cares a lot about. Frankly, whether JBoss will ever be J2EE TCK certified, I don't really care, but he told me big companies _do_ care about this, and that adoption of JBoss in commercial settings will accelerate once they have their "J2EE certified!" badge. Of course, many commercial vendors went at great length to get their appservers certified. Funny enough, I see the real competition shifting to the developer's desktop, i.e. they are pushing to sell _developer seats_ of their J2EE IDE. And while some of these companies might try to generate J2EE compliant code out of these tools, I'm pretty sure they are trying to make customers depend on the specific APIs, wizards and whatnot they offer with their bright and shiny IDE, which are carefully crafted outside the J2EE specification range. This way, while people technically should be able to switch appservers and be more independent, they won't since they would loose the 'benefits' of tools-specific APIs, interfaces and glue code.
Looking at the typical amount of underspecification in recent standards, I see plenty of carefully designed space for these vendor-specific 'interpretations' which will lock developers into a single vendor's proposition. So if I had to choose between a de-facto standard with direct access to the development team, or having to tunnel through layers of FUD and politics, my choice would be quick and positive.
*Update*: as usual, "Marc":http://blogs.cocoondev.org/cgi-bin/mt-tb.cgi/212 was mindreading again. It's funny to see, though our style surely is different, how much neurons can be shared. Does that mean there's actually less imagination between the two of us? ;-)