Eclipse Virgo Project Approved
Yesterday, Glyn Normington announced that the Eclipse Virgo project had passed project creation review, and is now awaiting provisioning; and that VMWare are now corporate committers with the Eclipse Foundation.
Eclipse Virgo will become the next version of SpringSource dm Server, which recently released version 2.0. The idea is that after a suitable code refactoring (including renaming to the
org.eclipse.virgo namespace) the code will be released as version 2.1, possibly with few other changes.
The key difference between dm Server and Eclipse Virgo is the former was licensed under GPL 3.0, whereas the new Eclipse Virgo will be released under the EPL 1.0, which will encourage more widespread adoption, as Adrian explained at the time:
The dm Server today provides a state of the art server platform for modular enterprise application development based on OSGi and the Spring Dynamic Modules (now standardized as the OSGi Blueprint Service) programming model. Enterprise OSGi, and the dm Server, have made huge advances. And yet it is fair to say that adoption of OSGi for enterprise application development does not come without a cost. Like many new technologies, an initial investment has to be made that will pay back over time. Hal Hildebrand captured the current situation quite nicely in his recent blog post on the OSGi Value Proposition.
There is a great deal of interest and innovation around enterprise OSGi and the dm Server. This interest is strongest amongst early adopters, and projects with requirements that match closely the dynamically modular nature of the OSGi Service Platform. For a mainstream development team though, who just want to build an enterprise application as quickly as possible, and with as little hassle as possible, the costs currently associated with adopting enterprise OSGi can outweigh the short-term benefits. This situation needs to be addressed before enterprise OSGi can become the de-facto approach for mainstream enterprise application development. Please note that I'm talking about enterprise application development here; if you're writing infrastructure software and need to create a "stackless stack" (Kirk Knoerschild, James Governor) then OSGi is already the de-facto approach, and fully supported by the dm Server and the associated dm kernel sub-project.
Adrian's remarks were taken out of context by some who focussed on the fact that modular systems can aid already complex systems, but are not necessary for the average Hello World type application. However, OSGi can help defeat complexity; at OSGi DevCon London 2010, Kirk Knoerschild delivered the keynote which stated that:
The complexity of software is increasing exponentially. Did you know:
- In 1990, there were 120 billion lines of code
- in 2000, there were 250 billion lines of code
- The number of lines of code doubles every 7 years
- 50% of development time is spent understanding code
- 90% of software cost is maintenance and evolution
Let's put this in perspective for what it means over the course of the next seven years. Between 2010 and 2017, we'll produce more code than the total amount of code ever written combined!
Add it all up, and there are some key takeaways here. We need something that will help us understand complex systems. We need something that help manage the complexity. We need something that will help ease maintenance. We need something that will help us deal with the natural evolution of software systems. We need something that will allow us deal with the natural architectural shifts that occur as a system grows to accommodate demand. For a long time, a central ingredient has been missing. But not for much longer, because the enterprise will get its OSGi!
Whilst it's too late for Virgo to be part of the Eclipse Helios train (due to be released in Summer 2010), it's quite likely that a new release of dm Server will happen, if not in time for EclipseCon 2010 (in March) then around the same time as the Helios release.
Do you think the move of project (and change of license) will encourage wider adoption of the product?