Month: November 2015

By 2013, WordPress’ admin had seen little change since the Crazyhorse redesign in 2008. Change happened in 2013, though it didn’t only result in a new look for WordPress. WordPress feature development changed, introducing a new approach in which feature design, feedback, and iteration used a plugin that was eventually merged with core.

In January 2013, Ben Dunkle proposed new, flat icons. The WordPress admin was outdated, particularly on retina displays where the icons pixelated. Flat icons would scale properly and also allow designers to color icons using CSS. Andrew Ozz checked in the changes.

The changes kicked off huge discussions about icons, a new trac ticket, and a long discussion on the UI P2. People were divided on the icons. Some liked them, but felt that they didn’t fit WordPress’ admin design; modern icons only emphasized how dated the rest of the admin had become. Consensus didn’t materialize. Mark, who was release lead at the time, decided not to put the changes in WordPress 3.6. Instead, designers interested in redesigning the admin could iterate on the design in a plugin called MP6.

Matt Miklic (MT), the designer who had put the original coat of paint on Crazyhorse, helmed MP6. Via Skype, Matt asked MT and Ben Dunkle to reimagine WordPress’ admin, consider how a redesign could work, and set parameters. MT believed that they ought to respect the research that informed Crazyhorse’s UI. Instead of iterating the layout and functionality, they focused on an aesthetic refresh.

Both Matt and MT were keenly aware of the issues and challenges in each major WordPress admin redesign. They wanted MP6 to be different.

Shuttle, for example, had been cut off from the rest of the community, designed by a cloistered group of designers trading comps and slowly losing touch with “the client.” No one person was responsible for Shuttle’s overall vision; there was no accountability.

By contrast, the Happy Cog team looked at WordPress with a fresh set of eyes. Their distance allowed them to treat WordPress as a piece of software, not as an object of devotion. They stayed in touch with their client — Matt — but were removed from the community’s thoughts and opinions. MP6 solicited feedback from all of the people with a stake in the project. That brought its own challenges — whose feedback was the most legitimate? What should be integrated? When was someone just complaining for the sake of it?

Crazyhorse emphasized the importance of in-depth user testing. With all the testing on Crazyhorse, MT knew that he didn’t want to carry out a structural overhaul, conduct extensive tests, and gather the data needed to prove improvement.

The MP6 project took a different approach. Like Shuttle, a group of designers worked alongside the free software project. Instead of a mailing list, they had a Skype channel so that they could talk in private, but anyone was allowed to join in. “Even though the group worked in private,” says MT, “the door into the group we were working on was open, so if anyone said they were interested they could just walk in.” This allowed people less comfortable with WordPress’ chaotic bazaar to participate. Designers traded ideas and feedback — without the danger of someone coming out of nowhere and tearing an idea down before it was even fully formed.

The MP6 project took advantage of WordPress’ plugin architecture; work took place on a plugin hosted on the WordPress plugin directory. Anyone could install the plugin and see the changes in their admin. Every week, the group shared a release and a report open to public feedback. This open process meant that community members could be involved on different levels. It also meant that the group could never steer too far off course. The core team was always aware of what was going on with MP6 and could provide feedback. More designers were involved than with Shuttle: the group grew to fifteen members. With MT as lead, they avoided the “too many cooks” problem. The designers and the community accepted that MT had the final say on the design.

The MP6 project was announced in March 2013. The design process began with MT playing around with the CSS. He started out with a unified, black, L-shaped bar around the top and the side of the admin screen: “the idea,” he said, “was that the black would feel like a background and the white would feel like the sheet of paper lying on top of it, so it would unify these disparate things.” Once MT assembled the basic visual, the contributors refined the design. These changes happened iteratively. The community saw a report and a new plugin release each week, on which they gave feedback.

Challenges arose. Google web fonts caused heated discussion. Web fonts are designed specifically for the web. They’re often hosted in a font repository. A designer uses a CSS declaration to connect to the repository and the font is delivered to a website or app. MP6 uses the Open Sans font, which means that the font in WordPress’ admin screens is hosted on Google’s servers. Whenever a user logs into their admin, Google serves the fonts. Some don’t want to connect to Google from their website; this also causes problems for people in countries where Google is blocked. Bundling the fonts with WordPress, however, requires a huge amount of specialized work to ensure that they work across platforms, browsers, and in different languages. In the end, they decided to use Google web fonts. A plugin was created to allow users to shut them off.

Despite minor hitches, the MP6 project went smoothly. Joen Asmussen, who’d been a part of the Shuttle project eight years earlier said, “I would say that MP6 did everything right that Shuttle did wrong.”

Over the eight years since the first attempt to redesign WordPress’ admin, WordPress had matured. When things are done behind closed doors, people feel disenfranchised, and yet the bazaar style model doesn’t suit every, single aspect of software development. It’s within this tension that a balance must be struck, with space for ideas to flourish.

The MP6 plugin merged with WordPress 3.8, released in December 2013, demonstrating that, while it may take a while to get there, harmonious design in a free software project is possible.

All of this happened as 3.6 rumbled on. Development continued on the core product, MP6 development happened separately; it wasn’t constrained by WordPress’ release timeline. MT and the designers iterated quickly; users installed the plugin to test it and offer feedback. This was a new process that hadn’t been possible before. To test new features in the past, a user would have to run trunk. By developing the feature as a plugin, a community member could focus by helping with the sole plugin that they were interested in.

MP6 was proving to be a success, and in the summer of 2013, it was decided, for the first time, to develop two versions of WordPress simultaneously — 3.7 and 3.8. WordPress 3.7 was a two-month, platform-focused, stability and security release lead by Andrew Nacin and John Cave. New features in 3.8 were developed as a plugin.

Nacin wrote:

This “features as plugins” method* will allow teams to conceptualize, design, and fully develop features before landing them in core. This removes a lot of the risk of a particular feature introducing uncertainty into a release (see also 3.6, 3.5, 3.4 …) and provides ample room for experimentation, testing, and failure. As we’ve seen with MP6, the autonomy given to a feature team can also allow for more rapid development. And in a way, 3.7 provides a bit of a buffer while we get this new process off the ground.

While the project prepared to merge MP6 as a plugin in WordPress 3.8, an opportunity arose to do automatic updates — something that had been talked of within the project for years. Automatic updates had long been a goal, previously unachievable. Automatic updates needed the proper code structure to be in place on WordPress.org, as well as community trust. Community members needed to be okay with WordPress changing their site automatically.

WordPress has collected data since WordPress 2.3 that allows WordPress.org to create personalized automatic updates. WordPress uses the data to make sure that a site receives an update compatible with its PHP version and site settings. In the few failure cases, the user gets an error message with an email address that they can use to email the core developers who will fix their website. As of late 2014, automatic updates are for point releases only. So while major releases of WordPress are not automatic (3.7, 3.8, etc.) point releases are (3.7.1, 3.8.1, for example). This means that security updates and bug fixes can easily be pushed out to all WordPress users.

Within the space of just two short releases — 3.7 and 3.8 — big changes transformed the software and the development process. Automatic updates mean that WordPress users are safer than ever. WordPress 3.8 saw the first release in which a feature developed as a plugin merged with core. This finally decoupled core development from feature development. So many past delays and setbacks happened because a feature held up a release. It gave developers more scope for experimentation and created safe spaces for contributors to get involved with core development. While the MP6 admin redesign was the first plugin integrated under this model, since then, feature-plugins have brought in a widget customizer, a new theme experience, and widget functionality changes. Experiments are ongoing in image editing, front-end editing, user session management, and menus.

