Part 3/Chapter 13

Development in a Funnel

Following WordPress 1.5, the software development process changed, precipitated by a version control system shift from CVS to a more modern version control system, Subversion (SVN). [footnote]A version control system is a tool for managing the changes to a piece of software, document, or other collection of information. Each change is identified by a number and the name of the person who has made the change. They are often accompanied by comments about what that change is. A version control system allows a project to keep track of changes and also to revert changes as necessary.[/footnote] The most active contributors at that time were Ryan and Matt, and when the move was made, none of the other original developers had their commit access renewed.

A committer is someone who can use the commit command to make changes to the group’s central repository. The number of people who can do this on a project varies, with projects deciding on the number of committers depending on their own structure and philosophies. The question of who should have commit access to the WordPress repository comes up again and again. There are regular threads requesting that more people be given commit access.

The move from CVS to Subversion marked a long period in which WordPress development operated through a funnel. Contributors created a patch, uploaded it to Mosquito (and later trac), [footnote]Mosquito was the first bug tracker used by the WordPress project. Later bug tracking moved to trac.[/footnote] and it was reviewed by one of the committers who committed the code to the main repository. Over time, the funnel narrowed as Matt’s focus went elsewhere and Ryan drove development. This “funnel” development style has advantages and disadvantages, and it was frequently the subject of discussion among the community, particularly on wp-hackers. The advantage of a funnelling process is that disagreements about code happen on the mailing list, before a change lands in the repository. The disadvantage is that one person has to review every patch, which frustrates developers waiting for their patches to be committed.

As WordPress began to take shape as a recognized free software project, with a defined development process and proper developer infrastructure, Ryan’s previous experience guided many of these changes. WordPress differed in that Linux has only one committer — project founder Linus Torvalds — whereas WordPress had two in Matt and Ryan. Over the years this opened up to more and more committers. The other difference is that Linux has “maintainers” who maintain different subsystems before pushing patches upstream. This means that Torvalds doesn’t review the thousands of patches that go into the kernel. He reviews a fraction of them and delegates review to trusted subsystem maintainers. Although WordPress in the future would move toward component maintainers, it never followed Linux in this manner.

There are a number of reasons that people request commit access: to speed up development, to prevent situations in which patches wait months for a review, to acknowledge the contributions of project regulars, to create a more egalitarian project structure. Adding a new committer to a project became a major decision and the project’s approach changed dramatically from the wild west days of coding in WordPress 0.7. When the project started, anyone who demonstrated some technical expertise and minimal dedication got commit access. All of those developers could commit code to the repository whenever they wanted. But as the project and the number of users grew, it became more important to have some sort of filtering mechanism. A committer is the filter through which the code is passed. When someone is given commit access to the repository, it demonstrates a level of trust. It signifies that a contributor is trusted to know which code should make it into WordPress.

Karl Fogel describes committers as “the only formally distinct class of people found in all open source projects.” “Committers are an unavoidable concession to discrimination in a system which is otherwise as non-discriminatory as possible,” he writes. As much as one tries to maintain that commit is a functional role, commit access is a symbol of trust, both in terms of coding skills and in a person’s adherence to the project’s core beliefs and ethos. A power dynamic exists between those who have commit access and those who don’t.

Committers provide quality control. To decide who to give commit access to, a project maintainer has to first find people who not only write good code, but who are good at reviewing other people’s code. This means being good at recognizing places in which code can be improved and providing constructive feedback. But there are other social skills that go along with being a committer. For one, the person needs to adhere to a project’s ideals. Within WordPress, this means being fully committed to the project’s user-first approach. Committers also need to “play well in the sandbox.” Someone may write flawless code, but if they are unable to work with others they aren’t going to make a wonderful committer. It’s important to make good choices about who gets commit access because once it’s been given, it’s difficult to take away.

In an attempt to avoid an “us and them” mentality in which committers have higher status than everyone else, the WordPress project had only two committers. This meant that everyone was subject to the same review process and the same rules. Opening it up to more people may have created dissatisfaction among those who didn’t have commit access. But by not opening it up at all, developers who felt that they could never progress within the current project structure became frustrated. So few committers in a growing project also meant a mounting number of patches that languished on trac as they awaited review.

There is a perennial tug-of-war between those who contribute to the project and those who maintain it, and even among the project leaders themselves. Who gets commit access and for how long? What sort of status is attached to commit? Should only lead developers be committers? What is a “lead developer” anyway? Over the coming years these questions play out at various stages in the project’s development.