A call to action for maintainers to support themselves and move forward.

Big notable projects like Linux and Node.js have comforting long term support cycles that ensure Enterprises and other production users can continue to use a release for years without migrating to a new one.

The ecosystems built on top of these projects tend to try and follow a similar cycle. They keep old releases in their CI configuration and block PR’s from being merged if they don’t work on older release lines.

I’m just going to come out and say it, this is a destructive practice for smaller projects.

1. This isn’t how LTS is done in big projects.

You can send a pull request to Node.js today and get it merged without a single test on an old release line. In fact, it is only merged to the CURRENT release line and your review will likely only mention that release line.

The LTS Working Group periodically takes recent changes and prepares a backport to an old release line. Who is the LTS Working Group? Vendors.

More specifically, it’s a collection of contributors that care about Long Term Support. All of them happen to work at companies with a strategic interest in Enterprise Node.js users (Google, IBM, NodeSource, Nearform).

LTS didn’t exist in Node.js until the Foundation brought these vendors into the process. It wouldn’t still exist without their involvement, and we’re all better for it.

You, in your GitHub project, probably don’t have this kind of investment from vendors.

You, in your GitHub project, probably don’t have the time or resources to manage more than one release line of development.

And yet, you’re putting up more of a barrier to contributions than big projects with lots of contributors and investment. Stop.

2. You’ll never get LTS contributions unless you stop providing them for free.

Contributors to projects tend to be users of newer releases. This is partly because people that are willing to dig into the internals of a module they use are closer to the bleeding edge.

But another reason we don’t get as many users of older releases contributing is that we aren’t really asking them to. If they can’t use anything new, what is their incentive to contribute?

If you cut support for an older release people will show up to complain, but how many of them are willing to contribute? How many of them have ever even considered it necessary?

We’ve cultivated a class of passive open source consumers who are disconnected from the realities facing the projects they depend on. If we are open to contributions to continue to support them, then we should also require that they step up to do this work.

3. You’re burning out maintainers.

I’ve talked to a lot of open source developers about burnout. A common theme is that they feel like there are far too many expectations on too few people.

In particular, people feel an obligation to do work they don’t even personally care about or are connected to.

If people who care about long term support are part of your contributorship, you can empathize with their needs and work with them as a peer. But because so few of the users of old releases are involved in the development process, maintainers see them as freeloaders with unreasonable demands and expectations.

The fastest path to fix this is to simply stop supporting use cases for which nobody concerned with that case is willing to contribute. If you don’t want the burden of these expectations burning out contributors, just stop considering these requirements until people are willing to step in and do the work.

4. Enterprise does not deserve a free ride.

There’s a lot of money coming from Enterprise into open source. Many companies are willing and able to put resources in when necessary.

The reason they haven’t spent nearly as much time with smaller projects is because they just don’t need to, these projects are already bending over backwards to support them for free.

These companies have no problem pitching in when they have no other choice. If Enterprise companies depend on your software, there’s a vendor selling to them that will do whatever it takes to make them happy.

Saying you won’t do the work to support an old release isn’t saying “I don’t care about you being a user.” Instead, you’re saying that there are two ways they can be a user.

• Upgrade.
• Help me keep it running for people who won’t upgrade.

Nobody is entitled to use software they don’t pay for without any effort whatsoever on their part.