A while back, I wrote a blog post about process. In that post I pointed out that closed source companies have the “advantage” of being able to control their development through the application of robust processes surrounding the SDLC. This gives them the ability to carefully manage costs (especially personnel costs) and the quality of a release. In the same post, I wondered how open source projects apply process, since the motivation of a paycheck is missing, and the distributed nature of most open source teams makes process enforcement virtually impossible.
As we’ve continued our investigation, and interviewed several open source people, it has become clear that open source projects have rejected traditional process, and replaced it with a new paradigm: the mailing list. So what is it and how does it work?
Generally speaking, an open source project conducts all its business through an online mailing list. Anyone can subscribe to the mailing list, and anyone can post to it. Because the open source community relies heavily on collaboration, everything is done collaboratively, through the mailing list.
Let me contrast a closed source process mechanism with the open source mailing list. With closed source, when a release is being planned, a product manager decides what features and other improvements he wants in the product. He documents those features in a Product Requirements Document, and passes that out to the technical management staff. There is generally a technical response document, estimating cost and schedule based on the list, and if the cost and schedule exceeds the window desired, a suggestion of a subset of the features to be implemented in lieu of the whole set. Usually through a few iterations (and probably more than a few meetings) a set of features and improvements is agreed upon, and the next step of the implementation begins. That’s process. It’s designed to give management a handle on the scope and the execution of the implementation. (It should be noted that a form of this process exists even in agile development methodologies, though it is done through multiple small iterations rather than a whole-release slug at the top, and may involve less documentation.)
Open source teams don’t (and don’t want to) use this process-bound approach. Stormy Peters talked a little about that in our recent interview: “Open source has created a different culture and so it’s created a whole different development process, and that’s what makes open source as a whole different. In open source software, they don’t hire managers who are really good at managing; technical people just pick up various responsibilities.”
So how are new features designated to be included in a release? Again according to Stormy, “ [An] idea doesn’t usually get proposed until that person’s willing to write it. It’s usually kind of assumed that if you brought up the idea, you’re willing to write it.”
Developers, then, bring ideas to the table by posting them on the mailing list. The idea gets tossed around by the community (which consists not just of developers, but of users and advisors as well). If the idea is well received, there is likely a discussion about the best way to implement the feature, and ultimately, the developer who proposed the idea does off and implements it.
The thing that makes this work, I think, is that the mailing list is utilized for all phases of development. Once the feature is implemented, the code is submitted back to the mailing list. It is scrutinized for adherence to project coding standards, tested, critiqued, probably taken back for changes and bug fixes a few times, and ultimately passed or failed. (In most cases, an open source project will have a group of “committers” who are the only people authorized to check code into the project source tree. They have the final word on whether code gets in or doesn’t.)
Stormy is a big open source proponent, while all my experience has been with closed source development. While I have no axe to grind, I know closed source process, and I don’t know the mailing-list methodology. I’m comfortable with process, and I know how to make it work for a development team. Even so, though, I get a certain sense of déjà vu when Stormy talks about the frustration of closed source process, as she does in our interview: “It’s actually frustrating to go back to the business world, and that document got printed and handed out in the meeting, but nobody emailed it around, and Fred wasn’t at the meeting and so he didn’t see it…” I get that. Process is a good way to manage a project, but is has some significant expenses of its own. My hat’s off to the open source way, at least if you’re developing open source software.
