Any Java developer, especially one who works with open-source software, will tell you that being the build monkey is a thankless job. You spend all of your time digging through Ant XML files and pulling down the proper classes and methods from constantly updated libraries and packages around the Internet and your internal repositories. Isn’t there anything that can save Java from the endless complexity of dependencies?

Well, there’s the OSGi development model, which was hailed as the enterprise developer’s way to make a modular Java server application without the never-ending burden of dependency wrangling. OSGi promises sane dependency injections with tightly integrated modular code—and the ability to hot-swap code in and out of a running application server without the need for a restart. It’s everything Java developers have asked for, right?

Well, yes and no. Yes, in that OSGi is supported by the Java industry, and in that software companies have begun building OSGi support into their servers and development tools. No, in that few enterprise developers seem to be adopting OSGi.

Why is that? We believe that OSGi, rather than simplifying server application development, has actually made it more complex, and there aren’t sufficient benefits to justify the added complexity.

The industry seems to understand the problem. SpringSource donated its DM Server to the Eclipse Foundation earlier this year to spur enterprise uptake of OSGi, and even Eclipse Foundation director Mike Milinkovich admits there’s a lot of work left to be done to expand enterprise uptake of the OSGi development model.

We’re not convinced that OSGi is worth the effort, and there’s no doubt that there’s a long road ahead. Milinkovich and Maven creator Jason van Zyl both estimated it would take OSGi another two years before the tooling and development model are friendly enough to spur uptake in the enterprise.

And what’s the benefit again? Enterprise developers have written many, many server-side Java applications without using OSGi. We believe that, unless something significantly changes, OSGi isn’t worth the enterprise investment.

Many business models
As you might expect, open-source business models were the main topic for discussion at the Open Source Business Conference in March. The conference affirmed that there isn’t one best model. There are many.

Last year, OSBC conference attendees voted on their favorite model, and they chose the dual-licensing model: That is, when a company builds a tool or application, it could offer the same bits under both the GPL license to open-source projects and another, more business-friendly license to enterprise customers who don’t want GPL restrictions.

How quickly things change. This year, the conference attendees turned their back on dual-licensing and voted Freemium as their favorite business model.

The Freemium model is all about creating great free open-source software that has one or more weaknesses that will inspire serious customers to purchase a paid version. For example, the free version may be difficult to manage on multiple servers, but the paid version will include a GUI administration console.

Are either of these models morally bankrupt from the free software perspective? Of course not. Even Richard Stallman sold archives of free software back in the 1980s in order to fund his Lisp machine project. Selling free software isn’t antithetical to the idea of “free software.”

After all, when you’re building out systems in development, you still don’t need to buy licenses just to take the software for a test drive. In the end, the secret to selling open-source software is to get that money to fund development any which way you can. Just don’t forget to offer paid services and paid support. That’s the classic model, which consistently took second place in both years of voting.