There are many advertised benefits of using open source. These potential and advertised benefits include business flexibility, freedom/liberty/libre, (often) no/reduced license costs (gratis), improved security through disclosure, improved testing in real situations, improved code review by multiple reviewers (many eyeballs), high quality, the ability to learn from the code (both about how a particular product works and general coding principles), and even betterment of society. However, I have found that the realization of these potential benefits of open source depends largely on the open source product itself. Indeed, there are many open source projects that enjoy very few of these benefits.
In the remainder of this blog posting, I will look at how the nature of a particular open source product often determines the ability to realize the general advertised benefits of open source associated with that product.
Business Flexibility
It has been argued that an advantage of open source is greater flexibility in switching implementations (no vendor lock-in). However, the ability to switch implementations often depends more on the degree to which a product (open or closed) is based on standards than on whether the product itself in open source or closed source. It is certainly true that a closed source standard-compliant implementation will be easier to switch out from than a non-standard open source implementation. The standards reference implementations in the Java space are open source and therefore are good examples of open source products that do support great freedom to switch out implementation. For example, one can, in theory, easily switch from Tomcat or GlassFish to WebSphere or WebLogic or switch the other way. This does not necessarily have anything to do with Tomcat and GlassFish being open source, but instead has to do with all these products (including the closed-source WebSphere and WebLogic) implementing the same standard.
No Cost / Free Beer / Gratis
Some definitions of open source explicitly require that open source software be freely available without any limitation or cost (free beer). However, others aren't as concerned about the "free beer" aspect as they are about the "free speech" aspect of open source. Although most products that are advertised as open source do seem to be available for no cost, this should not be assumed without careful reading of the product's license. Moreover, there are many proprietary and closed source products that are also free of charge. These include products such as JDeveloper (a Java IDE that is not open source but is available without charge), Oracle Database Express Edition, Adobe Reader, Flash Player, Microsoft Internet Explorer, etc.
As another example, I was using Flex regularly back in its closed-source-but-freely-available days as Flex 2 and really liked it even then. Although I was excited to see Flex 3 open sourced, it really didn't change my use of Flex much in terms of its daily use. I was honestly more interested in Flex 3's new features than the fact that it was now open source.
As I have posted about earlier, I believe that open source contributors have a right to expect compensation for their work and creativity. This compensation for open source contributors often comes from support and service contracts, sales of documentation, sales of related books and articles, and consulting sales.
In the end, price may be a benefit of a particular open source product over a particular closed source product, but there are usually many factors to consider such as the total cost of using each product (training, service contracts, etc.). With freely available closed source products in the mix, it is certainly possible to find a situation in which use of the open source product is no cheaper than using its closed source alternative.
Freedom / Free Speech / Libre
The ability change the code is something that certainly differentiates open source from closed source. However, even this obvious differentiating benefit deserves closer examination when determining how much of this benefit is actually realizable. One consideration is that some open source licenses have restrictions on changes to open source products that are included in distributed products. In some cases, these restrictions may be deemed unacceptable, making this particular benefit unrealizable for that organization with that particular open source product.
A second consideration is to truly evaluate the likelihood of actually changing the open source product's code to suit one's own needs. It may be that an individual or organization has no qualms about this and, in such a case, they will be able to readily realize this benefit. However, if the individual or organization is reluctant to actually make changes to source code of an externally-provided open source product because of needs such as greater testing, greater maintenance costs, additional efforts to integrate with future versions of the product, and so forth, then this benefit may lose its degree of realization.
The Many Benefits of 'Many Eyes'
Several of the benefits commonly associated with use of open source products depend on the presumption of "many eyes" reviewing open source code. It is argued that open source products are inherently more secure than closed source products because there are many more reviewers of the source code. The argument of many more reviewers of code also leads to the advertised benefit of better code reviews and better quality in open source products. With many more users of the open source product, the argument continues that open source is better tested than proprietary software. Finally, another benefit often attributed to open source is a greater likelihood of having bugs fixed quicker. All of this, however, hinges on the presumption that there are indeed 'many eyes' reviewing and using the open source product. What happens when that is not the case? What happens if no one is actively supporting a particular open source product? Do these benefits still apply?
One definite advantage of open source is that one always can look at the source code directly. However, I think many end users of open source don't actually look at source code that often, but instead rely on the assumption that other users of the open source will have reviewed the code, looked for security holes in the code, and run the code in their applications. This assumption is more likely to be correct or appropriate for open source products with large communities than it is for open source products with very small communities.
Open source projects that enjoy large communities are more likely to allow potential open benefits to be realizable benefits. Large communities tend to mean "many eyes," which in turn can lead to less likely security holes, to more highly reviewed code, and to code used more frequently in a wider variety of situations and loads.
At the other extreme are the open source projects with a community of one, the open source project founder. It is unlikely that these open source products with one creator (who is also the product's only user) have anywhere near the amount of review and testing as most proprietary products.
Several people have pointed out that open source does not necessarily make something more secure. This is covered in Many Eyes, But How Many Brains?. A similar argument against stating that open source always means higher quality software is made in Open Source Does Not Make Better Code. Better Programmers Make Better Code.
Learning from the Code
This is probably the generally advertised open source benefit that most easily translates to a realized benefit. Having access to source code can be instrumental in learning how the code works. Viewing the source code can help one better understand how to use the library it underlies. For example, when Michael Martin and I were writing the article Visualize Your Oracle Database Data with JFreeChart, we figured out some minor details of the JFreeChart API by looking at JFreeChart's source code.
Having access to the source code can be useful when debugging or working on performance tuning. It can also be useful for learning how to accomplish certain things in your own code. I remember learning HTML (along with many bad habits) in the early nineties by viewing the source code of others' web pages.
All Open Source is NOT Equal
Even though I use many great open source software products and know of many more, there are many times that number of open source products out there without much of a community and without much to offer yet. It is not appropriate to lump the good and the bad together, but instead good open source should be differentiated from bad or immature open source. When considering how many immature or unused open source projects are out there, consider that SourceForge alone has more than 230,000 software projects (as of February 2009). There are several really good and useful projects on SourceForge, but the degree of value, maturity, or even level of support per project varies greatly. This is true across many open source repositories.
Conclusion
Nothing in this blog posting should be interpreted to mean that I'm against open source. On the contrary, I love using strong open source products with large, vibrant, and active communities. My only point of this posting is that it is too simplistic to argue that open source is always better than closed source. Instead, like most things in life, it is more complicated than that. It really depends on the individual products being compared. The state of being open or closed source can be considered as one of the criteria in selection, but should not normally be the deciding factor. All else being equal (or even close to equal), I typically favor open source products, but I don't blindly select an open source product over its closed source alternative simply because one is open source and one is closed source.
Most of the products I choose to use regularly are open source (Java, Flex, AIR, BlazeDS, OpenLaszlo, Ant, NetBeans, Eclipse, log4j, JUnit, Spring Framework, GlassFish, JEdit, JFreeChart, Ruby on Rails, Tomcat, Apache HTTP Server, various flavors of Linux, Firefox, and on and on). Nearly all of them have very large and active communities. Most of them also have strong sponsors (such as Apache Software Foundation, Sun, Adobe, SpringSource, Oracle, etc.) who provide staffing (in many cases) and common direction for them.
All open source is not created equal. Some open source products are really good; others aren't very good at all. In the end, my favorite open source products are the ones that can take on any closed source alternatives toe to toe and come out equal to or ahead even without considering that they happen to be open source. In those cases, I am typically indirectly and perhaps even unknowingly enjoying the realized benefits of the open source nature of the product without focusing on that open source nature. After all, it matters more to me what works best, works most efficiently, is easiest to use and maintain, is most tested, and is most easy to switch away from if needed. Open source is often a characteristic of products that meet these expectations, but not all open source products do allow these potential benefits to be actually or easily realized.
The one benefit you can count on in just about any major open source product is the ability to see and, in most cases, change the source code if necessary. This often may not be a very attractive scenario, but it is the one benefit that can be always be realized with open source and never realized with closed source.
No comments:
Post a Comment