The 3.6 release cycle was challenging; it precipitated a new approach to the development process. Two core WordPress philosophies, design for the majority and again, deadlines are not arbitrary, were tested. The 3.6 release cycle process followed the cycle started in WordPress 3.4: there was a unified theme for the release — this time content editing. Small teams worked on key features. Some features need more research and development than can be achieved within a single development cycle, and the WordPress 3.6 cycle surfaced this flaw.

Post formats were 3.6’s headline feature. Introduced in WordPress 3.1., post formats allow theme developers to lend a unique visual treatment to specific post types.

Post formats lacked a standard user interface. In WordPress 3.6, release leads Mark Jaquith and Aaron Campbell tackled the problem. The release cycle had different stages: in the scoping chat, the release lead decided on the release’s key features, created teams, and assigned feature leads. Feature leads ran their teams. The release leads coordinated with the teams and made the final decision on what made the release.

Carrying out major user interface changes in just a few months is challenging, at best. WordPress 3.5 demonstrated that to meet the deadline, the release leads needed to put in heroic coding efforts.

The 3.6 release encountered problems; features were dropped as contributors discovered they’d overcommitted themselves. The biggest issue was around the post formats user interface, inspired by Alex King’s Post Format Admin UI. Much thought and study went into the post formats UI. Which UI would offer users a logical, intuitive workflow, without adding needless complexity to the UI or the experience?

The problem was that despite time spent on wireframes and development, the team ended up unimpressed. They created specifications, built to the specifications, and were unhappy with the result. “It’s like ordering something from the restaurant that sounds great,” says Aaron Campbell, “but as soon as it sits in front of you and you smell it, it’s like, ‘Ahh, definitely not what I was in the mood for.'” Even during WordPress 3.6’s beta period, community members experimented with better approaches to the problem.

April 29 was WordPress 3.6’s target release date. On April 23, Jen — who had by that point stepped back from her involvement in development — said that post formats weren’t ready. She said that the user interface was confusing, underscoring WordPress’ deadlines are not arbitrary philosophy. The thread, in addition to highlighting the post formats UI flaws, showed that not everyone supported deadlines are not arbitrary. Ryan Boren wrote:

The four month deadline is so fanciful as to be arbitrary. It always has been. Historically, we just can’t do a major release with a marquee UI feature in that time, certainly not without heroic efforts of the 3.5 sort. So we end up facing decisions like this. Every single release we wonder if we have to punt the marquee feature. Punting often requires major surgery that can be as much work as finishing the feature. Punting is demoralizing. Four month releases are empty promises that bring us here.

In the end, Mark and Aaron pulled post formats. A lot of work had to go in to removing it from core; the release was heavily delayed, finally appearing on August 1, 2013 — three months after the intended release date. The team promised to turn the post formats feature into a plugin, but the plugin never materialized.

Again, a user-facing feature held up a WordPress release. Because features were tied to the development cycle, it meant that the release cycle’s duration restricted and compromised UI features and/or major architectural changes. Just like tagging before it, post formats was a problem too complex to solve in a few short months. It isn’t always easy to make interface decisions. It’s harder to iterate on design than on code.

When the release deadline approaches and a feature isn’t ready, the development team rushes to try to get it finished. The release is delayed by a week, and then by another week, and in some extreme cases, as was the case with WordPress 3.6, the release is delayed by months. By that point, it becomes impossible to give a firm date for when a release will happen. And the process becomes more complicated as the release lead oscillates between trying to improve a feature and deciding to pull it. Up until 3.6, there was no contingency plan built into the development process that allowed for these challenges in designing a user-facing UI.

The solution to this problem was available, and always had been available, within WordPress’ infrastructure. Twice before, core user features had been pulled from plugins into core — widgets and menus. Widgets had been built for the WordPress.com audience, turned into a plugin, and brought in to core. Menus had stumped the core development team and they solved that problem with a plugin. In both these cases, feature design and testing happened long before approaching core. And as the WordPress 3.6 cycle dragged on, a small group of designers worked on a new WordPress feature in a plugin: it was a project called MP6. The project would be the flagship for a new approach to development that had a lasting influence on how WordPress features were developed.

By early 2013, the GPL discussion had slowed. Not everyone liked it, but most accepted that the WordPress project would only support 100% GPL products. Many were surprised by a sudden flare-up around not just GPL legalities, but the “spirit” of the license. In a 2008 interview, Jeff Chandler asked Matt about the spirit of the GPL. Matt said that the spirit of the GPL is about user empowerment, about the four freedoms: to use, distribute, modify, and distribute modifications of the software. Software distributed with these four freedoms is in the spirit of the GPL. WordPress was created and distributed in this spirit, giving users full freedom.

The Software Freedom Law Center’s opinion gives developers a loophole around themes — one that helps them achieve GPL compliance — but denies the same freedoms as WordPress. PHP in themes must be GPL, but the CSS, images, and JavaScript do not have to be GPL. This is how Thesis released with a split license — the PHP was GPL; the remaining code and files were proprietary. This split license ensures GPL-compliance, but does not embrace the GPL’s driving user-freedom ethos.

The loophole may have kept theme sellers GPL-compliant, but WordPress.org rejected that approach. In a 2010 interview, Matt said “in the philosophy there are no loopholes: you’re either following the principles of it or you’re not, regardless of what the specific license of the language is.” WordPress supports theme sellers that sell themes with a 100% GPL license. Those who aren’t 100% GPL receive no promotion on WordPress.org or on official resources.

In early 2013, ThemeForest — Envato’s theme marketplace — came under scrutiny. Envato runs blogs and marketplaces that sell everything from WordPress themes and plugins, themes for other CMSs, to photographs, videos, and illustrations. WordPress is just one aspect of their business, though a significant one, and ever-growing. Envato became GPL-compliant in 2009 by releasing their themes with two licenses: GPL for the PHP, and a proprietary license for the remaining files and code.

ThemeForest has long been a popular choice for individual theme sellers. It offers exposure and access to a huge user community. As the theme shop marketplace saturated, it became more and more difficult for new theme sellers to break through.

Theme shops like StudioPress, WooThemes, and Elegant Themes dominate the market. ThemeForest offers everything a theme seller needs: hosting, sales tools, ecommerce, and a shop front. People can sell themes without the set-up work that can steal so much time. Theme sellers make good money out of selling on ThemeForest. As early as December 2011, Envato announced its first theme seller to make a million dollars in theme sales.

In January 2013, ThemeForest author Jake Caputo received an email from Andrea Middleton (andreamiddleton) at WordCamp Central. He was told that, as a ThemeForest author, he was not allowed to participate at official WordPress events. Jake had already spoken at two WordCamps, had plans to speak at a third, and was helping to organize WordCamp Chicago.

The issue was over theme licensing and WordCamp’s guidelines. WordCamps are official WordPress events that come with the WordPress Foundation’s seal of approval. Organizers, volunteers, and speakers must fully embrace the GPL — going beyond GPL compliance to pass on all WordPress’ freedoms to users. The guidelines state that organizers, volunteers, and speakers must:

Embrace the WordPress license. If distributing WordPress-derivative works (themes, plugins, WP distros), any person or business should give their users the same freedoms that WordPress itself provides. Note: this is one step above simple compliance, which requires PHP code to be GPL/compatible but allows proprietary licenses for JavaScript, CSS, and images. 100% GPL or compatible is required for promotion at WordCamps when WordPress-derivative works are involved, the same guidelines we follow on WordPress.org.

ThemeForest vendors had only the split license, in which the PHP was GPL and the CSS, JavaScript, and images fell under a proprietary license. For Jake to become 100% GPL, he would have to stop selling on ThemeForest and find a new outlet for his themes. This meant losing access to the more than two million ThemeForest members — not to mention a significant portion of his income.

