In these first days of WordPress, new developers often received commit access to the code repository. This meant a developer could work on code and add it to the core software. There was no requirement for code review (though sometimes code would be sent around among developers before being committed). WordPress was still a small blogging script used mainly by the people who’d written the software. Many of the early commits are from names absent from the commit logs today:
emc3 (dougal), and even
michelvaldrighi, who came back and contributed to WordPress.
There was no real process in those early days. It was the extreme of what Eric Raymond talks about in his work, The Cathedral and the Bazaar. Raymond contrasts the open source bazaar-style development model with the “cathedral building” of traditional software development. The metaphor of the bazaar is apt, with its noise and bustle; people talking on top of each other, each with their own aim and agenda. A free software project operates in this jumble. Common sense tells you it’s all wrong but, just like the bazaar, this throng somehow works.
The first two years of the WordPress project were marked by this laissez-faire approach to development. A developer saw a problem and fixed it. If a developer was interested in a feature, they built it. They used their own experience as bloggers, as well as their b2 forum activity, to guide them. “As bloggers, we had similar desires to those other people had,” says Mike. “I seem to remember still sticking around the b2 forums and looking at what people were asking about and what people wanted while it was still in b2 and getting inspiration and ideas from that.”
It wasn’t until later that more hierarchy was introduced into the project, but in those first few years it hardly mattered. So few people were actually using the software. Many of the developers felt that they were working on blogging software for themselves and if other people wanted to use it, great. The legacy of that time, though, is that today’s developers must maintain and work with all of that code.
A frequently asked question, particularly around the time of the fork, was whether the new WordPress developers planned to rewrite the codebase. The b2 emphasis on getting easy-to-use features on the screen quickly was often at the expense of good coding practices. Michel was learning about PHP when he wrote b2; he tried to get new features on the screen as soon as he imagined them.
This simplistic, often chaotic, codebase put some developers off. Before joining the project, Dougal posted to the support forum asking how far the developers intended to go with the rewrite: were they planning to rewrite the whole codebase from scratch, or would something recognizably b2 still remain? The response was that they planned to structure the code more logically as they went along, with object-oriented code as a long-term goal.
There wouldn’t be a total WordPress rewrite. The WordPress project was launched in the wake of Mozilla’s browser, which was the result of a three-and-a-half year Netscape rewrite. Using Mozilla as a negative example, many developers in the free software community argued that rewriting software is a big mistake. While rewriting might produce an all-new codebase, it lacks the years of testing and bug fixes that come from using a mature codebase. It also leaves space for competitors to emerge while developers are focused internally on rewriting.
Instead of a wholesale rewrite, WordPress’ developers worked to iteratively improve and refactor code. For example, in late 2003, major changes to the file structure of WordPress involved replacing “
b2” files with “
wp-”, dubbed The Great Renaming. Tidying up b2’s files had been on Michel’s agenda in 2001 and he had made some improvements already, but they lacked consistency. Now the WordPress project had decided to tackle the problem. When the files were renamed with the new
wp- prefix, instead of the old b2 one, hack writers found that their hacks no longer worked, but it was believed that the upheaval was necessary to organize the file structure for long-term stability. WordPress’ file structure morphed from b2 to the familiar WordPress file structure used today, with many files consolidated into the
These sorts of iterative steps have been more of a feature of WordPress’ development than any major restructuring or rearchitecting. And, over time, such changes have become harder to do as the number of people using the software means that many more sites are likely to break.
To facilitate development, the developers needed a way to communicate. The hackers mailing list wasn’t set up for 17 months after project launch and the project’s main developers communicated on a private mailing list. IRC was one of the first tools the community used for communication. Freenode had a b2/Cafelog channel, so it made sense for WordPress to have one too. The first of these was
An IRC channel provides a virtual meeting space where people can instantaneously communicate with one another. It’s also possible to log an IRC channel so that a record of what happened can be posted online. In WordPress’ early days, many community members spent all day hanging out in the IRC chat room. For some, it was the tone of the IRC chat room that got them more actively involved in the WordPress community. Owen Winkler (ringmaster) recalls:
I had stumbled on IRC channels for other programs before, and you know, you ask a question and no one answers or they make fun of you. WordPress was never like that. When I started out, if you came to the channel and you asked a question, people answered the question. After you learned a bit, if you stuck around, you would answer the questions too.
It was this camaraderie that caused people to stick around. Many of them were learning to write code, making software for the first time, and they were doing it together. Over time, WordPress spawned more IRC chat rooms. The
#wordpress IRC chat room morphed into a place for user support, with a small community of regulars that frequented it. The
#wordpress-dev channel became the place where WordPress development took place, including weekly meetings and development chats. There were also individual chat rooms for the teams that worked on different areas of the project. [footnote]In late 2014, the WordPress project moved its communication from IRC to Slack.[/footnote]
WordPress.org forums were the other communication tool that the project had right from the beginning. WordPress.org launched in April 2003; initially it was home to the development blog, some schematic documentation, and support forums. The original WordPress homepage told the world that “WordPress is a semantic personal publishing platform with a focus on aesthetics, web standards, and usability.” The site gave the WordPress community a presence and the forums provided a home.
Originally, the forums ran on miniBB, but as the number of people on the support forums grew, the software couldn’t handle the load. In 2004, while stuck in San Francisco over Christmas, Matt took what he’d learned from WordPress and applied it to forum software, writing bbPress. Now, bbPress is a plugin, but when it was originally coded, it was stand-alone piece of software with its own templating system. Matt wrote in the launch post that he wanted to “bring some weblog and WordPress sensibilities to forum software.”
Today, the WordPress.org forums are mostly used for providing support to users and developers, but back when they were first set up, they were the community’s primary method of communication. The first post on the forums appeared before WordPress was even released, with a request to beta test the software. Word had gotten out about a b2 fork and people were eager to use it.
The support forums became a place to talk about everything related to WordPress: the WordPress.org website, bug reports, troubleshooting, and requests for design feedback. People also posted hacks and later, plugins.
Developers communicated on these open channels, but anyone was able to join in. It didn’t take long for people who weren’t developers to gravitate toward the project. Sometimes, these were people who used WordPress, but lacked the technical skills or confidence to actively contribute to the code. Others were more interested in the support roles essential to a successful project — writing documentation, for example, or providing support. Some of these people would go on to have just as big an influence on the project as any of the developers.