Proposal: Maintainable binary gem ecosystem

I want to propose the "maintainable binary gem ecosystem" concept.

Background

Currently, binary gems are maintained by gem maintainers. For example, Nokogiri's binary gems are maintained by Nokogiri maintainers.

Target platforms for binary gem are increased. It also increases maintenance costs of gem maintainers. For example, Nokogiri 1.19.0 provides 9 targets:

https://rubygems.org/gems/nokogiri/versions

• aarch64-linux-gnu
• aarch64-linux-musl
• arm-linux-gnu
• arm-linux-musl
• arm64-darwin
• java
• x64-mingw-ucrt
• x86_64-darwin
• x86_64-linux-gnu
• x86_64-linux-musl

I want to reduce maintenance costs of gem maintainers as much as possible to help gem ecosystem thrive. If maintenance costs of gem maintainers is higher, new gem maintainers may not be increased and current gem maintainers may stop maintaining. It may stagnate gem ecosystem.

Proposed solution

The "maintainable binary gem ecosystem" concept shares maintenance costs of binary gems with community instead of maintaining only by gem maintainers. Binary gems are maintained by others (not gem maintainers) like other package repositories such as Linux distribution package repositories (e.g. Debian's APT repository, Fedora's Yum repository, ...) and Homebrew. These package repositories are maintained by these package repositories' maintainers not upstream maintainers. I want to use this approach for binary gem ecosystem for maintainability.

How to implement the proposed solution

To split maintainers of source gem and binary gems, we need separated "gem owners" (who can push new versions) groups. Currently, rubygems.org has one "gem owners" group per gem. So we can't use the current rubygems.org features as-is to implement the proposed solution.

Here are some implementation ideas to split maintainers of source gem and binary gems:

1. Use separated RubyGems repositories instead of using only rubygems.org
2. Improve rubygems.org

1. Use separated RubyGems repositories instead of using only rubygems.org

If we use separated RubyGems repositories for binary gems, we can split maintainers of source gem and binary gems.

Gem maintainers pushes source gem to rubygems.org. Binary gem maintainers build binary gems from the source gem and push these binary gems to a separated RubyGems repository. rubygems.org and a separated RubyGems repository can use different "gem owners" groups. (Gem maintainers can push to rubygems.org but can't push to a separated RubyGems repository. Binary gem maintainers can't push to rubygems.org but can push to a separated RubyGems repository.)

For example, we can use GitHub's RubyGems repository feature: https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-rubygems-registry

If we want to create binary gems maintainers for Ruby 4.0 on Ubuntu 24.04, we can create the "rubygems-ruby-4.0-ubuntu-24.04" GitHub organization and add maintainers to the organization. Maintainers can push binary gems for Ruby 4.0 on Ubuntu 24.04 to https://rubygems.pkg.github.com/rubygems-ruby-4.0-ubuntu-24.04 RubyGems repository.

Ruby 4.0 on Ubuntu 24.04 users can use binary gems by the following Gemfile:

source "https://rubygems.org"

source "https://rubygems.pkg.github.com/rubygems-ruby-4.0-ubuntu-24.04" do
  gem "nokogiri"
end

gem "no-binary-gem"

There are some considerations for this solution:

• Users need to know which gem has a binary gem for the target (Ruby 4.0 on Ubuntu 24.04).
  • It may be inconvenient.
• Should we create binary gems maintainers per OS + OS version instead of Linux + libc variant (e.g. Linux + glibc, Linux + musl. This is "manylinux" like approach)?
  • In my opinion, yes. I want to split binary gems maintainers as much as possible to reduce maintenance costs of each binary gems maintainers.
• ...

2. Improve rubygems.org

npm has the "scopes" feature: https://docs.npmjs.com/about-scopes

It provides visibility and namespace. In this context, namespace is only important. If rubygems.org has the namespace feature, we don't need separated RubyGems repositories.

For example, we can create a @ruby-4.0-ubuntu-24.04 namespace for binary gems of Ruby 4.0 on Ubuntu 24.04. We can have separated "gem owners" for source gem (e.g. nokogiri) and binary gems for binary gems (e.g. @ruby-4.0-ubuntu-24.04/nokogiri) The "gem owners" of @ruby-4.0-ubuntu-24.04 namespace can push binary gems for Ruby 4.0 on Ubuntu 24.04.

The next step

I want to evaluate the proposed solution. I want to move some binary gem related features from rake-compiler to RubyGems for easy to evaluate. Here are features I want to move:

• Building a binary gem for the current platform
  • rake-compiler can build a binary gem for different platform but I don't need it in RubyGems
  • gem build --binary? It doesn't use fake.rb technique that mimics RbConfig. It just does gem install and package the installed one as a binary gem.
• ...(I may need more features)...

Start by reviewing the proposed separation of source and binary gem ownership, including the RubyGems repository and namespace approaches. Then examine rake-compiler's binary-gem capabilities and the proposed gem build --binary entry point; done means the maintainability proposal and the RubyGems features to evaluate have a clearly defined scope.