Trusting an Open Source Maintainer

Roughly a year ago we learned about the incredibly complex xz malicious campaign in which a presumed nation state attacker throughout years built up reputation in an open source project to secretly inject a backdoor into the SSH process. Once trust was established and he could author work without a forced review of another - the slow process began to create a backdoor secretly in the public light.

Of course we know how this story ends with the detected hit to performance in testing which led to this massive discovery and unraveling.

I started thinking about this as someone who maintains open source software and as someone who consumes a ton of open source software whether via hobby projects or work. From my perspective as a hobby project maintainer I have a huge issue in trusting others with the ability to push code / cut releases without my approval.

This is mainly due in part to how GitHub handles collaborators on open source projects personal projects.

A repository owned by a personal account has two permission levels: the repository owner and collaborators. For more information, see Permission levels for a personal account repository.

Now obviously we are skipping a ton of things here - you have a ton of flexibility:

• Use a Ruleset to enforce specific requirements prior to merge.
• Use legacy Branch Protections to require specific people to merge.
• Convert to an Organization for a more refined permission system.

Some of these are gated a bit by requiring payment or even an enterprise account, but GitHub has increased the functionality it offers to make sure you can grow the collaborators on a repository in baby steps.

So lets take a story of a common situation.

1. Find a great open source package to solve a problem.
2. Include said package and reap benefits for x time.
3. Encounter an issue and fix it up - make a pull request upstream.
4. Change sits and sits until you decide to implement an alternative system (patch files, fork, switch packages, etc)

More often than not I sit looking at a list of pull requests I've opened across tons of repositories that just sit. Its free work given to work managed for free - I don't expect anything done, but this puts me in a situation.

If I want the fix that I made in a 3rd party package - I have a few options:

1. patch-package - basically automates applying .patch files to a repository.
2. Fork the repository.
3. Switch to a different fork of the repository.
4. Switch to a completely different package that solves the same thing.

If I apply a patch file I'm generally growing a little bit of tech debt as I hope with every release of said software that my patch file continues to work, but more than not those patch files evolve into forking the project.

Once I fork the project - the progression of that project starts/ends with me. I forked it for a reason to solve an issue, but outside of that unless I give it effort - it sits where I left it. I become the maintainer for that fork of that project. Some of the community may switch to my fork of the original package and they assume a large amount of trust that I won't do anything to revoke that trust. Hopefully in time I can move back to the original project, but the original repository may be on its way to the "abandoned" status.

If I switch to a forked iteration of a package I'm trusting that new maintainer a lot. Which is hard these days when you hear on Hacker News every so often about a package slipping in some malware. It might not be the person, but you trust how well a maintainer can keep their account secure just as much as you trust the person.

A few weeks ago I was looking to see if the new Responses API from OpenAI was supported in the PHP iteration of the OpenAI SDK I use. Sure enough I find a thread and people are discussing just that.

Is this on anyone's radar? Looks like better tools and a push for agents. Built in web search tool now, gotta love that. Goodbye brave and perplexity, maybe?
https://platform.openai.com/docs/api-reference/responses

Someone unrelated to the project responds that they are working on it, but in a completely different repository. I click on and its a seemingly brand new GitHub account - 1 follower, 0 following, made in late 2024 and it just doesn't feel like something I want to trust. Since I would expect an engineer working in this day n age to have a more established GitHub account. Yet I'm in another position like I described above - my pull request sits without a merge as time goes by and I need to make a decision.

This time I feel AI isn't going away anytime soon and working in PHP is my perfect fit. So I send an email to the maintainers asking for collaborator permission to give this repository some more community involvement.

About a month later they accept, with the caveat "Start slow, I'll feel more confident trusting you with bigger changes."

I won't let that trust down and I'm hoping my established GitHub profile and decade history of releases from Apktool to Leaf resulted in establishing that trust. In this stance I don't need to make a fork - my fixes are merged and I can improve this library with the help of the community.