Initial ruby/rubygems governance doc

[schneems]

As a followup from https://www.ruby-lang.org/en/news/2025/10/17/rubygems-repository-transition/

To provide the community with long-term stability and continuity, the Ruby core team, led by Matz, has decided to assume stewardship of these projects from Ruby Central. We will continue their development in close collaboration with Ruby Central and the broader community.

I'm taking on this role of of proposing governance as a member of the Ruby Central Open Source Oversite Committee, and Ruby 3.2+ comitter via the syntax_suggest library.

This provides a starting point for a Governance doc. It attempts to:

• Document the current state of norms with regard to Matz and Ruby core.
• Present a well-defined boundary between Ruby Central (RC) and the technical management of the ruby/rubygems repository. This is achieved by separating administrative access (ability) from decision-making capability. Under this model, Ruby Central would need to work through a core team (via norms/communication) for permanent changes.
• Establish an explicit security team that can make swift decisions regarding access and threats. For example, if Ruby Central believed there was an active threat, they would need the buy-in from the security team to temporarily remove someone and the buy-in from the core team to permanently remove someone.
• Tighten norms around commit access and "active" status. While it's common for some Ruby open-source projects to have inactive members for many years, this project has a very large surface area that affects all Ruby users and the RubyGems.org service. I am seeking a stricter set of norms. Commit access can be a point of pride and identity for developers; to that end, I'm suggesting adopting a way to memorialize that status via an "alumni" status.
• Separate development from release capability.
• This document was reviewed and approved by the RC board. It was previously shared privately for feedback with Ruby core contributors (specifically, @hsbt, who is listed as the Ruby integrator of RubyGems) and with a maintainer of ruby/rubygems @colby-swandale, who had commit access prior to the repo being moved from rubygems/rubygems and has commit access now.
• This document is intended to be provisional, with an explicit mandate to replace and re-draft governance written in the doc.

[indirect]

@schneems who, exactly, did you reach out to? Since you did not reach out to me, I do not want to be included in your summary of "the group".

[colby-swandale]

Could we clarify what 'in public' means? I'd suggest defaulting to https://github.com/ruby/rubygems issues/discussions unless the matter involves Ruby core integration, in which case https://bugs.ruby-lang.org/.

[simi]

I've also reached out to several of the group of six who identify themselves as "the maintainers." The ones I spoke to expressed that they're unhappy with the communication and how events unfolded, and don't wish to work for or with RC. They're not willing to accept access as it's been offered. I understand that they've moved on to gem-coop and spinel-coop.

@schneems this part deserves update after our call. 🙏

[jeremyevans]

@schneems asked me to provide feedback on this PR. Note that while I've contributed to rubygems in the past and recently, I'm not very active in the project. Please consider these as recommendations from an outsider with significant open source experience, but not significant experience with rubygems itself.

In general, I think this governance document is a step in the right direction. It does seem overly bureaucratic to me at first glance, but that's probably because it is detailed and written down. While I generally prefer less bureaucracy, considering rubygems history, I think the level of bureaucracy is reasonable.

[jeremyevans]

I think ruby/rubygems should be treated similarly to other projects managed under the the ruby organization. I don't think rubygems should have non-committers with the ability to make access changes. This should be treated as an open source project, where the committers (or a subset of them) are in charge of handling access.

Just because RubyCentral hires someone shouldn't allow them to be granted access rights, nor should access rights be removed just because RubyCentral no longer employs the person. This is rubygems, not rubygems.org (I think these employment conditions would make sense for rubygems.org). I'm grateful for RubyCentral's funding of rubygems development, but funding should not imply control.

All rubygems committers should work from the perspective of improving rubygems, and should not make any changes to rubygems based on direction of Ruby Central or any other party unless they would make the same changes based on their own judgment in the absence of that direction. In terms of work on rubygems, all committers should represent themselves individually and not represent their employer or any other party.

[martinemde]

@jeremyevans well said.

[schneems]

High level, I agree. As written Ruby Central CANNOT install someone just because they're paid by "Ruby Central." But it's also important to me to have them represented as an interested/invested party in some way.

Sorry for the wall of text, I want to be thorough in presenting how I'm thinking:

I spoke to several people with detailed knowledge of the Rust Foundation setup with crates.io and cargo. It's not a 1:1 scenario due to some structural differences (501c3 versus 501c6, etc.), but generally, my takeaway there was that neither crates.io nor cargo has any hierarchical power over each other, and the foundation does not set technical direction. If crates or cargo want something, they have to get it via talking and communication. (for instance, if some change requires coordination, like the format of an index or the structure of some API). If they cannot come to an agreement, the Rust Foundation provides professional 3rd-party mediation services that they will pay for to help move things along (though this is not a common need AFAIK). If anyone has contacts at PSF, I would love to talk to them to compare/contrast.

