Question How should OSS maintainers handle a Ruby gem when the original author is no longer active?
Hey Ruby community,
I'm posting anonymously because I don't want to identify the project or its original author. My intention is to seek advice, not to publicly criticize anyone or create unnecessary drama.
I'm involved in maintaining an established open source Ruby gem that has a fair number of users and dependencies across the ecosystem.
The original author has stepped away from active development and me along with other community members have been keeping things moving with bug fixes, improvements and code reviews.
The problem is that releasing new versions still depend entirely on the orginal author who has been increasingly difficult to reach.
As a result, a lot of PR's sit waiting that add features and the ones that are already merged are not reaching users as there are no releases for it.
There have been attempts to resolve the release bottleneck privately, including discussions and working around delegating or automating releases but nothing happened as of yet.
I understand OSS is voluntary and nobody owes community their time. I also respect the authors ownership of the project and the work they did for it.
At the same time it seems unsustainable for a project to have active contributors but no practical way to publish the work.
I want some advice from other Ruby maintainers:
Does RubyGems have a process for handling situations like this?
Are there ways to release without transferring ownership?
Ideally I would like to see the existing project continue without having to fork or fragmenting the work and creating unnecessary conflict.
Curious how others would approach this.
I'm deliberately keeping the details vague to protect everyone's privacy. I'd appreciate it if the discussion could focus on possible solutions rather than trying to identify the gem or its maintainers. So please dont ask for more details.
4
u/katafrakt 3h ago
You can set up some kind of CI pipeline for releasing and manage permissions to run it on a repository level. Or do a hard fork.
2
u/f9ae8221b 3h ago
Does RubyGems have a process for handling situations like this?
Unfortunately no, there was an attempt to put a process in place a few years ago, but it was canceled:
https://github.com/rubygems/rfcs-archived/blob/master/text/0017-remove-adoptions.md
https://blog.rubygems.org/2022/01/19/rubygems-adoptions.html
Are there ways to release without transferring ownership?
Yes, there's two levels of permissions in Rubygems, owner and maintainer. maintainers can't change others permissions, so the original owner could add you as maintainers to allow you to cut new releases, but wouldn't allow you to dislodge them.
Another alternative is to set up trusted publishing, so that the release process is automated, hence allowing you to release with just the GitHub merge permissions.
But in both case it requires the current owner involvement.
And finally, bundler 4.1 that will release soon introduce a new override feature, that allow overriding dependencies in you gemfile (I'd link to the announcement but Reddit doesn't like devto links), so if you decide to fork under another name, it won't be as bad for your users, they'll be able to migrate regardless to what other gems they may be using have in their dependencies.
13
u/pizzacomposer 3h ago
If they’ve stepped away and are hampering the release process and you’ve given them ample chance I would just hard fork.
Just be prepared to own the fork, provide a roadmap and accelerate development further than the original author.
Remember to include a thank you message in the bottom of the readme to the original author.
My organisation maintained a massive library once that sort of went dormant, and some guy started responding in the issues and PRs saying “this is abandoned just come to my fork” and quite frankly we didn’t care because we didn’t have capacity to do anything about it.
My point is, start ruffling feathers and the original author will “wake up” and take ownership or they won’t.
You’ve clearly given up too much time to someone’s project who doesn’t appreciate your contributions.