Part 5/Chapter 38

Dealing With a Growing Project

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, 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 Other teams were scattered over mailing lists and blogs. Toward the end of 2010, a new blog network was set up on — 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 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 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, 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.