There are many ways to mess up an open source project, and many places to blame. A GitHub executive believes that both project maintainers and users should be blamed.
In a recent cautionary talk titled “99 Ways to Screw Up an Open Source Project,” Brandon Keepers, GitHub’s head of open source projects, listed numerous ways open source projects can go wrong due to mistakes made by users or maintainers. Keepers gave the talk at the O’Reilly Open Source Conference (OSCON) in Portland, Oregon, where he listed N ways to mess up an open source project.
Keepers said project participants might avoid giving constructive feedback, which demotivates maintainers. “We don’t report bugs; when we encounter problems, we say ‘This must be my problem… someone else will report this.’”
Participants might also be lazy, ask unthoughtful questions, or not read the documentation carefully. Keeper said that when maintainers don’t answer users’ questions quickly enough, users get angry at them. “We forget that maintainers are doing this voluntarily in their spare time.”
Conversely, as for project maintainers, they might make it hard for users to “understand what the project is for,” which undermines user confidence. They might make it hard for users to even get started. “The simplest thing is we don’t tell users how to use it.” Instead, maintainers might assume that the most knowledgeable users should figure it out on their own. Maintainers might also make the project unconfigurable or require too much configuration.
Releasing unreliable versions and avoiding publishing version roadmaps can also cause problems. Keeper said: “As we all know, we don’t really like planning new software, do we? Actually, I think many of us call it agile development,” he criticized agile development methods that don’t plan the entire project in advance. “But actually, what’s the use of being agile if there’s no plan at all?”
Other issues include delaying releases for major fixes, making breaking changes in minor versions, and not providing upgrade paths between versions. Not mentioning known limitations of software projects is also a problem.
Keepers said that if maintainers introduce ambiguous legal language and don’t adopt appropriate open source licenses, they can also damage code integrity. Patent, copyright, and trademark infringement are also issues.
If maintainers attract users before the project is ready, or choose an unpleasant or hard-to-pronounce name for the project, they can ruin the project’s reputation. Keepers said that “names that can’t be found online through Google search” are also a problem, and he mentioned two high-profile projects: Rust and Go. He believes that while these projects are excellent, it’s hard to find information about them. Keepers said that avoiding vigorously promoting the project is also a mistake.
Keepers said that exercising too much control, ignoring project concerns, or mismanaging code contributions can also completely undermine community trust. Another obstacle is not showing appreciation to code contributors.
Another problem is that maintainers don’t stop inappropriate behavior in online discussions. Keepers said: “The internet is actually a scary place” where many people exclude women and minorities, and mock non-native English speakers. Newcomers to projects also often find themselves the targets of ridicule.
Most categories of project screw-ups are inconspicuous small issues, such as lack of information. While these behaviors seem harmless, over time they can destroy the community built around the project and leave maintainers exhausted. Keepers emphasized that maintainers need to set a good example for software projects.
Reprinted with permission: Developer Relations »