WordCamp Central’s actions angered some community members; some thought it was unfair to ask theme sellers to give up their livelihood simply to speak at a WordCamp. Others supported WordPress.org; they believed the stance consistent with the GPL.

On both sides, people were frustrated for ThemeForest’s authors. While the issue had little influence on the powers-that-be at WordPress or Envato, theme authors stuck in the middle suffered. With only the split license at Themeforest, they had one choice — jeopardize their short-term livelihood by moving off ThemeForest.

The argument raged in the comments of Jake’s blog, spiralling to other WordPress community blogs, and to the ThemeForest forums. Matt joined the discussion on Jake’s blog, saying that if ThemeForest authors had a choice about licensing and could release their theme under the GPL, then “Envato would still be breaking the guideline, but Jake wouldn’t, so it’d be fine for Jake to be involved with WordCamps.”

Collis Ta’eed, CEO of Envato, responded on WP Daily, [footnote]WP Daily has since been acquired and its content moved to Torque magazine.[/footnote] outlining Envato’s licensing model rationale. As a designer, Collis’ main concern is protecting his designers’ rights, while ensuring that customers can use the resources they purchase.

As with so many disagreements in the WordPress community, it came down to a difference in emphasis. While the WordPress project emphasizes user freedoms, Envato emphasizes creators’ rights. Both felt strongly that they had the moral imperative, and backing down meant violating the principles that underpinned their organization. The WordPress project places user freedoms over and above every thing else. If this meant excluding theme authors who sold on ThemeForest, then so be it.

Collis, on the other hand, wanted to make sure that theme authors felt confident that their themes were safe from piracy. He was also worried about having a GPL option for authors. He wrote, “I worry that external pressures will force an increasing number of our authors to change their license choice, some happily, some not.” Having just one (split) license meant that authors wouldn’t be forced into that situation.

From the project’s perspective, theme authors could choose to sell their themes on ThemeForest, or sell their themes under the WordPress community’s ethos (and thus speak at WordCamps). In a podcast on WP Candy, Jake said he didn’t feel he had a choice about where to sell his themes. ThemeForest had become such an important part of his income that he would have to forfeit that income if he moved elsewhere. After the podcast, Collis wrote a second post on WP Daily, in which he said:

I think I’ve been wrong in my stance. I would like to change that stance, and feel that ThemeForest should offer an option for authors, if they choose, to sell their themes with a GPL license covering the entirety of the theme.

Collis surveyed ThemeForest authors to gauge support for a GPL opt-in option. “I felt pretty guilty that our authors were paying some sort of price for selling with us, that felt pretty wrong,” says Collis. The results showed that verified authors were split; some said they would license their themes under the GPL, the same number said they would stick with the split license, and 35% said that they didn’t know which license they’d choose. On March 26, Collis announced a 100%-GPL license for ThemeForest authors. Jake was once again allowed to speak at WordCamps.

The first en-masse, invitation-only WordPress community get-together — The Community Summit — took place in 2012. The Community Summit focused on issues facing WordPress software development and the wider WordPress community. Community members nominated themselves and others to receive an invitation; a team of 18 people reviewed and voted on who would be invited. The attendees — active contributors, bloggers, plugin and theme developers, and business owners from across the WordPress community — came to Tybee Island, Georgia, to talk about WordPress.

The main event, held at Tybee wedding chapel, was a one-day unconference. A few informal days for project work were scheduled afterward. In the morning, attendees pitched suggestions for discussion, discussion groups formed around tables, and twice during the day, individual groups shared their proposals for taking action.

The subjects discussed covered the spectrum of development and community issues. Development-specific topics included mobile apps, improving deployments, using WordPress as a framework, multisite, JavaScript, the theme customizer, and automatic updates. They talked about how to deepen developer experience, including better information for developers on UI practices. Broader community discussions focused on the role of the WordPress Foundation, open sourcing WordCamp.org, the GPL, and women in the WordPress community. There were discussions about different WordPress.org teams, such as UI, accessibility, theme review, and about improving documentation. Summit participants came from around the world; attendees talked about internationalization and global communities. Business owners raised issues such as managed WordPress hosting and quality control in commercial plugins. Finally, there were discussions about making it easier for both individuals and businesses to contribute to the project.

With so much discussion, many different ideas surfaced. Some proposed ideas moved forward, while others languished lacking contributor support. Summit discussions resulted in:

• Better theme review process documentation to increase consistency and transparency.
• A documentation and Codex roadmap (developer.wordpress.org eventually launched).
• Language packs included in core in WordPress 4.0.
• Headers added to the P2 themes to instruct contributors on how to get involved.
• Published a make/events sub-team list.
• Automatic updates for core.
• Individual plugin reviews on WordPress.org.
• Open sourced the WordCamp.org base theme.

As well as creating a space for contributors to discuss issues, many contributors met for the first time at the summit, and the in-person talks invigorated the community.

A new team — a plugin repository review team — formed. Up until then, Mark Riley carried the load reviewing plugins for the repository. The community believed plugins required the same rigor as themes. Plugin code quality was raised on community blogs and on wp-hackers. Otto started to review plugins too, and later Mika Epstein (ipstenu) and Pippin Williamson (mordauk) helped conduct plugin reviews. Later, Boone Gorges (boonebgorges) and Scott Riley (coffee2code) joined the team.

The plugin review team faces different challenges than the theme review team. A theme is a specific group of template files with a defined structure. It calls functions, it requires a header, footer, and a sidebar. A plugin can be anything at all, so there’s no way to automate reviews, which can be a lot of work. This review process cleared out malicious plugins, spam plugins, and plugins with security holes. A set of guidelines evolved to protect WordPress users.

Again, a small group of contributors created a team to address a specific project need. This has continued ever since the summit; a team develops training programs for people who want to teach WordPress, a team moderates WordPress.tv, and there’s a team of contributors who help to support meetups. The summit allowed people to get together, to talk about their own interests, meet like-minded contributors, and move projects forward. The community got to be together as a community, to get to know one another socially — instead of through text-based, online communication.

From late 2011 on, the development process iterated. Not optimal, it lacked accountability. Bottlenecks festered and deadlines passed. Each release from WordPress 3.4 on endured major development process change; it wasn’t until WordPress 3.8 that process experimentation slowed.

Experimentation started at the core team meetup in Tybee Island, Georgia, in December 2011. Lead developers, committers, and active core developers discussed the project’s issues and roadmap, informing the scope setting meeting for WordPress 3.4 on January 4, 2012.

The scope chat notes cover the issues discussed. The team acknowledged process problems. Jen listed the issues: “lack of good time estimation, resource bottlenecks, lack of accountability, unknown/variable time commitments/disappearing devs, overassignment of tasks to some people, reluctance to cut features to meet deadline.”

They split feature development into teams; two contributors would lead each team to reduce contributor overextension and project abandonment.

Ideally, a lead developer or a committer would lead each feature team. To help engage and mentor new contributors, one new contributor would pair with each lead or committer. Each team had to post regular updates and deliver their feature on time. They created a schedule with overlapping cycles that encompassed development, UX, and bug fixes to reduce bottlenecks.

The team decided that releases would have a specific focus. WordPress 3.3 had been a cluster of disparate features, some of which had been pulled because they weren’t ready. WordPress 3.4 was the first cycle to have an overarching focus — appearance/switching themes. The development team worked on improving both front-end and admin features that adjust a site’s appearance.

Between WordPress 3.4 and 3.5, the project leadership approach evolved — a change that had started back in WordPress 3.0 when Dion Hulse became a committer. Though Dion received commit access, he was not a lead developer. This was the first step toward decoupling the lead developer position from commit access. To reduce bottlenecks, the project needed committers, but not necessarily more lead developers. Separating the roles offered opportunities for strong coders and patch triagers, and for those who wanted to contribute, but not necessarily in a leadership role.

