Three years in, the project included developers, support forum volunteers, documentarians, and others helping out. Many had been around since the early days, and while the project and software had grown and changed, some felt that the governance structure had not. A free software project can be run in many different ways. WordPress has always had a Benevolent Dictator for Life (BDFL) structure: the final decision often rested with Matt, even if it was Ryan Boren who made and implemented most of the technical decisions. Some contributors, however, felt that the project could benefit from a committee structure, with a team of people driving the project’s direction and decision making. Others were unhappy with how Matt led the project, and left. The first major fork of WordPress didn’t involve software; it was within the community.
Some of the unhappy contributors met in September 2006, at the Ohio Linux Fest in Columbus. They had lunch together at a Buca di Beppo. Among the diners were four WordPress developers — Owen Winkler (ringmaster), Rich Bowen (drbacchus), Scott Merrill (Skippy), and Chris Davis (chrisjdavis). During lunch they talked about their grievances. The same story came up again and again — patches were rejected because they didn’t fit the project’s vision. The conversation kept returning to the possibility of setting up a new free-and-open-source (FOSS) project. By the time the meal ended, the developers had decided to stop talking and act: they would create a new blogging tool. A few weeks later at ApacheCon, they chose a name: Habari, which is Swahili for “What’s up?” or “What’s the news?” They created a governance structure and development ethos for the project, and started work in earnest.
Habari launched in January 2007, and many of its founding principles are in direct opposition to those of the WordPress project. The Habari Motivations page addresses the issues that the founding developers objected to in the WordPress project — and explains their different approach to running a free software project. It also highlights some problems that were afoot in the WordPress project three years after its launch. Every free software project — indeed every group or community — has its problems, especially as it becomes established. Tensions that were ignored during the initial heat of enthusiasm become entrenched, and as enthusiasm fades, those tensions surface.
Governance style was one major issue. Many weren’t happy with the BDFL model, despite its prevalence in free software projects, from Linus Torvalds of Linux to Guido van Rossum of Python. A BDFL typically has final say about the project’s direction and vision, but as a project grows, there are many people who wield influence and make decisions.
Rich Bowen, one of the developers who was dissatisfied with how WordPress was run, came from the Apache project. Apache has a committee model. The committee comprises developers and non-developers, all of whom have a say in how the project runs. Unlike WordPress, which requires that commits be approved by the committer and/or the patch reviewer, commits in Apache require consensus. Habari launched with a committee structure, much like Apache.
Designer Michael Heilemann was one person enticed by Habari. He’d designed the Kubrick theme and was looking for a new challenge after the Shuttle project failed before implementation.
Michael redesigned the Habari interface — which he says was both a good and bad experience. He enjoyed designing and implementing it, less so getting it approved. Because of Habari’s committee structure, a lot of time was spent discussing the new admin interface. People with no design background weighed in with opinions and everyone received equal weight. This left Michael feeling like he couldn’t get his work done and he ended up leaving Habari. When asked whether he prefers a BDFL or an Apache-style model, he says:
It’s easy to end up in very long discussions if everybody has equal footing. And that makes for a great democracy, but it’s also very hippie, 60s, everybody gets to sit around and share their opinion, but that’s not always something that’s really worthwhile. You don’t actually, necessarily, get a better product out of it. And so often you need somebody with vision, or at least somebody with a point of view with opinion to weigh in.
Commit access was another flash point. In the Apache project, a clear path existed to gain commit access to the repository. That wasn’t the case in early-2006 WordPress. Matt and Ryan acted as a funnel through which all code would be reviewed. More committers were eventually added, but it was a slow process and one that led to frustration, particularly among prolific contributors.
Coming from Apache, Rich Bowen brought a different perspective — which he shared with other dissatisfied developers. For Rich, WordPress didn’t constitute a true meritocracy — there was no opportunity for those with ability to gain power and responsibility. The final decision over who did and didn’t gain authority lay with the project’s leader — it was entirely up to Matt’s discretion. When Matt, in a discussion thread, said that WordPress is a meritocracy because commit access is provided to “the best of the best of the best contributors who prove their worth over time with high-quality code, responsiveness to the community, and reliability in crunch times,” Rich pointed out that because the final decision lies with the BDFL, the community can never become meritocratic.
At the heart of the discussion was a fundamental disagreement about how a free software project should be structured. In Homesteading the Noosphere, Eric Raymond discusses project structures and ownership, looking at how these emerge over time. WordPress follows Raymond’s outline: the project had a single owner/maintainer (or rather two — Mike Little and Matt Mullenweg). Over time, Matt assumed project leadership. In WordPress’ case, commit access carried with it an implicit level of authority. Those with commit access are the arbiters of the code that ends up in core. Matt made clear on a number of occasions that he didn’t “want it to be a status thing,” but it still became one.
Matt posted to the mailing list in 2005, saying “Committing != community status. It simply is a way to ensure that all the code that goes into the core is reviewed before being distributed to the world.” But community members naturally ascribe more authority and trustworthiness to those with commit access. It was unclear what it took to become a committer or a lead developer. Instead, the roles developed organically. For the community, authority naturally followed commit access to the repository, and commit access followed high-quality code submissions along with an understanding of and commitment to the project ethos. Commit is a symbol of trust; with only two committers, it appeared that the project leads did not trust others in the community.
This had another consequence: non-code contributions went unacknowledged. Commit access may have been given out sparingly, but authority and leadership were still achievable in theory by anyone who could write code. For those who worked hard in support forums, wrote documentation, or provided translations (among other supporting activities), there was no formal way to progress, gain status, or be acknowledged. Coders receive props for code accepted into core, but there was no equivalent system for those who worked or contributed elsewhere. When there were rumblings of discontent, it wasn’t just coders who were complaining.
Habari’s approach was radically different. Commit access was achievable by anyone. The Habari motivations page says “Our contribution model is a meritocracy. If you contribute code regularly, you will be granted permission to make contributions directly (commit access).” The project takes this approach even further — it isn’t just coders who received commit access. Owen Winkler, one of Habari’s founders, says:
There are some people who are committers, who are part of the primary management committee in Habari who I would never want to actually touch the code because they don’t really do development. But we give them access to it because they’ve demonstrated that they’re part of the community and they’re actively trying to advance Habari as a project.
In Habari, commit access is an explicit sign of trust and responsibility. If you’re building a project in which the two do not go hand-in-hand, keeping commit access solely as a checking mechanism makes sense. The problem? If it’s not clear to people within the project what constitutes authority, commit access becomes one of its few indicators.
WordPress’ focus has always been on users, and maintaining a good experience for them. One of the driving ideas behind Habari, on the other hand, was to create a tool that taught people about development, development best practices, and being part of a free software project. Rich Bowen, who did’t know a lot of PHP, said that he hoped that the new project would teach him about it. Habari eschewed WordPress’ low barrier to entry in favor of an approach that would cultivate fewer, but stronger, developers.
Habari was written in PHP 5.1, which gave developers access to PHP Data Objects. This provided a level of database independence that WordPress lacked. Habari developers found fault with WordPress for not using the latest coding practices, while WordPress developers felt that the Habari approach put users second. As Ryan Boren put it:
Screwing users because developers want to play is not cool. It’s a good way to become irrelevant. A big reason WordPress is so popular is because it is not infatuated with the latest, greatest developer lust objects that require users to upgrade their platform.
In February 2007, when Ryan wrote that comment, PHP 4 was still running on 88.44% of websites. PHP 5 adoption was slow and many web hosts didn’t support it. If WordPress had made the switch to PHP 5 it would have suddenly become unavailable on a huge number of hosts, breaking users’ sites around the world.
Habari’s license choice also signified fundamental differences in FOSS beliefs. WordPress uses a GPL license, intended to secure the freedoms of users. Habari, on the other hand, uses the Apache License, a permissive license that allows developers to use the code in any way — even in a proprietary product. Owen Winkler outlined the reasons why the Habari project doesn’t use a GPL license:
There’s the idea of developer freedom. If you give the software away you should be able to give it away with no requirements at all. If you want to take it and make software that you sell, then go ahead and do that. Hopefully you won’t. Hopefully you’ll contribute. Or if you do, you’ll contribute what you make back to the community somehow.
All these differences ended up being unresolvable, as developers felt increasingly disenfranchised despite slow changes within WordPress. Mark Jaquith, who received commit access while the other developers were quietly working on Habari, recalls, “I felt like […] Matt was right on the verge of loosening the reins, it felt like things were really starting to get good and they left. And I was like oh, if you’d just held on.”
But they didn’t. By the time the reins loosened they had founded their own project with their own ideals and focus. When there is a critical mass of people within a FOSS project who don’t accept its core ethos, there is always the possibility of creating a fork. This is not, necessarily, a Bad Thing. Rather than struggling with the constant debates and infighting that comes from a clash of beliefs, sometimes it is better for two groups to separate. Then each project can keep a laser-sharp focus on the things that matter to its contributors, and on the software and project that they want to create.
