“Is This Still Maintained?“

If you’re like the average open source developer, you’ve probably published some code on Github that you haven’t touched in years. Because the code has some users, then the project probably has a backlog of a couple dozen issues you’ll never get to. Some are bugs, some are feature requests; all require more attention than you have for them.

If you’re like the average open source developer who accidentally created a popular project, you’ve probably felt completely overwhelmed by users’ demands for support, bug fixes, and new features. Already have a full time job? Congratulations, now you have two jobs, but one of them doesn’t pay, doesn’t offer benefits or vacation, and you can’t quit.

Happy to frustrated emojis

How did we end up in a place where so much of the economy is dependent on poorly resourced, inadequately supported, open source infrastructure?

Because “open source” is more about building and collaborating in public, than it is about the license. Open source creates huge amounts of commercial and social good by letting participants pool development resources and create value at the intersection of common need.

But, these communities can exist on a spectrum of active and healthy, to inactive, toxic, and succumbing to entropy. Open source licenses only explicitly grant usage and redistribution guarantees; at its core, “open source” has also become the community’s implicit expectation of a well-maintained and supported project.

Have an idea for solving a problem? Put together some code and throw it up on Github. In doing so, your implicit assumption is:

  • Here’s some code I wrote.

  • Feel free to use it directly, or modify if necessary.

  • If you’ve made a generally useful modification, please submit a pull request.

In an ideal world, your benefit from accepting others’ contributions would exceed the cost of answering questions, providing code review, etc. However, the reality of users’ expectations end up being something like this:

  • Oh! Here is some code I can use on my project (probably work-related).

  • For support questions and feature requests, I’ll use the bug tracker.

  • If I want to add a new feature myself, I’ll submit a pull request and it will always be accepted.

Left unchecked, your “gift to the world” becomes increasingly difficult to maintain as the project grows in popularity.

Ay caramba! What can we even do?

In many aspects of life, managing expectations is a key ingredient for success. We can make open source infrastructure more sustainable by helping maintainers define the norms around their project. The challenge with implicit assumptions is just that; they’re implicit, and bring all sorts of implied agreements with them. By setting explicit expectations with their users, project maintainers will be able to reap the benefits of collaborating in public while avoiding maintenance burden burnout.

At the end of the day, such an explicit definition would include answers to:

  • Is the project maintained?

    • Who are the project maintainers? Why are they involved?

    • How often are new versions released?

    • Do you have an established roadmap?

  • Is this project supported?

    • What type of support is offered?

      • Only bug reports?

      • Feature requests too?

      • General usage questions?

    • What venues are appropriate for support?

    • What’s a reasonable timeframe for a response?

    • What types of questions aren’t supported?

  • What types of contributions are you accepting?

    • Do you prefer users create an issue for discussion beforehand?

    • Do you require test coverage?

    • Are you accepting new features? If so, within what scope?

Just like Creative Commons clarified expectations around permissive use of copyright, we have the opportunity to enable more sustainable open source maintenance by codifying best practices for maintenance and support norms.

Something you’re interested in? Join the conversation on Github, share this post as a vote of support for the idea, and/or sign up for the occasional email update.

Thanks to Eric Holscher, Josh Koenig, Nadia Eghbal, and Ryan Pitts for their feedback on this post. Inspiration from Is It Maintained?, Read The Docs Open Source Philosophy, Contributor Covenant, and others.

Topics Development, Drupal, WordPress