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:
- Open source is free to use, which means a company can spend money on people (aka innovation) instead of software licenses.
- There are now a critical mass of reliable open source components, which accelerates your product’s time to market.
- Open source produces quantitatively better software.
- 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:
- Identifying ways for people to be involved in the project that aren’t just code, with specific expectations for those roles.
- Writing more documentation for the project than I think I need, knowing the documentation isn’t for me, who knows the project really well.
- Identifying “good first bugs” as entry points into the codebase.
- Highlighting contributors in release notes (and tweets).
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…