For my personal experience, my open source work and salary are not unrelated, but my day job does not control Puma or syntax_suggest, for example. I have sprints where I say what I'm working on, we have kanban, and tickets. I can make the case that something is better fixed upstream or that I need time to make a solid reproduction or test case. I have accountability to them in that I must be able to justify why I think it's related. It's not appropriate for them to say "you must push feature X into repo Y." I get some misguided requests from time to time where individual co-workers might want me to fix something at the wrong upstream level (like pushing a feature to a repo instead of making a new library). In those cases, I help explain the situation and explore ways to get what they want in an appropriate way. If I can't justify company time, I'm not blocked from open source work, it's just not "funded," and I cannot say to my manager, "can't ship this huge company priority feature right now, there's a typo in a readme." (hyperbole) So that work would be delegated to nights/weekends/lunches.

Obligatory...I do not speak for Heroku or do this work on their behalf. I have an Outside Business Agreement with Heroku/Salesforce regarding Ruby Central foundation participation, basically a doc that says "we acknowledge this relationship and explicitly say it's okay to continue and that it's NOT done on behalf of the company. It is common for any structural involvement with ANY foundation or something like writing a book (I have an OBA for that too). I'm using Heroku as a concrete example I'm familiar with.

Funding example

Now, it helps to be specific with a type of thing that Ruby Central would want to influence and help make happen. The Open Source Security Foundation (OpenSSF) has a security maturity model https://repos.openssf.org/principles-for-package-repository-security.html with levels 0 through 3. To make the example easier, let's pick a specific feature already present

The package repository supports strong multi-factor authentication (MFA)

While MFA on the service is nice, we use CLI-based publishing tools to that service that are shipped through rubygems/bundler. I (personally) believe that ergonomics matter in security and that you need to make doing the right thing easy. Therefore, it's plausible that Ruby Central would invest in getting MFA support in bundler/rubygems (if it didn't already exist). Focusing on the bundler side (since it's this repo).

In that scenario, Ruby Central (a non-human entity) can act through its employees and members to:

• Have an employee or member reach out (communication) to understand blockers and chart a path forward
• Advertise and advocate "MFA is the future" via blog posts, conference talks, etc.
• Send a PR (if one of those employees is technically capable and it fits within the "kanban" of their priorities), or open an issue to talk about it first if that's preferred.
• Hire a consultant to do the coding work and make a PR.
• If a member or employee has commit, work with them on the most appropriate path forward. Possibly, they do the work. Possibly they socialize "hey my co-worker X, without commit is sending this PR that I care about, I'm going to review it, LMK if there are concerns or if you want more time to discuss."

The rules of regular open source repos still apply. Users and the community are centered first, then take care to respect limited resources (like maintainer time and attention). We all care about performance, maintainability, security, etc.

How foundations influence things

Stepping back, with this example, the idea is more or less that RC's influence comes through how it spends its time and attention on members and paid employees (or contractors). As opposed to giving RC direct authority, such as "ruby central always maintains one core team seat" (I think that would be a bad idea). It's also important to me that Ruby Central spends funds in other ways that support contributors/maintainers in ways that also help it meet its goals. For example, if a big feature lands but that contributor's company cannot pay to send them to a conference, maybe RC helps with the travel and asks for a "thank you RC" slide in exchange for that sponsorship.

Money can solve problems, it can also make new problems. I didn't put it in here, but I love this framing from Laurence Lessing (creator of Creative Commons):

Lessig (1999) identifies four elements that regulate behavior: Laws, norms, markets, and technology

• Code/architecture – the physical or technical constraints on activities (e.g. locks on doors or firewalls on the Internet)
• Market – economic forces
• Law – explicit mandates that can be enforced by the government
• Norms – social conventions that one often feels compelled to follow

Governance (IMHO, despite the name) is about establishing norms and recognizing other forces. Versus an example of a law would be a United States ITAR export control regulations.

Money is all about transactions. In a transaction, the books are cleared and everyone is made even. Open source and community work is about relationships where there's debts (good and bad). Pairing money with open source makes things more complicated as it's mixing transactional with relational. That's why clarity and transparency are important.

It's also important to recognize the perspective of the person getting paid:

For example, if someone sends a PR, are they taking away "hours" from someone already getting paid to work on it? If Ruby Central contracts with a developer to ship features, and they become well-known. Is it okay if another company also hires that contractor to do work in the same codebase or are they going "around" Ruby Central? If a company hires a maintainer as a consultant to work on a feature and that contract doesn't work out for some reason, is it acceptable if one of their employees works on it and sends a PR instead? From the governance perspective, bundler, the project, shouldn't have to worry about answering these questions.

But I want to advocate my position:

Ruby Central should not be in the business of selling access. It should be in the business of helping as best as it's able to, just like any other contributor, which brings me to a VERY important point:

• This is a project for the community: Community contributions are ALWAYS welcome and appreciated.

The best work comes from many eyes and many hands. Open source is powerful, not because it's free (gratis) but because it's got the best eyes in the world looking at it (because all eyes in the world can look at it).

This is me rambling a bit, but coming back to this:

funding of rubygems development, but funding should not imply control.

I agree, and the inverse should be true as well. Control should also not imply funding. Control should not be a prerequisite for someone to work for/with Ruby Central (or any other org, institution, or company that is willing to have a "bundler" kanban card on their board). In that way, I don't want it to be different than "normal" open source. I want it to be like how it works with Heroku and Puma. Ruby Central is special in that its name is in this doc. It has more of a relationship with the core than ACME Corp does (fictional example). But that is a relationship and not decision-making power.

[jeremyevans]

Currently, this has the security team only "advise" on security issues. It should be the security team's responsibility to fix/address security issues, not only advise of them.

Most of this section involves access, which I don't think is appropriate. My assumption is that any committer can make recommendations to the access team, and it is up to the access team to act of them. The security team should focus on code security, not on access issues. The members of the security team should not have permissions to add/remove accounts (unless the person is a member of both the security team and the access team).

[schneems]

unless the person is a member of both the security team and the access team).