And yet, confusion reigned on what the lead developer title actually entailed. Core team members perceived the role differently; no one agreed on what the lead developer title meant. For Mark Jaquith, the lead developer role has changed organically over the years. To begin with, the role related to coding. Over time, it transitioned, particularly around the growth of WordCamps: “We started going around and talking to users about some of the philosophy behind WordPress and the direction we wanted to take. It became more of a general leadership role in practice.” The role also evolved as lead developers worked with the community: often, lead developers responded to comment threads to address issues, or speak up on behalf of the project.

However, the role had never been formally clarified. While the lead developers handled many coding decisions, their additional responsibilities and authority were unclear. Did they have authority across the project? Should they make decisions in areas such as WordCamps, documentation, or theme review?

The lead developer role “didn’t really have a set of responsibilities assigned with it or expectations,” says Matt. According to him, the lead developer leads development, not other areas of the project; he believes that confering authority and responsibility to a development role makes it difficult for non-coders to achieve project authority and responsibility.

Matt had articulated as much, as early as 2005, in stating that commit access did not equate to community status. It may never have been Matt’s intention to automatically confer authority on people with commit access, though extending commit demonstrated that committers had earned trust, and, as such, people naturally looked to committers as community and code leaders. Since roles and responsibilities were undefined, people simply perceived commit access as a general leadership role. The only non-coder who had an official leadership role in the project — other than the lead developers — was Jen, but she was an integral part of the core development team and there was no clear path for anyone to follow in her footsteps.

In June 2012, the confusion around the role brought conflict. Since WordPress 3.0, a new generation of coders had driven development. Contributor changes were marked between the 2010 core meetup in Orlando, Florida, and the 2011 meetup in Tybee Island, Georgia. In 2010, just the small team of lead developers (Mark Jaquith, Andrew Ozz, Peter Westwood, Matt, and Ryan Boren along with Jen) met up. In 2011, the meetup had new faces including Dion Hulse, Jon Cave (duck_), Daryl Koopersmith, and Andrew Nacin.

From time to time, someone arrives and influences the project. In the early days, Ryan Boren drove WordPress’ development, but post-WordPress 3.0, it was Andrew Nacin. “Nacin like Ryan is one of those guys that just has an ability to get in a flow, and just really crank and get focused intensely, and get through a ton of work,” says Matt.

Nacin’s project influence grew, and between WordPress 3.4 and 3.5, Ryan Boren proposed that since Nacin drove releases strongly, he deserved recognition and should be made a lead developer.

Rather than appoint Nacin as a lead developer immediately, Matt proposed an organizational shift in the project. Matt argued that the lead developer title was historical and non-meritocratic, that those driving the project should hold leadership roles. Matt wanted opportunities for new developers to assume project leadership roles. He proposed that, instead of having a small group of lead developers, the project move to release leads, nominating Andrew Nacin and Daryl Koopersmith to assume the role in the next release. Matt’s proposal offered clear authority to individuals for a given release; release leads would have final say, both over the lead developers, and over Matt. Some in the “historical and un-meritocratic” roles perceived this move as an attempt to remove the old guard to make way for the new. While a number of the lead developers aren’t active in core on a daily basis, they are in regular contact with those who work on core, providing advice on architecture and development.

On reflection, Matt says that there was a misunderstanding. He didn’t mean to imply that the people holding lead developer roles were worthless or irrelevant, but that the roles did not reflect project reality. “A source of some of the conflict,” says Matt, “is this idea that the lead developers sort of had the same role as me where they had sort of purview over everything across all parts of WordPress.”

The lead developer role discussion raised dissatisfaction around project decision making. Many of those who ran day-to-day development felt that unilateral decisions were made without team consultation. Matt had taken a less active role in recent years, as Jen and Ryan, supported by the other lead developers, drove the project, yet decisions were made and announced without consultation. This was a culmination of other issues within the core development team and in the wider project: checking in code without consultation, providing feedback only toward the end of a release, and decisions around WordPress.org — the site Matt owns, but that influences the entire community.

In response, some core team members — including lead developers and other team members — sent a group email to Matt to express their discontent with the project. They felt that Matt’s perspective on the project’s organization, authority, and responsibility, didn’t reflect the project’s realities. The group proposed an official project leadership team; they wanted to retain the lead developer title as a meritocratic title for core developers who aligned with WordPress’ philosophies, demonstrated leadership, code expertise, and mentored new developers. While the group happily supported the release leads proposal, they felt that the decisions for architecture, code, and implementation should rest with the lead developers, and that decisions affecting the project should lie with a leadership team.

In response, those involved scheduled a Google Hangout to discuss the issues, air grievances, and find a way forward. As a result, things changed, and the first 3.5 release cycle post reflects some of those changes.

Andrew Nacin was promoted to lead developer, and core development adopted release leads with responsibility for an individual release cycle. They chose media as the scope for the 3.5 release; the development team had wanted to tackle it for some time, but with such a large scope, it hadn’t been attempted. Daryl Koopersmith created a plugin, called Mosaic, which was the prototype for new media management. Much of it was written in JavaScript, where Daryl’s expertise lay. But as a PHP free software project, there were few who could help him. As a result, Andrew and Daryl spent between 80 – 100 hours a week working on the release.

While the release itself was well received and media was overhauled, the actual development cycle wasn’t such a success. It was a huge amount of work, involving lots of feedback, codebase iterations, and coding a whole new feature from scratch. There were four major iterations to the user interface, including one 72 hours before the release. This meant that the new “release leads approach” got off to a faltering start. The intent was to have release leads guide and lead a release, not necessarily spend hours carrying out heroic coding feats. Once again, the release cycle focused on a single feature; it shipped because two coders broke their backs getting it done. But the next release cycle — 3.6 — revealed that the release-specific feature development model was broken.

By mid-2010, one theme was still a GPL holdout: Thesis, from DIYThemes. Created by theme designer Chris Pearson and blogger Brian Clark, Thesis was popular as a feature-heavy framework — it gave users many more options than most WordPress themes. Users can customize every element of their website via the user interface. On the original about page, Chris states Thesis’ aim: “I wanted a framework that had it all — killer typography, a dynamically resizable layout, intelligent code, airtight optimization, and tons of flexibility.” Tech blogs featured Thesis and high profile bloggers, including Matt Cutts, Chris Brogan, and Darren Rowse adopted it.

Chris Pearson was well-respected in the community; he’d already developed Cutline and PressRow before moving into the premium theme market with Thesis. A mid-2009 ThemeShaper post recalls Thesis’ influence as “The Pearson Principle”: “Bloggers want powerfully simple design on an equally robust framework.” With themes such as Revolution and Premium News, theme developers were already creating feature-rich themes, and Thesis cemented that approach, ushering in the era of the theme framework [footnote]The term “theme framework” is often used to refer to different things. In some instances, a theme framework is a base, or “starter” theme that a developer can build from. In other cases, it’s a drop-in code library that facilitates development. But it’s also used in marketing to users, when a theme framework is a feature-heavy theme with multiple options.[/footnote]. Chris called this approach “ubiquitous design.” A theme wasn’t simply a website skin, it was a tool to build your website. It took another four years before theme developers stopped packing themes with options and started moving features into plugins.

While theme vendors adopted the GPL, Thesis held out. Discussions between DIYThemes and Automattic went nowhere and relationships fractured. In June 2009, Brian and Toni were in discussions when a blogger’s comment thread was hijacked. A long debate about Thesis and the GPL ensued. Matt urged people to move away from Thesis, saying “if you care about the philosophical underpinnings of WordPress please consider putting your support behind something that isn’t hostile to WordPress’ core freedoms and GPL license.”

