My condolences, you’re now the maintainer of a popular open source project

The following are my slides and notes from a talk I gave yesterday at WordCamp Europe. This is more or less what I said, but not exactly.


I’d like to talk with you today about the emotional rollercoaster of maintaining an open source project. More specifically, the emotional highs and lows you’ll experience publishing your code online.

But first, let’s start by taking a look at the bigger picture.


Marc Andreessen, creator of the Netscape web browser, famously said “software is eating the world.” I’d like to posit that it’s actually open source software that’s eating the world, and I have a couple of data points to back me up.

First, a conclusion from the 2015 Future of Open Source survey: “Seventy-eight percent of respondents said their companies run part or all of its operations on OSS and 66 percent said their company creates software for customers built on open source. This statistic has nearly doubled since 2010.”

Second, Nadia Eghbal, who is doing really great research into the economics of open source, calculated that “open source was worth at least $143M of Instagram’s $1B acquisition.”

I think there are a few reasons for this Cambrian explosion of open source usage:

  1. Open source is free to use, which means a company can spend money on people (aka innovation) instead of software licenses.
  2. There are now a critical mass of reliable open source components, which accelerates your product’s time to market.
  3. Open source produces quantitatively better software.
  4. Near and dear to me personally, open source permits companies to collaborate on common problems without complicated business agreements.

So open source is pretty huge. But what is it exactly?

“Open source” now means two things.

Clearly, there’s the official definition, a permissive license which grants certain freedoms to the end user.

But when people use “open source” today, they’re probably referring to building and collaborating in public. In fact, they may not care about the license at all — over 80% of projects on Github don’t have an explicit license.

Why are so many people involved in open source? Well, for all of the business reasons covered before. I also think it’s joyful to get to work with people of a variety of cultures and backgrounds. Additionally, open source has given me a sense of permanence to my career, where the job I’ve taken from year to year has not.

There are a couple of different ways you can participate in open source.


Contributing is a form of short-term participation. You make a one-off or twice-off contribution, and then your involvement is over.

Maintaining is taking long-term ownership over a particular aspect of a project. In this equation I’ve produced, maintaining is greater than contributing both in level of reward, but also effort, commitment, and emotional involvement.

Let’s take a walk through the emotional journey of becoming a maintainer.


When thinking about becoming a maintainer, you might be too embarrassed by your code to publish it online. Here’s a little secret: everyone is embarrassed by their code. Being embarrassed by your code is not an excuse not to publish your project and become a maintainer.


In fact, publishing your project is a great excuse to learn. Posting your code online leads to conversations about it you wouldn’t have had otherwise. When people come to use your project, they’ll give you problems to solve that will help you grow as a developer.

Important to note: it’s a long, hard road to mastery — and the road never ends.


As the newly-minted maintainer of an open source project, you may feel discouraged you can’t ever finish your releases. I used to feel this way too. I used to plan a release by adding a bunch of issues to a milestone, and work against the issues until they were all done. However, a few to several to a dozen issues would always delay my October release date into December, January, and February.


With WP-CLI, I release new versions on a time-based schedule, and checklist the steps involved in the release process. Philosophically, I believe users shouldn’t care about which version they’re on, only that they’re on the latest and greatest. In fact, I avoid assigning issues to milestones until they’re done, or if they absolutely need to be fixed.

To streamline the release process, I’ve adopted a consistent release note format, so I never have to think about how they should be written. Similarly, I’ve created a checklist for the release process, and scripted as much of it as possible.

Important to note: wrapping up a release still takes several hours you’ll need to find in your schedule.


As the maintainer of an open source project, you may feel overwhelmed by your issue backlog. As your project becomes more popular, users will open up issues, and this will happen at a greater rate than your ability to close them. At some point, you’ll hit the 400 open issue mark and lose all hope.


In maintaining WP-CLI, I do my best to triage, prioritize, and make decisions. I review the backlog regularly, refining issues to ensure they have sufficient detail, assigning labels as necessary, etc. I prioritize by only assigning myself on a few issues at a time. Lastly, I make decisions — if an issue has been open for two years without any movement, then it’s probably not important to fix.

Important to note: you’ll never get to zero, so you’ll need to come to grips with what is a healthy number of open issues for your project.


As the maintainer of an open source project, you may get frustrated when issues turn into flamewars. Text has a very low emotional density. You and I having a conversation across from one another has high emotional density; we have body language, facial expressions, and vocal intonation to support the words we’re saying. Text-based conversation, with its low emotional density, can easily lead to misunderstandings.


