Managing an open source project

Xavier Borderie sent me a series of questions via email about managing an open source project. My responses are primarily from the perspective of managing WP-CLI.

How do you organize daily/weekly schedules so that community PRs are not forgotten? 

Call me a glutton for punishment, but I receive email notifications for all the GitHub activity of projects I manage. I use email because:

  • Email is easy to quickly process with keyboard shortcuts.
  • Email keeps track of read/unread state for me.
  • As needed, I can create filters to help manage my information flow.

Ultimately, this means I see a pull request as soon as it comes in (or, at least, when I check my email).

When I see the pull request come in, I take some form of action on it. This action is either:

  • Make a judgement as to whether the pull request will be able to land — yes without additional changes, yes with additional changes, or no.
  • Determine I’ll need to set aside dedicated time to review (and make a judgement).

In both cases, I respond to the contributor accordingly. In the latter case, I add the code review to my task management tool, and come back to it when I have the bandwidth.

All of this hopefully underscores I think it’s important to communicate well, and handle contributions in a timely, effective manner.

How do you manage with contributions which need rebasing, amending and/or tweaking — and the contributor is silent for months?

WP-CLI has a two-week abandonment policy. If we don’t hear from you in two weeks, then we consider the pull request is abandoned.

Usually around day 10, I’ll reach out on the thread and as the contributor if they’ll be coming back to finish up. They respond most of the time, with either “yes, just need another day or two” or “no, I’m too busy now.”

When a pull request is abandoned and I want to land the code anyway, I’ll fork their branch so they still get credit for the work they’ve done and finish it up.

Does every team member manages her/his own time, or do you clock community-related work?

My dba, Hand Built, actually just a business of me, myself, and I. In 2015 (the last year I calculated it), I spent 12.26% of my time contributing to open source.

This year, things are bit different. Not only do I get paid (on a part-time basis) to maintain WP-CLI, but I have the budget to eventually hire a couple more part-time maintainers. The first is ramping up right now.

The expectation is that each of us commits an average of five to ten hours per week towards project. The theory is this is enough time to make regular, substantial contributions to the project, while also having enough of a foot in the real world to focus our effort on what’s most important. Each person is expected to manage her/his own time, balancing WP-CLI with the rest of their life as they see fit.

What was the impact of 5 For the Future for you when it was launched, and do you feel the 5FF campaign is still relevant/followed today?

For those who aren’t in the loop, “5 For The Future” was/is a call by Matt Mullenweg for companies to dedicate 5% of their people towards the WordPress project:

I think a good rule of thumb that will scale with the community as it continues to grow is that organizations that want to grow the WordPress pie (and not just their piece of it) should dedicate 5% of their people to working on something to do with core — be it development, documentation, security, support forums, theme reviews, training, testing, translation or whatever it might be that helps move WordPress mission forward.

Personally, I’m not sure how much of an impact 5FF specifically had on increasing the labor pool for the WordPress project. It seemed to be more of a one-time rallying cry than anything else.

I don’t mean to discount the intent, though. While the WordPress project could certainly benefit from more labor capacity, it certainly has a lot already from a healthy variety of companies. Furthermore, introducing more labor to the project also requires scaling up capacity to direct the labor.

On the other side, five percent of people seems to be a very challenging goal for many companies. If I were to put a number to it, it seems like most companies engaged with open source would be in the one to two percent range.

Which isn’t to say it’s not important for companies to more effectively support the open source projects they depend on. Contributing to open source is still hard: it’s a lot of overhead to stay regularly engaged with a project, and difficult to account for the benefit of the contributions.

What it feels like to be an open-source maintainer

One reason this situation is so frustrating is that, increasingly, I find that issue triage takes time away from the actual maintenance of a project. In other words, I often only have enough time to read through an issue and say, “Sorry, I don’t have time to look at this right now.” Just the mere act of responding can take up a majority of the time I’ve set aside for open source.

