Is Open Source Always Better?

The obvious answer, of course, is "No." Anytime that a word like "always", "never," "absolutely," or "necessarily" is used in a question like this, the answer will almost always be no because there are very few absolutes in software development. The more interesting question is whether the fact that a particular product, service, or library is open source is an advantage or disadvantage in selecting that product, service, or library for use. As with many questions of any significance, any reasonable answers usually begin with "It depends ..."

The question of whether open source is inherently a positive or a negative comes up repeatedly. It came up this week in Adopting a Java Persistence Framework: Which, When, and What? The author, Sharad Acharya, states in this article that one of the liabilities of using open source Hibernate is that it is open source. This led to multiple feedback comments expressing surprise that open source was being used as a liability. In my experience, many developers have an extreme position on open source always being better than proprietary products while managers, customers, and other stakeholders often have an extreme position against open source because of support concerns, licensing concerns, etc. As open source products such as Linux, Apache HTTP Server, and Apache Tomcat have become pervasive, the one side has softened on its stance against open source. Many of my colleagues in software development, however, still seem to think of open source as always and absolutely superior to proprietary products.

Before going on, it is important to emphasize that open source does not necessarily mean free. Open source also does not necessarily mean standards compliant or imply any compliance to any specification. It so happens that several open source products happen to be both free and compliant to some standard or specification, but not all open source products are. Therefore, if a person argues that open source is superior to proprietary products because the open source has lower licensing costs or because open source is standards compliant, the argument is flawed.

It is important to understand so-called "Free Beer Versus Free Speech" differentiation to understand how and why not all open source is free of license costs. In fact, for a company that generates proprietary software, some open source licenses (such as the GNU General Public License) may be considered far more costly in the long run than a proprietary product's license. While an open source product is not necessarily free, it is also true that a free product is not necessarily open source. For example, Oracle provides both JDeveloper and Database Express Edition free of charge, but neither of these highly useful products are open source.

I really like the JFreeChart charting library and it is open source and it is free of license cost. That being stated, there is no implication in any of the JFreeChart documentation that I have seen that JFreeChart conforms to any particular standard or specification. In fact, I cannot even think of what standard or specification would be applicable to it.

Another important caveat in any discussion on open source is to point out that there is such a thing as proprietary open source, meaning that the code can be viewed, but the product itself is highly proprietary and in many of these cases requires licensing fees.

What conditions lead to "open source" being a positive or negative attribute of a software library or product? Off the top of my head, the following dependent conditions come to mind:

• Are clients, customers, management, and other stakeholders comfortable with the idea of open source software used in their applications?


• Does use of the open source product mean that we must make our product open source as well?


• Realistically, will we ever want or need the ability to view the source code for this product? Even more importantly, are we willing to make changes to the open source third-party product knowing that we will have to maintain these changes as new versions of the open source product appear that may address this problem or bug in a different way?


• If we are willing to change the open source product's code for our use, does this bind us to releasing the code to others as well and can we live with that?


• Is customer support important for this product and is it readily available at a reasonable cost?


• Is adequate, or even good, documentation available for this open source product or are our developers going to spend more in labor costs learning this product than the licensing fees would be for an easier-to-use and better documented proprietary product? Note that I am not saying that proprietary or closed-source documentation is necessarily better than that of open source. Instead, I am talking about a case in which a particular closed-source proprietary product has significantly better documentation than its free, open source counterpart.


• What is the nature of the community behind a particular open source product? Is it one person or a large, thriving community?


• When was the project last updated? If it is December 2007 and the last time the project was updated is September 2002, you might want to think carefully about using this product. This is especially true when the project's main page has a "Current News" or similar section with the latest entry being several years old. Some open source products die with little or no fanfare.


• Does the open source product offer features not offered by proprietary software (and would you miss them if they are not offered)?


• Does the open source product offer all of the features offered by the proprietary product (and would you miss them if they are not offered)?


• Is the open source product just as proprietary as the closed-source project with the only difference being that one can see its code?


• Are there considerations that my customer, client, or other end user has that encourage or discourage use of open source products in their software? For example, while I really like Firefox, I keep Microsoft Internet Explorer installed on my machine because there are still several sites that seem to only work on MSIE (including, not surprisingly, Windows Update).


• Is there an entity or individual which has legal responsibility and stewardship for this open source product? (Many open source products understandably exclude any legal responsibilities or warranties).


• Perhaps the most important "it depends ..." question is "it depends which open source product you are comparing to which closed-source product." In the end, I don't think "it's open source" should be used as a major benefit or liability in choosing between products unless the planned usage is likely to really take advantage of open source attributes (developers using product are likely to view and/or change code or the open source project being used is so prevalent and commonly used that advantages of thorough end user testing and enhancement requests will be realized).
.

I have had great success and have the utmost respect for several open source products including Apache Tomcat and HTTP Server, Apache Ant, Apache Struts, Apache POI, Apache XML (as well as Apache Xalan and Apache Xerces), Apache Batik SVG Toolkit, Apache FOP, Apache Log4J, Spring Framework, NetBeans IDE, GlassFish application server, Hibernate object-relational persistence, PostgreSQL database, JFreeChart charting library, JDOM, Laszlo Systems'OpenLaszlo, Adobe Flex, Ruby on Rails, Firefox, and more. In addition, consensus seems to be building around the advantages and usefulness of open source products such as Eclipse IDE and Apache Maven.

Unfortunately, for each one of the highly useful open source products identified above, there are tens or hundreds or even thousands of open source projects out there that are dead or dying or never really got off the ground. For these short-lived projects, being open source does not make up for their many other deficiencies.

