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…
A Journey To The Center Of WP-CLI. I’m speaking at WordCamp NYC. Join me at 4:45 pm on Sunday.
We tried not one but two experiments this year: specifying an overarching theme, "permanence", and requiring applications to be submitted by video.
It’s working out awesomely. Earlier this week, we announced our primary lineup of speakers. I suppose it’s a given because I’m the speaker coordinator, but I’d love to attend every one. They all tie into our theme of "permanence", yet stand strongly in their own right.
When we began planning this year’s WordCamp, I knew I wanted us to push hard to raise the bar. There are enough WordCamps happening every month, and subsequently talks making it to WordPress.tv, that the status quo shouldn’t be a generic, third time old presentation. Our idea: if we mandate video applications, and only one per person, it would encourage potential speakers to consider their pitch thoroughly. Furthermore, videos would enable us to better assess the person’s stage presence and ability to communicate concisely, both of which are important for inspiring an audience.
It’s safe to say we didn’t know if the idea would work until the day of the deadline. Up until the last 12 hours, the outcome was unknown and, frankly, a little nerve-wracking. In total, we received ~25 applications; 90% were submitted on the last day. It paid off though. Most of the applications were solid, obvious examples of much consideration, and the video format was a tremendous help for screening.
Go out on a limb every once in a while, take a risk, and see how it plays out.
#wcpdx aka WordCamp Beervana
The Zen of WP Development is being one with the code, and creating compelling web experiences with proper uses of the core API. It involves:
- Focusing on the question at hand, and ignoring distractions.
- Distilling complex situations into simpler parts.
- Pulling from deep knowledge of the codebase to understand how APIs interact.
- Striving for elegant solutions always.
Today, I was invited to present my perspective at WordCamp San Francisco. These are my slides. My notes are posted below them.
Announcing Our Speakers. WordCamp Portland speakers have finally been announced. I might be biased, but I think this is the first time I’ve wanted to attend every single session. Plus, we might even have one or two special guests show up for urge unconference track. If you’re feeling generous, we’re looking for volunteers too.
Today, I’ve been invited to give a talk at WordCamp Seattle titled “WordPress at the Command Line: An Introduction to wpshell and wp-cli”.
It’s exactly this — an introduction, because I hope to inspire further exploration of interacting with WordPress through the command line. Similar to Scribu, I’ve found “the keyboard is faster than the mouse” for many tasks, and that developing proficiency with the command line has dramatically increased my effectiveness as a programmer.
Enlightenment is knowing what your code is doing and why. Thankfully, instead of having to depend on your inner calm, there are a number of tools and strategies you can use to better see what’s going on. We’ll survey a range of topics you should explore to turn your frustration into bliss.
Feeling better already? In this session, we’ll touch on everything from debugging to best practices to coding standards to version control to performance and optimization. You’ll hear the insights WordPress.com VIP shares every day.
Session notes are below the slides.
Over the next couple of months, I’m looking forward to speaking at a few different events.
At WordCamp Phoenix on February 25th, I’m presenting “Mastering WordPress Development.” The title lends itself to a number of discussion topics, possibly including coding standards, how to perform migrations, writing bin scripts to manipulate lots of data, participating in open source projects, how to review your code, common mistakes we see at WordPress.com VIP, etc. If you have opinions as to what I should cover, I’d love to hear them in the comments.
On February 27th, Mike Bijon and I will be taking the Portland WordPress Users Group through using Git (and SVN) for version control and working within a team.
At CMA NYC March 18th through 20th, I’ll be leading three sessions (one per day):
- “I Want To Learn WordPress – An Introduction To Key Concepts” – All of the basics you need to get started, including the WordPress interface and key concepts like themes, plugins, PHP and MySQL, and how to choose a good web host and design for your site.
- “Hacking WordPress In The Newsroom” – How to take your WordPress development to the next level. We’ll review version control, coding standards, performance and optimization, debugging, and other best practices.
- “Making The Switch To WordPress” – Everything you need to know about switching to WordPress from CMS X. Well, most everything.