Your Open-Source Success Checklist

1. The License—The most restrictive open-source license is the General Public License (GPL), but it applies only if you intend to modify the software and redistribute it. Vendors have to make the source code for their changes available or work out a deal with the copyright owner to be released from the GPL. (The Free Software Foundation, which developed the GPL, is now in the process of revising it.) If you have no intention of distributing your modifications to software governed by the GPL, or anything integrated to it, then GPL is fine. But if there’s any chance you may distribute it outside your company, you should purchase an indemnified version.

2. The History—If the open-source project is just getting started, it may not survive. The developers’ initial enthusiasm can wane; the software may encounter bugs that can’t be fixed; users may abandon the project if something better comes along. You don’t want to end up with an orphan product, unloved and unsupported.

3. The Community—Most successful open-source projects have a leader who is respected by the developer community and is willing to delegate important pieces of the work to others. Delegation creates a healthy environment that attracts new developers. Look for projects that have a clear process for joining the community, for managing the project and for making contributions. Find the central communication core for the project (a message board or e-mail list) and read the history.

4. Code Ownership—Companies are more likely to attract capital and build trust with customers if they own the copyright to the code they support and their developers are the project managers and primary contributors to the code base.

5. The User Community—Projects involving complex software need big, active, happy user communities. Big communities mean that the software is filling an important need and that it works well enough for users to invest time trying to make it better. Small, unhappy user communities usually mean the project is poorly managed or the software is flawed. Again, check the main discussion board.

6. The Coverage—Open source thrives only when it is attractive to a large group of users. That’s why the most successful projects have been platform applications that can be used in virtually any company. Industry-specific or niche applications do not attract large communities.

7. How It Integrates—Open source is usually designed to fill a specific gap or fix a specific problem, often without concern for how the software will play with others. Check bulletin boards to see if the project’s developers are open to solving user integration problems. If they’re not, tread carefully.

8. Commercial Support—This is one of the better indicators of a project’s health. For CIOs who cannot afford to devote staff time to support, a robust commercial support ecosystem is critical.

9. Your Costs—It’s easy to get carried away when something is free. Normal due diligence for open source is still in order because implementation time isn’t free.

10. Proof of Concept—Don’t overlook open source just because it doesn’t scale or have all the bells and whistles. It can make a great testing platform or a proof of concept for a larger project that will use proprietary software.