I originally wrote a draft of this in December, but was inspired to finish it by recent events (i.e. actix-web).

We’ve all heard the trope that the “free” in “free software” does not necessarily mean “without cost” (source). In fact, it really almost never does. Even if a unit of software is available without monetary cost, other important costs, like the free time of the maintainers and involved parties, should not, and cannot be overlooked. I find that over the years, my perspective on FLOSS has changed drastically, and now can simply be expressed as “contribute, or die.” Of course, though, it’s not as simple as just saying three words.

Growing up, I was dragged to Episcopal church every Sunday, and though I wasn’t always paying attention when I was younger, I do remember the yearly services that were dedicated to recognizing the stewardship of church members, and encouraging them to continue into the next year. There was always an emphasis on “time, talent, and treasure,” which incidentally are important to the long-term success of any project, organization, or initiative.

It’s plain to see – long-lived projects cannot exist sustainably without sufficient stewardship (time, talent, treasure) from all involved. When it comes to software projects, proprietary or not, the lower the bus factor is, the less likely it is that a project can continue to exist.

A lack of any of these three main kinds of contributions (time, talent, and treasure)

• contributions of code (This means pull requests. Issues count too, but mind the ratio vs. PR’s)
• contributions of money (This means core members have the time available to work without, say, losing their home or going hungry)
• contributions to the community (This means creating tutorial content, adding documentation, promoting the project)

Can cause any of these outcomes:

• Software rot, overall quality decline, and a higher number of unresolved bugs/issues/feature requests
• People migrating from using the project to other options, leaving chats, etc.
• Decreased appeal of the project to newcomers
• Maintainers losing interest in continuing to maintain the project
• Heated interactions between maintainers and members of the community
• Ultimately, death of the project (no contributors, no community, no interest)

In short: contribute, or die.

It’s also fairly evident that this just so happens to be a vicious cycle of its own if left unchecked: each of the “death” outcomes effectively reduces the incoming “contributions,” until you eventually reach ultimate death. Especially when it comes to open-source, where “contributions” usually come as acts of community goodwill, rather than from paying customers/subscribers, any project that fails to become sustainable is surely doomed.

Case study: event-stream

Back in November 2018, event-stream, an npm package, was found to have a malicious dependency, flatmap-stream, which was added by a bad actor who offered to pick up maintenance of the project when its creator stepped down.

What happens when a project dies? What happens when the people who care about it can no longer afford to? Would this have happened at all?

Case study: actix-web

(This section wasn’t in the original draft, but I felt it was relevant, as it was the inspiration to actually finish the piece. Read more: https://words.steveklabnik.com/a-sad-day-for-rust)

The maintainer of actix-web, a Rust server library, shut down the project without warning, after receiving widespread negativity and backlash after a patch. The project repo is now a single Markdown file, containing a rant/postmortem. This greatly affects people who rely on the project, as now they either need to switch dependencies, or begin a new fork. There’s also the question of how this will affect the reputation of the developer in question.

What effect do comments like “never write Rust again” have on a maintainer’s emotions and mental health? How can we express discontent with a project we haven’t contributed to? What’s a graceful way to end a project you no longer wish to be responsible for?

Case study: Angel Framework

I am the creator/maintainer of Angel, a server-side/full-stack framework in Dart. The project grew to include dozens of auxiliary libraries, but I failed to consider to consider the cost, time-wise, of long-term maintenance of so many packages. This has caused me a lot of stress and frustration. Better planning could have prevented this. That being said, it has been very difficult to find people willing to contribute to Dart server-side projects at large – everybody talks about the lack of libraries, but not many people end up writing them. I am very grateful to everyone who has sent in pull requests, fixed the docs, and engaged in the chat, as they are, in a very real sense, the lifeblood of the project.

What if I had focused more on building community in the early stages? How can we create welcoming environments for new contributors? How do you overcome chicken-and-egg problems?

What can we do?

As I said earlier, all involved need to contribute in some way to guarantee a project’s longevity. In practice, not everybody will contribute, or at least not to the same extent, but as a project grows bigger in scope, there is certainly some critical mass of contribution necessary for it to be sustainable.

For maintainers, something we oft overlook is transparency. For example, Angel has not had a clearly-defined roadmap since the release of version 2, and admittedly, certain components (such as the ORM’s code generator) have stylistic issues that raise the barrier of entry for contributors. Adding clear contribution guidelines, listing contributors in project README’s, actively updating roadmaps, and hosting an accessible chat or communication channel (IRC is not a good choice for this in 2020) can go a long way toward making it easier for people to contribute. I’ll admit it – at some point in 2019, I seriously considered retiring the Angel project. I realized, though,  that if I could clearly define what would be necessary for me to continue working on it, it would go a long way toward making sure those things actually happened.

It is also important to express your gratitude to those who do contribute. Like the earlier example of yearly church services, thanking people for what they do is important for keeping morale high. People know when their effort is not sincerely recognized or appreciated. Don’t make the mistake of taking volunteers for granted.

Before you begin to promote a project, make sure you have a plan for its long-term maintenance. Review your plan to make sure it’s realistic. A big part of forming a community is about which niche you form that community in. For example, the community around using Dart on the server is very small compared to, say, Node or PHP, so a smarter plan when I had started would have likely been to keep the scope of the project relatively small, as it would likely never reach the critical mass of core contributors necessary to provide many features at high quality for a long time. That being said, I’ll be sure not be too hard on myself, because at the time I started promoting it, I was still an overly-optimistic high school student who simply lacked the foresight and life experience to have recognized the importance of having a long-term plan.

For users, your job is simpler – just find some way to contribute either your time, talent, or treasure, especially if you are making money by using the project. Things to not do, especially if you opt to not offer any contribution at all, include being disrespectful to those involved, or giving destructive criticism, especially if it’s not even in a channel where a maintainer is likely to see and work towards a solution at all.

Going Forward

On the surface level, “contribute or die” is about as people-friendly as telling someone with a question to “RTFM.” It is important, if you agree with this philosophy on open source, to be mindful of how you interact with newcomers, and to not sabotage your own project by acting rude, arrogant, or otherwise extremely unpleasant to people who possibly could have been good stewards. At its core, though, “contribute or die” is really the simplest way to explain the significance of stewardship to a project. I hope that I may have inspired people to contribute to projects they frequently use, and to maybe have convinced some maintainers to ask more (respectfully!) of their users.

Got something to say? Feedback, comments, etc.? Use the Disqus widget below.