Open Source means different things to different people. For some it's a business model. For others it's a way of collaborating. Some see it as a way of reducing costs. And some are out to change the world.

That may sound a touch dramatic, but it's a pretty accurate description of the landscape. So let's look at each of these and see if we can't point out something interesting and perhaps unexpected about how Java and Open Source are interacting.

Open Source as Collaboration
Although people gripe that Sun's Java implementation isn't Open Source (not yet, anyway), huge amounts of work have been done on software that supports the construction of sophisticated applications and platforms that is Open Source, especially under the auspices of the Apache Foundation. Having started as a simple Java servlet runner called Tomcat, the Jakarta project has blossomed into a diverse group of frameworks for common tasks, Web development, and enterprise applications.

Apache isn't the only one. One of the amazing things that even most Linux and Open Source advocates don't realize is just how much Open Source activity there is around Java. A huge percentage of the active projects listed at FreshMeat or hosted on SourceForge are written to run in Java Virtual Machines. You see the same level of collaboration in other dedicated communities including Codehaus and ObjectWeb, and, of course, the freight train known as the Eclipse Foundation.

When most people think about the products coming out of the Eclipse community, they think about the Eclipse Integrated Development Environment used to write and debug Java code. That's not wrong per se, but it overlooks the fact that Eclipse was designed as a platform to build applications on. Several major vendors have recently decided to base their products on top of the Eclipse Rich Client Platform. The next version of Lotus Notes will be built on this technology. Of course this will be transparent to corporate users, but great news for developers: as ever with Open Source, the work that Notes engineers put into improving the Eclipse platform for their own needs will benefit everyone who uses Eclipse technologies.

All of these are examples of the essence of the Open Source movement: collaboration. But why do people do it?

Open Source Reduces Costs
One of the common arguments advanced when explaining why organizations contribute to Open Source is to reduce development costs. Part of what any company does adds value - be this in terms of proprietary processes, specialized knowledge, or other unique abilities that give them a competitive advantage. At the same time, much of what has to be done to reach a point where they can provide that value is ground they share with others in the industry, and that is where collaboration, even with competitors, makes sense. We frequently see this in infrastructure - do you really need to create your own Java logging framework? No, of course not. There are already several excellent ones available (even over and above the Open Source-originated log4j that Java itself absorbed). On the other hand, if you've gone through the trouble of creating a library to do some complex yet common tasks that others have likely grunt through as well, does it make sense to maintain that library yourself, or to work with others so you can take advantage of improvements and fixes that they might make, quite frequently enabling new functionality you wouldn't have been able to afford? Really, each of these examples is nothing more than a joint venture, which is certainly a common enough structure in the business world. The next time you're arguing in favor of using an Open Source solution, you might bring this up.

And it's not just development cost. Not to be sneezed at is the fundamental premise that access to the code makes maintenance easier - and in many cases is the only thing that makes it possible. Being able to see what's going on in an application or platform is often absolutely necessary to diagnose and troubleshoot problems. This is applicable up and down the IT stack, but is particularly relevant for Java developers trying to squeeze every last drop of performance out of a heavily loaded platform. If you're running an enterprise application server, the combination of JBoss and Hibernate on top of one of the Open Source databases is hard to beat. Being able to deploy on commodity hardware and leverage non-traditional architectures has led to a price/performance ratio that's hard to beat.

Just as important are infrastructure projects. It's easy to forget that tools that are fundamental to our daily work like JUnit and Ant are Open Source - and this is a case where the price is right indeed. Further up the stack are more comprehensive tools for a range of tasks - projects like Maven (a comprehensive build and deployment tool), continuous integration systems like CruiseControl and BeetleJuice, which help automate the task of building and testing large software projects, and systems that bring knowledge together like Cargo.

That last one bears more detailed mention. One of my clients has me working on revamping the infrastructure they use to build their products and run functional tests across them. They're a Java shop, and so it's no surprise that their product, a rather large Web application, is built on Java servlets and JSP; and since they target a wide range of enterprise customers they need to test their app on as many application server containers as possible.

Not terribly unusual, but when you're trying to run automated tests, it gets tricky. Although in theory one should be able to interchangeably use different app servers, we all know that the different vendors (Open Source and commercial) who have implemented the servlet, JSP, and J2EE specs have all done it differently. Even assuming the application you're testing doesn't use vendor-specific extensions, you still have to deal with the problem of setting up, starting, and stopping the app server containers themselves. And as you'd expect, each app server has a significantly different way of being configured and run.

That's where Cargo, a project hosted by Codehaus, comes in. Working together, groups from different environments have concentrated knowledge of how to configure, start, and stop a wide range of different containers into a simple API that you can use from within a Java program or add to your Ant or Maven scripts. And this dramatically accelerates your testing.

Infrastructure, tools, automation, and testing. All of these taken together have reduced barriers to cross-platform development enabling Windows, Unix, and Linux and Mac developers to work together, helping broaden audience and use while reducing cost and complexity.

Open Source as Business Model
While some companies have leveraged Open Source as a way to reduce the cost of doing business, others have chosen Open Source as the basis of their business.

Object relational mappers are a necessary evil if you're forced to deal with a legacy SQL database system, but many developers, especially those working on small mobile or disconnected systems, have neither the resources nor the inclination to deal with such enormous complexity and in any case can't afford the footprint of such a combination on their devices.
Enter db4o.

Its Java native embedded persistence solution db4o is remarkably easy to use. Developers can be up and running in less than 10 minutes. And that's not 10 minutes of figuring out how to install the thing. That's a few brief lines of code and you've got a complete database that stores your data in the object-oriented form in which you work with it.

ObjectContainer db;
db = Db4o.openFile("warehouse.db");
// your code here. Perhaps...
Inventory a = new FastMovingItem();
q.setQuantity(400);

db.set(q);
db.commit();

And persisted! Queries are just as easy,

Inventory proto = new Invetory();
proto.setName("fruit");

List results = db.query(proto);

One of the great things about db4o is that it's native Java. You just feed it Java objects and get Java objects back out again - no need to translate your data model to some third-party pseudo-representation or any requirement to write endless metadata in XML. It does a really straightforward job of just getting on with persisting Plain Old Java Objects. No mucking around with bytecode enhancers (like JDO) and certainly none of the self-mutilation that goes with EJB.

db4o has proven really easy to use. You do have to wrap your head around the notion that you don't have to worry about foreign keys anymore - when you want a reference to another bit of data you just use a plain old Java variable because variables and instance fields are references in Java. Neat. The most remarkable part, though, has been the degree to which it enables object-oriented data models. For so long we've been forced to hamstring our domain object design in ways that are largely flat so we can shoehorn them into the legacy rows and columns of relational databases. With db4o, you can develop elaborate data models with complex object graphs and deep inheritance hierarchies and then persist that information without any fuss. Quite the productivity boost.

There have been some remarkable success stories with db4o. Intel is using it in its chip fabrication plants; it's embedded in the robots Bosch makes for food preparation and consumer goods packaging; Boeing is using it for a new multi-mission aircraft and BMW has built it into its latest cars. Customers can't say enough about the short start-up times, zero administration, and low memory footprint as they enthuse about why they chose it for their products. Not bad for a database that comes in a 400KB jar file.