In July 2010, the WordPress/Thesis debate reignited after Chris Pearson’s interview on Mixergy. In it, Chris shares Thesis’ revenue figures, putting a conservative estimate at 1.2 million dollars within 16 to 18 months.

Just over a week later, Matt and Chris took to Twitter. Matt was unhappy about Chris flaunting revenue and the GPL — violating WordPress’ license. Cutting remarks ensued until Andrew Warner from Mixergy set up an impromptu, live debate to discuss the issues. The hour-long discussion airs both sides of the argument. Matt argues that Thesis is built on GPL software — WordPress — and must honor the license. Matt suggests that Chris is disrespectful of all WordPress authors and that he’s breaking the law. Chris said adopting the GPL meant giving up his rights and losing piracy protection. He argues that “what I’ve done stands alone outside of WordPress completely,” and that Thesis “does not inherit anything from WordPress.” The argument descends into a rambling discussion of economics, and the conversation ends when Matt threatens to sue Chris if he refuses to comply with the GPL.

Matt, Automattic, and WordPress took public action against Thesis following the interview. Matt offered to buy Thesis users an alternative premium theme, consultants using Thesis were removed from the Code Poet directory of WordPress consultants, and Chris Pearson’s other themes — Cutline and PressRow — were removed from WordPress.com.

Matt wasn’t the only one in the WordPress community to come out swinging against Thesis. Other lead and core developers wrote about their GPL / Thesis stance. Ryan Boren wrote, “where do I stand as one of the primary copyright holders of WordPress? I’d like to see the PHP parts of themes retain the GPL. Aside from preserving the spirit of WordPress, respecting the open source ecosystem in which it thrives, and avoiding questionable legal ground, retaining the GPL is practical.” Mark Jaquith noted that WordPress themes don’t sit on top of, they’re interdependent on WordPress:

…in multiple different places, with multiple interdependencies. This forms a web of shared data structures and code all contained within a shared memory space. If you followed the code execution for Thesis as it jumped between WordPress core code and Thesis-specific code, you’d get a headache, because you’d be jumping back and forth literally hundreds of times.

Even developers who believed themes aren’t derivative of WordPress declared Thesis derivative. Developer Drew Blas wrote a script comparing every line of WordPress and Thesis. His script revealed several instances of Thesis code taken from WordPress. Core developer Andrew Nacin pointed out that Thesis’ own inline documentation declared: “This function is mostly copy pasta from WP (wp-includes/media.php), but with minor alteration to play more nicely with our styling.”

A former employee of DIYThemes left a comment on Matt’s blog:

check out Thesis’ handling of comments (thesis/lib/classes/comments.php). Large chunks of it are ripped right from WordPress. I know they are… because I’m the one who did the ripping. Whether I informed Chris of that or not doesn’t matter because I no longer have any of our old chat logs to prove one way or another, but suffice it to say the latest public release of Thesis (and numerous versions before hand) contain obviously GPL code. Whether those portions get rewritten in the impending 3.0 release, I don’t know… but for Chris to claim that he was responsible for and devised all of Thesis at 13:33 or so in the debate… Well, he was lying to you, either intentionally or not.

On July 22, — not even a week after the initial Mixergy interview — Chris Pearson announced that Thesis would be released under a split license. The public furor, compounded by pressure from inside DIYThemes, forced Chris to capitulate. Brian Clark drafted the license, shortly before leaving DIYThemes, citing “completely different opinions about the direction of the development of Thesis, the running of the company, and our relationship with the WordPress community.” When Thesis 2 launched in 2012, it had a new, proprietary license.

The debate around Thesis and the GPL had far-reaching implications for everyone involved. Prominent blogs moved away from Thesis. Brian Gardner’s Genesis theme became a popular choice. Thesis and Chris Pearson became less prominent in the community, focusing instead on cultivating and building a large customer base. The debacle also proved that WordPress will go to court to defend flagrant license abuse. There was, for a while, a relative calm in the community around the GPL. WordPress.org supported commercial theme sellers whose themes were 100% GPL and tolerated those that packaged their themes with two licenses. It would be another four years before the community found itself in another GPL argument on the four freedoms, this time between WordPress and Envato.

By the time WordPress 3.0 launched, more people were interested in WordPress than ever before. In the early days the project attracted developers, bloggers, and people interested in helping others via support or writing documentation. But several factors meant that people with diverse backgrounds were getting involved.

WordPress 2.7 demonstrated that making software isn’t just about writing code; design, user experience, UI expertise, and testing are all very much part of the process. Useful software requires a diverse set of eyes. This means attracting new contributors by illuminating the different ways one can contribute to the project.

While development, documentation, and support are obvious ways to participate, in 2009, Jen Mylo wrote about the different ways for people to contribute to the project. One was graphic design. After a 2008 icon contest was successful, the project tried to find more ways for designers to contribute. A new trac component for graphic design tasks ensued, and designers were invited to iterate WordPress’ visual design. People were also encouraged to participate with usability testing. WordPress 2.7’s success stemmed from user testing during the development cycle. The development team was keen to replicate this process in future releases. Jen also invited people to contribute by sharing ideas, feedback, and opinions.

As well as her work on the development blog, Jen and other project leaders spoke at WordCamps to encourage community involvement. Developing a strong community was becoming as important as software development.

Project infrastructure changes also affected WordPress’ growth, particularly in the third-party developer community. Users could readily find themes and plugins. Plugins iterated more quickly; the plugin directory launched in March 2007 in WordPress 2.3. Later that year, the plugin update notification system arrived, and from WordPress 2.7 onward, users could install plugins from their admin screens. Theme improvements were similar, if a little later. The theme directory launched in July 2008; it arrived on admin screens with WordPress 2.8 in 2009. Giving users more access to plugins and themes meant third-party developers had much greater access to users than ever. The theme and plugin directory were growing exponentially.

The theme directory was becoming more difficult to manage with the exponential theme growth. Joseph Scott (josephscott) developed the first version of the theme directory, and spent much of his time reviewing themes and providing feedback. While many theme issues were security-related, Joseph also advocated for best practices. Soon the work became too much for one person.

Joseph wrote:

The theme directory has been chugging along for more than a year now. During that time we’ve tinkered with the review process and some of the management tools, but haven’t really opened it up as much as we’d like. It’s time to rip off the band-aid and take some action; to that end, we’re looking for community members to help with the process of reviewing themes for the directory.

No one knew how the experiment would turn out. A rush of people signed up for the new mailing list; guidelines were drawn up. Though the overall response was positive, some felt that the guidelines were too restrictive — that some theme requirements should be recommendations. On the WP Tavern forums, Justin Tadlock outlined some concerns, specifically that guidelines didn’t allow themes with custom template hierarchies or custom image systems. Some believed the theme review team should check for spam and other objectionable practices. Other developers simply decided to remove their themes from the directory.

Manpower was a problem for those reviewing themes. The review queue was clogged with 100 themes by July 2010; new themes were added every day. Only three or four people were actively reviewing themes. Over time, automated processes and new tools have improved the theme review process. For example, the theme check plugin tests the theme against all of the latest theme review standards.

But despite the teething problems, the theme reviewers have a system that benefits both users and developers: users get safe themes approved by WordPress.org, and theme developers get feedback and help on their themes. There have been other, long-term benefits. Joseph says:

…looking back on it over the long term it’s been nice to see some folks who started way back then and have gone on to be very successful as far as developing their own themes, commercial themes, while still supporting free and open source at the same time. I think over the long term it’s been rewarding to see that jumping off point for people to be able to continue to produce more themes, and very well regarded and high quality themes.

