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 wouldnt develop new features for it, and wouldnt make any security fixes. contains a number of different tools for Go developers, one of which is , 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 , they said the call wasnt successful.
RELATED ARTICLE:
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 Id 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 gardenTom Bereknyei, lead engineer at , 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 doesnt necessarily mean that open-source components should be avoided. After all, Bereknyei points out that proprietary software doesnt necessarily have guarantees either, as a company could go out of business or change things in a way you dont 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 everythings
tested and documented, said Jay Conrod, software engineer at .
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 and , 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 ladderThe Kubernetes project is a good example of this. According to Eddie Zaneski, software engineer at and maintainer of Kubernetes and , Kubernetes has a 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 KubernetesEach 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 creat