In maintaining WP-CLI, I do my best to be empathetic, respectful, and firm.

First, I do my best to try and understand where the user is coming from. I try to put myself in their shoes, to figure out what they might be meaning that they aren’t necessarily saying.

Second, I’m respectful of the fact they’re using some of their precious time to try and improve my project. If they’re reporting a bug, it may be one that’s sunk a day or two of their time.

Lastly, being firm asserts myself as the authority on the subject, which sets the tone for the conversation and reduces ambiguity.

Important to note: you’ll still need to develop a thick skin.


As the maintainer of an open source project, you may feel overcommitted on your open source involvement. People ask you to do things, and you say yes. Too many yesses lead to stress.


In maintaining WP-CLI, I’ve discovered I need to make myself happy first, and set clear boundaries on my involvement. The best balance I’ve found is 2-5 hours per week, as a part of my normal work schedule. This keeps my involvement a passion, and from feeling too much like work. Because I prioritize the issues I’m working on, I can make regular progress on what I think is most important.

Important to note: commitments are a constant balancing act.


As the maintainer of an open source project, you may feel all alone. This is a current struggle of mine with WP-CLI as I try to find a long-term future for WP-CLI that isn’t wholly dependent on me. As fun as it is to be a benevolent dictator, I’m concerned about the project’s bus factor.


With WP-CLI, I’m shifting my focus to leadership, and identifying opportunities for others to be decision-makers with the project. More specifically, I am:

Important to note: You’ll never find all of the contributors you want, so you need to accept and make use of what you have, which can be difficult.

So, where is all of this heading?


WP-CLI is eating WordPress.

WP-CLI is becoming more and more embedded in the WordPress developer experience. It seems like there’s a WP-CLI session at every WordCamp these days.

With the command line, WP-CLI enables doing more with less effort. You can help WP-CLI eat WordPress by writing and maintaining custom commands.


Just like WordPress has plugins, the future of WP-CLI is packages of commands. For this future, I’m trying to proactively solve the problems WordPress has with plugins:

  • Where WordPress plugins are considered second-class to what’s included in core, I’d like WP-CLI packages to be considered first-class citizens amongst the commands in WP-CLI.
  • All too often, WordPress plugins have just one author. I’d like for each WP-CLI package to have two or three active maintainers.

We’re all aware that open source is an increasingly valuable part of the global economy. In this talk, I hope I’ve conveyed that, emotional rollercoaster aside, maintaining an open source project can be a hugely rewarding part of your career.

When you decide to take the leap, I look forward to saying to you…


#wcnyc: A Journey To The Center Of WP-CLI

The talk went great! I improved my wp present command to do some fancier Markdown parsing, and it worked out quite well. Here’s the markdown file if you’d like to skim through.

Although I didn’t finish my slides until this morning, I did a couple of things I’ll always be doing going forward:

  1. Produce a list of a few bullet points I want to hit for each slide, in case I get off track. I put these in Apple Notes so I could easily reference from my phone when I got stuck.
  2. Practice the presentation a couple times. This was really helpful to identify how I wanted to transition between each slide.

The visual representation of the slides are below.

Continue reading “#wcnyc: A Journey To The Center Of WP-CLI”

#phppdx: WordPress as an Application Platform

Last night, I presented to ~25-30 people at the PDX PHP meetup on “WordPress as an Application Platform”. Even though I’m no longer with Human Made, I think what they’ve done with WP Remote (and Happytables) is the bleeding edge and worthy of sharing.

Ultimately, the point I wanted to get across is two-fold:

  • Many applications you could think of building are easily doable with WordPress.
  • WordPress-based products are even more interesting when you have a few, and durable components to share between them.

After the talk, I asked Zack for his feedback:

  • Went well: introduction via Freshbooks example really set the stage for what we were talking about. Avoided misunderstanding / different opinions of what a web application was.
  • Next time: Challenge people more. Explanation of how HM built WP Remote was a bit surface level. Could’ve gone deeper into the architecture as a frame of reference for people when they run into it.


All of the references I mentioned in the slides are available at the following links.

WP Remote components:

  • Job Agency – Asynchronous jobs system for WordPress, built on WP-CLI.
  • HM Rewrite – Wrapper for the WP Rewrite API.
  • h-api – Simple, descriptive API pattern. Needs work for public consumption.

Object cache drop-ins:

Future of WordPress:

#pdxwp: Code Review Takes Two

