Four Considerations When Using Open Source in Production

IT staff and developers often overlook non-technical considerations that are critical when running open source on a production system.

Most IT staff and developers have no problem technically evaluating open source software.  However, they often overlook other considerations that could mean success or failure of a production system.

Here are some of the top non-technical issues you should consider for any open source that will be running in your production environment.

1.    Understand ALL the licenses

Most people realize that they need to understand "the license" associated with a piece of open source software, but most people don't realize there's often more than one license associated with individual open source packages.  

Open source packages often bundle other open source components, which may have different licenses.  There are also many cases where a package includes specific files or pieces of code under different licenses.  You need to find, review, and follow ALL of those bundled licenses.   For example, if a project is licensed under the Apache License but includes other open source code provided under a GPL license, you must comply with each of those licenses for the relevant portion of the software.

2.    Vet the project and community

Just as you would vet a proprietary software vendor, you need to do the same with an open source project or community you are considering.  You'll want to know the size of the community; how long the project has been around; whether patches and updates are regularly released; and how actively it's supported through community forums and mailing lists.

It's not unusual to find code from "dead" projects backed by one uninterested developer in major open source repositories.  You may decide that you're comfortable using open source code from an inactive project and self-supporting it, but you'll want to make sure that you've made an informed decision.  You can research more about the open source projects you use on sites like olex.openlogic.com and www.ohloh.net.

3.    Watch out for incidental distribution

Many IT organizations believe that the copyleft clauses of licenses like the GPL do not apply to them because they do not sell software.  However, it's highly likely that some of the applications you develop are distributed outside the walls of your organization.  It might be an iPhone application on your corporate website, tools for partners, or software that's embedded in a product you give to customers.

You can still use open source in these situations, but it's critical that you understand exactly what open source is being used and that you comply with the relevant licenses.  Many of the companies that have been sued over violations of open source licenses were not even aware that they were distributing open source software.   Don't let it happen to you.

4.    Don't forget about support

For any open source software going into production, you'll need to consider the level of support that's needed.  In the case of small libraries where you have extensive in-house expertise, self-support using community mailing lists is a reasonable option.   If you don't have internal expertise, or you need help with more complex and critical systems, then you may want to consider other support options.

There are a variety of companies that can assist with support, including vendors dedicated to a single open source project, system integrators, and support aggregators that support many different open source projects.  Don't forget to shop around since it's a competitive market and you'll likely find options at a variety of price points.

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.
Now read: Getting grounded in IoT