Part 5/Chapter 35

The WordPress Foundation

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

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

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

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

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

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

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

The WordPress Foundation’s website states its mission:

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

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

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

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

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

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

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

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

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

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