Some otherwise useful open source applications lose their advantage or usefulness when the language or technology provides a viable or even better alternative. For example, when Java 5 introduced annotations, the previously highly useful XDoclet became much less useful for many of us. Similarly, while some still prefer Log4j, others have started using the java.util.logging classes introduced by Java 1.4 for logging needs. Although annotations, Java logging, and JAXP and other standardized XML parsing were part of Java even before it was partially open sourced, most of us migrated to using annotations and a large number of us migrated to using the logging utility and JAXP even though that meant leaving open source alternatives behind.

So what makes a relatively small number of open source products truly superior or at least compelling alternatives to their commercial (and typically but now always closed-source) counterparts? These factors are important to understand to separate the truly useful open source from the rest. Here are some of my observed characteristics of the most useful open source.

• Open source product enjoys large, committed community of developers, users, articles and blogs authors, etc. The poster child for this is probably the Apache Software Foundation (ASF). There are some open source project hosting sites that don't prevent anyone from starting any project. While this freedom sounds nice, it makes it more difficult for end users to separate the truly great open source from the mediocre and even poor open source. The ASF's strict policies related to project incubation and committers' involvement tend to lead to more serious projects with real futures. When the community of committers is not as large as one would like, this condition can be somewhat alleviated by committed individuals. JFreeChart and JDOM come to mind for examples of these products. However, they do boast large user communities.


• Open source product is standard or specification compliant. Many of the most useful open source products are actually reference implementations for specifications (Tomcat, GlassFish, and TopLink Essentials come to mind). Even if a particular open source product is not the reference implementation, it is most useful when it implements a specification or standard. Otherwise, it is not all that different from the often castigated "proprietary" software. There are some open source products that are de facto standards because there is no specification that provides the standard. Examples of these include Ant and Struts before JavaServer Faces.


• Open source product is orders of magnitude simpler to use and apply than its commercial and/or standards-compliant counterparts. Some open source products have been wildly successful because they provided a more direct and simpler way to accomplish the same results as the more difficult standards-compliant approaches. The Spring Framework, for example, gained huge popularity when developers realized how much easier it was to apply Spring+Hibernate on a web server than to use EJB 2.x. Likewise, many people still choose Tapestry or other web frameworks over JSF because of the often perceived greater simplicity of the JSF alternatives.


• Open source product offers significant features or benefits not provided by the proprietary, commercial, and closed-source alternatives. Because monetary licensing cost (or lack thereof) is a benefit, cost can be factored into such a determination. For example, JBoss was the first major application server to provide significant enterprise Java support at no license cost. Another example is JFreeChart. It is more likely though that the true benefit might be better specification compliance (Tomcat/GlassFish) or significant added ease of us or significant innovative features at the time (Spring Framework/Struts).

There are many potential advantages to open source products, but not all open source products realize all or even some of these advantages. Potential advantages of open source include (1) ability to view the code, (2) ability to change the code, (3) collaboration from many different users to get "best of breed" ideas, and (4) the ability to have far wider and deeper testing from many real users.

The advantages of open source are not always realized. Many of will rarely actually change an open source product's code for our uses. More of us may look at the code for inspiration (I like to do this with Spring Framework for example), but I think even this benefit is often overrated. Open source products can really only boast of better user testing if they are used by a large community. The one-person open source project with three end users is probably no where near as well tested as most commercial products. Another advantage often associated with open source is quick bug fixes. This really depends on the open source product and its community. The idea that open source can enjoy the best ideas from many different sources is noble and idealistic and sometimes works out as advertised. However, it often leads to disagreements, project fractures, and spun off projects competing for the same space. Again, large well-received open source software projects are the ones most likely to enjoy the advantages of many innovative ideas.

Just as not all open source products can claim to enjoy any or all of the benefits commonly associated with open source, it is also true that the better open source products tend not to be saddled with many of the common complaints about open source projects. For example, poor documentation is often cited (and in my experience is a real issue) as a negative of many open source products. The better open source projects tend to be better documented and often even have strong third-party documentation in the forms of books, articles, blogs, and other real user documentation.

I have been the beneficiary of many fine open source projects, tools, and libraries. I appreciate the long hours that many developers and users have put into making some of these open source products that finest product available in their respective areas. With that stated, I'll also add that a few of us among the development ranks have become to used to thinking that open source is always and necessarily better than closed-source (which we often equate with license costs).

As with most things in software development, there is no solid rule of thumb and we need to use engineering judgment and compare products on a case by case basis and evaluate these products against our own peculiar and particular needs. The only thing that I would feel comfortable saying absolutely about this is the politician-friendly statement: "In general, with all else being equal, I prefer open source products." It is rare that "all else is equal" and the "in general" gives me an escape route for a few exceptions even to this rule of thumb. Some people consider "open source" an automatic advantage, some do consider it an automatic disadvantage (though I think the number of people in this group is shrinking thanks to many successful open source projects), and the rest of us realize that "open source" or "closed source" is only one piece of the overall package that should be considered when evaluating and selecting products that best satisfy our customer needs.

I have never even looked at any source code for some of my favorite open source projects, tools, and libraries, but I have directly benefited from the ability and willingness of others to view and change source code in these products. Even more commonly, I have benefited from the wide use and "real life" testing of these products. So, while I generally look favorably upon open source, I also realize that slapping the "open source" label on a poor product does nothing to make it a better product and that there are situations where certain individuals don't see the advantages to open source and might even see it as a liability.