Open source software is not free. It costs time and money to evaluate the available packages and evaluate licenses, and when you use open-source software you take on greater risk than if you developed the code in-house or purchased it from a vendor. Loads of risk! Overall, however, the cost is probably cheaper than developing your own, and may be cheaper than purchasing the software from a commercial vendor.
It may seem that I’m being equivocal on the issue. Don’t misunderstand – I have adopted or been involved with the adoption of dozens of open source packages, and for the most part they have been a significant boon to our products and services. The most notable example is JBoss, which I used to replace our old application server resulting in a huge boost to our bottom line. I can’t go into financial details but it was really, really worth it. Another extremely useful package is Eclipse, which we not only use each day for our development work but with which we have also integrated because so many other people use it. A third example is CruiseControl, which we use for our continuous build process, but which we are thinking of replacing with Hudson. But we’ll not worry about that situation in this post. Let’s talk about how to minimize risk and maximize the benefit of adopting an open source package.
When considering an open source package, it is probably rare to simply grab the code and continue to develop it in-house. Often you want the project to thrive and expand, keeping up to date with new technologies and creating and maintaining integrations with other packages as the situations arise. When you choose a package that is likely to survive for a long time, you have the opportunity to upgrade versions when your own customers or stakeholders request a feature that the open source package now offers. It takes time to integrate an open source package into your infrastructure, and it’s a good idea to leverage that initial investment over and over again. A package that is not continually evolving is a package that is destined for that open source scrap heap in the sky. Problem is, it happens – all the time. So before you adopt a particular package you must ask questions like:
- Does the project have a viable corporate sponsor? Corporations sponsor open source projects when it is strategically useful for them to do so . For example, IBM sponsors Eclipse because it is a good competitor to Visual Studio, attracts junior developers in a way that IBM historically hasn’t been particularly successful due to its corporate background, is coded in Java which has the right optics in relation to Visual Studio, and is a solid platform with a lot of community involvement. The involvement of a corporate sponsor or a viable consulting operation is usually the best indicator of the long-term success of a project.
- How mature is the project compared to its alternates? New projects gain a lot of buzz in the marketplace, but a better indicator of long-term success is that the project is still going strong long after the initial glow has faded. This usually takes a few years. If somebody else has been doing it for longer and has a solid technical infrastructure, then maybe you should consider them instead of the darling child. This is a hard call, of course.
- How active is the project compared to alternatives? Success breeds success. Count how many committers are on the project. See how active the user group is. Are people’s questions being answered? Does it look like somebody cares?
Whether or not a package has good long-term prospects does you no good if it doesn’t offer the functionality you need. Unfortunately you can’t simply go to the project website and make sure there is a check-mark beside every feature you need. The project website is like a generic RFP (request for proposal) page. If you have experience with RFPs you will know what I am talking about. Often the package claims it has or supports a feature but not in a way that you would expect. For example, “integrates with Excel” could be claimed if you can export a CSV (comma-separated values) file. Sometimes that’s good enough, and sometimes it isn’t. Therefore, you have some work to do. You must not accept any claims the project authors make about “usability” without actually thinking about the scenarios that you need to address and seeing whether they can be addressed with the software using natural gestures. You must not accept any claims the authors make about standards compliance without thinking about those portions of the standard that really matter to you. Some of the more mature standards are so extensive in scope that it is virtually impossible for an open source project to be fully compliant in the first year or two of releases. The authors really intend to be fully compliant, but they’re not going to advertise all the bits where they are not fully compliant today. They may not even know where they do not comply, either because nobody bothered to ask or because there is no suitable verifier available. Standards compliance verifiers are available for some standards, but frankly it is a thankless task to put together such a tool and people aren’t stumbling over themselves to make them.
Many XML standards, for example RIF (the Requirements Interchange Format that the automotive industry uses to exchange requirements documents) allow for arbitrary proprietary extensions. Organizations can and do make some pretty liberal interpretations of the scope allowed in these proprietary extensions. This can sometimes be an issue for open source projects. They can rightfully claim compliance with a standard, but if you intend to use them in conjunction with a commercial tool that uses proprietary extensions, then you may have problems.
The next issue you will have to address is whether the open source package integrates well with your existing infrastructure. Does it use a language with which your developers are familiar? Is it a library when you really need a standalone application? Is it a standalone application when you really need a library? Is the API (application programmer interface) well structured and well documented? Does it provide functionality that you don’t want? For example, does it listen on a port, thereby opening up a potential security hole, or failing to start if the port has already been allocated to another application?
More questions: Can the code be maintained in-house if project goes under? Are you able to build it? Do they use build tools that you use? Is the code readable and well architected? Can it be tested automatically for regression? Does it come with its own set of automated regression tests? Can you fix bugs and replace the default version of the package with your patched version? These sorts of questions help you determine the true cost of adoption of the package. Do not assume the project will be popular and well-supported in the future. Real products take hard work to maintain and evolve as their ecosystem evolves around them. Volunteers are not getting paid (directly) for their efforts. As a seasoned volunteer myself I can assure you that volunteer burn-out is not only possible, it happens all the time.
Finally, the open source license must be acceptable. GPL (GNU General Public License) is what we refer to as a viral license, meaning if you incorporate GPL code into code that you sell then you are obliged to make your own proprietary source code open and GPL. Wouldn’t your competitors love to see that happen? There are literally thousands of open-source licenses published in the marketplace right now, but most of them are similar to the Lesser GPL license. The LGPL license is not viral. It allows you to incorporate the LGPL package into a product you sell without forcing you to publish your own code. There are situations where it’s acceptable to use GPL code, especially as part of your in-house suite of tools. But tread carefully. Hire a lawyer. It may save you a world of hurt down the road.
In summary, when considering open source software, here are the questions you must ask:
- Is the project viable in the long term?
- Does the package have the features you need?
- Does the package integrate well with your existing infrastructure?
- Can you build and maintain the package?
- Is the license acceptable?
If the answer is no to any one of the those questions, move on. Find another package, or buy something from a commercial vendor, or develop the needed functionality in-house. The future of your organization depends on you making a good call.