There are many examples in software development of open source products introducing useful concepts and approaches that are later standardized. It is often the case that the creative developers behind the most successful open source products can deliver innovative features much quicker than a standards committee could ever hope to do. Standards are, by their nature, more difficult to create because they require consensus of so many different organizations and people with different agendas and ideas of what is best. However, standards creators can adopt tried and proven features introduced by open source (and commercial) offerings once the value of the features is proven.
Ironically, once a standardized approach provides the desirable features originally offered by the open source project, the open source product's future is often eclipsed by that of the standardized approach. In this blog entry, I'll look at some of the open source products that have provided great benefit to only be overtaken in use by the standards they inspired. I will also look at some open source products that managed to survive and even thrive against the standardized competition offering the same features. From these products, I will observe what I believe makes these products successful.
XDoclet and Apache Commons Attributes
XDoclet is one of the most obvious examples of an open source product providing a useful feature, but being "overcome by events" when standardized approaches adopted that feature. XDoclet's popularity rose rapidly as J2EE (before it was Java EE) developers recognized many benefits of being able to annotate source code to have deployment descriptors and boilerplate interfaces generated from the source code. However, once annotations were formally added to the Java programming language with J2SE 5, use of XDoclet fell precipitously because its main benefits and features could be achieved using standards. XDoclet's main page currently shows its "Last Published" date as 5 May 2005 and its most recent news item is dated 23 October 2004 (XDoclet 1.2.2 released).
Like XDoclet, Apache Commons Attributes became less necessary with the adoption of annotations in Java. As of this writing, the last news update on the Commons Attributes page is dated 3 August 2006 (release of Attributes 2.2) and the "Last Published" date is 1 August 2007. According to Jürgen Höller's presentation Spring 2.5 on the Way to 3.0, it appears that Spring 3 will "prune" Commons Attributes support.
Of course, not everyone is using J2SE 5 or Java SE 6 and many legacy Java applications running in newer JREs may not have been ported specifically to use new features, so it is not surprising that XDoclet and Commons Attributes are still used, albeit at a much lower rate than in their peak years.
Log4j
I must admit my surprise at the resiliency of Log4j despite the introduction of many Log4j-like concepts with the JDK 1.4 introduction of java.util.logging as a standard, built-in approach to logging from Java applications. The "Last Published" date for the main Log4j web page is, as of this writing, 1 September 2007, and the latest news item is dated 29 August 2007 (release of log4j 1.2.15 and log4j extras 1.0).
Although I know many developers on applications using JDK 1.4, J2SE 5, and Java SE 6 that still prefer log4j (because of features in Log4j that are not in java.util.logging), the lack of recent changes to log4j and the changes of direction involved with Log4j 1.2, Log4j 1.3 (abandoned), and Log4j 2.0 (experimental) lead me to believe that some of the steam is running out for log4j. This may be partly due to the feeling that there is not much more that needs to be added to an already useful logging tool, but it may also be due at least partially to the existence of the standardized java.util.logging package. The standard Java logging package has started to add numerous useful features such as the ability, via JMX, to set the logging level dynamically and remotely.
Another open source project, Apache Commons Logging, allows developers to use both or move between Log4j and java.util.logging. The presence of this project illustrates that log4j has not gone away.
JDOM
JDOM was wildly popular for some time because this non-standard library was so much easier to use than other available approaches. In particular, JDOM's strategy of supporting Java-specific APIs rather than the more XML-general APIs supported by alternatives made it much more approachable for a large number of Java developers.
JDOM's latest news entry is the release of JDOM 1.1 on 18 November 2007. While JDOM still seems to be used on a large number of Java-based projects, most of my anecdotal experience has been with new applications using more standard approaches such as Java API for XML Processing (JAXP) and Java API for XML Binding (JAXB). JAXB, in particular, does a nice job of abstracting XML specifics so that Java developers can focus on using Java objects bound to XML rather than on the XML. The addition of XPath support to Java with the javax.xml.xpath package has provided Java developers with yet another standard approach for querying XML from Java.
Hibernate
Hibernate is one of the best examples of a non-standard open source project becoming a de facto standard. Hibernate might be most simply described as a Java object-relational mapping (ORM) framework. Hibernate heavily inspired the newer and actual standard Java Persistence API (JPA). Hibernate has remained a major force in the ORM world partly because its developers made the decision to tweak Hibernate to provide a JPA implementation. In other words, rather than Hibernate competing against JPA, Hibernate is an implementation of JPA.
Spring Framework
Spring Framework founder Rod Johnson's book J2EE Design and Development (and its sequel J2EE Without EJB) not only laid the groundwork for the Spring Framework, but also had enormous impact on the enterprise Java community. Not only did the Spring Framework help bring inversion of control (IoC) and dependency injection (DI) into the Java mainstream, but the framework also helped reinforce the benefits of using regular Java classes rather than numerous interfaces and class inheritance hierarchies.
JSR-220 adopted many of the features that were most popular in Spring and incorporated them into EJB 3 and Java EE 5. These improvements made Java EE much easier to use, but I believe that many enterprise Java developers are still jaded by their experience with EJB 2.x and have not adopted Java EE 5/EJB3/JPA as quickly as one might have expected.
Besides the fact that negative experiences with EJB 2.x may have jaded many of us and turned us cynical about EJBs, I think there are other explanations for Spring's success despite Java EE adopting many of Spring's concepts and features. These reasons for Spring's success include its great support for reducing boilerplate code related to Java APIs such as JDBC, JMX, JMS, RMI, and many others. The Spring Framework has continued to offer cutting edge features like OSGi support to continually differentiate it from more standard alternatives. Also, once many developers had switched from EJB 2.x to Spring, it would require enough pain or dissatisfaction with Spring to return to EJB.
I am curious to see if recent SpringSource announcements regarding their new Enterprise Maintenance Policy and their new licensing models for new products and the recent blogs questioning the openness of Spring impact the number of developers and applications using Spring. While I believe that these developments undoubtedly will turn a certain number of developers away from Spring, the real question is how many that will be. It is highly possible that Spring will lose a relatively large fraction of users/developers, but that SpringSource will still be monetarily better off with the smaller user base. I believe that these recent developments in the Spring community may be enough of a reason in some developers' minds to try out alternatives, including returning to EJB.
Other Examples
There are many more examples of where an open source product has brought forth great innovation, has inspired or directly fed into a standard approach, and then has fallen by the wayside as the standard alternative satisfies the same needs in a standard way. Examples include Doug Lea's util.concurrent library (fed into and replaced by java.util.concurrent package) and MC4J (replaced largely by JConsole and VisualVM, which are delivered with Sun's Java SE 6 JVM).
Observations
From this quick tour of open source products which have had more standardized approaches adopt some of their biggest benefits and most valuable features, a few observations can be made regarding what keeps these products alive.
1. Open source frameworks and toolkits that offer more than the standardized version offers may survive because they do offer these "extras" that make using the less standard product preferable even to using the more standardized product. Examples of this include log4j providing more than java.util.logging and Spring Framework offering more than just the dependency injection and POJO-orientation now available in EJB3. Other examples include the continued popularity of Apache XMLBeans and Castor despite the availability of standardized JAXB.
2. Strength and commitment of the open source product's community also have an effect. The commitment and interest of the primary developers of the open source product are particularly important in the success of the product when more standardized approaches offer many of the same benefits. The open source products must continue to innovate and offer features the standard counterparts don't.
3. Perhaps most importantly, an non-standard open source project is most likely to survive once a standard alternative adopts it best features and concepts if the open source product is willing to adapt to complement the standard approach and add value to it. This is the strategy that Hibernate seems to have taken and it is true (even if not all that common) that the Spring Framework can be used with a Java EE application server and with EJBs.
Conclusion
Because standards bodies are, by their nature, almost always going to generate innovation at a slower pace than a few creative and like-minded individuals can, it is not surprising that standards have and will continue to adopt some of their best features from proven open source frameworks. Also, because many of these open source projects are started simply because a (usually painful) gap is identified in the existing standards, it is also not surprising that many of these projects will be less necessary once the standard alternatives do adopt the features they provide. In fact, I think there are few things that can be more satisfying to the ego of an open source product founder than having his or her ideas accepted enthusiastically and adopted into standards, even if it means a lessening importance of his or her open source product. However, anyone starting an open source product to satisfy a glaring omission in the current standards implementations must realize that his or her success will often be the very thing that eventually leads to that very product losing its significance in the software development world.
Additional Resources
* Open Standards, Open Source
* Open Source and Standards
* Open Source and Open Standards
No comments:
Post a Comment