In an effort to broaden my horizons beyond writing code, I've been reading a lot of business books lately. Coming from a mostly Free Software background, it's been an enlightening experience1. One thing sticks out the most: Processes matter, and they matter more than I ever thought.
It's common for me to contribute to random projects. Launchpad and Github and the like make it easy (can we get a Launchpad version of this shirt2?). However, I'm not likely to contribute to a project that has a HACKING document longer than any source file in the entire tree. If it takes me longer to figure out how to send a patch than it takes to write the patch, there might be some problems.
Here's what Brandon Hays says in his blog post Why I Still Don't Contribute to Open Source:
Guidelines often make a maintainer’s life easier, and mine harder. Yes, maintaining an open-source project is an arduous, thankless task. But I’ve looked at contribution rules/guidelines that turn a simple idea for a fix into a bureaucratic brick wall worthy of Microsoft.
Now, when projects grow large, processes are a necessity. Launchpad, for instance, has a good culture of code reviews and a relatively strong emphasis on testing. I've only heard war stories about what it was like to hack on Launchpad before those processes and guidelines were in place. I don't have enough fingers and toes to count how many times code reviews and testing prevented me from doing something insanely stupid in a proposed patch to Launchpad.
Processes aren't bad. We need them, sometimes to maintain quality, more often to maintain sanity.
Here's a personal example of a not-so-good process: Not long after Launchpad started putting more thought into how we use javascript (back in late 2008), we put together this process of UI reviews3. We already had a good culture for code reviews, and we wanted to do the same with UI. We started with one or two people who seemed to have a good handle on what good UI is, and we worked to train and graduate new UI reviewers. This seemed like a good idea, because we could gradually get everyone on the same page with regards to what good UI was.
We trained a handful of developers, and then interest waned in becoming a UI reviewer. Some people still attempted to get UI reviews, others would just ignore the process entirely if they could get away with it (and I don't blame them: attempting to get multiple reviews can be a PITA). It wasn't until a chat with Aaron Bentley that I realized the real problem with this process: We were inadvertently telling experienced Launchpad developers they didn't know enough about UI. In some cases, that was true, but in most cases, we were missing out on some great suggestions for good UI in Launchpad. Recently, Curtis Hovey proposed that UI reviews be discontinued and it was instantly ratified. Launchpad's UI has grown leaps and bounds since then.
The Patch Pilot program that the bzr team created is a perfect example of a process that promotes the Bazaar culture. One core developer takes a time out from his/her regular duties (slowing velocity) to help guide patches from the community. "Hey, we have a process for patches (and even a HACKING document, but don't worry if you don't know it all just yet. <developer> will personally guide you through the process."
Now, every time someone proposes a new process, I spend some time thinking about it more. How would this process affect culture? Is the proposed process in-line with the goals and values of the project?
Personally, I think it's best to choose people over process, but I also don't maintain any projects that have an abundance of contributors.
When in doubt, ask Zed Shaw.
1 The best book I've read this year was Harvard Business Review's 10 Must Reads: The Essentials
2 Seriously, I want one that says "Merge Proposal or GTFO" Maybe even get a picture of dobey scowling to go on the back.
3 I liked the idea of UI reviews. I'm also relatively impetuous, so it's to be expected.