So much open source, so little time…

The three key things to consider when you are selecting open source

The Free Software Foundation recently updated its license recommendations guide. While there are a lot of developers looking to license their creations under open source licenses-with new projects popping up at a rate of hundreds per day-there are many more developers selecting open source components for apps and stacks they are stitching together.

For the latter, what factors should you weigh in selecting amongst the half million available open source projects? Licensing is a concern and may be the key factor, but there are other very important considerations as well. If your company has a particularly comprehensive open source policy, that should guide you, however only about 40% of companies even have formal policies.

1. Licensing

As with most things in life, it depends...in this case on the intended use and licensing for your project. Will your software ever be distributed and, if so, under what license? If you will distribute open source, lean towards the same or compatible OSS licenses. For distributing under a commercial license, avoid "copyleft" or "reciprocal" licenses like GPL family and Mozilla Public License.

Generally, when mixing copyleft code with your own, you may only distribute the resultant under the same copyleft license, which requires making the source available. Better choices are permissive license like the BSD, Apache and MIT licenses that primarily just require you maintain attribution in the code.

Building an application for your own or your company's internal use? A reciprocal license is fine, so licensing shouldn't be a big factor. Do take the long view, however, when considering this. Many an internal tool eventually gets rolled into a product, so work out appropriate licensing now lest you have to rip out code later.

A "tweener" use model is a customer-facing application, SaaS or free. Generally, users accessing your code via a browser does not raise licensing issues, however, there is a class of license aimed at this scenario. AGPL is the best-known example; its obligations are triggered on users' "interacting with (an application) remotely through a computer network."

2. Security & Quality

Particularly if you are developing an outside the firewall facing application, security is a concern.  At minimum you should review a component's known vulnerabilities in the NVD (National Vulnerabilities Database) to see if there are issues impacting your implementation. Also, quality is always a consideration, so you need to assess code quality as well.

There is nothing inherently insecure or buggy about open source. In fact, as per Linus' Law (formulated by Eric Raymond), "Given enough eyeballs, all bugs are shallow." Raymond's point is that popular projects are well tried and tested, thus tend to be less buggy and more secure. So, a simple proxy for quality and security is project popularity.

3. Community & Support

Open support scenarios vary widely. Companies have built businesses around supporting some packages-Red Hat being the clearest example. At the other end of the scale are projects with a single developer. Typically open source is supported by a community and active ones can do a terrific job. Post an issue on the project's bug tracking system or forum and a developer half way around the world may fix it or send you a workaround while you sleep.

Ergo, be sure to consider community and support when picking a component. It is also the case that open source is built for do-it-yourselfers, so if you are inclined that way, you need not depend upon others. On the other hand, if you are looking for some hand-holding, you should favor projects for which commercial support is available.

Conclusions

Licensing is an important consideration, if you intend to distribute software. In all cases, do your diligence to find solid software with an active community and appropriate level of support for your needs. This requires some research, but that small investment pays off in avoidance of downstream problems and reduced maintenance costs.

How do you do this homework? The open nature of open source means that project pages on forges are loaded with information (albeit often in a raw form). It's also a great idea to talk to colleagues (if your company tracks who's using what open source) or other developers in the community. Finally, there are free web resources like Ohloh.net (owned by my employer), that aggregate this kind of information across projects.

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.

Copyright © 2011 IDG Communications, Inc.

IT Salary Survey: The results are in