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…


#feelingrestful: A more RESTful WP-CLI

Earlier today, I gave a talk at A Day of REST about unlocking the potential of the WP REST API at the command line — by creating a more RESTful WP-CLI. Check out the project on Github, and stay tuned for the v0.1.0 release. Read on for my (loosely edited) annotated slides from the presentation.

Continue reading “#feelingrestful: A more RESTful WP-CLI”

#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”

#pdxwp: wp-cli is for WP devs on a deadline

As a part of tonight’s “It’s Tool Time: 4 Tools You Cannot Live Without” meetup, I presented on my beloved wp-cli. wp-cli is a command line interface for WordPress, and a tremendously powerful tool for WordPress developers on a deadline. So powerful, in fact, I wrote my slides as a command 15 minutes before my talk.

Continue reading “#pdxwp: wp-cli is for WP devs on a deadline”

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.

Continue reading “Webstock: Karen McGrane, Adapting Ourselves to Adaptive Content”

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.

Continue reading “Webstock: John Gruber, In Praise of Pac-Man”

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.
Continue reading “Webstock: Chris Coyier, The Modern Web Designer’s Workflow”