Rob Whittaker
boosted
🎉 alchemy_cms v8.0.6 has been released!
https://github.com/AlchemyCMS/alchemy_cms/releases/tag/v8.0.6
🎉 alchemy_cms v8.0.6 has been released!
https://github.com/AlchemyCMS/alchemy_cms/releases/tag/v8.0.6
Rob Whittaker
boosted
Contributing to RubyGems (.org)
A few months ago, I wrote about a move that bypassed the maintainers who had built the RubyGems and Bundler projects for decades. I had some questions about trust, governance, and whether Ruby Central could be a responsible steward of our community’s infrastructure.
So it might seem strange that I recently submitted a pull request to rubygems.org.
This post is about that contribution, but it’s also about a question I had to answer for myself: Why help a project when you have concerns about the organization running it?
The Short Answer: the code doesn’t belong to Ruby Central. It belongs to the community.
When I contribute to rubygems.org, I’m not endorsing Ruby Central’s past governance decisions. I’m improving a piece of infrastructure that every Ruby developer depends on, including me, including my team, including developers who have no idea any controversy exists.
The people reviewing my PR weren’t board members making decisions. They were developers like me, with their time spent making the Ruby ecosystem better. Withholding contributions punishes them, not the people who had made the past governance decisions.
The Problem That Got Me Involved
My team had adopted a shared GitHub Actions workflow for releasing our gems. Instead of duplicating release logic across repositories, we maintain one canonical workflow and call it a shared gem release, It’s similar to this:
# In my-gem/.github/workflows/release.yml
jobs:
release:
uses: our-org/shared-workflows/.github/workflows/ruby-gem-release.yml@mainClean pattern, common in organizations with multiple gems. One problem: RubyGems.org’s trusted publishing feature didn’t support it.
When you use a reusable workflow, the OIDC token from GitHub points to the shared workflow’s location, not your repository. RubyGems.org expected these to match. Our releases were failing. I needed to revert back the old flow, where we have slight release difference in each repo. Not ideal.
I found https://github.com/rubygems/rubygems.org/issues/4294 from 2023. No one had fixed it, yet.
Choosing to Contribute
I had options. I could work around the limitation. I could complain on social media. I could wait for someone else to fix it.
Instead, I decided to fix it myself.
Here’s my reasoning: Open source is bigger than any single organization. RubyGems existed before Ruby Central, and the codebase will outlast whatever governance structure exists today. Contributing good code, code that helps developers, is worthwhile regardless of organizational politics.
If you are going to contribute, you might as well do it well, so here are some tips doing just that and that I kept in mine with my RubyGems feature.
Structure Your Commits Like a Story
Maintainers review a lot of code. Help them follow your thinking: Clear summaries, explanation of why not just what, security implications called out, and reviewer contributions credited.
Write a PR Description That Respects Their Time
Your description is your pitch. Answer these questions immediately:
- What problem does this solve?
- How does it solve it?
- Are there security implications?
- How can reviewers verify it works?
Mine looked roughly like: Enables trusted publishing for gems using reusable workflows from external repositories
Short. Scannable. No mystery about what’s happening.
Tests Are Your Credibility
Comprehensive tests tell maintainers you’ve thought through edge cases:
The test names describe scenarios. A reviewer can understand what’s verified without reading implementation details. And the security test verifying that mismatched workflows are rejected, matters a lot for authentication code.
Receive Feedback Graciously
This is where contributing gets genuinely valuable. The reviewers know the codebase. Their feedback makes your code better.
I received two pieces of feedback that improved my implementation:
“The validation is tricky to understand. Could we use declarative Rails validations?”
My original:
def workflow_repository_fields_consistency
owner_present = workflow_repository_owner.present?
name_present = workflow_repository_name.present?
return if owner_present == name_present
errors.add(:base, "…")
endThe suggestion:
validates :workflow_repository_owner, presence: true, if: -> { workflow_repository_name.present? }
validates :workflow_repository_name, presence: true, if: -> { workflow_repository_owner.present? }Same behavior, more idiomatic.
“This query branch is unreachable given your other validation.”
Dead code I hadn’t noticed. The reviewer spotted that my .or() clause could never match because another validation prevented that data state from existing.
Both changes made the code better. I implemented them, credited the reviewers, and the PR was approved.
The Bigger Picture
After my code contribution was merged, I submitted a documentation PR to https://github.com/rubygems/guides explaining how to configure the new fields. Features don’t help if users don’t know they exist.
Now every Ruby developer using shared release workflows can use trusted publishing. That’s a small improvement for potentially thousands of people.
But here’s what I keep coming back to: the people who reviewed my PR, who gave thoughtful feedback, who approved and merged the changes. They’re developers who care about the Ruby ecosystem. They showed up, they did good work, and they made the project better.
Open source is ultimately about people, not organizations. The code is written by individuals. The reviews are done by individuals. The community is made up of individuals who choose to contribute their time.
Ruby Central’s past governance may have disappointed me. But the Ruby community hasn’t.
If You’re Hesitant to Contribute
Maybe you have concerns about other projects’ leadership. Here’s what I’d say:
Contribute to the code, not the org chart. Your pull request improves software that real people use. The maintainers aren’t the executives. Don’t punish them for decisions they didn’t make.
Find a problem you care about. Fix it. Submit the PR. The Ruby ecosystem, our community, is worth contributing to.
The PR discussed in this post is https://github.com/rubygems/rubygems.org/pull/6184. The documentation update is https://github.com/rubygems/guides/pull/410.
#code #ruby #rubygems
Contributing to RubyGems (.org)
A few months ago, I wrote about a move that bypassed the maintainers who had built the RubyGems and Bundler projects for decades. I had some questions about trust, governance, and whether Ruby Central could be a responsible steward of our community’s infrastructure.
So it might seem strange that I recently submitted a pull request to rubygems.org.
This post is about that contribution, but it’s also about a question I had to answer for myself: Why help a project when you have concerns about the organization running it?
The Short Answer: the code doesn’t belong to Ruby Central. It belongs to the community.
When I contribute to rubygems.org, I’m not endorsing Ruby Central’s past governance decisions. I’m improving a piece of infrastructure that every Ruby developer depends on, including me, including my team, including developers who have no idea any controversy exists.
The people reviewing my PR weren’t board members making decisions. They were developers like me, with their time spent making the Ruby ecosystem better. Withholding contributions punishes them, not the people who had made the past governance decisions.
The Problem That Got Me Involved
My team had adopted a shared GitHub Actions workflow for releasing our gems. Instead of duplicating release logic across repositories, we maintain one canonical workflow and call it a shared gem release, It’s similar to this:
# In my-gem/.github/workflows/release.yml
jobs:
release:
uses: our-org/shared-workflows/.github/workflows/ruby-gem-release.yml@mainClean pattern, common in organizations with multiple gems. One problem: RubyGems.org’s trusted publishing feature didn’t support it.
When you use a reusable workflow, the OIDC token from GitHub points to the shared workflow’s location, not your repository. RubyGems.org expected these to match. Our releases were failing. I needed to revert back the old flow, where we have slight release difference in each repo. Not ideal.
I found https://github.com/rubygems/rubygems.org/issues/4294 from 2023. No one had fixed it, yet.
Choosing to Contribute
I had options. I could work around the limitation. I could complain on social media. I could wait for someone else to fix it.
Instead, I decided to fix it myself.
Here’s my reasoning: Open source is bigger than any single organization. RubyGems existed before Ruby Central, and the codebase will outlast whatever governance structure exists today. Contributing good code, code that helps developers, is worthwhile regardless of organizational politics.
If you are going to contribute, you might as well do it well, so here are some tips doing just that and that I kept in mine with my RubyGems feature.
Structure Your Commits Like a Story
Maintainers review a lot of code. Help them follow your thinking: Clear summaries, explanation of why not just what, security implications called out, and reviewer contributions credited.
Write a PR Description That Respects Their Time
Your description is your pitch. Answer these questions immediately:
- What problem does this solve?
- How does it solve it?
- Are there security implications?
- How can reviewers verify it works?
Mine looked roughly like: Enables trusted publishing for gems using reusable workflows from external repositories
Short. Scannable. No mystery about what’s happening.
Tests Are Your Credibility
Comprehensive tests tell maintainers you’ve thought through edge cases:
The test names describe scenarios. A reviewer can understand what’s verified without reading implementation details. And the security test verifying that mismatched workflows are rejected, matters a lot for authentication code.
Receive Feedback Graciously
This is where contributing gets genuinely valuable. The reviewers know the codebase. Their feedback makes your code better.
I received two pieces of feedback that improved my implementation:
“The validation is tricky to understand. Could we use declarative Rails validations?”
My original:
def workflow_repository_fields_consistency
owner_present = workflow_repository_owner.present?
name_present = workflow_repository_name.present?
return if owner_present == name_present
errors.add(:base, "…")
endThe suggestion:
validates :workflow_repository_owner, presence: true, if: -> { workflow_repository_name.present? }
validates :workflow_repository_name, presence: true, if: -> { workflow_repository_owner.present? }Same behavior, more idiomatic.
“This query branch is unreachable given your other validation.”
Dead code I hadn’t noticed. The reviewer spotted that my .or() clause could never match because another validation prevented that data state from existing.
Both changes made the code better. I implemented them, credited the reviewers, and the PR was approved.
The Bigger Picture
After my code contribution was merged, I submitted a documentation PR to https://github.com/rubygems/guides explaining how to configure the new fields. Features don’t help if users don’t know they exist.
Now every Ruby developer using shared release workflows can use trusted publishing. That’s a small improvement for potentially thousands of people.
But here’s what I keep coming back to: the people who reviewed my PR, who gave thoughtful feedback, who approved and merged the changes. They’re developers who care about the Ruby ecosystem. They showed up, they did good work, and they made the project better.
Open source is ultimately about people, not organizations. The code is written by individuals. The reviews are done by individuals. The community is made up of individuals who choose to contribute their time.
Ruby Central’s past governance may have disappointed me. But the Ruby community hasn’t.
If You’re Hesitant to Contribute
Maybe you have concerns about other projects’ leadership. Here’s what I’d say:
Contribute to the code, not the org chart. Your pull request improves software that real people use. The maintainers aren’t the executives. Don’t punish them for decisions they didn’t make.
Find a problem you care about. Fix it. Submit the PR. The Ruby ecosystem, our community, is worth contributing to.
The PR discussed in this post is https://github.com/rubygems/rubygems.org/pull/6184. The documentation update is https://github.com/rubygems/guides/pull/410.
#code #ruby #rubygems
Cursed Bundler: Using go get to install Ruby Gems
https://nesbitt.io/2025/12/25/cursed-bundler-using-go-get-to-install-ruby-gems.html
#HackerNews #CursedBundler #Go #Get #RubyGems #SoftwareDevelopment #Programming #Hacks
🫧 socialcoding..
boosted
How to Host Your Own #Mastodon Server on a #VPS (5 Minute Quick-Start Guide)
This article provides a guide for how to host your own Mastodon server on a VPS.
Running your own Mastodon server on a VPS is an excellent way to enjoy an efficient and secure Mastodon experience.
What is Mastodon?
Mastodon is a #decentralized social media platform that enables users to post ...
Continued 👉 https://blog.radwebhosting.com/how-to-host-your-own-mastodon-server-on-a-vps/?utm_source=mastodon&utm_medium=social&utm_campaign=mastodon.raddemo.host #rubyonrails #selfhosting #rubygems #selfhosted #activitypub #installguide
How to Host Your Own #Mastodon Server on a #VPS (5 Minute Quick-Start Guide)
This article provides a guide for how to host your own Mastodon server on a VPS.
Running your own Mastodon server on a VPS is an excellent way to enjoy an efficient and secure Mastodon experience.
What is Mastodon?
Mastodon is a #decentralized social media platform that enables users to post ...
Continued 👉 https://blog.radwebhosting.com/how-to-host-your-own-mastodon-server-on-a-vps/?utm_source=mastodon&utm_medium=social&utm_campaign=mastodon.raddemo.host #rubyonrails #selfhosting #rubygems #selfhosted #activitypub #installguide
🫧 socialcoding..
and 1 other
boosted
How to Host Your Own #Mastodon Server on a #VPS (5 Minute Quick-Start Guide)
This article provides a guide for how to host your own Mastodon server on a VPS.
Running your own Mastodon server on a VPS is an excellent way to enjoy an efficient and secure Mastodon experience.
What is Mastodon?
Mastodon is a #decentralized social media platform that enables users to post ...
Continued 👉 https://blog.radwebhosting.com/how-to-host-your-own-mastodon-server-on-a-vps/?utm_source=mastodon&utm_medium=social&utm_campaign=mastodon.social #selfhosted #rubyonrails #installguide #selfhosting #activitypub #rubygems
How to Host Your Own #Mastodon Server on a #VPS (5 Minute Quick-Start Guide)
This article provides a guide for how to host your own Mastodon server on a VPS.
Running your own Mastodon server on a VPS is an excellent way to enjoy an efficient and secure Mastodon experience.
What is Mastodon?
Mastodon is a #decentralized social media platform that enables users to post ...
Continued 👉 https://blog.radwebhosting.com/how-to-host-your-own-mastodon-server-on-a-vps/?utm_source=mastodon&utm_medium=social&utm_campaign=mastodon.social #selfhosted #rubyonrails #installguide #selfhosting #activitypub #rubygems
"I am concerned that Ruby Central’s board with full knowledge of the consequences and the alternatives voted to take over a collection of open source projects from their maintainers without consent. Especially when these maintainers were acting in good faith at the time. This is the organisation we are meant to trust to host our Ruby gems."
#JoelDrapper, September, 2025
https://joel.drapper.me/p/rubygems-takeover/
If what Joel describes here is true, this is deeply fucked.
Agaric Tech Collective
and 3 others
boosted
The prospect of fashy RubyGems.org/Ruby Central getting displaced by a literal coop with a .coop domain name ( https://gem.coop ) is beyond entertaining for me. I am so excited. LFG
The prospect of fashy RubyGems.org/Ruby Central getting displaced by a literal coop with a .coop domain name ( https://gem.coop ) is beyond entertaining for me. I am so excited. LFG
Alex Akselrod
boosted
🔥 Breaking: Former #RubyGems maintainers have launched the Gem Cooperative, a community-run RubyGems server with open governance.
We spoke with the team behind it. Read the full story on the Socket blog → https://socket.dev/blog/gem-cooperative-emerges-as-a-community-run-alternative-to-rubygems-org #Rails #Rubylang #Ruby
🔥 Breaking: Former #RubyGems maintainers have launched the Gem Cooperative, a community-run RubyGems server with open governance.
We spoke with the team behind it. Read the full story on the Socket blog → https://socket.dev/blog/gem-cooperative-emerges-as-a-community-run-alternative-to-rubygems-org #Rails #Rubylang #Ruby
“we identified a small number of accounts whose privileges no longer matched current role requirements”
(We therefore removed everyone’s access.)
I don't know what the ultimate outcome for the #Ruby community will be from all of this Ruby Central noise.
I think the lesson to draw for everyone else is that if you're running something for a community's benefit it should be organized in a legally legible way with clear governance polices from the jump. Better still would be something with a strong legal framework like the PSF or the Open Home Foundation.
It should not be feasible for one asshole to coerce a takeover of a huge community resource like #RubyGems without lots of public brake pumping.