Nolan Lawson — What it feels like to be an open-source maintainer

Contributing to open source

Want to contribute to an open source project but don’t know where to begin? Don’t worry — with a bit of effort and dedication, you too can contribute to open source.

Before you begin, it’s helpful to acknowledge the history of open source. Historically, the term “open source” refers to software published under an open source license. These days, “open source” refers to both the software license and the community around the project. The community can be large, or it can be small. The people could be involved on a daily basis, or weekly basis, or rarely. “Open source” is almost an incomplete term, because it can refer to a broad spectrum of projects.

What project should I contribute to?

You get to choose! Which brings us to the first rule: make yourself happy first.

Contributing to open source can be an emotionally fraught activity. You may getting a fight with someone about whether an idea is good or bad. You may spend hours working on a pull request or new piece of documentation, only to have it rejected. Or, you may go weeks without hearing a reply to that issue you wrote. While it’s easy to construe these experiences as “bad”, often they can occur as a matter of circumstance — not the fault of a specific person.

Going into the open source, know your own motivations: Why do you want to contribute? What do you hope to gain from the experience? How much time are you willing to commit?

Also know that it’s not about you. The scope of the project may include that feature you want to contribute, or it may not. In contributing to an open source project, you’re delegating final decision making authority to the project maintainer.

If you manage your own expectations accordingly, you can keep contributing a rewarding experience.

How do I contribute to a project?

Just like many cultures have their own customs and norms, open source projects can have a variety of ways to manage the contributing process.

One good place to start would be to see if the project has a file in its repository. For example, here is the for WP-CLI. Or, there may be an equivalent document on the project’s website. For example, here’s the contributing page for The project will likely outline guidelines for contributing code, writing documentation, providing support, etc.

Another place to look would be the project’s issue tracker. Specifically, look for issues tagged “good first bug” (or some equivalent label). These are issues they have been identified as starting points for new contributors.

Please keep in mind, libre != gratis. The open source license grants you the freedom to use and modify, but not commitments of other people’s time. Most contributors are involved in the project on a volunteer basis (potentially even nights and weekends). Please be respectful, and set your expectations accordingly.

Down to SF for WONTFIX Cabal

Flying down to SF for the day to attend WONTFIX Cabal, an unconference on open source project maintenance. The topics I’m struggling with most right now are: support burden (where to draw the line helping end users), and new feature development (how to decide what gets built). Even though open source has been around a while, it still feels very much like the early days.

RethinkDB: why we failed

And our users clearly thought of us as an open-source developer tools company, because that’s what we really were. Which turned out to be very unfortunate, because the open-source developer tools market is one of the worst markets one could possibly end up in. Thousands of people used RethinkDB, often in business contexts, but most were willing to pay less for the lifetime of usage than the price of a single Starbucks coffee (which is to say, they weren’t willing to pay anything at all).

This wasn’t because the product was so good people didn’t need to pay for support, or because developers don’t control budgets, or because of failure of capitalism. The answer is basic microeconomics. Developers love building developer tools, often for free. So while there is massive demand, the supply vastly outstrips it. This drives the number of alternatives up, and the prices down to zero.

Slava Akhmechet – RethinkDB: why we failed

Getting the WP REST API endpoints into core

The question shouldn’t be “when will the WP REST API endpoints be committed to core?” but rather “how can the WordPress project ship solutions to more and better Big Hairy Ambitious Goals?”

If we can solve this organizational design challenge, then landing the WP REST API endpoints, and other large improvements to the project, becomes an “easy” task (or at least one requiring a known amount of people with a known amount of involvement). If we can’t solve this organizational design challenge, then it does us no good to commit the endpoints to WordPress core. My biggest fear is for the endpoints to become another media library.

Specific to the WP REST API endpoints, I think it’s time for WordPress to aggressively pursue the component maintainer model. We need effective, reliable component maintainership to take responsibility for producing quality endpoints for each component.