The second session of the day that really appealed to me was “An Open Source Project Called “Failure:” Community Antipatterns to Know and Avoid“. When I saw that Ben and Fitz of subversion fame were joined by other open source heavy weights, I was sold on this panel. In this panel each member presented one anti-pattern in open source project, where an anti-pattern is a negative pattern that projects should aim to avoid.
Chromatic started off by talking about blocking patterns, where a blocking pattern occurs when someone in a project promises to do something, but doesn’t actually fulfill that promise. Once this happens other members of the project refrain from starting on this project themselves, because person X has promised to hack on it. No one gets motivated to work on this piece of work and it starts blocking progress in the project. Don’t let anyone get an exclusive lock on a project! Chromatic continued by giving two examples that show this anti-pattern:
- When a bug presents someone from getting work done. Certain bugs can preclude people from making progress — identifying and focusing on those bugs should keep the project moving.
- When no one makes a decision that impedes progress. Sometime continuing work depends on someone making a decision which could affect downstream work. In order to avoid throwing work away, people will wait until a decision has been made.
Josh Berkus talked about a “We don’t need no stikin’ docs” anti-pattern. While he presented his entire anti-pattern sarcastically, I’ll tell you about his pattern straight out. Josh talks about the flawed mentality that if something was hard to write it should be hard to understand. That’s obviously bogus — projects should aim to provide user documentation, contributor documentation, and developer documentation in order to make it easy for users to be drawn into the project and become contributors/developers. Josh cited SQL Ledger as the a good example — the project has been around for 10 years, but there are no free docs. You can purchase documentation, but no current free documentation exists. Lack of usable documentation prevents open source projects from drawing in new participants.
Alan talked about projects screwing around with licenses as another anti-pattern. Without licenses all projects have is shared source, that is ambiguous for use. Licenses provide a social contract that tells people what they can do with your code. Licenses also provide a legal contract suitable for defending your rights in court. While most conflicts never see court and are resolved through peer-pressure, a legal backup is necessary in case peer pressure fails. Alan gave the example of the XFree86 project that underpinned nearly all Linux distros a few years ago. Then the board of the project started screwing around with its license and added a clause that forced people to awkwardly credit the XFree86 project. With this move it started alienating its developers and a fork of the project happened shortly thereafter. Today, XFree86 has only two developers and most distros have switched over to the forked version provided by X.org.
Brian Fitzpatrick talked about the “Don’t feed the trolls” anti-pattern. He shared the case of where a subversion user found a bug and reported the bug quite acerbically. Calling the subversion developers names and insinuating much worse about their parents and grand-parents. The Subversion developers asked details about the bug, which they received along with another helping of hate. The bug was fixed and scheduled to go out with the next release. Yet, the troll continued to spew hate, but the subversion team paid him no mind since the issue at hand (the bug) was fixed. Soon thereafter, the troll left.
Ben Collins-Sussman talked about how partial subversion commit access is often times a bad idea, since it places trust into a grey zone. Often times admins of subversion repositories ask how to setup partial commit access and Ben engages these people to find out their motivations. He asks why they should not allow people to commit to the whole repository. No one is going to sneak in a change, since other developers are watching for commits. So what if a developer commits a change to some place where they should not be committing? Changes can easily be reverted, so why worry? If a developer commits code to the wrong place, someone can ascertain if that was an honest mistake or done purposefully. Either way, engage people and talk to them. Don’t solve your social problems with technical solutions!
Karl Fogel presented the “passive disinterest becomes active resistance” anti-pattern. In this pattern someone from the community suggests a feature that the developers think is a bad idea. If the developers shoot down this idea the suggester may become confrontational and become troublesome in the community. People like these may keep re-opening closed bugs and pestering developers as part of their active resistance. Rather than shooting down the idea and stopping the suggestion cold in its tracks, Karl suggests that developers should instead encourage the suggester to expand on their idea. Developers could say: “Propose your idea, but you may not get much attention for your idea. The developers may simply not implement it.” This does not block off the suggester and allows them to get the idea out, even if no one takes action on it.
I’ve seen several of these patterns in the past few years of my open source work. While some of these patterns are quite obvious (its clear documentation is necessary to draw in developers) other patterns like Chromatic’s blocking pattern may not be obvious. I’ve had this happen to me when I first started working on FreeAmp back in the day. Coming from a classical software development mentality I made a list of who promised to code what. As predicted by Chromatic, this list became a “who is slacking on this” list and hampered development until I nuked the list.
Thanks for sharing your patterns, gang!