We did a second pass at our code review meetup — last night turned out much better than the first. The high point for me: most of the “presentation” was, in fact, discussion. The latter proved to be way more valuable for everyone, as most of the twenty people in the room don’t do code review on a regular basis.

Here’s what we did:

  • Jeremy Ross submitted a section of code he had been working on, along with instructions on what he wanted feedback on.
  • On Saturday, I reviewed the code. I committed it in one commit to a branch in a private Github repo. On the changeset, I did a line-by-line read-through, commenting as I went. To wrap the review up, I created a pull request explaining how I did the review, what I looked for, and how to interpret my feedback.
  • Saturday night, I prepared a reveal.js presentation with an introduction to code review and the contents of what I found in my review. reveal.js is a super slick tool for preparing a HTML/CSS/JS presentation out of content in Markdown.
  • Jeremy read and considered my review, then updated the presentation with his feedback.
  • I did most of the presentation discussion facilitation, and Jeremy talked through how he received my feedback.

reveal.js doesn’t produce great static slide output, and I used its Markdown feature which requires Grunt to serve, so the bulk of what we covered will forever live on in the outline that follows.
Continue reading “#pdxwp: Code Review Takes Two”

Webstock: Karen McGrane, Adapting Ourselves to Adaptive Content

This week I’m at Webstock, a lovely conference in New Zealand. I’m doing my best to write little blog posts about the amazing presentations. Please forgive any typos, etc. If you’re here too, come write a haiku at Automattic’s booth.

Karen McGrane has made a career of dragging media companies kicking and screaming onto the internet. She’s helped with projects like a redesigned, Atlantic Media’s web properties, and TIME’s new responsive redesign. “It’s tempting to think that mobile is a design and development problem,” but the real challenge of mobile is content.

To kick things off, compare NPR and Conde Nast. The latter has spent tremendous effort replicating print editions into iPad apps. When the iPad first launched, Karen asked Paul Ford what the effect might be on the publishing industry. This is what she heard:

We’re about to usher in a golden age of PDFs on the iPad.

Conde Nast has gone even as far as make print designers produce two layouts for the iPad: portrait and landscape. The 1980’s aren’t coming back, though.

NPR has taken an alternative approach: Create Once, Publish Everywhere. The story is created once, and let each platform determine how it should be presented. NPR’s CMS captures just the right structure for the content. All of this data is available through the API.

iPad issue sales are on the downswing for Conde Nast. For NPR, viewership has grown by 80%. They attribute it solely to the API and it’s downstream effects on how they produce editorial products.

Thirty years ago, TV Week made the decision to produce multiple versions of their content, and assign meaningful metadata to it. Thirty years later, that content still has value because it’s reusable in new or uninvented contexts.

“News organizations already have structured content […] So many problems in mobile would be solved if everything had a dek.”

One of the biggest challenges in digital is the notion that content and form are closely coupled. That how something looks has a significant influence on what it means. That there’s a “primary platform” for a given piece of content. For many news organizations, this primary platform is still print.

Adaptive content doesn’t mean content prepared for print and then moved to other devices. Nor does it mean content prepared for the web, then pushed to print and mobile. It means focusing on structured content that can live anywhere.

Here’s how it can be done:

  • Write for the chunk – Many CMSes give writers WYSIWYG editors where they can dump in whatever they want. They should not be permitted this.
  • Demystify metadata – The Guardian’s iPad application uses an algorithm to read editorial decisions from the InDesign layout to determine story priorities. Brilliant reuse of existing effort.
  • Better CMS workflow – Writers hate fields and checkboxes because the interface is terrible. “CMS is the enterprise software that UX forgot.” E-commerce checkout flows are analysed to the pixel — content creation flows should receive just as much attention.

“Metadata is the new art direction.” – Ethan Resnick. The more work you put into structuring your content now, the more opportunities you’ll have in the future.

Webstock: John Gruber, In Praise of Pac-Man

This week I’m at Webstock, a lovely conference in New Zealand. I’m doing my best to write little blog posts about the amazing presentations. Please forgive any typos, etc. If you’re here too, come write a haiku at Automattic’s booth.

John Gruber, well everyone knows who John Gruber is. If you don’t, please hand in your internet license.

Pac-Man is a maze. The maze is filled with dots. You eat all of the dots, without being eaten in turn by the monsters changing you. There are power dots in corners which turn the monsters into ghosts you can eat. Everything leads to points.

