Community blogs became important gathering spaces for those who wanted to communicate outside the core project’s official channels. One of these was WP Candy, a blog started by Michael Cromarty and later taken over by Ryan Imel. Another was WP Tavern, run by Jeff Chandler. WP Candy and WP Tavern became places where the community could share and discuss ideas, as well as vent outside the project’s central channels — and over time, both have hosted many major community debates.
One of the biggest debates was around data collection.
When WordPress 2.3 shipped with update notifications, the initial debate quieted down. Lynne Pope (Elpie) reopened the discussion in 2009 on WP Tavern’s forums, and also posted to wp-hackers. Lynne pointed out that Matt had said data collection would be reviewed in WordPress 2.5. She discussed URL collection and asked whether WordPress had a need to collect them, suggesting that an anonymous identifier could replace the blog URL. In the discussion thread on WP Tavern, Lynne went further into her concerns:
wordpress.org is not a legal entity so there is nobody to sue if data is misused. You can’t sue a community. There is no disclosure about what data is collected or how it will be used. People are just supposed to trust that volunteers working on an open source project can be relied upon to keep personal data private?
Since much of the data is freely available on the internet, many were unconcerned about the collection, but Lynne pointed out that what isn’t readily available is the totality of that information (WordPress version, PHP version, locale setting, plugin information, and the website’s URL as a package). In 2009, people were growing more concerned about internet privacy. People signed up for social media services that collected huge amounts of data, used to target advertising. A 2009 paper reported that personally identifiable information could be leaked from social networks (PDF) and third parties could link that data with actions on other websites. At the same time, internet users were becoming more vocal about privacy concerns. In February 2009, for example, when Facebook changed its Terms of Service to say that user data would be retained by Facebook even if the user quit the service, the company faced an outcry and was forced to backtrack.
In the midst of these privacy concerns, WordPress was a bastion of the independent web. If a person has privacy concerns, they can avoid using social media; but they can create a website using something like WordPress, on their own server, with complete control over their own data. For some people in the community, data collection tarnishes this independence. There is potential for abuse, and even if there is trust in the people who have access to this data now, there’s no guarantee that others with access to the data will use it in the same way in the future.
The more I thought about it, the more my knee-jerk objections faded away. Your server is doing an HTTP request, so the server knows your server’s IP address. You can figure out what blog domains are hosted on that IP with a search on Bing or several other search engines. So if WordPress.org really wanted to know your URL, it could find it. Again, that’s just based on the IP address, which you HAVE to send for HTTP to work. If your URL is discoverable, and your IP address has to be sent, withholding the URL doesn’t actually get you more privacy, ultimately.
While wp-hackers saw some of this discussion, it mostly took place on WP Tavern. The discussion thread generated 291 responses — the most popular post in the forum’s lifespan. It was also heavily discussed on Weblog Tools Collection under a post from Jeff Chandler, titled “Is WordPress spyware?”
The issue was reopened on WordPress trac, and was proposed for the development chat agenda. Some community members felt that their privacy concerns were valid, and that they weren’t being taken seriously. In the thread, Matt posts that WordPress.org only stores the latest update sent, but no historical data. Historical data is only held in aggregate so that statistics can be provided for plugin and theme developers.
Mark joined the discussion on WP Tavern to share some of the reasons he changed his mind:
An IP address, which must be sent by the server, is not significantly more anonymous than a URL.
URLs allow WordPress to verify the identity of a blog. When URLs are hashed it’s no longer possibly to verify the blog identity. Without proper verification, systems that involve plugin rankings based on usage or popularity are open to manipulation and abuse.
The privacy policy was updated to cover api.wordpress.org.
The core developers stuck with their decisions, not options philosophy; no option was added to turn off update notifications. By the time it was raised again, in 2009, the project could apply another one of its philosophies to making the decision — the 80% principle: if 80% of users find something useful, then it belongs in core; if not, then it belongs in a plugin. A number of plugins were created to disable update notifications, but only a fraction of people used them. A clear notification of a website or plugin update was more important than adding a preference to satisfy a small number of people within the WordPress community.
WordPress continues to collect data about sites, which is used in a number of ways. The project, for instance, can make informed decisions about which technologies to support. Using the data, it was possible to tell that, in 2010, around 11% of WordPress users were using a PHP version below 5.2, and that fewer than 6% of WordPress users were using MySQL 4.0. Using that information, the development team was confident about dropping support for PHP 4.0 and MySQL 4.0. Browser usage data also helped in the decision to deprecate support for Internet Explorer 6.
Data is helpful when there is a security issue with a plugin, too. The project can detect how many sites have a plugin active and can determine the severity of the issue. In the case of a security issue in a popular plugin, web hosts are informed so that sites with insecure versions of a plugin can be blocked at the host level. Update notifications were also an important stage in the road toward automatic updates for minor releases, which were introduced in WordPress 3.7.
In December 2009, the core team — Matt, Mark, Ryan, Westi, Andrew, and Jen — met in Orlando, Florida. Despite working together on the project for years, it was the first time that some of them were meeting face to face. Working from the Bohemian Hotel lobby, they discussed live project issues, including “the merge, canonical plugins, the WordPress.org site, community stuff, and all the other things that are important but that we never seem to have time to address.” As well as discussing WordPress’ vision and goals, they had a trac sprint that edged them closer to shipping WordPress 2.9.
From left to right: Mark Jaquith, Jen Mylo, Andrew Ozz, Peter Westwood, Matt Mullenweg, Ryan Boren.
Direction for the coming year(s), canonical plugins, social i18n for plugins, plugin salvage (like UDRP for abandoned plugins), WordPress/MU merge, default themes, CMS functionality (custom taxonomies, types, statuses, queries), cross-content taxonomy, media functions and UI, community “levels” based on activity, defining scope of releases, site menu management, communications within the community, lessons learned from past releases, mentorship programs, trac issues, wordpress.org redesign, documentation, community code of conduct.
Meeting in person allowed them to bounce ideas off of one another and to get work done. Jen recalls:
We sat in these red velvet chairs in the bar of the Bohemian Hotel in Orlando, and when it was time to eat we would go into the dining room and we would eat. And we’d come back and we’d work, and we were on our laptops and actually going through trac as well. And doing bug scrubs, but then we would stop and we would have just conversations and we’d go outside maybe or we’d go out to lunch. And so we kind of mixed it up, and it was just so helpful. Both in terms of just getting to know each other better, and the actual work.
Meetups continue to be part of core development, from small and focused ones with the core team to large gatherings involving the whole community. Members meet at WordCamps, or at dedicated meetups to do code sprints and to discuss the general project and development direction. They provide an opportunity for people to discuss issues without the barrier of a screen, and also to socialize, hang out, and get to know one another better. When community members meet, they generate new ideas and thrash out old ideas in detail. Meetups aren’t, however, without side effects. Meeting in person, by its nature, excludes everyone who isn’t physically present. In a free software project, it’s important to balance offline meetups with online activity, which allows everyone to have a say.
The canonical plugins project was discussed at the first core meetup. The WordPress plugin repository was growing, and many plugins did the same thing. Large, complex plugins can transform WordPress, though some plugins had poor code quality, while some were out of date. Sometimes, a developer drops a plugin, leaving users without support or updates — a big problem if a user relies heavily on the feature. The core development team felt that some plugins warranted a similar process to the core development process, where a group of coders lead a plugin’s development, deciding what goes in and what doesn’t, in a similar way to how WordPress, BuddyPress, and bbPress are developed. Rather than having ten SEO plugins, or ten podcasting plugins, for example, there would be one canonical plugin, sanctioned by core with its own official development team.
WordPress’ core development team supported the proposal, which Jen wrote about on the blog; the strong relationship between WordPress core and canonical plugins would ensure plugin code was secure, that they exemplified the highest coding standards, and that they would be tested against new versions of WordPress to ensure compatibility.
Early discussions focused on what to call this cluster of plugins. The community voted and decided on “Core plugins.” Then, a team got to work, which included Westi, Aaron Campbell (aaroncampbell), Austin Matzko (filosofo), Stephen Rider (Strider72), and Pete Mall (PeteMall).
Health Check, which checks a website for common configuration errors and known issues; PodPress, a popular podcasting plugin which had been abandoned; and a proposed plugin to shift the post by email functionality from core into a plugin were the first canonical plugins.
But plugin developers weren’t so enthusiastic. They liked having ownership over their own plugins. The WordPress project was accused of trying to stifle the growing plugin market. Discussions continued among developers about how core plugins might influence them. Justin Tadlock said:
There’s been some great discussion here, but it seems a little one-sided. Most of the people leaving comments are developers. What would make the conversation much better would be to hear from more end users.
I will refrain from sharing my opinion until I can gauge what a larger portion of the user base is feeling because, quite frankly, that’s the portion of the community that influences my opinion the most.
User feedback on the thread was positive: any help sifting through the mass of WordPress plugins was a benefit. Why should users have to sift through fifty contact form plugins when there could be one, officially sanctioned plugin that could serve 80% of users? The project didn’t intend to kill off the plugin market, and Mark Jaquith tried to calm developer fears: “Core plugins will be safe and stable,” he wrote, “but limited in scope and probably a little bit boring and not completely full-featured.”
The core plugins project, however, was beset by other problems. While there was potential for success, they lacked the tools to work effectively across a broad group of plugins. “We didn’t have the toolset at the time to do it properly,” says Aaron Campbell, “without stepping outside of the WordPress ecosystem quite a bit and relying on something like a GitHub or something like that, which we prefer not to rely on for things that are really kind of the core of WordPress.”
To properly manage core plugins, the WordPress project’s infrastructure would have to change. When the plugin repository was built, it was designed with one author per plugin; developer collaboration tools didn’t exist. (While the plugin repository has become more flexible — it’s now possible, for example, to have multiple plugin authors — traditional developer collaboration tools are still lacking.) A system to submit contributions, discuss and modify patches, and merge them are useful for multiple developers working on a single plugin. To develop WordPress, tools have been built around the Subversion repository to make that possible, and the modified trac instance encourages collaboration. But each core plugin would need a replica of the infrastructure that WordPress uses itself, and it became obvious that the plan was untenable.
On top of this, many of the developers were burned out from WordPress 2.9 (and taking a break with the promise of a major release cycle in WordPress 3.0). They didn’t have the time or energy to build core plugins, as well as develop the core product itself. Despite the coverage the project got across the community, and despite the initial burst of energy, the canonical plugins project eventually fizzled out.
Jen Mylo emphasized usability, as well as encouraged more people to contribute to WordPress. Conversations happened on wp-hackers and trac, but it wasn’t always obvious how new people could get involved with the project. Project growth compounded the problem; it wasn’t easy for a new contributor to understand what was going on, nor how to contribute. Jen wrote about how to get involved, and the development blog announced patch marathons and bug hunts.
Jen brought more structure to the project: she reinstated weekly development chats with agendas and prevented discussions from disappearing down rabbit holes. When she joined the project, core developers communicated in two main ways: via the IRC chat room and by private Skype channel. Skype’s drawback is that it’s closed — it doesn’t create opportunities for other people to get involved. Also, because the main blog at the time, wpdevel.wordpress.com, was on WordPress.com and not WordPress.org, it didn’t feel official. There had been little project management; developers wrote code and pushed it out when it was ready.
At this time, Matt stepped back. Ryan Boren led development, while Jen stepped up to project-manage the software and took a leadership role within the community.
She tried to address communication fragmentation within the project. By 2009, project communication happened in different places: trac, wp-hackers, the #wordpress-dev IRC chat room, wpdevel.wordpress.com, and the WordPress.org development blog. Jen highlights the state of each of WordPress’ primary communication channels: the #wordpress-dev channel had become mostly inactive; wp-hackers had thousands of subscribers, but was often just a troubleshooting forum; the development blog was used for official announcements only; the wpdevel.wordpress.com blog (directed now to https://make.wordpress.org/core) housed team progress updates; Trac had become an unworkable mess with hundreds of irrelevant tickets; and the ideas forum contained many highly voted, but irrelevant threads.
Communication improvements were discussed in a forum thread. Suggestions included: a place other than trac for people to raise things; a way to make it easier for people to write automated unit tests, allowing the community to vote on ideas; greater documentation integration for WordPress and trac; adopting P2 for discussion; and using BuddyPress — a social-networking plugin that is a sister project to WordPress — on WordPress.org.
Amid suggestions were complaints: it was noted that no one official read the ideas forum, timezone differences made IRC meetups difficult to attend, and too many communication channels existed — far too many for people to keep up with. Some people complained about community governance and a lack of transparency. As Jen observed, “Your post just proves the point that communication is an issue. I would not say that WP lacks a clear direction, I would say that it simply hasn’t been communicated properly.”
Jen wanted to clarify how project decisions were made. It wasn’t uncommon for people to toss feature requests into IRC chat. People needed to know what each communication channel was for and understand the correct channels to ask questions and request features.
Much of the development discussion had shifted from wp-hackers to trac. Trac’s main benefit is that it focuses discussion directly on the bug, feature, or enhancement at hand. That said, as more and more people started using it, it became — just like wp-hackers — susceptible to intractable, bikeshed discussions.
Smilies were at the heart of one such recurring discussion. In 2009, a ticket requested replacing WordPress’ smilies with Tango/Gnome smilies. Ryan Boren committed the patch.
The smilies landed first on WordPress.com, which receives daily codebase updates. The feedback was negative and reaction on the trac ticket spiralled; contributors were unhappy that smilies had been changed without discussion. They argued that WordPress had changed users’ content, without giving them any say in it. The discussion spread from trac tickets to community blogs. Some wanted a public poll to aid the decision.
Ryan Boren eventually reverted the change, saying: “Back to the prehistoric smilies that everyone complains about but evidently likes better. 🙂 I was a fool for not appreciating the explosive topic that is smilies, my bad.” [footnote]The smiley debate was reignited in 2014, when WordPress.com updated its emoticons and a proposal was made to produce high-dpi smilies for use on retina displays. Once again, people had strong opinions, as seen across community blogs. As of 2015, the smilies are still not updated.[/footnote]
As well as trying to fix communication problems, some worked on improving documentation. To commit a patch in WordPress core, there is a review process. The WordPress Codex, on the other hand, is the opposite: any contributor can publish documentation immediately. This is a low-friction way to create documentation, but because it lacked rules and structure, it became difficult to navigate; pages fell out of date, and — despite the efforts of the documentation team — it became a mess. User documentation is packaged up with developer documentation, often on the same page, and for many WordPress users and developers, the Codex became less useful. In the meantime, WordPress tutorial blogs proliferated. In the absence of good, official documentation, people went elsewhere.
The Handbook Project sought to create references for theme and plugin development. The team launched a trac instance and wordpress.com blog to manage the handbooks. It can be difficult to recruit long-term help on documentation. With the low-entry barrier, many people make their first WordPress contribution through documentation, but as they figure out the project’s contours they move on to contributing to core. The original handbook project was passed between different people, and by 2014 it was near completion.
In mid-2009, WordPress dropped the long-term security branch — something Mark Jaquith had maintained since 2006. The plan was to maintain it until 2010. During that period, however, there were major changes to WordPress’ security. Backporting those changes into the 2.0.x branch meant complex rewriting that could have introduced new bugs or instability. The developers found that few people were on 2.0; new feature proliferation meant that people upgraded more readily. The legacy branch continued until just six months shy of its 2010 target, and was deprecated in July 2009.
Not backporting is a conscious decision. I would rather invest 100 hours in backward compatibility in a new version than 2 hours in backporting a fix to an obsolete version of WordPress. Plus, as noted by everyone else, backporting was often impossible because it wasn’t one or two line fixes, it was architecture changes that would touch dozens of files. The LTS was actually less stable with these “fixes” backported because it had almost no one using it.
Rather than supporting an LTS branch, the project focuses on easy updates and compelling features that entice users to upgrade. This iterative process has continued to improve throughout the project’s history, from Matt’s first mention of upgrades in his 2006 State of the Word address, to automatic updates introduced in WordPress 3.7. This approach focuses development on keeping users secure, rather than trying to maintain older software branches.
As the project transformed, so did the wider economy around WordPress. When Brian Gardner released the Revolution theme under the GPL in late 2008, theme developers watched with curiosity to see how it would influence his business, as it seemed counterintuitive to give a product away.
As theme authors watched and waited, commercial theme licensing came to a head. Toward the end of 2008, 200 themes were pulled from the WordPress theme repository. A statement was added to the About page of the Theme Directory that said, “All themes are subject to review. Themes for sites that support ‘premium’ (non-GPL or compatible) themes will not be approved.” This meant that the Theme Directory no longer allowed free GPL themes that linked back to the site of a premium theme seller, whether the themes they sold were GPL or not.
Premium theme developers and the wider community were annoyed. What was the problem with theme authors selling themes? The themes hosted on the Theme Directory were free and complied with the GPL. As so often in the past, people conflated the actions of WordPress.org with Automattic and the company came under fire. Some perceived theme removal as a sign that Automattic didn’t want anyone making money.
The theme sellers were genuinely unhappy. Their themes were pulled without warning. Many theme sellers saw their free theme releases as a way of supporting the free software community, and spent considerable time ensuring that they met the theme repository’s standards. They felt as though a rug had been pulled from underneath them: they’d done their best to comply with WordPress.org standards, but suddenly it wasn’t enough.
An email from Matt made the rounds in the community:
Thanks for emailing me about the theme directory. The other day I noticed a ton of bad stuff had snuck in like lots of spammy SEO links, themes whose sites said you couldn’t modify them (which is a violation of the GPL), etc. Exactly the sort of stuff the theme directory was meant to avoid.
There were also a few that violated WP community guidelines, like the domain policy. So since Monday we’ve been clearing stuff out en mass. If you’re kosher with the GPL and don’t claim or promote otherwise on your site and your theme was removed, it was probably a mistake. Give us a week to catch up with the bad stuff and then drop a note.
In a podcast on Weblog Tools Collection, Matt discussed his position on the premium theme market (transcription). In the interview, he describes how, while updating a friend’s website, he was looking for WordPress themes in the directory. He found themes with SEO links or linked to SEO sites — behavior that the Theme Directory had been set up to avoid. The WordPress.org team questioned whether they wanted to allow GPL themes that only served as advertisements for non-GPL themes elsewhere.
In the interview, Matt discussed the distinction between “premium” and “free” themes, and the importance of correct labeling. When it comes to “premium” themes, Matt argued that the word “proprietary” makes more sense than “premium” or even “commercial.” GPL themes, such as Brian Gardner’s Revolution, could be commercial.
I love what Revolution has done, where they say ‘Ok, so we still sold the theme, and we still bundle the support and everything like that with it, but it’s also available as GPL.’ So they’re able to, within the GPL framework, create a business and respect the underlying license of the community that they are building on top of.
Matt made it clear that theme developers were free to do what they wanted on their site, but the WordPress project was equally free to do what it wanted on WordPress.org, and that included whether it should or should not promote businesses that sold non-GPL WordPress products.
Part of the aim of the theme and plugin repositories is to promote theme and plugin developers. The project doesn’t want to promote theme developers who follow the license to get on WordPress.org, but then violate WordPress’ license elsewhere. So, theme sellers who sell non-GPL products outside of WordPress.org aren’t promoted on the site.
The interview delineated what WordPress.org would and would not support. People got an answer, whether they liked it or not. The storm calmed and cleared the way for 2009, when businesses started to embrace the GPL.
In the months following the debate, people wondered how to sustain a business under the GPL. As the first to embrace the license, Brian Gardner advised other premium theme sellers. In April 2009, Spectacu.la, the theme shop that first posted about themes being removed from the repo, announced that it was going fully GPL. It was followed in June by iThemes and WooThemes.
…the WordPress themes supplied contain elements that are derivative of WordPress’s copyrighted code. These themes, being collections of distinct works (images, CSS files, PHP files), need not be GPL-licensed as a whole. Rather, the PHP files are subject to the requirements of the GPL while the images and CSS are not. Third-party developers of such themes may apply restrictive copyrights to these elements if they wish.
WordPress themes are not a separate entity from WordPress itself. As Mark Jaquith wrote later, “As far as the code is concerned, they form one functional unit. The theme code doesn’t sit ‘on top of’ WordPress. It is within it, in multiple different places, with multiple interdependencies. This forms a web of shared data structures and code all contained within a shared memory space.”
Following that announcement, more theme sellers adopted the GPL license, though not all went 100% GPL (i.e., including CSS, images, and JavaScript). Envato, for example, whose marketplace, ThemeForest, was growing in popularity, opted for GPL compliance — with two licenses, in which the PHP was GPL, but the additional files were proprietary.
Themes that are packaged using this split license follow the GPL. The PHP carries a GPL license and other assets do not. The other elements — CSS, images, JavaScript, etc. — usually have some sort of proprietary license. This ensures legal compliance. It aims to protect author rights by removing the freedoms guaranteed by the GPL — the freedom to use, modify, and distribute modifications. Users are not free to do what they want with a theme licensed in such a way because the CSS and JavaScript are just as important to a theme as the PHP that interacts with WordPress’ internals. But it would be a number of years before this licensing debate would occur.
According to Ryan Boren, WordPress 2.7 ushered in “the modern era of WordPress.” It also brought a new face to the WordPress project. WordPress 2.5’s redesign wasn’t well received, though the reasons why weren’t clear. Was the user interface the problem? Or did people dislike it because they felt cut out of the process?
Jen Mylo (jenmylo)[footnote]At that time, Jen Mylo’s name was Jane Wells. Her name changed in 2013.[/footnote] and Matt are old friends. At the time, she ran a usability testing and design center at a New York agency in conjunction with Ball State University. The center’s usability studies used the latest eye-tracking technologies with clients, including television networks such as ABC, NBC, and MTV. When a TV network missed a usability test window, Jen offered the slot to WordPress at cost.
The usability review had three stages conducted in two rounds. In Round 1, they tested WordPress 2.5, gathering “low hanging fruit” recommendations to improve the admin’s UI. Using the recommendations, the development team created and tested a prototype (Test1515) to learn whether users’ experiences had improved. In Round 2, they created and tested a more drastic prototype — dubbed Crazyhorse[footnote]Unlike WordPress releases, smaller projects, like Crazyhorse, don’t always follow the jazz-musician naming convention.[/footnote] — based on the Test1515 findings.
The research team used three main testing methods in Round 1:
Talk-aloud, in which participants are asked to think aloud as they carry out tasks.
Morae screen activity and video recordings, which allow researchers to watch participants remotely.
Eye-tracking technology to identify granular problems.
Twelve participants tested WordPress’ admin. In Round 1, despite finding WordPress generally easy-to-use, the researchers identified several problems, including:
Verbs vs. nouns: users found it difficult to conceptualize tasks because they weren’t action-oriented (Write/Manage). Instead, users perceived content in a more object-oriented way. (Posts, Pages, Comments, etc.)
Users didn’t spend time on the dashboard. They used it as an entry point for other pages.
The write post screen caused problems for users. Tags and categories appeared below the fold; some participants forgot to add categories and tags before publication — returning to the post screen to add them afterward.
The comments screen was confusing. Users didn’t understand that they had to click on a commenter’s name to edit a comment; they looked in the wrong place when asked to move a comment to spam.
The difference between uploading and embedding media in the media uploader confused users.
Round 1 testing on WordPress 2.5 uncovered minor issues with settings, the media library, link categories, and tag management. Users also wanted more control over dashboard modules and the post edit screen.
In addition to a laundry list of small interface issues that presented simple fixes, such as changing comment author links, we were faced with larger issues such as the desire for user-determined hierarchies on long/scrolling screens, ambiguity in the Write/Manage navigation paradigm, and a disconnect between the act of adding media to a post and the ability to manage it. — Usability Test Report (PDF)
Minor changes were incorporated into the Test1515 prototype and tested — though they were so minor that participants didn’t react strongly either way. The team created Crazyhorse to:
maximize vertical space,
reduce scrolling,
increase access to navigation to reduce unnecessary screen loads,
enable drag and drop on screens that would most benefit from user control, and
redesign management screens to take advantage of natural gaze paths.
Jen and Liz Danzico — who continued to work on WordPress’ usability in the Crazyhorse project — created the design for the prototype. They sketched multiple ideas: front-end editing, accordion panes, and a top navigation. They chose the simplest prototype: a left-hand navigation panel, similar to Google Analytics and other web apps.
The dashboard in the Crazyhorse prototype.
WordPress developers built the Crazyhorse prototype in a Subversion branch, based on the prototype document (PDF), which outlined changes and rationale. The project focused on user experience and functional development, so the prototype retained WordPress 2.5’s visual styles. As in Round 1 testing, participants carried out tasks; talk-aloud, Morae, and eye-tracking helped assess results.
Most participants preferred Crazyhorse over WordPress 2.5 and every new feature tested provided actionable information for the next version of WordPress.
Participants loved the navigation on the left-hand side of the screen. They also preferred the object-oriented approach to organization. (Posts, Pages, Media, etc.)
Participants thought the Crazyhorse dashboard was more useful, and people appreciated the ability to customize it. They liked QuickPress, though they weren’t sure if they would use it. With action links beneath comments, users found it easier to edit and moderate them.
The Write Screen in the Crazyhorse prototype.
The new Write screen had a drag and drop feature — allowing users to decide which elements got prime screen real estate. They also liked access to post comments; they felt that the new media uploader — with media library integration — was a huge improvement.
The bottom publish bar in the Crazyhorse prototype.
Users panned a publishing bar that floated at the bottom of the screen — they’d look at the bar a few times before realizing it contained the Publish button. Some users compared it to a banner ad or thought it part of their browser.
While Happy Cog and project Crazyhorse did user research, they ended up with quite different results. For Happy Cog, Liz interviewed community members and conducted in-person user testing. The Crazyhorse project, however, used eye-tracking technology. This meant that the testers didn’t have to rely solely on what participants said; they had insight into what participants were actually looking at during tests. Additionally, gaze trails revealed how users navigated the screen with their eyes, allowing testers to ask: what draws user attention first? Do they miss important UI elements? Do they understand what they’re seeing?
With the Crazyhorse prototypes a proven success, fleshing out its design was the next step. When Crazyhorse first merged with trunk, it was a set of live wireframes. Design changes had not been introduced to prevent swaying participants by color or typeface preferences. By the time the Automattic meetup in Breckenridge, Colorado, took place in 2008, Crazyhorse was ready for some color.
At Automattic meetups, small teams work on projects assigned at the beginning of the week. Matt Miklic (MT) (iammattthomas) [footnote]At that time, Matt Miklic’s name was Matt Thomas. His name changed in 2014.[/footnote] took on Crazyhorse with free design rein. In redesigning the admin, Jen and MT produced many designs. There was a heavy blue variant reminiscent of Shuttle-inspired WordPress, and a version using the light blue, grays, and orange of Happy Cog. Eventually, these two main variants melded into a gray color scheme that WordPress featured until 2013. Andrew Ozz (azaozz) received commit access to help implement the Crazyhorse changes.
Jen’s community connection differentiated the Happy Cog and Crazyhorse processes. She kept the community abreast of what was going on. She did testing as an adjunct to the WordPress project to verify actual usability flaws with little community involvement. If it had been just a matter of user color preferences, the Crazyhorse project would have been fruitless. But when testing revealed WordPress’ interface needed to change, community dialogue ensued. The designs and the usability report were shared on the development blog. The team surveyed users on navigation options, and the community discussed issues on the wp-hackers mailing list. When WordPress 2.7 released, the launch post lists the posts Jen and the developers wrote about the process. Up to that point, it is the only iteration of the WordPress admin to have such an information trail.
With the Crazyhorse project, WordPress’ admin changed drastically — twice in 2008 alone. When screenshots of the changes appeared on community blogs, the inevitable question was “why are they changing it again?” WordPress 2.5’s design hadn’t settled in before another huge change came about with the implementation of Crazyhorse in 2.7. A UI change meant that users of varying skill levels needed to relearn how to use WordPress; the growing WordPress tutorial community would need to retake every screenshot and reshoot every video. However, when WordPress users upgraded, the feedback was positive. Users loved the new interface; they found it intuitive and easy to use — finally demonstrating that it wasn’t change they had been unhappy with just nine months earlier — but the interface itself.
The Write Screen in the WordPress 2.7 admin.
WordPress 2.7 brought the WordPress Plugin Repository to the admin screen. Users no longer had to download a plugin and upload it using FTP. They could search the plugin directory for the features they needed right from their admin, and install the plugin with just a few clicks. This made it much easier for WordPress users to quickly find and install plugins, removing FTP’s technical barrier to entry.
After completing the Crazyhorse redesign, Jen joined Automattic to work on WordPress. At that time, there was a close core developer group who led the project working in IRC and in Skype. In October 2008, Jen first appeared on wp-hackers. She brought fresh eyes and a completely new perspective. Her background in user testing and user experience was largely absent in the community until she joined the project. “Having someone with actual formal training in testing and user experience, it was just useful,” says Mark Jaquith. “It was not just useful then, but it also changed us. Or at least it changed me. Where I started thinking in these ways as well and becoming better at stepping out of my own head.”
This new focus on user testing and user experience meant that the software would work for everyone who wanted to install it — not just a small set of users.
In the wake of sponsored themes, theme developers were looking for ways to make money. Some made money from customizations, but increasingly, people wanted to make money with WordPress products rather than with services. Why build one site when you can build one theme and sell it multiple times? If theme developers couldn’t sell links, they could do the next best thing — sell themes directly to WordPress users. There was, however, some hesitation around this. When the project removed sponsored themes from official resources, people interpreted this in different ways:
“WordPress doesn’t support sponsored themes.”
“WordPress doesn’t want me to make money.”
“Automattic doesn’t want me to make money.”
Some people felt that Matt only wanted Automattic to make money from WordPress, a situation that wasn’t helped when, after the sponsored themes debate, Matt announced a WordPress.com theme marketplace, resulting in cries of hypocrisy. Despite laying the initial groundwork, Automattic decided not to go ahead with the plan. “It didn’t seem right to go into it when we hadn’t really worked out all the licensing issues yet,” says Matt. [footnote]The theme marketplace didn’t launch until 2011, four years after the initial announcement.[/footnote]
While the WordPress.com theme marketplace was set aside, employees inside Automattic were still curious about whether people would pay for a blog design. Noël Jackson (noel), a former Automattic employee, recalls the time when premium WordPress themes started to appear:
It was interesting, especially in the beginning when it started happening. It was interesting to see revenue figures for themes that were released as a premium theme — not a WordPress.com premium theme — but someone selling their theme and keeping the GPL license and thinking, “Well, people are actually buying this.” There wasn’t an issue with it. I think that made everybody happy.
Bloggers who used WordPress dabbled with making themes. They released them for free. “A funny dynamic happened,” recalls Cory Miller (corymiller303), the founder of iThemes. “People started hitting my contact form and saying will you customize this, or will you do this theme, or will you do all that stuff, and I was like I’m, I’m kind of a fraud here. And so I started charging for my work.” This is the familiar tale that some of the most prominent WordPress business founders tell today. Many of the people who run these businesses started out simply by making themes. These were often accidental businesses, with accidental businesspeople — people who came to the community to scratch their own itch and found themselves inundated with requests for help, support, and customizations.
Although sites like Template Monster sold WordPress themes as early as 2006, the last quarter of 2007 saw the first surge in WordPress premium theme releases from within the WordPress community. Brian Gardner’s Revolution — one of the first premium WordPress themes — launched in August 2007. A few weeks after, Tung Do released Showcase. Later that year also marked the launches of Proximity from Nathan Rice, Solostream from Michael Pollock, Cornerstone Theme from Charity Ondriezek, Premium News Theme from Adii Pienaar, and PortfolioPress from Magnus Jepson. Early the following year, Chris Pearson released Thesis.
Most of the theme vendors followed a similar path: from blogger to hobbyist themer. From releasing a free theme to testing the brand-new market. Few had career aspirations — these were side projects to make them money in their spare time. Some also did independent development for clients. But the idea that selling WordPress themes could be big business didn’t cross their minds. “Even when I quit my job to spend more time working on these themes,” says Adii Pienaar (adii), co-founder of WooThemes, “and eventually rebranding and calling that effort WooThemes, I still thought that I was going to build a business around the custom design/development stuff, around consulting.”
Theme sellers weren’t sure how to price and license their themes. There was no community consensus about licensing and nothing clear from the project. Theme authors created their own license. A common model was offering a single-use license to use a theme on one site, and a developer or bulk license to use a theme on more than one site. These licenses restricted the number of sites on which a theme could be installed, and what the user could do with a theme. Some, for example, required that the user retain the author credit in the theme, which enabled the authors to charge users to remove the attribution link.
Users downloaded a free theme at no cost, or paid for a premium one. The label “premium,” however, implied that paid themes were intrinsically better, as though attaching a price tag elevated premium themes above free (and theoretically inferior) themes.
These commercial themes were often branded as “premium themes,” but there was little consensus about what made a theme “premium.” When Weblog Tools Collection (WLTC) asked, “What Makes a WordPress Theme Premium?,” responses from community members were varied: “better documentation and support,” “less bloggy,” “better design,” “better features,” “better code,” and “more functionality.” Several people argued that money was the only difference between free and premium themes.
What distinguished designers and developers making free and premium themes was the time and effort they put into them, and the level of effort required to set them up. In an interview in June 2008, premium theme developer Darren Hoyt talks about the differences between creating a free and premium theme. He outlines his considerations:
That hand-coding and tweaks to the files should be minimized with the inclusion of a custom control panel.
That users shouldn’t have to download plugins so all theme functionality was bundled with it. “We tried to make Mimbo Pro more than just a theme or ‘skin’ and more like an application unto itself.”
That best practices for commenting code, valid markup, and well-written CSS are followed.
That documentation be provided and evolve.
That buyers get ongoing support and interactions with the developer.
Brian Gardner, designer of Revolution, said in a March 2008 interview that for him, a premium theme differs in how the site looks and acts. “If people respond to a site and say ‘wow, I can’t believe WordPress is behind that,’ that’s what premium themes are all about.”
Attitudes varied widely between users, developers, and other community members. The user who interviewed Brian Gardner was a keen Revolution advocate. He commends the guaranteed support, comfort, safety, and the feeling that he’s being looked after. A price tag doesn’t necessarily equate to these things, but some premium theme developers make customer support a priority — and their theme sales rise. WordPress was no longer confined to the world of personal blogging. Businesses, particularly small businesses, used WordPress to build their websites. Paying a small fee for peace of mind was a worthwhile trade-off; it brought the promise of ongoing support. A free theme came with no guarantees.
Some theme developers were frustrated by premium theme sellers. “‘Premium,’ when it comes to WordPress themes,” writes Ian Stewart in 2008 (iandstewart), “simply means ‘it costs money’ and not ‘of superior quality.'” The false dichotomy set up by the “premium” label undervalues themes released for free. Justin Tadlock (greenshady) released the Options theme to prove that there was nothing to stop developers from releasing a free theme fully packed with bells and whistles. He was one of the first to explore an alternative business model, setting up his own theme club. In contrast to theme sales, he wanted to create a community around theme releases and support. Later that year, he launched Theme Hybrid.
The issue of whether someone should be selling themes wasn’t clear-cut. Some thought that you had to choose: you could either be involved in the community, or make money selling themes or plugins.
In a discussion on a wp-hackers thread from March 2008, the author concluded that a person either focused on making money or contributing to the community. But Mark Jaquith pointed out that the two aren’t mutually exclusive: it’s possible to make money with WordPress, while still making a positive contribution to the project. In the same thread, Matt outlined how he saw businesses best interacting with the WordPress community:
A GPL software community is like the environment. Yes you could make profit building widgets in your widget factory and not pay any heed to the forests you’re clearing or the rivers your (sic) polluting, but in a few years you’re going to start to deplete the commons, and your business and public perception will be in peril…Contrast that with sustainable development, with giving back to the community that sustains (and ultimately consumes) your services and you have the makings of something that could be around for generations to come.
Matt didn’t see the premium theme market as in step with the community. He proclaimed premium theme sellers were in “murky waters,” pointing out that there wasn’t much money in the enterprise. In a 2009 conversation with Ptah Dunbar, Matt said that he didn’t like where premium WordPress themes were going, and that the premium theme market wasn’t helping the community to grow.
Whatever the community’s perception, users pay for themes, and companies that sell themes make money. Take ThemeForest, for example. The marketplace sells themes and templates for WordPress and different CMSs, as well as HTML templates. Upon launch in September 2008, ThemeForest sold mostly HTML templates; WordPress themes were 25% of sales. By September 2009, WordPress themes were 40% of all ThemeForest sales. In 2013, WordPress themes were 60% of all sales.
The discussions weren’t just focused on whether people should make money from WordPress. A bigger question was: how should themes be licensed? WordPress itself is licensed under the GPL. The GPL’s copyleft distribution terms ensure that distributions and modifications of the software carry the same license. Derivative works also carry the license. Is a theme derivative of WordPress? There were arguments for and against, speculation, and opinion — much of which was based on interpretations (or secondhand interpretations) of the license. Court cases are rarely fought around the GPL. Those that come close are often settled out of court, as with the Free Software Foundation vs. Cisco lawsuit, which happened at the same time as the WordPress community’s debate over WordPress themes. The community was divided into two camps — those who thought themes didn’t have to be GPL, and those who thought they did.
There are a number of different factors, and one is whether a WordPress install and its theme is an “aggregation” or a “combination.” The GPL FAQ distinguishes between the two: an aggregate means putting two programs side by side (like on a hard disc or a CD-ROM). People who thought that themes don’t have to be GPL argued that WordPress with a theme is an aggregate. They believed that a theme modifies the output of WordPress, but doesn’t necessarily engage with its internals. WordPress core developers, however, stated that themes use WordPress core internals. For a theme to be completely independent, it would need to use none of WordPress’ internal functions.
For those who accepted that PHP was linked with WordPress in such a way that the theme inherited the GPL, there was still another possibility: distributing with two licenses — which is what people often refer to as a “split license” — or what Matt described as “packaging gymnastics.” While the PHP in a WordPress theme works with WordPress internal functions, the CSS, JavaScript, and images do not. Therefore, a theme developer can package their theme with two licenses: one for the PHP and one for the other files. For theme authors concerned about piracy and copyright, this protected their intellectual property, while ensuring they followed the letter of the GPL. For the project, however, this was simply an evasive game that did an injustice to the spirit of the GPL.
Piracy was a major concern for many theme authors. They worried that anyone could buy their theme, legally distribute it, and even sell it. Putting a proprietary license on a theme, however, doesn’t stop people from distributing them. Themes from commercial sellers cropped up on torrent sites all over the web and were sold on forums such as Digital Point for a cut price. It was easy, if a user wanted, to download a commercial theme for free (though it often came loaded with additional links and malware).
Other fears were around making money. How could a business make money by selling a product that the buyer had a right to give away — or even sell themselves? Designers and developers were reluctant to distribute with a license that they thought would damage their business. While Matt suggested they look into doing custom development, theme sellers were interested in selling products. It’s more immediately obvious how you can scale a business selling products than with services. After all, if you don’t factor in support and upgrades, it’s possible to sell a digital product ad infinitum, creating a relatively passive income for yourself. Time and resources constrain doing custom design or development for clients.
Revolution was the first theme to be distributed with a 100% GPL license. Brian Gardner, Revolution’s developer, has a typical theme developer story — he started as a tinkerer, did some contract work, started to sell themes, and realized he could make a business out of it.
Developers often came to the project with an implicit awareness of the free software and hacker ethos; they were comfortable with sharing code. Theme sellers came through another route: first they were bloggers, then tinkerers, then designers. As opposed to developers, theme sellers believed they had to protect their designs. “I and others that were starting to sell themes at that point wanted to protect our work,” says Brian. “We were almost scared of the open source concept where the design and images and the code we felt was all ours and really wasn’t derivative of WordPress itself so we sold things on a proprietary level.”
I’m happy to give significant promotion to theme designers who stop fighting the license of the platform which enabled their market to exist in the first place, just email me.
This was the encouragement that Brian needed. He emailed Matt to tell him he was interested. Before making the switch, Brian flew to San Francisco with fellow theme author Jason Schuller to talk to Toni and Matt. They discussed why theme sellers were using proprietary licenses and their fears around piracy. Matt and Toni made it plain: they were happy for theme sellers to make money, but themes needed to be GPL. In all of the confusion around the GPL, the message had become mixed. Theme sellers thought that they were expected to give themes away, not just that they were expected to distribute themes matching WordPress’ principles of freedom.
In the midst of these debates, themes found a new home on WordPress.org. The theme viewer that had been hosted on themes.wordpress.net was riddled with problems: themes had security holes, and many of them had obfuscated code. The system was continually being gamed, there were duplicate themes, and many contained spam. The theme directory on WordPress.org was set up to rectify this; it was a place developers could host their themes, and where users could find quality WordPress themes. In July 2008, the Theme Directory launched on WordPress.org, using bbPress (which, at that time, was not a plugin), making it easier than ever to distribute free themes.
Shuttle had failed back in 2006 and WordPress’ admin still needed a redesign. Matt turned to design studio Happy Cog. Jeffrey Zeldman, Happy Cog founder, led the project, along with WordPress’ logo designer Jason Santa Maria and UX designer Liz Danzico.
Whereas Shuttle focused on aesthetics, Happy Cog identified and corrected information architecture problems, and updated and improved WordPress’ look and feel. Despite the project’s user-first ethos, the admin screens had become cluttered, as new features were sometimes added in a haphazard way. The change between WordPress 1.5 and WordPress 2.3 speaks for itself.
The Write screen in WordPress 1.5.The Write screen in WordPress 2.3.
Happy Cog produced designs that WordPress developers then coded. The project included user research and an interface audit to identify WordPress’ strengths and weaknesses, and to inform new structural and interface designs.
WordPress, as a free software project, was an unusual client for a traditional design agency. Matt and Jeffrey formed a buffer between the Happy Cog team and the community, but the designers, nonetheless, knew this was an entirely different type of client. Jason Santa Maria says:
Any other client will have customers and their own community, but you really have to just manage the people inside of a company, whereas when you’re dealing with an open source project, you deal with the people that you’re talking with, but there’s this whole gamut of other people that you will only ever get to talk to a small portion of. I think that that’s really difficult.
Plus, I think that on an open source project like this, it’s inherently different, not just because it’s more of a CMS than an informational website — the design needs are different — but it’s just a different kind of way to work, knowing that whatever you do probably isn’t going to stick around for very long. It’s going to continue to evolve and continue to be adapted. Usually, in the very near-term as well, not even three-four months from now, but next week.
An audit and usability review were among the first steps. Liz Danzico researched and produced a 25-page document on WordPress. WordPress needed an admin that didn’t intrude on the user. In the audit, she quotes Mark Jaquith: “That’s when I know WordPress is doing its job: when people aren’t even aware they’re using it because they’re so busy using it!”
Liz spoke to Mark Riley, whose support forum experience gave him direct access to users’ complaints. One of the major problems he highlighted was the clutter that had amassed in the Write screen between WordPress 1.2 and WordPress 2.0. Features had been added and then tucked into modules using the pods introduced by the Shuttle project. There were many actions a user could take on the Write screen, and many of them were confusing or hidden.
Discussion focused on navigation structure: labelling, position, and functionality grouping. Should they go with an object-oriented navigation (Posts, Pages, Comments, etc.) or an action-oriented navigation (Write, Manage, etc.)? Liz’s first hunch — supported by the newly launched Tumblr — was that users preferred navigating by nouns. She felt WordPress’ verb structure was confusing. The first navigational structure iterations introduced both a noun version and a verb version. In the end, however, and after limited user testing, the team went with a mixture of nouns and verbs: Write, Manage, Design, Comments. This meant that the functionality for different content types was scattered over different menu items — to write a post, for example, users would go to “Write.” To manage the same post they would navigate to “Manage.”
Happy Cog provided extensive and detailed proposals and research for WordPress, and shared them with Matt. Their reports display a sensitivity to web users, and an appreciation for simplifying and streamlining WordPress.
When it came to the design stage, Jason Santa Maria created three designs to present to Matt, who would choose one to move forward.
He designed three early mockups:
Mockup Number 1.Mockup Number 2.Mockup Number 3.
Matt chose the visually lighter design. Jason had taken Shuttle’s heavy blue palette and lightened the interface. An orange accent color complemented the lighter blues.
When the design was finally signed off, WordPress trunk started to transform. As changes took place, community feedback was posted to wp-hackers. Was the admin actually more usable? Major changes broke familiar patterns. Some comments compared the design to Shuttle’s; a few community members even wanted to implement Shuttle’s interface.
Just before release, a sneak peek was posted to the development blog, and WordPress users installed the release candidate to get a better look. The response echoed that of the rest of the community. Regular WordPress users were surprised by the functionality changes to the Write screen. For some, it was a step backward.
The Write screen in the WordPress 2.5 admin.
WordPress 2.4 was the first version to fall significantly behind the 120-day release cycle. Versions 2.2 and 2.3 were mostly on schedule, but the Happy Cog redesign brought in major changes to the codebase. Rather than just delaying release, a version was skipped, moving straight from WordPress 2.3 to WordPress 2.5, which was scheduled for release in March.
But there were bigger problems with this release cycle than just the delay. The community felt that they had not been consulted; they felt disenfranchised. In some ways, the redesign was destined to fail before it even began. With no participation and no process, there was no way to ensure community buy-in. Jeffrey Zeldman, reflecting on the process, says:
It worked for us, from our perspective, that we were a small team reporting to a single client who had life or death approval over everything. We had to please one user: Matt. He could say yes or no. We completely bypassed the community. That enabled us to get a design done that we felt was crisp and focused and achieved certain goals. And that sounds great. Except that, because the community wasn’t involved, inevitably, the design then became unpopular because nobody got their say in it. And if I could go back and do it again, I would involve them up front, and find ways to get my feedback without it turning into a committee clustercuss.
As with Shuttle before it, problems surfaced in the design process. Free software projects are collaborative enterprises; when part of the process moves behind closed doors to avoid the problems of working by committee, new problems arise. However much a project tries to avoid it, that committee exists and must have its say.
Peter Westwood became a core committer in July 2007, bringing the number of people who could commit code to four. Westi got involved in the project in 2004 while working as a software engineer — he had written a script that downloaded WordPress and installed it on a server. He helped with the Codex, and found and fixed bugs. Like many other developers, he had little PHP experience when he came to the project.
The wp-hackers mailing list was in its third year, but productive discussion there diminished over time. More and more decision-making happened elsewhere. For example, in February 2007, Ryan integrated phpmailer with WordPress. The code was committed after a short discussion on trac. It wasn’t until September that a phpmailer conversation took place on wp-hackers — one that few committers participated in.
There is just one thing I want to make clear about wp-hackers: a hacker is not someone who discusses or pays lip service or dissents or casts a vote or says what can or should be done. Hackers aren’t committee members. Hackers are more interested in proving what can be done than arguing about it.
There was too much talking and not enough hacking on wp-hackers, and opinion often swayed conversations rather than fact. Mailing lists can become dominated by people who have time to comment, rather than those doing the work. The latter might have the most valuable feedback, but they’re often too busy to keep up with a high-traffic mailing list.
WordPress isn’t alone in this phenomenon. A 2013 study of the Apache Lucene mailing list (PDF) found that “although the declared intent of development mailing list communication is to discuss project internals and code changes/additions, only 35 percent of the email threads regard the implementation of code artefacts.” As well as discussing development, mailing list participants discussed social norms and behavior. The study also found that project developers participate in less than 75 percent of the discussions, and start only half of them. Developers prefer to communicate on the issue-tracking software — a finding resonant with WordPress, as developers ultimately switched from the mailing list to WordPress trac.
Mailing lists tend toward bike shed discussions, [footnote]The notion of a bike shed was popularized in FOSS projects by Karl Fogel. In his book, Producing Open Source Software, he reprints an email from Poul-Henning Kamp to the FreeBSD mailing list with the title “A bike shed (any color will do) on greener grass…,” in which Kamp uses the “painting the bikeshed” analogy to describe discussions on the mailing list.[/footnote] a term derived from Parkinson’s law of triviality:
Parkinson shows how you can go in to the board of directors and get approval for building a multi-million or even billion dollar atomic power plant, but if you want to build a bike shed you will be tangled up in endless discussions.
An atomic plant is so vast that only very few people can grasp it. The board of directors assume that somebody has the knowledge and has done the groundwork. In contrast, everyone can build a bike shed, so everyone has an opinion on how it should be done, and especially what color it should be painted.
In his book Producing Open Source Software, Karl Fogel notes that as the technical difficulty of an issue goes down, the “probability of meandering goes up:”
…consensus is hardest to achieve in technical questions that are simple to understand and easy to have an opinion about, and in “soft” topics such as organization, publicity, funding, etc. People can participate in those arguments forever, because there are no qualifications necessary for doing so, no clear ways to decide (even afterward) if a decision was right or wrong, and because simply outwaiting other discussants is sometimes a successful tactic.
In 2007, for example, discussion about what to call links got heated. A member of wp-hackers asked, “Anyone know why it’s still called Blogroll in admin, when it’s called Bookmarks in functions (wp_list_bookmarks) and yet displays by default as a list of “Links” in the sidebar?” The original post, “Blogroll, Bookmarks, Links,” generated a total of 79 emails on the mailing list alone, and the discussion spilled over to a trac ticket.
Of course, one person’s bike shed is another person’s bête noire, and there were times when wp-hackers was alight with community members who insisted on giving specific issues serious consideration. One such instance was in early September 2007, before the release of WordPress 2.3, which contained the update notification system. This system alerts users when a new version of WordPress or of a plugin becomes available to install. The system collects information about the WordPress version, PHP version, locale setting, and the website’s URL from a user’s site, and sends it back to http://api.wordpress.org. A further piece of code carries a plugin update check, which sends the website’s URL, WordPress version, and plugin info (including inactive plugins) to api.wordpress.org.
For some, the data collection appeared contrary to the free software project ethos. They thought that collecting the blog URL was unnecessary. A ticket on WordPress trac requested that update checking be anonymized. Others had no problem with WordPress collecting the data, but were unhappy that WordPress did not disclose it. A number of people who didn’t oppose the changes nevertheless felt that there should be a way to opt out, so that users who required complete privacy would be able to turn off data collection.
This debate goes to the heart of one of WordPress’ design philosophies: decisions, not options. This idea is heavily influenced by a 2002 article written by GNOME contributor Havoc Pennington. Many free software user interfaces cram in options so that they can be configured in multiple ways. If an argument ensues in a software project about whether something should or shouldn’t be added, a superficial solution is to add an option. The more options one adds, the more unwieldy a user interface becomes. Pennington writes, “preferences have a cost [..], each one has a price and you have to consider its value.” He outlines the problem with too many options:
When there are too many preferences it’s difficult for a user to find them.
They can damage QA and testing. Some bugs only happen when a certain configuration of options is selected.
They make creating a good UI difficult.
They keep people from fixing real bugs.
They can confuse users.
The space that you have for preferences is finite so fill it wisely.
WordPress developers carefully consider the introduction of any new option, and have become better at it over time. When the data collection question arose, they were extremely reluctant to introduce new options. Westi posted to wp-hackers:
One of the core design ideas for WordPress is that we don’t introduce options lightly. The moment you think of making a feature optional you challenge the argument for introducing the feature in the beginning.
What benefit would an opt-out button for update notifications provide to users? The purpose of the notifications is to help users to stay up-to-date and secure. Adding an option to opt out of update notifications would only reduce the number of people who updated their sites, and increase the number of insecure instances of WordPress. The benefit to adding the option didn’t outweigh the cost.
Consequently, and despite the extensive discussion on wp-hackers, WordPress 2.3 was launched as planned, with the following note in the announcement post:
Our new update notification lets you know when there is a new release of WordPress or when any of the plugins you use has an update available. It works by sending your blog URL, plugins, and version information to our new api.wordpress.org service which then compares it to the plugin database and tells you whats (sic) the latest and greatest you can use.
Amid these discussions, the project structure changed when Peter Westwood and Mark Jaquith became lead developers. The announcement post describes them as “a few old faces who are taking on bigger roles in the community.” Both were active committers who had taken on greater leadership roles. Both had participated in many of the more challenging discussions in the community, and they didn’t always agree with current project leadership. They both, for example, opposed Matt’s proposal for the taxonomy structure, and Mark was one of the people who voiced concerns over data collection in WordPress 2.3. They added new perspectives to the project leadership: for the first time since the early days of the project, there were people other than Matt and Ryan to help guide and shape development of both the software and the project.
A community of hobbyists drove WordPress for a long time, but eventually, the hobbyists wanted to support their hobby. Developers charged for customizations; Automattic was building a blog network along with related products like Akismet. Theme designers, too, wanted to make money for the time and effort they put into developing themes for the project.
It isn’t immediately obvious how someone can make money and still uphold the ethos of a free software project. How can the two goals co-exist? In the early days of the WordPress economy, the distinction between freedom and free beer was blurry. Community members fumbled for answers: is it acceptable to make money with a GPL project? Who has the right to make money out of a project that belongs to its volunteers? How can one run a theme business when the core product is free?
The period between 2006 and 2009 was one of experimentation and discovery for businesses in the WordPress ecosystem. During these tumultuous years, the community wrestled with commercialization while the theme marketplace grew. WordPress users — web users — have always been concerned with their websites’ look. As WordPress became more popular, many bloggers built their own themes and realized that they could generate income from them.
Themes lagged behind plugins for an official repository. For a long time, themes were hosted on themes.wordpress.net, an unofficial theme directory. Theme developers could simply upload their theme and users could browse the directory.
The WordPress Theme Viewer in 2007.
The system was susceptible to spam and duplicate themes. Some theme developers abused the system by downloading their theme multiple times, to boost their ranking and appear among the most popular search results. The Theme Viewer was at the center of the first big debate about themes.
Theme designers tried theme sponsorship as a way to make money from their designs. Designers often use a link to their website in their theme as a credit. Kubrick, for example, links to Michael Heilemann’s website. Every site that installs the theme links to the designer’s website. The number of incoming links to a website is a variable in Google’s PageRank algorithm: the more incoming links, the higher the PageRank, the further up in Google’s search engine results. If thousands (or even hundreds) of people install a theme, the designer can watch herself soar up Google’s search results. If that link comes from a high-authority website, even better.
Designers soon realized the link doesn’t have to be to their own website. Links have an intrinsic value, particularly to internet marketers. With a link in a WordPress theme, marketers don’t have to approach individual sites to ask them for a link. All they have to do is pay a web designer to include it in their theme, release the theme for free, and soon hundreds of sites are linking back to their desired URL.
Theme sponsorship approaches varied. Sometimes, companies contacted well-known theme authors to sell links in their themes. Theme authors could also be proactive. Authors advertised and sold their themes on websites, others auctioned themes at Digital Point, or they simply offered links for sale. In those early days, once the sale was made, designers would promote the theme on different WordPress theme sites, including official sites such as the WordPress Codex, community resources like the WordPress Theme Viewer, and reputable blogs such as Weblog Tools Collection. These themes were often distributed with a Creative Commons 3.0 license, which permits free sharing and theme adaptation, provided the credit link remains.
Some theme creators published themes with visible text links but didn’t tell their users about the link, others used PHP or CSS to hide the links, while others still made it very clear that the theme had been sponsored.
For those in favor of theme sponsorship, the matter was simply about being paid for their work. Why should they work for free? Selling sponsored links ensured they could create and distribute free themes, which benefited the whole community. They argued that designing a good theme takes time and that non-sponsored themes were inevitably of poorer quality than sponsored ones.
Sponsored themes quickly became prevalent, with even respected authors selling links in their themes. Many considered it a “great business model”; finally, a way to make money from WordPress! Besides, those who supported the model argued that the default WordPress blogroll contained links to all of the original developers of WordPress — Alex, Donncha, Dougal, Michel, Matt, Mike, and Ryan — all of whom were benefiting in Google’s search results.
Others felt that themes.wordpress.net was becoming a spam repository. More than 50% of themes on the WordPress Theme Viewer were sponsored themes. These contained links to everything from iPhone repair services to gambling websites, and from web hosting to flower delivery. Some themes were uploaded multiple times with only minor changes, thereby increasing the number of links on the Theme Viewer. Critics of theme sponsorship — many of whom were designers themselves — said that the themes polluted the community. They weren’t against theme designers making money, but they didn’t want to see the WordPress community become a hive of spam and SEO tricks. Theme sponsorship had opened the floodgates to SEO and internet marketers.
Buying and selling links went beyond the WordPress community. A few years earlier, Matt Cutts, the head of web spam at Google, had explained how link-selling affected PageRank. Google’s algorithm detected paid links, and while it wasn’t foolproof, it worked pretty well. Paid links made it harder for Google to gauge a website’s trustworthiness. As a result, Google took away that site’s ability to affect search results:
Reputable sites that sell links won’t have their search engine rankings or PageRank penalized – a search for [daily cal] would still return dailycal.org. However, link-selling sites can lose their ability to give reputation (e.g. PageRank and anchortext).
WordPress users who installed sponsored themes could be penalized for links that they weren’t even aware they were hosting. And, hidden links could further reduce a user’s PageRank. In a post in April 2007, Matt Cutts condemned hiding links in a website and asked web masters to disclose paid links.
There were plenty of themes that contained links that weren’t sponsored. Designers would include a credit link to their website in the theme’s footer. Designing and releasing a WordPress theme allowed designers to increase their profile on the web. Like internet marketers, their websites benefited from higher search engine results, and website visitors might click on the link, generating more business for the designer.
It was common at that time for a designer to release their themes under a Creative Commons license, which asks users to leave the credit link intact. In the middle of the sponsored link furor, one designer took the next step. Tung Do (tungdo) authored the popular WordPress resource WPDesigner.com, along with a number of WordPress themes. In April 2007, he announced he would release his themes under the GPL. “Despite that I’m just ONE theme designer and despite that I don’t contribute directly the WordPress code (sic),” he wrote, “I believe that switching to GPL is a step in the direction to support the WordPress team and to help the WordPress theme community grow (positively).”
Weblog Tools Collection (WLTC) was the first website to take direct action against sponsored themes. At WLTC, designers submitted themes and Mark Ghosh, who ran the site, regularly wrote about theme releases. In April, Mark weighed in on sponsored themes. While he didn’t condemn them outright, he did institute a new policy:
All themes with sponsorship links will be labelled as such when they are published, non-sponsored themes will be published first, and we require sponsorship disclosure to be made to us when authors make us aware of their new themes. If this disclosure is not provided and the theme has sponsored links, the author will be barred from being able to post their new themes on weblogtoolscollection.com until further notice.
The 166 comments Ghosh received highlighted just how divisive the issue was. Viewpoints ran to both extremes. Many users were unhappy about links being placed in their websites — this was particularly concerning to people whose websites had a moral or religious bent. While users supported linking to theme authors, they weren’t happy that links for credit cards or flower delivery were being displayed on their website. Theme developers said that it was a way for them to fund themselves and the creation of free themes, and that they were sad to see it being abused.
A few days later, Matt followed Mark’s lead and posted on WLTC about sponsored themes. He had become aware of the trend back in September 2006, when he had downloaded the Barthelme theme from plaintxt.org and discovered a link to a New York flower delivery service. For him, there were three main issues:
that sponsored links negatively impact a user’s Trustrank and that the user hadn’t made this decision themselves;
that sponsored themes are adware;
that theme authors who sell links and release their work under a creative commons license contravene the GPL.
All of these factors meant a negative experience for WordPress users. While the project allowed people to make money from WordPress-related products and services, it didn’t support methods detrimental to users. Whatever the original intentions of sponsored links, themes had become so polluted that they undermined the trust that a user had in the software and in the community. As a user-focused community, the project needed to regain that trust.
The argument that theme authors deserved to be compensated for their work held little weight when WordPress itself had been built by volunteers. There was no opposition to people making money from WordPress, but official project resources should only promote companies and individuals in line with the core project ethos.
Matt closed the post, linking to a vote on a proposal to remove sponsored themes from WordPress.org. The discussion on the thread has arguments for and against theme sponsorship; some voted for a complete ban, others for sponsored theme disclosure, while others felt theme designers should be allowed to include any links they want in their theme.
Some theme developers saw theme sponsorship as a valid way of making money, and were angry about being branded as “unethical.” This was particularly the case when they saw other theme developers behaving unethically, from downvoting other developers’ themes and using sock puppetry to upvote their own, to stuffing themes with copious links to their website.
Despite the sponsored theme ban on official WordPress resources, link sales continue today. The Digital Point forums, for example, are filled with themes available for sponsorship. Theme sponsorship is not without its dangers. In 2012, a former theme sponsor posted on the Webmaster world forums about Google penalization for “inorganic” incoming links:
Some 2+ years ago in throws (sic) of questionable wisdom I sponsored about five or six WordPress themes where the “Designed by” link in the footer gets replaced by a link to your site. They were nice looking and “relevant” themes, at least as far as the name and pictures used in design suggest. They were not used much initially and I did not think much of them until these “unnatural links” notices started flying a month ago. Google confirmed that these links were the issue, but with the themes in the wild there wasn’t a whole lot that the sponsor could do about it other than contact the websites using the theme and asking them to remove the link.
Sponsored themes were the first large-scale attempt at making money from WordPress themes. Custom design and development existed too, but link sales appeared to be a valid way of making money, particularly at a period when the web teemed with SEO experts and internet marketers on an unremitting search for ways to climb Google’s search results. Sponsored themes brought WordPress, not for the first time, into proximity with SEO, both white hat and black hat. Selling links in a theme slipped easily into questionable SEO practices; it also turned out to be an unsustainable business model. With Google as the rule-maker, a simple policy change could wipe out an entire market. And as sponsored themes started to disappear from the community, theme designers and developers looked for new ways to support their hobby.
In the wake of the exodus to Habari, the project began to evolve. In March 2007, Robin Adrianse (rob1n) became WordPress’ first temporary committer when he received commit access for three months to help Ryan Boren address languishing trac tickets.
Also in March, the plugin directory launched. Before the plugin directory, developers hosted their plugins on their website. The directory gave them exposure to a huge number of WordPress users. Samuel Wood (Otto42) recalls how the plugin directory encouraged him to distribute his code. “I was writing them before, but I didn’t give them to anybody. It encouraged me to release plugins because I had a place to put them.”
The WordPress Plugin Directory in 2007.
WordPress 2.1 had launched in January 2007, after a release cycle of more than a year. WordPress 2.2 was the first to adopt the new 120-day release cycle. This goal, which would later become codified as deadlines are not arbitrary in WordPress’ philosophy, was an ongoing challenge. It was tested in WordPress 2.2, which featured a new taxonomy system — the biggest database architecture change to date. Developing in an open source environment means leaving time for every voice to be heard, waiting for volunteers with busy lives to get things done, and discussing new features and architectural changes. It’s a challenge that WordPress would have to address release cycle after release cycle.
In the early 2000s, the internet abounded with discussions about the best way to organize information. Content has metadata assigned to it, which can be used to organize and display information. Traditional web classification methods imposed a top-down categorization structure. A website created a category structure and users placed their content in the correct category. These structures were often rigid, forcing users to shoehorn their content into something that didn’t necessarily fit. A new method of classification emerged — tags, a bottom-up classification form in which an index or a cloud can be generated based on keywords that the creator applies to the content.
Social bookmarking site Del.icio.us was the first to use tags. While Del.icio.us wasn’t a bookmark management pioneer, its tagging system set it apart. Users tag the links they save, and the tags are then used to group together links in a user’s own collection and across the entire social network. Visiting the link http://delicious.com/tag/php displays all links tagged PHP.
The classification system in which users classify content themselves, creating mass tagging networks, became known as a folksonomy.
In 2005, Technorati, the blog search engine, launched its own tagging system. It enabled users to run a tag search across major platforms such as Blogger and Typepad, CMSs like Drupal, and other services such as Flickr, Del.icio.us, and Socialtext.
WordPress lagged behind, and there was pressure from both the free software and WordPress.com communities to add tags to the platform. WordPress’ native classification form is hierarchical, top-down categories. To interact with WordPress, Technorati picked up the “tag” from the WordPress post’s category. Many users found this unsatisfactory, as categories and tags are two different types of classification.
Categories can be tags but tags cannot be categories. Categories are like the huge signs you see on aisles in supermarkets – “Food”, “Hygiene”, “Frozen,” etc., (sic) they guide you to sections where you can find what you are looking for. Tags are like the labels on the products themselves.
Categories and tags address two distinct use cases. Categories are more rigid, whereas tags are a lightweight way of classifying content. There was, of course, a plugin that did the job: WordPress users installed the Ultimate Tag Warrior plugin (though WordPress.com users could not).
A database stores all the content and data of a WordPress user. The database contains different tables from which data is retrieved. There is a post table, for example, which stores post-related data. The user table stores user data. Making changes to the database is not trivial. Any changes have to be done correctly because undoing them in the future can be difficult. Changes need to be performant. In a PHP/MySQL setup, increasing the number of database queries can slow the site down. The question arose: where should we store tagging data? Should it be in a new table? Or should it be stored in an existing table?
We already have a ton of rewrite, API, etc. infrastructure around categories. Mostly I see tagging as a new interface to the data. On the display side, people want their tags listed separately from their categories, and probably something like a tag cloud function.
Previously, WordPress had already successfully reused tables; for example, posts, pages, and attachments are all stored in the same table, and at that time, the categories table also contained link categories. Tagging, from a user’s perspective, enabled them to tag posts, display a list of tags, and display posts with the same tag. What was the point in duplicating the infrastructure when it could be achieved within the current table system?
Few developers supported putting tags in the categories table. Some believed the table would become bloated and argued that adding tags to it meant including additional code to keep the two taxonomy types separate. This additional code could introduce bugs, and make future maintenance and extension of the table difficult for developers.
On wp-hackers, April 2007 was spent discussing the new database schema for taxonomies. A suggestion that gained considerable community traction was splitting categories, link categories, and tags into their own individual tables — but it was impossible to reach consensus.
It would perform faster as no additional queries would need to be carried out to support tags. A separate tag table would require at least two extra queries on the front end.
It would provide a better long-term foundation. Tags and categories would be able to share terms (for example the category “dogs” and the tag “dogs”).
There were no user-facing or plugin-facing problems.
In the thread, he also proposed an alternative, inspired by Drupal’s taxonomy system: creating a new table for terms within a specific taxonomy. Terms are the items within a category, tag, or any other taxonomy; dog, cat, and chicken are all terms within an “animal” taxonomy. This additional table allowed terms to be shared among taxonomies, while having the same ID (the ID is what identifies an item in the database). Just one term — “dog” for example — would be saved in the database, and this term could be used in any taxonomy.
Ryan Boren proposed a compromise, one which enabled individual terms to be part of any taxonomy, while keeping the same ID. It was a three-table solution, with tables for terms, taxonomies, and objects. Discussion ensued, a new trac ticket was opened up, and a new structure was created based on this proposal. The first table, wp_terms, holds basic information about single terms. The wp_term_taxonomy table places the term in a taxonomy. The final table, term_relationships, relates objects (such as posts or links) to a term_taxonomy_id from the term_taxonomy table.
The database structure for WordPress taxonomies.
This approach had the advantage of assigning one ID to a term name, while using another table to relate it to a specific taxonomy. It’s extensible for plugin developers who can create their own taxonomies. It also enables large multisite networks, such as WordPress.com, to create global taxonomies — unified tagging systems in which users of different blogs can share terms within a taxonomy.
Like many WordPress features, tags landed on WordPress.com before they shipped in WordPress. From the beginning, the new structure caused huge technical problems. The increase in tables meant that WordPress.com needed more servers to deal with the additional queries. “It was slower to be completely honest,” says Matt. “That was a cost that we saw in a very real way on WordPress.com, but also a hidden cost that we did impose on everyone who was doing WordPress in the world.”
More than just a challenging code problem, the taxonomy implementation highlighted problems in the development process. Heavy discussion meant development dragged on. Some wanted to delay the release. Some wanted to pull the feature. Others wanted to revise the schema in a subsequent version. Andy Skelton responded to the wp-hackers discussion:
To include a premature feature in an on-time release degrades the quality of the product. I refer to not only the code but the state of the community. Increments are supposed to be in the direction of better, not merely more. Better would be to release on time with a modest set of stable upgrades.
To block release while the one new feature gets sorted out would be a maladjustment of priorities. If 2.2 seems light on sex appeal, so be it. Better to keep the release date as promised.
The 120-day release schedule was in danger because of one issue. Making major architectural changes to core just weeks before a release was contrary to the aims of the new development process. A thread suggested delaying 2.2’s release. The architectural changes were too important to be done in an unsatisfactory way.
Eventually, Matt decided to delay the 2.2 release, pull tags out of core, and bring in widgets — a user-facing feature that would encourage people to update their version of WordPress.
Andy Skelton developed widgets for WordPress.com users; he built them to give bloggers more flexibility with their site’s layout. Widgets are code blocks users can drag and drop into place through the user interface. They allow bloggers to add a calendar, a search bar, or some text (among other things) to a sidebar in any order they wish. It was a hugely popular feature on WordPress.com; the plugin for WordPress was also a great success. Launching widgets on WordPress.com meant that many different users could test them before they made it into core as a feature.
The new tagging feature finally shipped in WordPress 2.3 — in a structure that was the outcome of extensive negotiating and haggling. This wrangling process has had consequences for WordPress developers ever since. Shared terms have had lasting implications for core developers, plugin developers, and users. The problem with shared terms is that an item could have multiple different meanings, but the database treats all of them identically. For example, the word apple. A developer creates the taxonomy “Companies” and the taxonomy “Fruit,” and the user places the term “apple” in both. Conceptually, this is a different item — a company and a fruit — and they appear in the user interface as two distinct entities. But the database treats them as the same thing. So if a user makes changes to one — for example, capitalizing it — changes are made to both.
In a post in 2013, Andrew Nacin wrote that, “Hindsight is 20/20, and shared terms are the bane of taxonomies in WordPress.” Each term is represented in two different ways. Since an individual term can appear in multiple taxonomies, it’s not straightforward to identify the actual term in the actual taxonomy that you want. It has become a challenge to build new features that use one identification method when there are parts of WordPress that use the other.
A case in point: to attach metadata to a term, there must be one object identifier. However, the public ID uses a different identifier. It is extremely difficult to target data consistently when it is identified in multiple ways. WordPress has a long-term commitment to maintaining backward compatibility, so creating a new schema isn’t possible. The effort to get rid of shared terms must progress step by step, over a number of major releases (this is being carried out over three releases in the 4.x series).
The over-engineered taxonomy system came about through argument and compromise. When the bazaar model works, it can produce software that people love to use. The model fails when intractable arguments result in compromises that no one is 100 percent happy with. The new taxonomy system did, however, contain one notable benefit. Neither of the original proposals for the taxonomy schema (putting tags into the category table, or creating a new table just for tags) would have allowed developers to create custom taxonomies, and the latter became a major element in WordPress’ transition from a straightforward blogging platform to a bonafide content management system.
Even with these setbacks, software development continued mostly on schedule. Since tags were pulled from 2.2, there were only 114 days between WordPress 2.1 and 2.2, and then 129 days between the release of 2.2 and 2.3. While delays would recur in some future releases, there was nothing that resembled the long, dark year between 2.0 and 2.1.
