Commercial open source software has arrived. There have been commercial sponsors of open source projects for a long time, but the recent spate of high-price (for open source, at least) acquisitions of companies with open source products at the core of their business has made a splash in the technology industry. In addition, Sun’s convulsions into the open source world have left the Java landscape decisively in open source territory.

Is this recent trend toward commercial open source good for open source software? Is it good for the Java developer? Is the utopian spirit of the open source movement about to get crushed by greed, profit seeking, and evil corporate maneuvering? Well…let’s see.

Open source software has had a clearly beneficial impact on the tools we use everyday. It provides a rich and varied ecosystem where technologies can compete purely on their merits in the hands of the people who actually use them. This ecosystem allows the virtues of natural selection to shape the tools, libraries, and frameworks we use to get software built.

As a result of this healthy selection pressure, the open source projects that gain widespread adoption and thrive are those that solve real problems in the best way. Technologies that fail to solve problems fail to gain acceptance and die. The open source landscape is littered with the carnage of this competition. Sourceforge, for example, is strewn with the corpses of thousands of projects that, for one reason or another, couldn’t compete and therefore died.

In stark contrast, the monolithic piles of technology offered as complete solutions from proprietary software vendors look increasingly like sleepy isolated atolls whose pace of innovation is far outstripped by the technologies on the open source mainland. Of course, competition in the marketplace exerts selective pressure even on proprietary software. However, because open source software is, in general, more freely available than proprietary software, the adaptive process happens much faster. If you’re a developer living on one of those insular vendor islands, you’re often presented with a “solution” to every problem. Unfortunately, the solution is seldom best of breed and may not actually work.

In a previous life, before working on Terracotta, I was a software architect on one at the largest retail Web sites in the world. We built a software stack out of best-of-breed components, most of which were open source. We used Apache as our Web server, Tomcat as our application server, Linux (though, later, we switched to Solaris x86) as the server operating system, and many smaller open source libraries to solve specific problems like database connection pooling. We also had some very expensive proprietary load-balancing hardware and an even more expensive proprietary database server. But, everything we assembled was the best implementation of its function that we could find.

There were a number of services, however, that we couldn’t find solutions for, either proprietary or open source, that we had to build ourselves. Specifically, we were forced to build a sophisticated caching infrastructure (which, incidentally, informed much of the thinking that led to Terracotta). But, the openness of our platform allowed us to integrate our solutions into the software stack. There were a number of times when we cracked open the Tomcat source code to add our own improvements and to provide hooks for our bespoke solutions.