Good first Gutenberg issues

Want to submit your first pull request to Gutenberg? Here are a few good first issues to get your feet wet:

Read through the contributing guide for details on how to get started. Feel free to ask questions on the specific issue, or join us in the #core-editor channel with any questions you might have.

RFC #17: Experiments and the Economics of Open Source

RFC #17: Experiments and the Economics of Open Source. I joined Nadia and Mikeal to discuss my work on WP-CLI, the economics, origins, staying productive as a maintainer, fund raising, and the state of WP-CLI "today" (aka last May when this was recorded).

Update: I forgot I said this: "[The GPL] is used often as a blunt instrument for enforcing certain economic dynamics around everyone's businesses." Pretty good!

Open source is debt

An idea I'd like to throw in the wild.

Open source is software businesses use to shorten time to market and accelerate their product. Some businesses build and collaborate in public because it's a leverage strategy to get more from less. Most businesses maximize their use of open source software because they get it for "free".

Debt is the financial term, stolen for the sake of illustrating a concept.

Open source is debt because:

  • Open source software is not a sellable asset. It's both priceless and devoid of monetary value. What counts is the business value it enables.
  • The liability, and effort required to service this liability, grows as: 1) the software gains users, and 2) those users become more dependent the software. Support is a variable accelerant to the liability (e.g. it can grow the liability at an exponential rate).
  • Maintainers hold the debt liability. Their ongoing labor is required to service the debt. Typically, maintainers can only escape the obligation by declaring bankruptcy: "it's done" or "I'm done."

This idea could be helpful framing for:

  • Businesses to understand their dependency on open source in CFO-friendly terms.
  • Communities to understand the debt burden carried by maintainers, and general health of the project.

Another, possibly more correct, way of thinking about this is: "every line of source code, open or closed, is a liability." Businesses own 100% of their closed source liability. They like open source because they would rather own 0% the liability.

Landing Gutenberg in WordPress 5.0

Some incomplete ideas I've been noodling on that I want to make public.

Ultimately, the goal is: the vast majority of WordPress users are excited and should be able to use Gutenberg on day one. Fundamentally, this breaks down into two objectives:

  1. Make the end-user experience is so good that WordPress users actively want to switch to it. We need to continue user testing as we have been, and iterate based on real user feedback. We also need to market Gutenberg — communicate what users should expect and get them appropriately excited.
  2. Mitigate WordPress plugin and theme incompatibilities, to minimize conflicts that would cause WordPress to fall back to the classic editor. Success is defined by the majority of WordPress users being able to use Gutenberg on day one. If too many can't use Gutenberg because of conflicts, then we've failed at launch.

I've been brainstorming some strategies for the latter, which really is two parts: identification and mitigation.

First, we need to identify the true extent of the problem: what plugins and themes are incompatible with Gutenberg, and in what ways are each incompatible? Some automated ways we can produce this data includes:

  • Manual/automated analysis of action and filters usage, etc.
  • Activate each in an isolated environment and take before/after screenshots of the editor screen.

But, I'm thinking good ol' fashioned crowd-sourcing might be most effective. What if WordPress users had an easy way to report whether a given plugin or theme was compatible with Gutenberg? We could collect this data in aggregate to get a good sense of what types of incompatibilities we should expect, and where we should focus our efforts.

Once we've identified the plugin and theme conflicts, we'll need to mitigate them. Doing so will require excellent documentation, so authors more easily understand the changes they'll need to make, and deputizing other developers to help with the outreach process.

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.