> ## Content Index > Fetch the complete content index at: https://connortumbleson.com/llms.txt > Use this file to discover other available public pages before exploring further. # Trusting an Open Source Maintainer - URL: https://connortumbleson.com/2025/04/07/trusting-an-open-source-maintainer/ - Published: 2025-04-07T02:30:12.000Z - Updated: 2025-04-07T02:30:12.000Z - Description: Open source packages always have maintainer(s) associated with them and generally you trust them. - Author: Connor Tumbleson - Tags: Technology ![](https://connortumbleson.com/content/images/2025/04/photo-1640030104754-0a33c686c533-1.jpeg) Photo by [Ronda Dorsey](https://unsplash.com/@thirtyspoke?ref=connortumbleson.com) / [Unsplash](https://unsplash.com/?utm%5Fsource=ghost&utm%5Fmedium=referral&utm%5Fcampaign=api-credit) Roughly a year ago we learned about the incredibly complex [xz malicious campaign](https://connortumbleson.com/2024/03/31/watching-xz-unfold-from-afar/) 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. ![](https://connortumbleson.com/content/images/2025/04/github-permissions.png) GitHub "Collaborators" 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](https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-user-account-settings/permission-levels-for-a-personal-account-repository?ref=connortumbleson.com). Now obviously we are skipping a ton of things here - you have a ton of flexibility: - Use a [Ruleset](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets?ref=connortumbleson.com) to enforce specific requirements prior to merge. - Use legacy [Branch Protections](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule?ref=connortumbleson.com) to require specific people to merge. - Convert to an [Organization](https://docs.github.com/en/organizations/collaborating-with-groups-in-organizations/about-organizations?ref=connortumbleson.com) 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. ![](https://connortumbleson.com/content/images/2025/04/patch-package.svg) [https://github.com/ds300/patch-package](https://github.com/ds300/patch-package?ref=connortumbleson.com) If I want the fix that I made in a 3rd party package - I have a few options: 1. [patch-package](https://github.com/ds300/patch-package?ref=connortumbleson.com) \- 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](https://connortumbleson.com/2021/11/08/malware-and-npm-packages/). 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](https://github.com/openai-php/client?ref=connortumbleson.com) 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](https://platform.openai.com/docs/api-reference/responses?ref=connortumbleson.com) 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. ![](https://connortumbleson.com/content/images/2025/04/github.png) [https://github.com/openai-php/client](https://github.com/openai-php/client?ref=connortumbleson.com) 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.