Peter Westwood became a core committer in July 2007, bringing the number of people who could commit code to four. Westi got involved in the project in 2004 while working as a software engineer — he had written a script that downloaded WordPress and installed it on a server. He helped with the Codex, and found and fixed bugs. Like many other developers, he had little PHP experience when he came to the project.
The wp-hackers mailing list was in its third year, but productive discussion there diminished over time. More and more decision-making happened elsewhere. For example, in February 2007, Ryan integrated phpmailer with WordPress. The code was committed after a short discussion on trac. It wasn’t until September that a phpmailer conversation took place on wp-hackers — one that few committers participated in.
Exchanges on the mailing list inclined less toward development, and more toward meta-discussions about the mailing list itself, from the high signal-to-noise ratio, to ideas to improve mailing list etiquette.
Andy Skelton wrote about the problem with wp-hackers:
There is just one thing I want to make clear about wp-hackers: a hacker is not someone who discusses or pays lip service or dissents or casts a vote or says what can or should be done. Hackers aren’t committee members. Hackers are more interested in proving what can be done than arguing about it.
There was too much talking and not enough hacking on wp-hackers, and opinion often swayed conversations rather than fact. Mailing lists can become dominated by people who have time to comment, rather than those doing the work. The latter might have the most valuable feedback, but they’re often too busy to keep up with a high-traffic mailing list.
WordPress isn’t alone in this phenomenon. A 2013 study of the Apache Lucene mailing list (PDF) found that “although the declared intent of development mailing list communication is to discuss project internals and code changes/additions, only 35 percent of the email threads regard the implementation of code artefacts.” As well as discussing development, mailing list participants discussed social norms and behavior. The study also found that project developers participate in less than 75 percent of the discussions, and start only half of them. Developers prefer to communicate on the issue-tracking software — a finding resonant with WordPress, as developers ultimately switched from the mailing list to WordPress trac.
Mailing lists tend toward bike shed discussions, [footnote]The notion of a bike shed was popularized in FOSS projects by Karl Fogel. In his book, Producing Open Source Software, he reprints an email from Poul-Henning Kamp to the FreeBSD mailing list with the title “A bike shed (any color will do) on greener grass…,” in which Kamp uses the “painting the bikeshed” analogy to describe discussions on the mailing list.[/footnote] a term derived from Parkinson’s law of triviality:
Parkinson shows how you can go in to the board of directors and get approval for building a multi-million or even billion dollar atomic power plant, but if you want to build a bike shed you will be tangled up in endless discussions.
An atomic plant is so vast that only very few people can grasp it. The board of directors assume that somebody has the knowledge and has done the groundwork. In contrast, everyone can build a bike shed, so everyone has an opinion on how it should be done, and especially what color it should be painted.
In his book Producing Open Source Software, Karl Fogel notes that as the technical difficulty of an issue goes down, the “probability of meandering goes up:”
…consensus is hardest to achieve in technical questions that are simple to understand and easy to have an opinion about, and in “soft” topics such as organization, publicity, funding, etc. People can participate in those arguments forever, because there are no qualifications necessary for doing so, no clear ways to decide (even afterward) if a decision was right or wrong, and because simply outwaiting other discussants is sometimes a successful tactic.
With its community growth and low barrier to entry, the WordPress project has been susceptible to bike shed discussions like any other free software project. A Google search for “bikeshed” on the wp-hackers mailing list displays the discussions in which someone has cried “bike shed,” as does a similar search on trac.
In 2007, for example, discussion about what to call links got heated. A member of wp-hackers asked, “Anyone know why it’s still called Blogroll in admin, when it’s called Bookmarks in functions (wp_list_bookmarks) and yet displays by default as a list of “Links” in the sidebar?” The original post, “Blogroll, Bookmarks, Links,” generated a total of 79 emails on the mailing list alone, and the discussion spilled over to a trac ticket.
Of course, one person’s bike shed is another person’s bête noire, and there were times when wp-hackers was alight with community members who insisted on giving specific issues serious consideration. One such instance was in early September 2007, before the release of WordPress 2.3, which contained the update notification system. This system alerts users when a new version of WordPress or of a plugin becomes available to install. The system collects information about the WordPress version, PHP version, locale setting, and the website’s URL from a user’s site, and sends it back to https://api.www.ads-software.com. A further piece of code carries a plugin update check, which sends the website’s URL, WordPress version, and plugin info (including inactive plugins) to api.www.ads-software.com.
For some, the data collection appeared contrary to the free software project ethos. They thought that collecting the blog URL was unnecessary. A ticket on WordPress trac requested that update checking be anonymized. Others had no problem with WordPress collecting the data, but were unhappy that WordPress did not disclose it. A number of people who didn’t oppose the changes nevertheless felt that there should be a way to opt out, so that users who required complete privacy would be able to turn off data collection.
This debate goes to the heart of one of WordPress’ design philosophies: decisions, not options. This idea is heavily influenced by a 2002 article written by GNOME contributor Havoc Pennington. Many free software user interfaces cram in options so that they can be configured in multiple ways. If an argument ensues in a software project about whether something should or shouldn’t be added, a superficial solution is to add an option. The more options one adds, the more unwieldy a user interface becomes. Pennington writes, “preferences have a cost [..], each one has a price and you have to consider its value.” He outlines the problem with too many options:
- When there are too many preferences it’s difficult for a user to find them.
- They can damage QA and testing. Some bugs only happen when a certain configuration of options is selected.
- They make creating a good UI difficult.
- They keep people from fixing real bugs.
- They can confuse users.
- The space that you have for preferences is finite so fill it wisely.
WordPress developers carefully consider the introduction of any new option, and have become better at it over time. When the data collection question arose, they were extremely reluctant to introduce new options. Westi posted to wp-hackers:
One of the core design ideas for WordPress is that we don’t introduce options lightly. The moment you think of making a feature optional you challenge the argument for introducing the feature in the beginning.
What benefit would an opt-out button for update notifications provide to users? The purpose of the notifications is to help users to stay up-to-date and secure. Adding an option to opt out of update notifications would only reduce the number of people who updated their sites, and increase the number of insecure instances of WordPress. The benefit to adding the option didn’t outweigh the cost.
Consequently, and despite the extensive discussion on wp-hackers, WordPress 2.3 was launched as planned, with the following note in the announcement post:
Our new update notification lets you know when there is a new release of WordPress or when any of the plugins you use has an update available. It works by sending your blog URL, plugins, and version information to our new api.www.ads-software.com service which then compares it to the plugin database and tells you whats (sic) the latest and greatest you can use.
The project also published the first version of a privacy policy on www.ads-software.com.
Amid these discussions, the project structure changed when Peter Westwood and Mark Jaquith became lead developers. The announcement post describes them as “a few old faces who are taking on bigger roles in the community.” Both were active committers who had taken on greater leadership roles. Both had participated in many of the more challenging discussions in the community, and they didn’t always agree with current project leadership. They both, for example, opposed Matt’s proposal for the taxonomy structure, and Mark was one of the people who voiced concerns over data collection in WordPress 2.3. They added new perspectives to the project leadership: for the first time since the early days of the project, there were people other than Matt and Ryan to help guide and shape development of both the software and the project.