It was invented by Toru Iwatani. At the time, coin-operated video games was a nacent industry. Game operators converged at a conference every year to choose new games to buy. Pac-Man never stood out as a hit game. Until it did $1 billion in the first few years, more than Star Wars did in ticket sales.

Buckner & Garcia introduced a song in 1982 called “Pac-Man Fever.” It made it to #9 on the Billboard charts. Gruber remembers being able to play Pac-Man at the grocery store and an entire arcade of Pac-Man machines. It was the first game to reach this level of success.

Gruber ascribes Pac-Man’s success to four characteristics:

  • Fun
  • Simple
  • Obvious
  • Challenging

Mr. Do!, on the other hand, was an incredibly complex game only a few people at Webstock remember. For instance, when you eat the snack in the center of the screen, the screen changes color, some more bad guys come out that are more aggressive, and then maybe you get another life. Gruber still doesn’t know what the best technique is for winning the game.

Mr. Do! was a popular arcade game, but no one thought it was important enough to track how much money it made. Pac-Man was much more than a popular arcade game. “Everything in Pac-Man was iconic.”

The monsters in Pac-Man had their own names and unique personalities. “Blinky”, the red monster, persistently chased Pac-Man. He was the one most likely to kill you. “Clyde”, on the other hand, was a dumb oaf.

Pac-Man was popular because it rewarded obsessiveness, but Gruber argues it was financially successful because it was a game everyone could get. You didn’t have to be a gamer to know how to play it.

The original Macintosh was similarly successful. It challenged the status quo of interacting with a computer through the command line by offering an interface that was more intuitive. Gruber thinks Macintosh designers inherited many ideas from video games of the time. There was even iconography (e.g. a bomb on the restart modal) you’d expect to see in a video game, not an operating system.

iOS takes the simplicity even further. All of your apps live on your homepage. You’re either on your homepage or in an app. “Android is Mr. Do!” because there’s additional levels of complexity and conventions you need to learn.

Gruber’s advice: if you can’t describe your project in one sentence, you’re not working on a simple project. “Ten pounds of effort on one simple design element will have way more impact than one pound of effort on ten design elements.”

Webstock: Chris Coyier, The Modern Web Designer’s Workflow

This week I’m at Webstock, a lovely conference in New Zealand. I’m doing my best to write little blog posts about the amazing presentations. Please forgive any typos, etc. If you’re here too, come write a haiku at Automattic’s booth.

Chris Coyier is a humorous man. He was also a designer at Wufoo and now does CSS Tricks and CodePen. Today he’s covering:

  1. Getting started designing.
  2. Local development environment.
  3. Working on a team.
  4. Preprocessing saves happiness.
  5. Testing, testing, testing.

Chris designs in Photoshop, to the faux-horror of everyone in the room. Photoshop is more “left brainy” than a CSS editor. It affords more creativity. WebZap gives you buttons and other web patterns to use in your mockups.

The blank canvas is a challenge for every profession. In the design world, you might:

  • Toss down a texture.
  • Draw some shapes.
  • Avoid making wireframes.

As soon as you have a Minimum Viable Design in Photoshop, though, take it to the web. Making it perfect in Photoshop just means you’ll have to do the work all over again.

“Let’s change the phrase ‘designing in the browser’ to ‘deciding in the browser’.” – Some Guy I Missed

Don’t work live on a server. Just don’t.

Instead, you can and should develop in a local environment. If you’re building for WordPress, MAMP is a good option to provide everything you need to run a web server.

Two tools to demystify version control: Github for Mac and Tower.

Chris is all about the Sublime Text. In version 3, being able to jump to files is amazeballs. Emmet does all sorts of crazy HTML auto-completion.

Some advantages to using a preprocessor like Sass:

  • DRY awesomeness.
  • Mixins allow you to define named functions, and use those functions elsewhere in your Sass. Everyone screws up CSS3 vendor prefixes. Mixins allow you to only screw up (and fix) in one place.

Sass plus Compass gives you an amazing number predefined mixins.

Editor’s note: All of this frontend hotness is blowing my mind. I didn’t even know.

Preprocessing also greatly simplifies media queries. And it makes writing CSS fun again.

CodeKit is a Mac app that automagically preprocesses all of your shiz. It will inject style changes into your browser while you edit. Great for when you might need to style web apps with various states. It can also losslessly compress any image assets used in your site.

The easiest way to make a website faster is to load less stuff. If you can’t remove it entirely, you can concatenate and minimize.

Testing is a big PITA. BrowserStack lets you test in a variety of browsers from the comfort of your own home.