As the WordPress project settled into concrete groups, communication needed to improve. Core product development was discussed on wpdevel.wordpress.com. Other teams were scattered over mailing lists and wordpress.com blogs. Toward the end of 2010, a new blog network was set up on WordPress.org — make.WordPress.org became the new home for WordPress contributor teams, with blogs for core, UI, theme review, and accessibility. Over time new blogs such as support, documentation, plugins, and community, were added.

Each make.WordPress.org blog runs the P2 theme. Created by Automattic for internal communication, P2 is a microblogging tool that allows users to post on the front end — similar to Twitter — without the 140-character limit. Threaded comments on posts allow for discussion. Unless made completely open, only people who are editors of a blog can write a post while anyone is able to comment.

The “make” blogs are an important centralized space on WordPress.org where contributors gather. If a contributor is interested in core development, they can follow the core blog; forum moderators can follow the support blog; people with a UI focus can follow the UI blog. Contributors can subscribe to the blogs and follow along with what’s going on from their email inboxes.

By moving everything onto P2-themed blogs on make.WordPress.org, the conversation’s tone has changed — everything takes place in public. This encourages a more respectful attitude among community members. The focus is on getting work done, rather than devolving into arguments.

These sorts of focused communication improvements have helped the project to build capacity and grow. What often happens is that a need appears, a call goes out, and if enough people answer the call, the project moves forward. This sort of community and capacity building is an important part of running a successful free software project. As the community grows, needs change and new contribution areas open up. A project that grows so far beyond its hacker roots that it encompasses a diverse set of contributors is a healthy one.

By the time WordPress 3.0 came out in 2010, 107 WordCamps had been held across the world, in countries as diverse as Thailand, Germany, the Philippines, Canada, Israel, and Chile. WordCamps create spaces in which WordPress users, developers, and designers converge to listen to presentations and talk about WordPress. Participants meet project leaders, socialize, and get to know one another. WordCamps attract new contributors, and developers meet with users to learn about problems they experience with WordPress.

WordCamps have always been informal, and through the early events, the organization was just as informal as the events themselves. In the beginning, interested community members simply decided to organize a WordCamp. They contacted Automattic for stickers, buttons, and other swag. A blog for WordCamp organizers was set up in 2009, so that organizers could communicate with one another.

In May 2010, Jen took over as central WordCamp liaison, instituting changes in WordCamp organization. Jen said that “WordCamps are meant to promote the philosophies behind WordPress itself.” Without any real structure and oversight, things happened contrary to WordPress’ core philosophies. For example, WordCamps accepted sponsorship from people and companies in violation of WordPress’ license — the GPL. While non-GPL compliant developers and companies are welcome to attend WordCamps, they’re not able to organize, sponsor, speak, or volunteer. This is because WordCamps are official platforms of the WordPress project, and the project doesn’t want to endorse or publicize products contrary to its own ethos.

Without central oversight, issues arose at WordCamps. Many WordCamps ran without budgets. Some organizers took money for themselves. One WordCamp accepted sponsorship money, the WordCamp folded, and the sponsorship never returned. Another opened for registration just so that the organizer could compile a mailing list to which they could send marketing emails.

WordCamps needed better oversight, including clear guidelines. From May 2010 onward, that started to happen. Jen published the first set of WordCamp guidelines.

WordCamps should be:

• about WordPress.
• open to all, easy to access, and shared with the community.
• locally organized and focused.
• open to lots of volunteers.
• stand-alone events.
• promote WordPress’ philosophy.
• not be about making money.

In some quarters, the changes went down badly. Others were more relaxed about the changes, but they, too, asked why people who promoted non-GPL products would be banned from speaking. While many WordPress theme shops were 100% GPL, those that weren’t 100% GPL were indignant that they would have to be GPL-compliant just to speak at a WordCamp.

There were frustrations about the way in which the guidelines emerged. They were published without consultation with WordCamp organizers and appeared to be an edict from above. Brad Williams (williamsba1) says: “I think it probably would have been more beneficial across the board for some more open conversations between the Foundation and the organizers to make sure, one, that these guidelines make sense and that we’re all on the same page and if there was any concerns get those out in the open.” As with previous decisions, the guidelines weren’t part of a conversation between the Foundation and the WordCamp community. When they appeared, they seemed unilateral and the rationale was poorly communicated.

Some guidelines responded to community problems. It is important that WordCamps focus on the software. At least 80% of the content should be about WordPress. Presentations about social media, SEO, and broader technology issues should not be the event’s main focus. Other guidelines were more about ensuring that events about WordPress mirror the project’s organization and ethos. Like the project, WordCamps ought to be volunteer-driven, from the organizers, to the speakers, to the volunteers who help out during the day. The WordPress project was built by volunteers and WordPress events run on volunteer power. WordCamps should also be accessible to anyone who chooses to attend. This means keeping ticket prices intentionally low.

The guidelines have evolved over the years, with community feedback. While not everyone is happy with them, WordCamps continue to flourish around the world.

WordPress 3.0 arrived in 2010, bringing change not only to the software, but to the development process and project structure. Commit access was opened up and all these changes shaped how the project works today. WordPress’ philosophy — deadlines are not arbitrary — was seriously challenged.

In January 2010, Dion Hulse (dd32) received commit access during the 3.0 release cycle. In the post announcing Dion’s access, Matt outlines a new goal for the project:

One of the goals for the team in 2010 is to greatly expand the number of people with direct commit access, so the emphasis is more on review and collaboration. Right now commit access is tied up with being a “lead developer,” of which we’ve always found a small group of 3-5 works best, but now we want commit to be more a recognition of trust, quality, and most importantly activity, and something that can dynamically flow in and out as their level of commitment (har har) changes and decoupled from the “lead dev” role.

This new approach and decoupling commit access from the lead developer role signaled a big change when every patch went through either Matt or Ryan. There was a need to extend trust to contributors, without necessarily giving them leadership roles within the project. While there were no formal rules, several contributors received commit access: Ron Rennick (wpmuguru), focused on multisite, Dion focused on HTTP, and Daryl Koopersmith (koop) worked on front-end development, while Andrew Nacin (nacin) was the codebase generalist.

As well as a symbol of trust, extended commit access meant that tickets and bottlenecks were cleared quickly. When lead developers got distracted by life and work, Ryan Boren carried the load. New committers reviewed and committed tickets.

April 13, 2010 was WordPress 3.0’s release date. Similar to prior releases — despite having a deadline — development focused on scope and headline features, rather than meeting the date. Three main features were defined in the scope chat: merging WordPress MU with WordPress, menus, and a new default theme to replace Kubrick.

Merging WordPress MU with WordPress came for several reasons: WordPress MU was difficult to maintain, 95% of the code was the same as the main WordPress codebase, and Donncha had to manually merge new features post-release. Because WordPress MU hadn’t gained attention from plugin developers, it felt separate from the main WordPress project. To give users a clean upgrade path, WordPress MU merged with WordPress.

Ron Rennick, a longtime MU user, assisted with the merge. He and Andrea, his wife, had used WordPress MU for years for their homeschooling blogging network. His script turned a WordPress install into a WordPress MU install. He reverse engineered his script to bring MU functionality into WordPress, ensuring a way to convert a single WordPress install to a Multisite install.

Ron ran a diff [footnote] A diff is a comparison tool that compares the difference between two files.[/footnote] against the WordPress MU code, looked for differences in the codebase, and merged them into WordPress core. Ryan Boren and Andrew Nacin cleaned up the code. Ron also merged features absent from WordPress MU in plugins, such as domain mapping — a feature originally developed by Donncha.

Plan A was to allow users to upgrade to WordPress Multisite with one click. “The reason we decided not to do that,” says Ron, “is that a lot of the shared hosts would not have been happy if their users could just take any WordPress install, click a button — without actually knowing anything about what was going to happen — and convert it over to Multisite. The decision was made to actually make it a physical process that they had to go through.” To change a WordPress installation into Multisite, WordPress users have to edit wp-config. They need basic technical knowledge.

