Helping out Open Source

I've blogged about open source development a lot - whether from the entitlement you see day to day or the funding aspect. This time I want to dive into how I've recently started helping projects I depend on.

I've often fallen into a situation many times where a package I depend on seems to have stalled out with maintainers. In this situation I'm not even referring to unanswered bug/support tickets - I'm referring to opening a pull request to fix an issue and it sits and sits and sits forever.

You as a developer have plenty of options in this situation to workaround this delay:

• You can fork and fix. By "forking" you can depend on your iteration of the repository and move on.
• You can leverage "patch-package" which can apply patches on a top of a dependency prior to usage.
• Some package managers between different languages allow you to point that dependency to your branch/change.

All in all any of those options incur an amount of tech debt. Does anyone really want their project to have a ton of dependencies all pointing to specific commits of random engineer's copies?

In some situations maybe the dependency you depend on is so important to your project you have no choice but to fork it and support it. You can look back at the years prior and wonder - "If I needed this package so bad, why didn't I support this project?". These are all questions that eat at you for every single dependency choice.

An example I like referring to is Laravel adding a new PHP version as supported. Laravel generally depends on a ton of software that they don't control. When a new PHP version comes out - they go into the ecosystem helping gift fixes to projects they depend on. This is a financial donation in a way as an engineer's time is spent adding support to a dependent project.

In some situations during this effort they may find a project is simply not reacting to their work and it stalls out - blocking their upgrade effort. This may result in monetary donations to entice a maintainer to support, asking to join the efforts with elevated permission or just forking and moving on. A perfect example of this was when fzaninotto/Faker went abandoned so Laravel helped start a generic organization FakerPHP with maintainers from different frameworks across the ecosystem of that forked package.

So throughout work we've done our fair share of donations and forking, but I wanted to try something different as I encountered delays in OpenAI for PHP and fastlane merging fixes we required. I wanted these projects to succeed, but if donations didn't help and contributed code didn't help - it was time to try something else. The OpenAI for PHP SDK was missing the massive new OpenAI endpoint (Response API) and fastlane was generally just decaying hard when it came to new iOS changes and Xcode 26. Even the community in both of these situations were wondering the same as myself.

I just emailed the maintainer(s) and asked to become a maintainer myself. In both cases after a mini "vetting" I was given permission on both organizations to help out. I understand the delay from the maintainers, because it takes a lot of trust to share your project with another person. We've seen countless times that trust be abused for malware, destruction or more. So with roughly a month of time of waiting or vetting I was able to get to work helping out.

In terms of the PHP project the biggest helping point was enabling CI runs for other contributors. What I mean by that is GitHub by default will not execute CI pipelines for untrusted code unless manually approved or that author has had merged code prior. This prevents malicious accounts from opening changes that just mine Bitcoin on your CI system. So the biggest support I gave the OpenAI in the beginning was just peeking pull requests and enabling the CI to run.

Authors would get emailed as the build failed and they would iterate. A simple button click led me to pull requests that were closer to ready than prior. I knew when I was contributing code that waiting for days or weeks to just see if my code passed the CI pipeline killed all progression I had for that contributing that fix. So I wanted to make sure that folks dedicating time to support the project were quickly supported on their changes.

For this project I noticed the decay in early 2025 and I was added in April of 2025 so once I felt more comfortable with committing changes I had to get to work cutting a release. Thankfully for a PHP project this is nothing more than a change log update and a tag. So I cut some releases and got into a good pattern adding all the needed fixes and features that our clients depended on, while putting some time aside to merge community fixes.

• v0.13.0 - May 14, 2025
• v0.14.0 - June 24, 2025
• v0.15.0 - August 4, 2025
• v0.16.0 - August 26, 2025
• v0.16.1 - September 4, 2025
• v0.17.0 - October 2, 2025
• v0.17.1 - October 9, 2025
• v0.18.0 - October 31, 2025

I was happy this one worked out as well as it did. As the project has stabilized and all OpenAI endpoints are covered so I can slow down the release pace and probably aim for a monthly bug fix release. That extra free time gave me the courage to see if I could join the team of fastlane.

When I started researching how fastlane is managed I was surprised to learn the scale of all the repositories and organizations it has. For an end user previously just using a single gem I was quite unaware everything else fastlane had to offer. For a small breakdown you may find these projects at the center of fastlane development.

• fastlane/fastlane - The unified repo for all modules.
• fastlane/docs - The documentation
• fastlane/fastlane-sirp - The forked "sirp" plugin for Apple auth
• fastlane/github-actions - The CI "bot"
• fastlane/fastlane.tools - The website
• fastlane/frameit-frames - The frames for "frameit"
• fastlane/docker - The CI Docker image
• fastlane-community/* - Plugins fastlane oversees.
• + many many more.

This was quite a collection of plugins, tooling and projects. However, with nearly 20 maintainers I figured things were covered. Maybe as Felix stepped back in 2019 (the creator) and Josh (the lead) no longer was paid in November of 2021 perhaps led to the slow decline of the project. It may have also been Google holding the IP, the credit and the brand yet doing nothing in return.

In February of 2023 hope had started with a thread spawning on Mobile Native Foundation urging Google to give up fastlane and give it back to the community. In October of 2023 that was actually approved by both organizations. Though as the clock ticked into 2025 not much had changed. Google references were all over the codebase. CI systems had decayed and even with a staggering amount of maintainers the open issue count across all repos exceeded 1,500.

So I was excited when I got a response from a maintainer that I had been added and could get to work. With this organization though you always need a reviewer on each change unless you are an owner and allowed to bypass it. In the circumstance of OpenAI for PHP I had elevated permission to merge what I needed without another reviewer. This worked great as I respected the boundaries and only merged things I felt safe merging which allowed me to move fast on pulling the repository out of abandonment.

On the fastlane side - I'm stacking PRs across so many repos right now its getting difficult to follow. When another maintainer comes along to give an approval or feedback I'm moving again, but the speed of requiring another reviewer it'll take some time. Even if you get needed approvals some of the deployment mechanisms to RubyGems, Docker or Netlify are housed under a single individual. This means you gotta track down that one guy holding the key and ask for support to push a project forward.

So my first chunk of work has been entirely driven by CI/CD systems. Since a good chunk of my job at work is CI/CD systems - its quite natural to evolve an organization to a secure pipeline that can survive with OIDC deployments to not have a dependency on any single person.

I cut my first fastlane release (v2.229.0) on November 21, 2025 and it failed during CI. It took a quick fix to workaround OpenSSL 3.6.0 changes, but then it was released! Unfortunately it was still not perfect with Ruby 3.4, but I quickly submitted a PR intended for a patch release and augmentation to test suite to prevent it. The speed here is slower than I'd prefer, but in time I'm hoping to contribute a fully automated CI & CD system to the entire fastlane organization.

So while I've forked a few repositories, donated to entice fixes and patched my way to success. I'm having fun with this new way of getting fixes done by just joining the project directly and working towards success for the greater community.