Much has been written in columns and editorials about why organizations should, or should not, choose to use open source software. But let’s turn the question on its head — why should (or shouldn’t) an enterprise consider distributing its own software as open source?
The question of whether to use open source software is receiving the answer, “yes,” with increasing frequency. But the question of whether to distribute software under an open source license often has a less definitive answer.
The benefits of using open source software have been well documented. We’ve all heard them. Using open source software shifts investment away from third-party licenses and toward in-house knowledge workers. Open source software can be modified as needed rather than when the vendor decides to add new features or fix bugs. Open source software is more secure because its transparency encourages “many eyes” to find and fix vulnerabilities.
Critics counter that the benefits of open source are over-hyped. They argue that hidden costs in support and lost productivity maintaining the software outweigh low or no licensing fees. They question the integrity and reliability of software developed by volunteer communities compared to paid, managed employees. They suggest that open source transparency increases rather than decreases its vulnerability to security compromise.
Going Open Source
What if you’re the one deciding whether to release your software under an open source license? Suppose you or your organization has developed server software of some kind. It could be a variation on existing software — a Web server or a chat server, for example — or a new kind of server that promotes a protocol you’ve developed. In a traditional proprietary business model, the source code is the recipe that contains the product’s value. So why give it away?
- Attaching your company to high-quality, widely distributed software can produce a positive ‘halo effect’ for the brand.
- Lowering the barrier to adoption by distributing software as open source can increase its popularity. You can leverage its widespread use by selling value-added products or services, such as support, customization, or fee-based complementary software. This is one of the most common strategies and is used by popular open source vendors, including Red Hat, MySQL, and Zope.
- Open sourcing a software protocol can generate inertia around usage of that protocol, which can then be leveraged into commercial product. The instant messaging platform Jabber was developed on this model.
Choosing a License
Distributing software under an open source license does not mean you have to put it into the public domain and then lose all control over it. Most open source software includes some kind of licensing agreement whose terms define how the software may or may not be used, modified, and distributed. The Open Source Initiative approves licenses that meet several fundamental criteria.
All open source licenses support free redistribution of the original software, meaning that someone can redistribute the software without owing any royalty or fees to the copyright holder. Anyone who distributes the software must provide unhindered access to its source code, which may be distributed with the product or available in an accessible place. Open source software can be modified and redistributed under the same terms as the original license. The license cannot restrict any person or party from its terms. The license also cannot place any constraints on software distributed alongside the open source software.
These basic principles leave enough room for interpretation, given that there are more than 50 approved open source licenses. Certainly the most popular and best-known open source license (and grandfather to many others) is the GNU (pronounced “new”) General Public License, which is often referred to as simply the GPL.
Distributing software under an open source license does not mean you have to put it into the public domain and then lose all control over it. Most open source software includes some kind of licensing agreement whose terms define how the software may or may not be used, modified, and distributed.
The GPL and many other open source licenses differ most often in how they handle distribution of modifications, sometimes referred to as “copyleft.” The GPL establishes strong copyleft provisions. This means anyone who modifies the source code and wishes to distribute her modifications must do so under the same license as the original copyright. Some have described the GPL of being a “viral” license in this regard, which is considered a strength or a weakness, depending on whom you ask.
In recent years, the Mozilla Public License, or MPL, has gained popularity against the GPL. Designed by the Mozilla Foundation for its open source projects, including the famous Firefox Web browser, the MPL contains more-diluted copyleft provisions. It requires publication of source code to modifications for only a limited window of time. It is also less viral than the GPL in how it requires modifications be licensed.
Finally, there are even more liberal licenses, such as the BSD and Apache licenses. These put no constraints on modifications and allow anyone to do pretty much whatever he wants with the code.
Considering how many open source licenses are in use, and the fact that a license is ultimately a legal documents, we recommend seeking legal advice when choosing a license for your open source software.
The nature of open source software, with its building blocks out in the open, encourages community participation. While a conventional commercial software vendor may have a user community looking for product support, open source software can also cultivate an active developer community.
Depending on the nature of the software, consider encouraging developers to modify and improve the software. Or, you might encourage the development of complementary software.
Thousands of open source projects are found on the online repository, SourceForge, but only several dozen enjoy active development communities. Hundreds or thousands languish and wither on the vine, so simply putting your software out there may not be enough to draw an active development community.
To build support, identify other open source projects in areas similar to or that complement your software. Get involved in those communities and promote your open source product. Create mailing lists and message boards to promote collaboration and communication.
When Not to Open Source
It would be simplistic to suggest that releasing code under an open source license is optimal or appropriate for every project. There may be times when an open source license doesn’t make sense. For example, does the project include any code that you do not want to or cannot publish?
It may seem like an obvious question, but large projects can contain many thousands of lines of code, sometimes originating from other places. Consider the high-profile, drawn-out lawsuit between SCO and IBM. SCO claims that certain open source Linux distributions, including those distributed by IBM, contain proprietary code taken from intellectual property SCO owns. The case remains unresolved, but identifying potential problems before they turn into lawsuits is never a bad idea.
Also, consider the product’s potential audience and their preferences. For example, in some industries, enterprises are suspicious of open source software and feel more comfortable paying for licenses from commercial vendors. While some argue that these buyers are being overly conservative or old-fashioned, the fact is, if they are your market, you want to remain attractive to their desires, and if open sourcing your software could alienate them, it should be undertaken cautiously and after much scrutiny, if at all.
Despite these concerns, adoption of open source software continues to grow rapidly. There is a proven market in place, and it continues to accommodate a widening array of products.