My 18-Months Rule for Open-Source Contributions

Published on January 16, 2025, filed under Development (RSS feed for all categories).

I regularly contribute to open-source projects. While that rarely includes feature work, it often includes filing issue reports, suggesting features, and proposing code optimizations (that is, preparing PRs). I contribute in good faith, as a web professional appreciating, backing, and rooting for open source and the people behind open-source projects.

So far so good—you’re probably doing the same.

Just as regularly running into projects, however, that are open but not communicative or collaborative (or not consistently so), I’ve found that I needed a rule.

I’ve established that on a regular basis, I look for contributions (from me) that are older than 18 months that have not been responded to. (The “18-months rule.” Note “not responded to,” that is, without any activity.)

These contributions I then pull—I close the report, the suggestion, the PR.

Why do I do this?

Three reasons:

1. Honor My Time

Counterintuitively (I can’t recoup my time), with pulling my contributions I honor my own time. If I go the extra mile (googliness) to support a project, then I don’t expect anything—but a response. (I find this a fair expectation in my own open-source projects, too. A constructive contributor deserves feedback.) So if a contribution is not being acknowledged, I will honor it in retrospect, by revoking it and being more selective about contributions to such a project.

This doesn’t necessarily mean I stop supporting a project altogether—it just means that I invalidate contributions not responded to.

2. Encourage Healthier Open-Source Communication and Collaboration

An open-source project that de facto operates without managing the work of volunteers sets an example of poor communication and collaboration. I believe 18 months, the timeframe I’m currently using (yet which I may adjust), to be ample time even for swamped projects to respond. Pulling older contributions may disincentivize projects that do not show courtesy to their contributors, and through that negatively shape open-source culture for everyone.

Here it seems useful to remember that projects that cannot or do not elect to process contributions, can easily prevent them by making their projects private or by not accepting issues and PRs in the first place.

3. Provide Data to Projects That Are Understaffed and Underfunded

Now, having your contributors pull their contributions is probably the least desirable form of prioritization, but it is one—by removing them, I also help projects not to be distracted, to focus on the work in front of them, and perhaps to look beyond their headlights later. Them noting that people are pulling back their work may also help build staffing and funding cases, because it can serve as a datapoint that the open-source experience they’re providing is alienating contributors.

---

That last sentence may sum up the motivation for me: I’ve begun to feel alienated by open-source projects that don’t respect, and with that waste, contributors’ time. And so I’ve come to believe that we can and maybe should pull our contributions, to honor our time, to encourage better communication and collaboration, and to give projects data that working with them, well, isn’t great.

Is this “harsh”? It’s not meant to be (and nothing here carries particular sentiment or judgment), and it could as easily be turned around. This is deciding about one’s own work: In the end, we’re talking about free labor, something no one is entitled to receiving—especially when they cannot or do not appreciate it. The 18-months rule allows me to offer free labor to whom welcomes it—and not to who don’t.

PS.
If you want to do similar, GitHub’s issues (github.com/issues) and pull requests (github.com/pulls) pages make reviewing easy (especially when accompanied by a reminder—I’m working with an annual one).

About Me

I’m Jens (long: Jens Oliver Meiert), and I’m a frontend engineering leader and tech author/publisher. I’ve worked as a technical lead for companies like Google and as an engineering manager for companies like Miro, I’m a contributor to several web standards, and I write and review books for O’Reilly and Frontend Dogma.

I love trying things, not only in web development (and engineering management), but also in other areas like philosophy. Here on meiert.com I share some of my experiences and views. (Please be critical, interpret charitably, and give feedback.)