Terminology was one of the biggest headaches surrounding the merge. In WordPress 3.0, the project decided to move away from the word “blog,” and instead refer to a WordPress installation as a “site.” More and more people were using WordPress as a CMS, so the “site” label felt more appropriate. However, in WordPress MU, the parent — example.org — is a site, while the subdomain blog.example.org is a blog. With WordPress MU and WordPress merging, which one was the site? An individual WordPress install, or a WordPress install that hosted many blogs? WordPress MU became WordPress Multisite, but that wasn’t the end of it.

To complicate matters further, WordPress MU had a function get_site_option, which gets options for the entire network, and get_blog_option which gets options for individual sites. The functions, therefore, don’t relate entirely to the user interface. That was just one of the functions that caused problems, as Andrew Nacin noted.

Custom post types and custom taxonomies were two big changes in WordPress 3.0. The default content types in WordPress are posts, pages, attachments, revisions, and nav menus (from WordPress 3.0), and the default taxonomies are categories and tags. In WordPress 3.0, custom post types and taxonomies were given a user interface. So instead of being restricted to just posts and pages, developers could create themes and plugins that had completely new types of content for users, such as testimonials for a business site or books for a book review website. This opened up totally new avenues for theme and plugin developers, and those building custom sites for clients.

Menus were the big user-facing feature for WordPress 3.0. At the time, it wasn’t easy for people to add navigation menus to their websites. Menu plugins were popular, so much so that it was obvious that the feature met the 80/20 rule. (Would 80% of WordPress users take advantage of the feature? If yes, put it in core, if not, keep it in a plugin.) The menus ticket was opened in January 2010. The first approach was to create a menus interface similar to the widgets interface. By mid-February, however, little progress had been made. Proposals competed on how menus should work. Ryan and Jen contacted WooThemes to discuss bringing their custom woo navigation into WordPress core. This was just days before the planned feature freeze on February 15, 2010.

WooThemes’ custom navigation made it easy for users to add menus to their websites. Developer Jeffrey Pearce (Jeffikus) worked with Ptah Dunbar (ptahdunbar) on the core team to modify WooThemes’ code for core, and to prepare core for the feature. At the time, core updated jQuery to match the version WooThemes’ theme framework used. The original WooThemes codebase created new database tables for the menus. As a general rule, WordPress avoids adding tables to the MySQL database. Instead, core developers used custom post types — existing core functionality.

However, Jeffrey found the time difference challenging. Jeffrey is based in South Africa; core development work happens mostly on US time zones. Development chats took place at 20:30 UTC, which was 22:30 in South Africa. Additionally, Ptah and Jeffrey kept missing each other on Skype.

An environment in which everyone had a voice and an opinion wasn’t something that WooThemes was used to in their development process. Adii Pienaar, co-founder of WooThemes, described the process as excruciating. One of the main points of contention was that WooThemes had originally put the menus in the center of the screen with boxes to add menu items on the right-hand side. WooThemes had invested time into designing it that way, but the menu interface was flipped around to match WordPress’ left to right interface convention.

The menu integration was one of the first times that the project had worked directly with a commercial business (other than Automattic). While the process was not always completely smooth, both sides benefitted from collaborating. WordPress got its menu system. While not exactly the same as the menu system that WooThemes created, it accelerated development. WooThemes got the satisfaction of seeing its code used by every WordPress user. Not everyone felt that WooThemes received adequate credit, though Jeff didn’t share this viewpoint. “Just to have our name on the contributors’ wall — that to me was good enough,” he says. “It’s nice just to be able to say, I built a part of WordPress. No one can ever take that away from me. That was recognition enough for me.”

WordPress 3.0 ended up being a huge release, and while menu discussion continued, launch was delayed again and again. By April, the core team was still sending around wireframes — discussing whether menus should be pulled from 3.0. The release candidate kept being pushed back. Matt reiterated one of WordPress’ key philosophies:

Deadlines are not arbitrary, they’re a promise we make to ourselves and our users that helps us rein in the endless possibilities of things that could be a part of every release.

Feature-led releases meant delays. Menus caused the hold-up with WordPress 3.0, with prevarication over the user interface and implementation. The final release was packed full of features that included the new menus, the WordPress Multisite merge, custom post type and taxonomy UI, custom backgrounds and headers, and an admin color scheme refresh. Any of these features could have been pushed to the next release, but there was no willingness to do so.

One of the more controversial changes in WordPress 3.0 was a new function called capital_P_dangit. This function ensures that the letter “p” in WordPress is capitalized. People felt that WordPress was messing with their content — that this automatic correction was the start of a slippery slope. For some, it was overbearing pedantry, for others, censorship. WordPress has no business changing what people wrote. Some saw it as incommensurate with the project’s core freedoms: openness, freedom, and community.

Most importantly, the filter broke URLs in some instances. This was reported before WordPress 3.0’s release, but because the filter had already worked well on WordPress.com, it wasn’t fixed immediately. For example, a user reported that his image, named “WordpressLogo_blue-m.png” was broken because it had been renamed to “WordPressLogo_blue-m.png.” Upon upgrading to WordPress 3.0, other users — those with folders with the lowercase “p” — had the same problem. As well as folders, URLs with the lowercase “p” were broken. Hosts saw an uptick in support requests. “When 3.0 arrived,” says Mike Schroder (dh-shredder) of Dreamhost, “we had a deluge of support with broken URLs due to capital_P_dangit() applying to all content. This was a particular problem because it was popular among customers to use /wordpress as a subdirectory for their install. We helped customers with temporary workarounds in the meantime, but were very happy to see the issue fixed in 3.0.1.” Mark Jaquith added a fix, but many contributors believed WordPress should never have broken users’ websites in the first place.

The capital_P_dangit function isn’t the only WordPress function that filters content. Other filters include emoticons, autop, shortcodes, texturize, special characters, curly quotes, tag balancing, filtered HTML / kses, and comment link nofollows. From the core developers’ perspective, capitalizing the “p” in WordPress didn’t actually change the meaning of the sentence, except in edge cases such as, “Wordpress is the incorrect capitalization of WordPress.”

Core developers became frustrated by the hyperbole around the filter and the time spent arguing about it. In a comment on Justin Tadlock’s blog, Mark Jaquith said:

Calling corrections censorship is absurd. It is no less absurd when the capitalization of a single letter is called censorship. There is actual censorship going on all around the world at this very moment. I’m damn proud of the fact that WordPress is being used to publish content that makes governments around the world afraid of the citizens who publish it. I’m incredulous that people are making a fuss about a single character (which is only one of dozens of automatic corrections that WordPress makes). It’s free software that is easily extended (or crippled) by plugins. If the thought of going the rest of your life without misspelling WordPress it too much to bear, you have an easy out. Take it, take a deep breath, and try to pick your battles.”

A website Mark created reflects the position of many of the core developers on the capital_P_dangit discussion:

While this had all of the hallmarks of a bikeshed, there were some procedural issues that community members felt ought to be taken seriously. Whether the WordPress software capitalized the “p” in WordPress or not, the method by which the function was added to core broke accepted procedure: no ticket was opened, no patch uploaded to trac. The code was simply committed. For some, this set up an “us vs. them” mentality, where some core developers could commit code as they saw fit, while everyone else in the community was subject to a different process.

Despite these development snafus, with WordPress 3.0, the platform matured, making “WordPress as a CMS” a reality. It also introduced a new default theme for WordPress, ushering in a new approach with new annual default themes. Gone was Kubrick, with its bold, blue header. The new theme, Twenty Ten, showcased WordPress’ new menus feature.

