May 01, 2003
Freeloading: forking open source
Yesterday, my dear friend and colleague met someone who, granted, runs what appears to be a serious local Java business. Since the number of in-depth techy Java consultancy companies is relatively limited in our corner of the world, it is always nice to hear Java is being used successfully in other companies, and of course there's the obvious talk about open source projects being used. The use of open source projects in a Java development environment seems to have become an established practice, as opposed to the Redmond-supported situation. This is nice. Many, if not all Java developers I know habitually run Ant instead of their IDEs proprietary build system, or choose an IDE which supports Ant, as many do currently. For them, Ant has become infrastructure commodity, just like Apache as a web server, and Tomcat as a servlet container. As much as JBoss would like to see this changed, EJB infrastructure stills is subject to some deliberation, hence JBoss is being used increasingly, but cannot be called commodity, yet.
In terms of application infrastructure, it is hard to deny the success of Struts. While the prospect of MVC for the web can hardly be called anything else than marketing blabla, Struts does a good job at what it promises. It's a nice contained framework, with a number of utility classes and frameworks around it, and is used by a lot of Java web developers. So even if "we":http://cocoon.apache.org/ like to see this different, Struts is top of mind for webapp development ATM, and consequentially is also becoming a commodity.
Funny enough, it seems that "we":http://outerthought.org/ still are about the only company around "here":http://www.belgium.be/ who have grasped the clue of these so-called commodity open source infrastructure tools: that it serves our customers better to work *inside* the communities developing such tools, rather than branching, forking and doing our own thing. In the end, there's the obvious limit of headcount and brain mass. We are a small company (and have no ambition to change that anytime soon), so in order to keep our brains fit and to keep an eye on the world outside, it serves us and our customers well to keep in touch with open source projects and communities. Other similar companies apparently think different: they use the code being produced by these communities as a way to increase profit margins, maybe by stating they wrote this themselves, or by shortening lead times. Of course, there's nothing wrong with that. But when doing so, they (if they are smart) might encounter bugs or performance issues in the codebases they are using, and might fix them.
Now, while they use the open source _brand_ to gain trust with their customers (this is good since it is based on Struts and _BTW, we use all kinds of open source so it will cost you less_), they fail to _give back_. Of course, this _giving back_ theme sure sounds good on the first of May, but we regularly encounter awkward looks if we insist on this in a (business) decision. People fail to realize that this might be the ultimate customer focus: where could the code be better guarded than in a totally open and transparent environment, where codebases might survive for much longer than the people or companies who created them? So while it might seem cool to go for the proprietary performance branch of company _xyz_, think twice: you might be dependent on that code for longer than the duration of the business relationship between you and _xyz_.
So especially when working with smaller companies, whose future might be less certain than that of "Big Blue":http://www.ibm.com/ or "Fiercily Red":http://www.oracle.com/, consider to negotiate some *real* escrow arrangement. If they happen to fork, make them give back, so that you, the customer, increase your supplier-independency.
*Update*: Werner "reacted":http://www.shiftat.com/blog/page/werner/20030501#re_freeloading and I posted a "comment":http://www.shiftat.com/blog/comments/werner?anchor=re_freeloading. No Werner, it's not at all about you.