How to ruin an open source project: Let us count the ways

GitHub official Brandon Keepers provides warnings about bad practices that can kill projects

There are lots of ways to kill an open source project, and there's plenty of blame to go around. Both project maintainers and users are culpable, one GitHub official believes.

During a cautionary presentation Wednesday entitled "99 ways to kill an open source project," Brandon Keepers, who heads up open source efforts at GitHub, cited a myriad of ways things can go wrong because users or maintainers take the wrong steps. In Keepers' presentation at the O'Reilly Open Source Convention (OSCON) in Portland, Ore., he cited a list of how-tos for ruining an open source project.

Participants can do things such as avoid giving constructive feedback, which ruins maintainers' motivation, Keepers said. "We don't report errors, we run into problems and say, 'well it must have just been my problem, it's just my machine …. Somebody else will report it.'"

Participants also can ask lazy questions or not read the documentation. Then if maintainers do not respond to a user's issue quickly enough, users can spew hatred at them, Keeper said. "We forget the fact that [maintainers are] doing this in their free time and volunteering."

For their part, project maintainers can make it difficult to "understand what a project even does," which ruins the confidence of users, Keepers said. They can be make it difficult for users to even get started. "The simplest thing: We don't tell them how to use it." Instead, maintainers can expect the most-sophisticated users to figure it out on their own. Maintainers also can make a project unconfigurable or require excessive configuration.

Making releases unreliable and avoiding release road maps also can cause problems. "We all know that we don't actually like to plan new software, right? Actually I think we call that being agile," said Keeper, taking a bit of a swipe at agile methodologies that do not preplan an entire project. "But really, what's more agile than not having a plan at all?"

Other problems include delaying releases with critical bug fixes, making breaking changes in minor releases, and not providing an upgrade path between versions. Not mentioning known limitations of a software project is also a problem.

Maintainers also can ruin the integrity of code by introducing legal ambiguity and not applying a proper open source license, Keepers said. Violating patents, copyrights, or trademarks are issues as well.

Maintainers can ruin the reputation of a project by attracting users before the project is ready or choosing offensive or unpronounceable names for projects. "Un-Google-able names" also can be an issue, said Keepers, citing two projects that have garnered attention: the Rust and Go languages. These are great projects, but it's difficult to find information about them, he argued. Avoiding the marketing of a project is a mistake too, Keepers said.

The trust of the community can be ruined by exerting excessive control, ignoring concerns about a project, and poorly managing contributions, said Keepers. Another hindrance is failing to show appreciation for contributors.

Inappropriate behavior in online discussions that goes unchecked by maintainers is another problem. "The Internet can be a really horrible place," with people marginalizing women and minorities and ridiculing non-English speakers, Keepers said. Project newcomers also can find themselves ridiculed.

Most of the categories for ruining projects are akin to subtle non-events, such as the absence of information. These "paper cuts" are small offenses but can build up over time and destroy the community around a project and burn out maintainers, Keepers said. Maintainers need to set up good patterns for software projects, he stressed.