In January 2006, a Google survey found that WordPress powered 0.8% of websites. The project was growing, and with greater adoption came greater tension. Growing pains are common for organizations — especially in democratic communities where everyone has a voice — and WordPress was not immune.
WordPress contributors come from a range of backgrounds, and include formally taught developers, self-taught hackers, designers, people doing support and writing documentation, business owners, and bloggers. Contributor diversity is one of WordPress’ strengths, but wrangling so many viewpoints brings its own challenges. Disagreements coalesce around three broad issues: approaches to development and community building, styles of communication, and opinions on who the software is for (users or developers, for example, or users and business owners).
The Shuttle project was but one example. While the participants communicated privately, hoping to streamline and expedite the project, other WordPress contributors were concerned that work was going on behind closed doors and felt cut out of an important part of WordPress’ evolution. Co-founder Mike Little was one of those vexed by the process.
In June 2005, the Shuttle project updated the write screen, introducing a new “pods” functionality that let users collapse parts of the screen. The changes were discussed only on the closed wp-design mailing list, precipitating a long discussion on wp-hackers about openness. While Matt saw the commit as a starting point for discussion, others perceived it as a wholesale change made without communication. Many in the community felt that discussion should happen ahead of the commit, and that the community should have been informed about Shuttle’s work. That was, after all, how free software projects should function.
IRC discussions focused on Matt and Ryan as bottlenecks; only they had commit access, so all issues had to go through them. After lengthy conversations about how to make the process more open, Mark Jaquith and Sean Evans (morydd) became “bug gardeners,” getting maximum trac privileges.
Inline documentation also generated heated debate. Many developers find exploring code a valuable learning tool, and there was strong community support for improving WordPress’ inline documentation. However, when Rich Bowen (drbacchus) proposed documenting WordPress’ functions, Carthik responded that inline documentation was frowned upon and would lead to bloat. Referring to a thread from May 2005, he offered:
Commenting is tricky. Some “well-commented” code I’ve seen had a bunch of lines of repetitive filler that “documented” what you could easily see by just looking at the code itself and doubled the size of the program. APIs should be documented religiously, but I think spending a ton of time on redundant comments for code only a few core hackers will ever look at will bloat the codebase and waste everyone’s time. I also believe that well-written code usually doesn’t need comments unless it’s doing some sort of voodoo or workaround.
Rich’s initial proposal was the first volley in a lengthy back-and-forth about the best way to generate documentation from the code and the best inline documentation format. Matt argued that documentation shouldn’t be auto-generated, pointing to the Codex as the best place for documentation, and the conversation ultimately went nowhere despite ongoing community support. Tickets went ignored, and Owen Winkler created his own developer function reference:
Contributors from traditional coding backgrounds also butted heads with the self-taught hackers with whom WordPress is so closely identified, again over documentation. Many original WordPress developers were entirely self-taught. Michel’s get-it-on-the-screen approach filtered through the project, sometimes at the expense of coding practices that more experienced developers took for granted — like inline documentation, which some hackers considered superfluous to writing code, even bloat. It would take some time before it became standard practice in the WordPress community.
Problems weren’t limited to inline documentation. Mark Riley, one of WordPress’ longstanding forum moderators, pointed out in 2006 the many ways that the WordPress Codex was failing users. The Codex recommended that users hide which version of WordPress they were running — but the code itself contained a comment asking users to leave the information visible. Instructions were often confusing to less-technical WordPress users; a section on permissions stated that “All files should be owned by your user account, and should be writable by you. Any file that needs write access from WordPress should be group-owned by the user account used by the webserver,” assuming that all users would know how to configure this. Because it was so easy for non-technical users to download and install WordPress, Mark argued, documentation should be written in clear, simple language.
Release dates were another fault line. Almost every release cycle, Mark asked for the release date in advance so that he could ensure the support forums were properly staffed to handle the barrage of questions. Again and again, a release would arrive and surprise him. “All I am trying — and yet again completely failing — to ask,” he pleads “is that IF you want support for the product it would nice to at least let the forums know. You guys just don’t see it do you? You really don’t have a clue.”
Each of these issues highlights the tension between developers and non-developers on the project. WordPress encouraged people from all backgrounds to get involved, but developers weren’t always interested in supporting them. Many developers in the project were self taught, with the free software do-it-yourself attitude — if they could teach themselves PHP, why couldn’t others? Mark Riley’s mounting frustrations are clear on the wp-hackers mailing list, as he repeatedly posts questions from the support forums and requests help from developers.
These challenges are unsurprising. When so many passionate people come together to work on a project, disagreement is inevitable. A free software project is a melting pot of people with different ideas, opinions, and backgrounds.
Conventional wisdom says that this approach to creating software shouldn’t work. But somehow it does. Despite the challenges, contributors stick around, new contributors constantly join, and the project grows. In the end, what matters isn’t the specifics of any one conflict, but how the community resolves them and moves on.