9 things to look for in an open-source project

Not all open-source projects are created equal. There are plenty that have not been touched in years -- heck, I probably wrote a few of them. If you're going to rely on a community-contributed open-source project, you'll want to ensure the code is up to your standards and that the community will continue to support it throughout the project's life cycle.

Although there is no litmus test for "good" open source, there are several common, language-agnostic indicators of a healthy project:

1. Update frequency. The most commonly cited metric is: When was it last updated? A year ago? A week? An hour? You don't want to inherit a stale codebase. The last update isn't the only thing you should be looking at, though. How frequently is it updated? Is development occasional or continuous? Do changes occur on the weekends (suggesting a hobby) or during the week (suggesting a business)? On GitHub, most of this information is presented as graphs.

2. Issues. Issues and bug reports are good things -- really. If you find an open-source project with no open issues, that doesn't mean it's perfect. In fact, it often means the opposite. A vibrant support community with heated discussions and an endless list of proposed features means you've got lots of eyes reviewing the code and driving its development. Open issues are great, and closed issues are even better.

3. Forks, stars and downloads. Each distribution platform provides its own metrics to describe popularity. On GitHub, watchers, stars and forks are the strongest indicators of a project's popularity and use. On WordPress.org, on the other hand, you can see the number of downloads a plugin has received and its average user rating. If a project is distributed via a package manager (e.g., RubyGems.org or NPM), you can see the number of installs. Those indicators show how much the project is used, but be careful not to confuse adoption with quality.

4. Documentation. How is the project documented? Is it simply written up in a readme.txt file or via a dedicated documentation site? Documentation that glosses over technical assumptions (e.g., how to install, requirements and dependencies) often indicates more casually developed software. Dedicated marketing sites (e.g., Jekyllrb.com) show that the project maintainers are serious about getting their code into the hands of users and thus are more likely to support it.

5. Organization or user. Who's behind the project? If it's an individual, what's his or her day job? Is he or she an expert in whatever the thing does? Does he or she have a vested interest in maintaining the project down the line? Being backed by a company or organization can be a good indicator of quality and stability, but first take a look at the author's other work. Does he or she understand open source or is this simply an effort to generate good will toward his or her brand? On GitHub, the owner's name precedes the project name in the URL. Simply drop the project name to see what else the developer is working on.

6. Number of contributors. Is the project a solo act or a team effort? Having a long tail of contributors indicates that there is a community of users who rely on and care about improving the software. Contributors need not be only technical. Look at those contributing to documentation, posting in the support forums, or filing issues and feature requests. Look closely at the community's values and how it makes decisions.

7. Who else uses it? There are lots of open-source projects that can meet the above criteria, but if none of your peers is using the project (or worse, have not even heard of it), that could be a major red flag. Many companies proudly showcase their open-source projects, and Google searches can often reveal those that don't.

8. License. Is the project properly licensed? Does it contain a license file or just a reference to a license in the readme.txt file? Do files contain the proper headings where required? The strictness with which the software is licensed and the type of license used can indicate how familiar the publisher is with open source and how serious he or she is about providing you with unburdened intellectual property. Most important, make sure the license is compatible with your project and goals.

9. The code itself. Nothing beats a technical expert opening the hood and poking around. Did the developer follow the language's common conventions and design patterns? Did he or she use a framework or build everything from scratch? Did he or she use a package manager? Even if you're not a developer, take note of whether comments are clear and free of misspellings and whether the project includes extensive tests. Projects get bonus points for using a continuous integration platform such as Travis CI, which shows a commitment to releasing quality software.

Remember: Software is written by humans for humans. When in doubt, ask. Developers want you to use their software and will be glad to help. Open an issue requesting information on the project purpose and status. Ask questions such as: Is it a fun hobby or will it be around in a year? Who else is using it? Should I base my business or critical mission on this?

There's good software and there's bad software, and luckily, open source provides us with a handful of built-in metrics to gauge a project's quality and longevity, even without reading a single line of code. Before bringing open-source code into your next project, if you don't know the author, be sure to take a closer look.