Exactly that.

The original basis of this design is "role based access" (RBAC) https://en.wikipedia.org/wiki/Role-based_access_control. Different roles have different powers. So someone could be security + access or just security or just access.

I originally took this to the extreme, and had "core" not require access at all. This is similar to Rust's crates/cargo teams where someone invested and willing to help can show up and they can have an impact even if they don't have commit or haven't contributed any code. Under that model, someone could be on "core" would have the power to vote on who becomes a committer even if they themselves are not a committer. (i.e., it's not strict inheritance hierarchy).

I got feedback that the nuance was confusing for core, so I took it out there, but left it in for other areas. I wanted to have the ability to have a large security team with many eyes, without having to increase risk/attack surface area of giving everyone admin.

It's not explicitly called out in the doc, but there are some checks and balances I tried to bake in:

• Core members can remove someone from core, but need another party's access to actually remove their access.
• Security members have the authority to remove access (not status) from a core team member, but need another party to remove the access
• Access members have the technical capability to remove anyone, but no authority to do so without explicit command of another party.

At the end of the day I want to balance having some formality and explicit structure without having people feel like they need a hall pass or to read the bylaws to take a bathroom break. I'm also not actually on any of these teams nor am I on the Ruby Central board. And I'm sort of acting as a mediator and having to guess at where the line is (saying too much or saying too little).

[schneems]

@simi I understand that you want to air grievances. I feel you've made your position well-known. We've discussed the wording in my description privately, and I feel that's a better location. I don't think this is helping to move things forward, but I wanted to respond to your questions about me in public (but also hidden).

Off-topic response to your comment

I was never contacted, and I never rejected any access.

According to the access logs you removed access from yourself on 9/23/25, you were never removed:

• action: org.remove_member, timestamp: 9/23/25 20:28:05 UTC actor: simi, user: simi

Access logs cover all of September. Neither Shibata-san, nor Marty, nor anyone else touched your access. Not on September 9th, not on September 18th. The only person to remove your access was you. That might be related to why no one has ever asked you to come back, several hours prior to removing your access, you also posted you were "leaving Ruby Central" indicating your access had been taken.

On December 12, you messaged me about my PR for governance, stating you wanted to talk. I thought that meant you might be interested in helping to "bury the hatchet" and bootstrap "core" at best, or, at worst, you were pissed and wanted to vent. I was hesitant about reopening wounds and didn't want to lead with that agenda. I could tell from everyone's blog posts that they were mad, but thought that if I could sit with that anger for a while, I could maybe help something heal.

On December 15th, 2025, 23:30 UTC, we had a call. I believe you're in the CEST (UTC +1) timezone, which would put that at about 11:30pm your time, which is quite late. In this call, I believe I asked:

Would you accept commit?

(or a close variation.)