WordPress 3.0 ushered in changes to the project and the development process. It opened up WordPress to a new generation of people who became increasingly active. Over the coming releases, some of those committers would take on leadership, both in terms of development and in the wider community.

Throughout this time, Automattic held WordPress’ trademarks. Trademarks are an important asset to companies, to free software projects, and to anyone who has a product to protect. A trademark represents a project’s reputation, and is a symbol of official endorsement. Free software licenses protect the terms under which a program can be distributed, but they don’t grant trademark rights. In a 2009 article on trademarks in open source projects, Tiki Dare and Harvey Anderson report that of the 65 licenses endorsed by the Open Source Initiative (OSI), 19 don’t mention trademarks, 19 prohibit trademarks in publicity, advertising, and endorsements, and a further 26 explicitly exclude trademark rights.

Trademark law protects a piece of code’s marks and branding — not the code itself. A software project’s code exists in its community’s commons, but the trademarks do not. The growing issue of free software trademarks was conceded in 2007 with GPLv3. One clause states that the license may be supplemented with terms “declining to grant rights under trademark law for use of some trade names, trademarks, or service marks.” This reflects that free software communities accept that a trademark is not necessarily linked to the software.

Users and consumers associate a trademark with the original project; the trademark denotes trust, quality, and dependability. It also helps to verify identity: if you’re dealing with a company bearing the Widget Company logo, then you expect to be dealing with Widget Company. This matters in the free software community as much as in the corporate world. A free software project’s trademark carries certain assumptions: that the project maintainers and developers are either involved with or officially endorse that product or service, and that it meets quality standards. “Being the source of code arguably matters more than source code in an open-source business,” write Dare and Anderson. “The code is easily replicated, as it is open, but the trust associated with source (or origin) is not replicable. Trademarks are all about source.”

Automattic registered the WordPress trademarks in 2006, but some contributors — who had helped build the software or started their own local communities — felt that they had as much right to the trademarks as Automattic. Some community members believed that the community owned the codebase and thus should own the trademarks, not the corporate entity. What Automattic did have, and the community at large didn’t, was the structure and money to protect the trademarks from abuse and dilution. This often came at the cost of good relations with the community.

Automattic had always intended to place the trademarks with the WordPress Foundation, which is a separate entity from the company. Automattic acted as a short-term trademark guardian, protecting the trademarks until another body could take over. This was made clear to the company’s investors at the outset. Phil Black, one of Automattic’s first investors, recalls knowing that the trademarks would not remain with the company. “It wasn’t like Matt was proposing something to us where we felt like a significant asset was being lost,” says Phil. “A significant asset was being transferred to the right third party as we thought that it should have been.”

The Foundation counterbalances Automattic, providing checks and balances should Automattic ever be acquired. “Let’s say Evil Co. ran Automattic,” says Matt, “and Evil Co. only cares about making money. The balance between WordPress.org and the WordPress Foundation and WordPress.com is such that I think even Evil Co. would do the right thing with regard to the community and the code and everything.”

The Foundation took longer to set up than expected; various factors needed to be in place before it launched. Before the trademarks could be transferred, they needed to be properly secured and protected. Toni Schneider managed this during his early days at Automattic. It also took a long time to register the non-profit with the IRS. Because non-profits are tax-exempt, it can be difficult to set one up. Matt wanted the Foundation to hold the trademarks, but simply holding trademarks is not considered a legitimate non-profit activity. Applications sent to the IRS were denied for several years. In the end, the WordPress Foundation received 501(c)(3) status as an organization charged with educating people about WordPress and related free software projects.

The WordPress Foundation’s website states its mission:

The point of the foundation is to ensure free access, in perpetuity, to the software projects we support. People and businesses may come and go, so it is important to ensure that the source code for these projects will survive beyond the current contributor base, that we may create a stable platform for web publishing for generations to come. As part of this mission, the Foundation will be responsible for protecting the WordPress, WordCamp, and related trademarks. A 501(c)3 non-profit organization, the WordPress Foundation will also pursue a charter to educate the public about WordPress and related open source software.

The WordPress Foundation was launched in January 2010. Automattic transferred the trademarks later that year in September. As part of the transfer, Automattic was granted use of WordPress for WordPress.com, but not for any future domains. Matt was granted a license for WordPress.org and WordPress.net. As well as transferring the trademarks for WordPress itself, the company also transferred the WordCamp name. As with WordPress itself, this protects WordCamps as non-profit, educational events in perpetuity.

The community was pleased with decoupling WordPress the project from Automattic the company. It gave people more confidence that Automattic was not out to dominate the WordPress commercial ecosystem. Despite some initial confusion about how people were allowed to use the WordPress trademark, eventually it settled down.

In the same year, both Matt and Automattic explored different ways to support the WordPress project. Matt set up another company, Audrey Capital, which is the home for his investments. Audrey Capital allows him to hire developers for tasks that he doesn’t have time for, and this separation offers some balance between people who contribute to WordPress and who aren’t employed at Automattic.

“The idea was to kind of have five people at Automattic working on WordPress core, five people at Audrey working on WordPress core, and then I’ll try to get the different web hosts to each hire a person or two each, and so there’ll be between the three, fifteen-ish people, full-time on WordPress.org,” says Matt.

Developer Samuel Wood (Otto42) was Audrey Capital’s first employee. Matt and Otto share a love for barbecue. Otto was looking for someone to sponsor a BBQ team at the international barbecue festival in Memphis, Tennessee. Knowing Matt liked barbecue, Otto asked him to sponsor the team. Matt said yes and went to Memphis for the festival. The following year, Matt sponsored the group again, and eventually asked Otto to work for him at Audrey. Andrew Nacin — who would go on to become a lead developer of WordPress — joined Otto, and since then, Audrey has hired three more people to work on the WordPress project.

At the same time, changes at Automattic would have an ongoing influence on the project. By August 2010, the company had more than sixty employees. The sheer number of people meant that the completely flat structure was becoming harder to manage. The company moved to a team structure in which groups of people worked on different projects: themes, VaultPress, and support, for example. One of the newest teams at Automattic was the Dot Org Team, dedicated to working on the free software project. Ongoing members were Ryan Boren and Andrew Ozz, WordPress lead developers; Jen Mylo, formerly WordPress’ UX lead responsible for the Crazyhorse redesign; and Andrea Middleton, who managed WordCamps.

Teams are fairly fluid inside Automattic, and people come to the Dot Org Team to work on the WordPress project, often bringing with them the knowledge and skills that they’ve developed elsewhere in the company. Employees can also do a “Dot Org rotation,” which means that they work on the WordPress project for a release cycle.

The Dot Org Team has helped mitigate the effects of hiring from the community. Seven out of the first ten Automattic employees came from the WordPress community, and over the years, the company has hired a number of contributors. While this has been good for individuals and for Automattic, it hasn’t always had a positive effect. When WordPress.com was almost the sole focus, contributors worked on the core project, which benefitted both the project and Automattic. Some early contributors who became Automattic employees found themselves spending less and less time on the project. Mark Riley, who was employed to do support, found that he had no time to help out in the WordPress.org support forums. For other people, this has happened slowly, over time, as Automattic has expanded into other products, while the core project evolved in a different direction — one with governance and structures, wildly different from the days of throwing up patches, heated discussions on wp-hackers, and waiting for Matt or Ryan to commit code.

The Dot Org Team has formed a bridge between the company and the community, ensuring that there are people within Automattic whose attention is 100% on growing the WordPress product and project. In 2014, the number of people working on WordPress from Automattic expanded even further. The Dot Org Team split into two: a developer team that works on the core software and on WordPress.org (Team Apollo), and a community team that is focused on events and the community (Team Tardis).