Title: 2015 — WordPress Book

---

# Year: 2015

Part 6/Chapter 44

## 󠀁[MP6](https://wordpress.org/book/2015/11/mp6/)󠁿

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

In January 2013, [Ben Dunkle proposed new, flat icons](https://core.trac.wordpress.org/ticket/23333).
The WordPress admin was outdated, particularly on retina displays where the icons
pixelated. Flat icons would scale properly and also allow designers to color icons
using CSS. [Andrew Ozz checked in the changes](https://core.trac.wordpress.org/changeset/23369).

The changes kicked off huge discussions about icons, [a new trac ticket](https://core.trac.wordpress.org/ticket/23415),
and a [long discussion on the UI P2](https://make.wordpress.org/ui/2013/02/12/discuss-icons/).
People were divided on the icons. Some liked them, but felt that they didn’t fit
WordPress’ admin design; modern icons only emphasized how dated the rest of the 
admin had become. Consensus didn’t materialize. Mark, who was release lead at the
time, decided not to put the changes in WordPress 3.6. Instead, designers interested
in redesigning the admin could iterate on the design in a plugin called [MP6](https://wordpress.org/plugins/mp6/).

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

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

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

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

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

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

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

The MP6 project was [announced in March 2013](https://make.wordpress.org/ui/2013/03/09/as-a-continuation-of-the-work-begun-in/).
The design process began with MT playing around with the CSS. He started out with
a unified, black, L-shaped bar around the top and the side of the admin screen: “
the idea,” [he said](https://archive.wordpress.org/interviews/2014_02_04_Thomas.html#L104),“
was that the black would feel like a background and the white would feel like the
sheet of paper lying on top of it, so it would unify these disparate things.” Once
MT assembled the basic visual, the contributors refined the design. These changes
happened iteratively. The community saw a report and a new plugin release each week,
on which they gave feedback.

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

Despite minor hitches, the MP6 project went smoothly. Joen Asmussen, who’d been 
a part of the Shuttle project eight years earlier [said](https://archive.wordpress.org/interviews/2013_11_05_Asmussen.html#L73),“
I would say that MP6 did everything right that Shuttle did wrong.”

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

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

[⌊The Write screen in the WordPress 3.8 admin.⌉⌊The Write screen in the WordPress
3.8 admin.⌉[

The Write screen in the WordPress 3.8 admin.

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

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

[Nacin wrote](https://make.wordpress.org/core/2013/08/07/wordpress-3-8-meeting-thursday-august-8/):

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

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

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

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

Part 6/Chapter 43

## 󠀁[The Problem with Post Formats](https://wordpress.org/book/2015/11/the-problem-with-post-formats/)󠁿

The 3.6 release cycle was challenging; it precipitated a new approach to the development
process. Two core WordPress philosophies, _design for the majority_ and again, _deadlines
are not arbitrary_, were tested. The 3.6 release cycle process followed the cycle
started in WordPress 3.4: there was a unified theme for the release — this time 
[content editing](https://make.wordpress.org/core/2012/12/19/wordpress-3-6-cycle/).
Small teams worked on key features. Some features need more research and development
than can be achieved within a single development cycle, and the WordPress 3.6 cycle
surfaced this flaw.

Post formats were 3.6’s headline feature. Introduced in WordPress 3.1., [post formats](https://codex.wordpress.org/Post_Formats)
allow theme developers to lend a unique visual treatment to specific post types.

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

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

The 3.6 release encountered problems; [features were dropped](https://make.wordpress.org/core/2013/02/19/dropping-editorial-flow/)
as contributors discovered they’d overcommitted themselves. The biggest issue was
around the post formats user interface, inspired by Alex King’s [Post Format Admin UI](http://alexking.org/blog/2011/10/25/wordpress-post-formats-admin-ui).
Much thought and study went into the post formats UI. Which UI would offer users
a logical, intuitive workflow, without adding needless complexity to the UI or the
experience?

The problem was that despite time spent on wireframes and development, the team 
ended up unimpressed. They created specifications, built to the specifications, 
and were unhappy with the result. “It’s like ordering something from the restaurant
that sounds great,” [says Aaron Campbell](https://archive.wordpress.org/interviews/2014_06_05_Campbell.html#L71),“
but as soon as it sits in front of you and you smell it, it’s like, ‘Ahh, definitely
not what I was in the mood for.'” Even during WordPress 3.6’s beta period, community
members [experimented with better approaches to the problem](http://ran.ge/2013/04/11/re-thinking-wordpress-post-format-ui-an-exercise/).

[⌊The post formats user interface.⌉⌊The post formats user interface.⌉[

The post formats user interface.

April 29 was WordPress 3.6’s target release date. On April 23, Jen — who had by 
that point stepped back from her involvement in development — [said that post formats weren’t ready](https://make.wordpress.org/core/2013/04/23/post-formats-schedules-and-philosophy/).
She said that the user interface was confusing, underscoring WordPress’ _deadlines
are not arbitrary_ philosophy. The thread, in addition to highlighting the post 
formats UI flaws, showed that not everyone supported _deadlines are not arbitrary_.
[Ryan Boren wrote](https://make.wordpress.org/core/2013/04/23/post-formats-schedules-and-philosophy/#comment-8523):

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

In the end, [Mark and Aaron pulled post formats](https://make.wordpress.org/core/2013/05/29/post-formats-ui-is-exiting-core-will-live-as-a-plugin/).
A lot of work had to go in to [removing it from core](https://core.trac.wordpress.org/ticket/24452);
the release was heavily delayed, finally appearing on August 1, 2013 — three months
after the intended release date. The team promised to turn the post formats feature
into a plugin, but the plugin never materialized.

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

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

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

Part 6/Chapter 42

## 󠀁[The Spirit of the GPL](https://wordpress.org/book/2015/11/the-spirit-of-the-gpl/)󠁿

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

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

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

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

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

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

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

The issue was over theme licensing and WordCamp’s guidelines. WordCamps are official
WordPress events that come with the WordPress Foundation’s seal of approval. [Organizers, volunteers, and speakers](http://plan.wordcamp.org/become-an-organizer/representing-wordpress/)
must fully embrace the GPL — going beyond GPL compliance to pass on all WordPress’
freedoms to users. The guidelines state that organizers, volunteers, and speakers
must:

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

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

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

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

The argument raged in the comments of Jake’s blog, spiralling to other [WordPress community blogs](http://www.poststat.us/what-now-for-commercial-theme-authors/),
and to the [ThemeForest forums](http://themeforest.net/forums/thread/wordpressorg-bans-themeforest-members-from-participating-in-official-wordcamp-gatherings/85648?page=2).
Matt joined the discussion on Jake’s blog, [saying that](http://www.designcrumbs.com/automatically-blackballed#comment-430)
if ThemeForest authors had a choice about licensing and could release their theme
under the GPL, then “Envato would still be breaking the guideline, but Jake wouldn’t,
so it’d be fine for Jake to be involved with WordCamps.”

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

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

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

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

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

Collis surveyed ThemeForest authors to gauge support for a GPL opt-in option. “I
felt pretty guilty that our authors were paying some sort of price for selling with
us, that felt pretty wrong,” [says Collis](https://archive.wordpress.org/interviews/2014_04_11_Taeed.html#L86).
[The results](http://notes.envato.com/news/survey-results-about-gpl-opt-in-choice/)
showed that verified authors were split; some said they would license their themes
under the GPL, the same number said they would stick with the split license, and
35% said that they didn’t know which license they’d choose. On March 26, Collis 
announced a 100%-GPL license for ThemeForest authors. Jake was [once again allowed to speak at WordCamps](http://www.designcrumbs.com/un-blackballed).

Part 6/Chapter 41

## 󠀁[The Community Summit](https://wordpress.org/book/2015/11/the-community-summit/)󠁿

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

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

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

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

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

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

A new team — a plugin repository review team — formed. Up until then, Mark Riley
carried the load reviewing plugins for the repository. The community believed plugins
required the same rigor as themes. Plugin code quality was raised on [community blogs](http://wptavern.com/is-a-plugin-validation-team-a-pipe-dream)
and on [wp-hackers](https://lists.wordpress.org/pipermail/wp-hackers/2010-August/034146.html).
Otto started to review plugins too, and later Mika Epstein ([ipstenu](https://profiles.wordpress.org/ipstenu))
and Pippin Williamson ([mordauk](https://profiles.wordpress.org/mordauk)) helped
conduct plugin reviews. Later, Boone Gorges ([boonebgorges](https://profiles.wordpress.org/boonebgorges/))
and Scott Riley ([coffee2code](https://profiles.wordpress.org/coffee2code)) joined
the team.

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

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

Part 6/Chapter 40

## 󠀁[The Transition to Release Leads](https://wordpress.org/book/2015/11/the-transition-to-release-leads/)󠁿

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

Experimentation started at the core team meetup in Tybee Island, Georgia, in December
2011. Lead developers, committers, and active core developers discussed the project’s
issues and roadmap, informing the [scope setting meeting for WordPress 3.4](https://irclogs.wordpress.org/chanlog.php?channel=wordpress-dev&day=2012-01-04&sort=asc#m349775)
on January 4, 2012.

The scope chat notes cover the [issues discussed](https://make.wordpress.org/core/2012/01/05/dev-chat-notes-01042012/).
The team acknowledged process problems. Jen listed the issues: “lack of good time
estimation, resource bottlenecks, lack of accountability, unknown/variable time 
commitments/disappearing devs, overassignment of tasks to some people, reluctance
to cut features to meet deadline.”

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

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

[⌊The proposal for the 3.4 release process.⌉⌊The proposal for the 3.4 release process
.⌉[

The proposal for the 3.4 release process.

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

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

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

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

The lead developer role “didn’t really have a set of responsibilities assigned with
it or expectations,” [says Matt](https://archive.wordpress.org/interviews/2014_07_07_Mullenweg.html#L214).
According to him, the lead developer leads development, not other areas of the project;
he believes that confering authority and responsibility to a development role makes
it difficult for non-coders to achieve project authority and responsibility.

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

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

From time to time, someone arrives and influences the project. In the early days,
Ryan Boren drove WordPress’ development, but post-WordPress 3.0, it was Andrew Nacin.“
Nacin like Ryan is one of those guys that just has an ability to get in a flow, 
and just really crank and get focused intensely, and get through a ton of work,”
[says Matt](https://archive.wordpress.org/interviews/2014_07_07_Mullenweg.html#L196).

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

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

On reflection, Matt says that there was a misunderstanding. He didn’t mean to imply
that the people holding lead developer roles were worthless or irrelevant, but that
the roles did not reflect project reality. “A source of some of the conflict,” [says Matt](https://archive.wordpress.org/interviews/2014_07_07_Mullenweg.html#L214),“
is this idea that the lead developers sort of had the same role as me where they
had sort of purview over everything across all parts of WordPress.”

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

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

In response, those involved scheduled a Google Hangout to discuss the issues, air
grievances, and find a way forward. As a result, things changed, and the [first 3.5 release cycle post](https://make.wordpress.org/core/2012/07/11/recognition-and-news-about-the-3-5-cycle/)
reflects some of those changes.

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

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

Part 5/Chapter 39

## 󠀁[Thesis](https://wordpress.org/book/2015/11/thesis/)󠁿

By mid-2010, one theme was still a GPL holdout: Thesis, from DIYThemes. Created 
by theme designer Chris Pearson and blogger Brian Clark, Thesis was popular as a
feature-heavy framework — it gave users many more options than most WordPress themes.
Users can customize every element of their website via the user interface. On the
original about page, [Chris states Thesis’ aim](https://web.archive.org/web/20080610074529/http://diythemes.com/thesis/about/):“
I wanted a framework that had it all — killer typography, a dynamically resizable
layout, intelligent code, airtight optimization, and tons of flexibility.” [Tech blogs featured Thesis](http://thenextweb.com/2008/07/17/thesis-represents-the-next-generation-of-wordpress-themes/#!A2Baz)
and high profile bloggers, including [Matt Cutts](http://www.mattcutts.com/blog/switching-things-around/),
[Chris Brogan](http://www.chrisbrogan.com/thesis-wordpress-theme/), and [Darren Rowse](http://www.problogger.net/archives/2008/07/18/thesis-a-wordpress-theme-design-worth-considering/)
adopted it.

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

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

In July 2010, the WordPress/Thesis debate reignited after Chris Pearson’s interview
[on Mixergy](http://mixergy.com/chris-pearson-thesis-interview/). In it, Chris shares
Thesis’ revenue figures, putting a conservative estimate at 1.2 million dollars 
within 16 to 18 months.

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

Matt, Automattic, and WordPress took public action against Thesis following the 
interview. [Matt offered to buy Thesis users an alternative premium theme](https://twitter.com/photomatt/status/18548422506),
consultants using Thesis were [removed from the Code Poet directory of WordPress consultants](http://www.flickr.com/photos/mg315/4792383313/),
and Chris Pearson’s other themes — Cutline and PressRow — were [removed from WordPress.com](http://www.pearsonified.com/2010/11/former-cutline-pressrow-theme-user.php).

Matt wasn’t the only one in the WordPress community to come out swinging against
Thesis. Other lead and core developers wrote about their GPL / Thesis stance. [Ryan Boren wrote](http://ryan.boren.me/2010/07/15/wordpress-theme-licensing/),“
where do I stand as one of the primary copyright holders of WordPress? I’d like 
to see the PHP parts of themes retain the GPL. Aside from preserving the spirit 
of WordPress, respecting the open source ecosystem in which it thrives, and avoiding
questionable legal ground, retaining the GPL is practical.” Mark Jaquith [noted that WordPress themes don’t sit on top of, they’re interdependent on WordPress](http://markjaquith.wordpress.com/2010/07/17/why-wordpress-themes-are-derivative-of-wordpress/):

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

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

A former employee of DIYThemes [left a comment on Matt’s blog](http://ma.tt/2010/07/syn-thesis-1/#comment-481845):

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

On July 22, — not even a week after the initial Mixergy interview — [Chris Pearson announced](https://twitter.com/pearsonified/status/19288707443)
that Thesis would be released under a split license. The public furor, compounded
by pressure from inside DIYThemes, forced Chris to capitulate. Brian Clark drafted
[the license](http://technosailor.com/2010/07/29/exclusive-interview-brian-clark-leaves-diythemesthesis-theme/),
shortly before leaving DIYThemes, citing “completely different opinions about the
direction of the development of Thesis, the running of the company, and our relationship
with the WordPress community.” When Thesis 2 launched in 2012, it had a new, proprietary
license.

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

Part 5/Chapter 38

## 󠀁[Dealing With a Growing Project](https://wordpress.org/book/2015/11/dealing-with-a-growing-project/)󠁿

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

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

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

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

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

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

Joseph [wrote](https://wordpress.org/news/2010/06/expanding-the-theme-review-experiment/):

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

No one knew how the experiment would turn out. A [rush of people signed up for the new mailing list](https://lists.wordpress.org/pipermail/theme-reviewers/2010-June/);
[guidelines were drawn up](https://codex.wordpress.org/index.php?title=Theme_Review&oldid=91889).
Though the overall response was positive, some felt that the guidelines were too
restrictive — that some theme requirements should be recommendations. On the WP 
Tavern forums, Justin Tadlock outlined some concerns, specifically that guidelines
didn’t allow themes with custom template hierarchies or custom image systems. Some
believed the theme review team should check for spam and other objectionable practices.
Other developers simply decided to [remove their themes from the directory](http://quirm.net/2010/08/27/retiring-themes/).

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

But despite the teething problems, the theme reviewers have a system that benefits
both users and developers: users get safe themes approved by WordPress.org, and 
theme developers get feedback and help on their themes. There have been other, long-
term benefits. [Joseph says](https://archive.wordpress.org/interviews/2014_05_27_Scott.html#L66):

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

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

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

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

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

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

Part 5/Chapter 37

## 󠀁[The WordCamp Guidelines](https://wordpress.org/book/2015/11/the-wordcamp-guidelines/)󠁿

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

WordCamps have always been informal, and through the early events, the organization
was just as informal as the events themselves. In the beginning, interested community
members simply decided to organize a WordCamp. They contacted Automattic for stickers,
buttons, and other swag. A blog [for WordCamp organizers](http://wordcamphowto.wordpress.com/2009/06/26/hello-welcome-to-this-super-blog/)
was set up in 2009, so that organizers could communicate with one another.

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

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

WordCamps needed better oversight, including clear guidelines. From May 2010 onward,
that started to happen. Jen published [the first set of WordCamp guidelines](https://web.archive.org/web/20100723003529/http://central.wordcamp.org/about/).

WordCamps should be:

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

In some quarters, [the changes went down badly](http://onefinejay.com/2010/05/19/a-few-questions-on-jane-wells-revised-wordcamp-policies).
Others [were more relaxed about the changes](http://www.bloggingpro.com/archives/2010/05/19/wordcamps-need-to-be-gpl-too-now/),
but they, too, asked why people who promoted non-GPL products would be banned from
speaking. While many WordPress theme shops were 100% GPL, those that weren’t 100%
GPL were indignant that they would have to be GPL-compliant just to speak at a WordCamp.

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

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

The [guidelines have evolved over the years](http://plan.wordcamp.org/become-an-organizer/representing-wordpress/),
with community feedback. While not everyone is happy with them, WordCamps continue
to flourish around the world.

Part 5/Chapter 36

## 󠀁[WordPress 3.0](https://wordpress.org/book/2015/11/wordpress-3-0/)󠁿

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

In January 2010, Dion Hulse ([dd32](https://profiles.wordpress.org/dd32)) received
commit access during the 3.0 release cycle. In the [post announcing Dion’s access](https://make.wordpress.org/core/2010/01/12/dd32-whatcha-gonna-do/),
Matt outlines a new goal for the project:

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

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

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

April 13, 2010 was WordPress 3.0’s release date. Similar to prior releases — despite
having a deadline — development focused on scope and headline features, rather than
meeting the date. Three main features were defined in the [scope chat](https://irclogs.wordpress.org/chanlog.php?channel=wordpress-dev&day=2010-01-07#m51679):
merging WordPress MU with WordPress, menus, and a new default theme to replace Kubrick.

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

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

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

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

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

To complicate matters further, WordPress MU had a function `get_site_option`, which
gets options for the entire network, and `get_blog_option` which gets options for
individual sites. The functions, therefore, don’t relate entirely to the user interface.
That was just one of the functions that caused problems, [as Andrew Nacin noted](http://nacin.com/2010/03/25/terminology-nightmare-blogs-sites-networks/).

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

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

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

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

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

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

WordPress 3.0 ended up being a huge release, and while menu discussion continued,
launch was delayed again and again. By April, the core team was still sending around
wireframes — [discussing whether menus should be pulled from 3.0](https://irclogs.wordpress.org/chanlog.php?channel=wordpress-dev&day=2010-04-15&sort=asc#m109848).
The [release candidate kept being pushed back](https://make.wordpress.org/core/version-3-0-project-schedule/).
Matt [reiterated one of WordPress’ key philosophies](https://make.wordpress.org/core/2010/04/20/deadlines-are-not-arbritrary-theyre-a/):

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

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

One of the more controversial changes in WordPress 3.0 was [a new function](https://core.trac.wordpress.org/changeset/14996)
called `capital_P_dangit`. This function ensures that the letter “p” in WordPress
is capitalized. People felt that [WordPress was messing with their content](http://justintadlock.com/archives/2010/07/08/lowercase-p-dangit)—
that this automatic correction was the start of a slippery slope. For some, it was
overbearing pedantry, for others, censorship. WordPress has no business changing
what people wrote. Some saw it as incommensurate with the project’s core freedoms:
[openness, freedom, and community](http://justintadlock.com/archives/2010/07/08/lowercase-p-dangit).

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

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

[Core developers became frustrated](http://justintadlock.com/archives/2010/07/08/lowercase-p-dangit#comment-211354)
by the hyperbole around the filter and the time spent arguing about it. In a comment
on Justin Tadlock’s blog, Mark Jaquith said:

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

A [website Mark created](http://capitalp.org/) reflects the position of many of 
the core developers on the `capital_P_dangit` discussion:

[⌊capital_p_dangit⌉⌊capital_p_dangit⌉[

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

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

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

Part 5/Chapter 35

## 󠀁[The WordPress Foundation](https://wordpress.org/book/2015/11/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](http://www.ifosslr.org/ifosslr/article/view/11/37)
report that of the 65 licenses endorsed by the [Open Source Initiative (OSI)](http://opensource.org/licenses),
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](http://www.gnu.org/copyleft/gpl.html). 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](https://archive.wordpress.org/interviews/2014_04_15_Black.html#L49).“
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](https://archive.wordpress.org/interviews/2014_04_17_Mullenweg.html#L355),“
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](http://wordpressfoundation.org/) 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](http://ma.tt/2010/09/wordpress-trademark/)
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](http://ma.tt/2010/09/wordpress-trademark/#comments) 
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](https://archive.wordpress.org/interviews/2014_04_17_Mullenweg.html#L379).

Developer Samuel Wood ([Otto42](https://profiles.wordpress.org/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).

## Posts navigation

[Older posts](https://wordpress.org/book/2015/page/2/?output_format=md)