A few days ago I started (and finished) working on my latest hardware project, which I call “Home”. If you’ve ever worked with MicroPython, which this project uses, you may have come across mpfshell, an extremely useful utility which makes managing the program on the microcontroller very easy.

I use mpfshell for my projects, and I wanted to upload compiled scripts to the microcontroller, but mpfshell did not do this natively. “No matter”, I thought, I will just write the feature and issue a pull request to the original developer, who can then incorporate it into the main program. I went to GitHub to see if something similar was already under way, but I saw the project in a semi-abandoned state, with issues and pull requests piling up and receiving no response.

This prompted me to think about a pervasive problem in open source, which I want to discuss here and offer a solution to.

Abandoned projects

Maintaining open source software is a tough (and mostly thankless) job. Being in charge of a popular project can be a significant amount of work, and while you do receive contributions in the form of pull requests that other people write, the aggregate amount of time spent reviewing those, offering suggestions and doing development of your own on the project can be pretty large, especially when you maintain more than a few projects.

Oftentimes, as is the case of mpfshell above, the maintainer doesn’t have enough time to dedicate to the project, or gets tired of working on it, or they stop having the itch it scratched, or just doesn’t feel like maintaining it any more. Whatever the reason, the project is usually left to languish, as even picking an experienced, trustworthy and willing successor is a fair bit of work.

What if it doesn’t have to be this way?

A potential solution

When I realized that mpfshell was no longer maintained, I was a bit puzzled as to how that could happen. Here was a useful project, with users who cared enough to open issues and submit pull requests, yet nobody had stepped up and offered to maintain it, and the maintainer hadn’t had the chance to find someone themselves. Clearly, the problem of appointing a successor must be too hard.

A potential solution presented itself, though: Just like I was willing to take up ownership of the project and keep it going, because it solved my problem, what if I founded a community of willing, experienced and trustworthy maintainers who could offer to maintain any project that they chose?

What if this offer wasn’t limited to abandoned projects, but also to projects whose maintainer(s) just needed some help?

What would that look like?

The responsibilities of maintainership

A good maintainer must have numerous qualities:

• They need to be trustworthy. They have the ability to push code directly to people’s machines, and people want to rest assured that that code won’t do anything malicious. The OSS ecosystem has managed to mostly avoid this so far, altough there are some notable exceptions I will mention later on.
• They need to be experienced. It’s a technically demanding affair, and the maintainer needs to know enough about development to keep code (and general) quality high.
• They need to have a strong sense of direction. Maintaining a project isn’t just about writing code for it and merging contributions, it’s about having a vision of how you want the project to evolve and helping it evolve that way. Someone who adds every feature anyone requests without considering whether it belongs in the project is not a good maintainer.

These qualities are doubly important when you’re the second mainainer of a project. The first maintainer is usually the creator of the project, so the bar for that is “donating enough time to create the project in the first place”, but the second maintainer is actively chosen and is held to a higher standard.

Code Shelter

I realized that this was an idea worth trying, and that it wouldn’t take too much time to set up an initial version, so I set off to create what became Code Shelter, a community of vetted volunteer open source maintainers.

Code Shelter aims to be as open as possible, while still fulfilling the criteria of a good maintainer that I detailed above. The idea is that the community will consist of maintainers and projects. The maintainers go through a vetting process that verifies the above criteria and ensures that only trusted and experienced people become part of the community. The projects don’t go through vetting, but can be added to Code Shelter at any point.

A maintainer who needs help with a project of theirs can add the project to Code Shelter by giving the latter admin access, and every maintainer in the community will be able to commit to the project, merge pull requests, respond to issues, release new versions, etc. Of course, Code Shelter can’t guarantee that the project will find a maintainer, as it’s on a volunteer basis, but it does make it trivial for interested people to start contributing to a project right away.

Right now, Code Shelter has a good number of maintainers and some projects, but the goal is to expand to both more people and more projects. It has been working quite well so far, and one success story that made me particularly happy is that the maintainer of mpfshell agreed to add the project, so I spent a few hours merging pull requests, fixing bugs, developing new functionality and releasing, and I’m happy to report that now mpfshell does include automatic compilation before upload.

The longer-term intent is that enough projects and maintainers will have joined CS that, when someone qualified stumbles upon an OSS project they’re using and realize that it’s been abandoned, both they and the project will be members of Code Shelter, and they will be able to improve it immediately.

Challenges

This model has some significant challenges to overcome, not the least of which is the worry over a compromised maintainer, like what happened with the event-stream npm package. There, the maintainer did not want to work on the project any more, someone contacted them offering to help maintain it, they accepted the offer, but it turned out that the person was malicious and had included malware in the package, compromising the computers it was installed on.

When I read the original maintainer’s response to the incident I was moved, and it struck me as a sensible response in an unfortunate situation. They are just someone whose project got a lot more popular than they expected or intended, they didn’t want the burden of maintenance any more but they also didn’t want to abandon the project and leave their users stranded, so they did the best they could and handed it to someone else. They couldn’t really have known that this someone was malicious, and it’s unfortunate that this isolated incident erodes trust in open source and offers of maintenance.

I believe that Code Shelter is a very good solution to the above. If it existed at the time, the maintainer wouldn’t have to trust the first person who offered, and would be able to leave the vetting to the community instead, avoiding this incident. CS is even more important in the case of projects whose maintainers never get an offer from anyone, and thus just abandon the projects completely.

A broader issue is one of trust and questions of control. If you actively maintain a project but still need help, Code Shelter is a great solution for adding experienced eyes and hands, but how can you trust the new people? Not only in trust in the sense of malice, but also in the sense of trusting their abilities from a product roadmap perspective, since you want some assurance that the project won’t suddenly veer off in a completely different direction.

I struggled with this a bit myself when adding my projects to CS, but then realized that I trust every single one of the maintainers to work on any of my projects. Ultimately, though, this is a point that needs to become a part of the CS culture, ie respecting the wishes of the existing maintainer/owner/project lead when helping out, and the way to do this will be with both guidelines on how to work on projects and giving feedback to maintainers who don’t. Of course, this applies to a much lesser degree to abandoned projects.

The future

What excites me most about the future of Code Shelter is what I see as a shift in the open source model. The first step was opening up the code and letting people submit patches, and the second step was democratizing this development by making it trivial for anyone to contribute patches on GitHub, GitLab, etc, which the maintainer then triages and accepts. Code Shelter can be the third step in this evolution, by making it trivial to share triage and release privileges, which is currently the last point of centralization. The onus of deciding who is qualified shifts from the single maintainer to the community, with the advantages and disadvantages that entails, and ultimately reduces the bus factor greatly and enables much wider sharing of the responsibility of maintaining a project.

Ideally, project maintenance would become a wide community affair, where people would naturally be attracted to a few projects they liked and helped maintain them. The weight of qualifying people is thus greatly reduced, since everyone in the community is vetted and continuously evaluated, and of course removed if it turns out that they were malicious or otherwise detrimental to Code Shelter and OSS in general.

Epilogue

I am very optimistic about the project, and think it’s a great idea. I hope there will be enough uptake on both sides (projects and maintainers), and that maintainer vetting it will be able to scale to large amounts of people, but the only way to find out is to try to do it.

I would welcome any feedback on anything in this post or on the project, you can Tweet, toot, or email me directly, as always.