You did not directly answer; you deflected and brought up preconditions. Perhaps you missed the wording, or since it was so late, forgot that specific question, but it was a key goal of the conversation going in. I understood the precondition list to mean that you would not accept commit (only) unconditionally. I didn't think I needed to change the wording.

After the call on December 17, 2025, you posted (above)

"@schneems this part deserves an update after our call. 🙏"

And quoted my mini-recap of "where we're at." This surprised me. I looked long and hard at my wording. I realized I asked "willing to accept commit" rather than actually ... offering commit (a power I do not directly have). So I made this change: "They're not willing to accept access as it's been offered discussed." On December 20th, 2025 I messaged a gem.coop member about it (but not you) to get a second opinion on the wording.

I had not offered commit access, but we did discuss it, and it was my understanding that commit (alone) would not be accepted. This also matched my understanding that on 9/19/25 1:53:25 UTC an org invitation (org.invite_member) was given to one current gem.coop member who previously lost access. This invitation was retracted on 9/24/25 1:07:58 UTC as it had not been accepted, and when I followed up with them, they expressed a much smaller subset of pre-conditions.

I left my original wording intentionally vague rather than enumerating the preconditions listed for accepting a commit. I wanted to acknowledge the situation without feeding into it or reopening wounds. I generally try to "say less or say more" and have a hard time enumerating your position (and you did not offer me an acceptable wording alternative) than to list your preconditions.

These preconditions were stated during our call on December 15th, and you reiterated these points again over the coming days in chat. I've also heard similar sentiments listed from at least two total gem.coop members.

Summarizing the preconditions you (and others) have stated. You:

• Rejected the notion of "just commit" on bundler
• Desired for this repo to be returned to the rubygems org.
• Reject the notion that Matz has ANY say over the direction of the bundler/rubygems codebase or other codebases in the rubygems org and that you believed that previously he was beholden to final decisions made by "the maintainers"
• Demand that the github.com/rubygems org access should be returned to its prior state with the implication that:
  • The gem.coop maintainers have total control over all codebases, including the RubyGems service
  • That Ruby Central should use this codebase to run RubyGems.org, and if they want or desire any changes, they can send a PR and that will be evaluated and unilaterally accepted or rejected by gem.coop maintainers. Or that they can fork-it.
• Want to see some kind of retributive punishment for Marty and Shibata-san (re-iterated above)

In addition, you've expressed that the reason you commented initially was to delay or stop the governance process from moving forward. This seemed like a counter signal to the co-signed "We want to move Ruby Forward" blog post, but I believed at the time that you were venting/grieving the loss of access that was taken from you.

I don't appreciate how you've misrepresented some key facts. Privately, you expressed emphatically that access had been taken away from you, and no one had offered to return it to you. My heart. So much. I told several people, including another gem.coop member I was waking up at 3am after our conversations. Unable to get back to sleep. After your Reddit comment yesterday, I decided to check on the timeline via access logs, and found out that you removed yourself. Which does not feel like you've been engaging truthfully with the community or me, in good faith.

I can understand vaguely that you're generally fighting "for everyone else," and I can see nuance in your position. But everyone has been hurt here, and no one is happy. The community is hurting, Ruby is hurting. I didn't plan on moving this reply to a public venue, and I don't think the Ruby issue tracker is the place to re-hash things.

Since I've spent more time on this part of the description than the rest of the doc combined, I've removed the mention of gem.coop members from the description, which can help get this back on track.

[noteflakes]

Why is Ruby Central mentioned at all in this document? I believe this is a valid question both on principle and in practice. Being that the project is now under the ruby org, why does Ruby Central still hold special status?

[schneems]

From the description:

As a followup from https://www.ruby-lang.org/en/news/2025/10/17/rubygems-repository-transition/

To provide the community with long-term stability and continuity, the Ruby core team, led by Matz, has decided to assume stewardship of these projects from Ruby Central. We will continue their development in close collaboration with Ruby Central and the broader community.

I said more here #9187 (comment). I feel it's important though to represent that RubyGems.org has some stake in this project: Beyond just pulling from the service bundler and rubygems CLIS are the de facto client interfaces for pushing artifacts to RubyGems.org. Also that Matz and Ruby Core have vested interests in RubyGems (as they're vendored with Ruby).

For some context of where I'm coming from: I've been working on other governance and started the idea of firming up the Puma support docs a while ago. In the support docs, we say we explicitly support some things (operating systems, Ruby versions, etc.) because we depend on them. But there are other things that depend on US that we care about, such as stability with Sinatra or Rails. On the one hand, it is impossible to list all your dependents. On the other hand, it reflects the state of reality even if it's not exhaustively enumerated.