This is why your open source project is failing

At OSCON this year, Red Hat's Tom Callaway gave a talk entitled "This is Why You Fail: The Avoidable Mistakes Open Source Projects STILL Make." In 2009, Callaway was starting to work on the Chromium project—and to say it wasn't a pleasant experience was the biggest understatement Callaway made in his talk.

Callaway said he likes challenges, but he felt buried by the project, and reached a point where he thought he should just quit his work. (Callaway said it's important to note that Chromium's code is not bad code; it's just a lot of code and a lot of code that Google didn't write.) This was making Callaway really frustrated, and people wanted to know what was upsetting him. Callaway wanted to be able to better explain his frustration, so he crafted this list which he called his "Points of Fail."

While Callaway didn't intend to become famous from a single blog post, people did find it and started to read it and discuss it. The list that was just a way to get some relief from frustrations led to speaking invitations, articles on other sites, and even a grading matrix for open source classes. Before diving into his points of fail, however, Callaway wanted to define success. Having people use our software is one measure of success. Next (and my favorite to talk about) we need healthy communities in order to be successful. We want people to help improve our products, help each other, and ship regular releases. Finally we want our work to be "distribution friendly." A "distribution friendly" open source product is one that is pre-packaged, Callaway said.

Most Linux users still receive most of their software from their distributions' package sets. This is the first place people are going to look when they're seeking out new software. After he'd explained success, Callaway addressed some of his points of fail:

• If your codebase is too big, it's going to limit who's going to be able to download your code.
• There is no good reason in 2015 for a FOSS project to not have public source control. This helps people contribute and determine the health of your project based on the date of the last commit.
• If your source control has no web viewer and/or no documentation, these two are obvious things to have
• Code that doesn't build is worse than no code! You need documentation on how to build the project from the source.
• Use build tools
• Bundling is not going not be maintainable. Bundling leads to forking.
• Forcing people to install only in a specific directory

Callaway said projects fail:

• If your code depends on Microsoft Visual Anything (you get 100 points of fail)
• If your project is hosted in a system without redundancy or in a computer in a closet or under a desk
• If you lack communication tools (a mailing list, website, and/or bug tracker)
• If your code is a fork of another project and your primary developers were not involved in the parent project
• If your code was proprietary before you open sourced it (you cannot change the past)
• If your code does not have consistent licensing
• If your code doesn't have any documentation
• If most mailing list posts are met with silence, snark, or insults
• If more than 50 percent of your contributors work for one company
• If you code doesn't support localization
• If you don't have governance or you depend only on the company that released the code for governance

My favorite part of this talk was Callaway's passion for the items on the list. Take heed of these if you're involved in an open source project. You can view all of the points by reading the original blog post.

This article is part of the OSCON Series for OSCON 2015. OSCON is everything open source—the full stack, with all of the languages, tools, frameworks, and best practices that you use in your work every day. OSCON 2015 will be held July 20-24 in Portland, Oregon.