Most code in existence today utilizes open-source components, but it’s important to remember where, and who, that open-source code comes from. 

Open-source software is mostly developed and maintained by volunteers. Unlike a company with resources to hire more developers, the maintainers of most open-source projects have to carry the burden of what comes after them. 

For example, at the end of 2022, the maintainers of the Gorilla toolkit announced they were archiving the project, meaning that they wouldn’t develop new features for it, and wouldn’t make any security fixes. Gorilla contains a number of different tools for Go developers, one of which is mux, a URL router and dispatcher that has been forked nearly 2,000 times on GitHub.

When the current maintainers decided they wanted to move on, they had put out a call to the community asking new people to start contributing. In their goodbye letter, they said the call wasn’t successful. 

RELATED ARTICLE: Open-source software sees growth across the board

“As we said in the original call for maintainers: ‘no maintainer is better than an adversarial maintainer!’ — just handing the reins of even a single software package that has north of 13k unique clones a week (mux) is just not something I’d ever be comfortable with. This has tended to play out poorly with other projects,” the maintainers wrote in a farewell letter announcing the archiving of the project. 

Open source is like a garden

Tom Bereknyei, lead engineer at flox, likens open source to a garden. “Most people enjoy the scenery at almost no cost. Malicious people can ruin the place if left unchecked. There are few gardeners and even fewer supervisors. Some gardens are organized, some are chaotic. Some have been around for generations, and some are abandoned after a month. Maintenance can be invisible and thus not appreciated, until the moment that maintenance disappears,” he said. 

This doesn’t necessarily mean that open-source components should be avoided. After all, Bereknyei points out that proprietary software doesn’t necessarily have guarantees either, as a company could go out of business or change things in a way you don’t like. 

But it is important to know how the open-source projects you rely on are planning for the future, and it underscores the importance of having trusted maintainers in the pipeline. That way, when a top maintainer needs to leave the project, there is someone who has built that trust that can step up and do a good job stewarding the project. 

“Being a good reviewer is a lot of work: you have to have a clear vision for a project

and make sure contributions are consistent with that, in addition to making sure everything’s

tested and documented,” said Jay Conrod, software engineer at EngFlow. 

The way to handle contributors and maintainers will vary depending on project size and company support. For example, Conrod previously worked at Google where he was the maintainer of the projects rules_go and Gazelle, and he has also worked full-time maintaining Go. 

At one point, maintaining rules_go and Gazelle was too much in addition to his regular work. His plan for transitioning off the project was to invite a group of regular contributors to become maintainers, providing them with write access to the project. Then, over the course of a year he met with them regularly to continue solidifying the relationship. 

“I think this approach of inviting specific people, building relationships with them, and making sure they have the resources they need is important,” said Conrod. 

Climbing the leadership ladder

The Kubernetes project is a good example of this. According to Eddie Zaneski, software engineer at Chainguard and maintainer of Kubernetes and Sigstore, Kubernetes has a contributor ladder that is designed for helping people grow into leadership roles with the following rankings:

  • Members, who are active contributors to the project and must be sponsored by at least two reviewers
  • Reviewers, who are responsible for reviewing code
  • Approvers, who can review and approve contributions
  • Subproject owners, who are technical authorities on a specific subproject within Kubernetes

Each of these roles has increasingly strict requirements as you work up the ladder. For example, in order to become an approver, you would have had to have been a reviewer for 3 months, been the primary reviewer for at least “10 substantial PRs,” reviewed or merged 30 PRs, and have been nominated by a subproject owner.  

According to Conrod, another way to ensure that an open-source project is maintainable in the long-term is having contributors from a number of different companies. For example, with Go, though the majority of maintenance is done by Google, a few of the big packages are maintained by external contributors. 

Conrod also emphasized the importance of building a strong community, in which people are able to ask each other questions and just generally help each other out. It can even lead to business partnerships or the creation of related projects.

For example, EngFlow, is a business built around the open-source build project Bazel, and there are a number of open-source projects built on top of Bazel too. Because of this, he believes that if Google ever stopped supporting Bazel, the Bazel community could continue on because there’s already so much existing expertise outside of Google. 

Chainguard’s Zaneski believes that companies that benefit from using open-source technologies should also be committing time back to those projects. His company practices what they preach, too, as Chainguard is one of the top contributors to Kubernetes. 

This would involve actively ensuring that a developer’s  workload is such that they have the time to contribute to the projects. He believes the bare minimum is enabling developers to spend 20% of their working time on contributions to open source.. 

Bereknyei also offered the advice to start a support contract with a maintainer if you rely on their project. “This provides a business relationship and goes a long way to ensuring support.”