7 ms·

Our stewardship: Where we are, what's changing and how we'll engage

91 points by baggy_trough 1y ago

hungryhobbit 1y ago
Better late than never I guess.
baggy_trough 1y ago
I still find it rather baffling that they just removed David Rodríguez outright without trying to work this out in advance. He did most of the work in recent times. Seems like max damage approach.
- mijoharas 1y ago
  Has deivid spoken about any of this publicly yet? I was looking to see his take, but didn't find anything (other than some posts confirming that he'd had his access revoked too)
- byroot 1y ago
  They didn't. They initially left him as owner of the bundler gem after they removed 3 other owners, indicating they wanted for him to continue to be a maintainer. He posted on the rubygems slack that he left and is conditioning his return on all other maintainers being reinstated.
  - baggy_trough 1y ago
    He said this on Slack earlier: "The immediate reason for this is simple: my commit access to the repository has been revoked, so I can no longer do the job anymore." Do you mean that he removed himself?
    - byroot 1y ago
      There are two different things, GitHub access, and gem ownership (permission to publish packages). Based on previous posts, they did revoke everyone GitHub access, but with the intent to give it back to some maintainers after they signed some sort of contributor agreement. However on the package publishing side, you can see that on Sept 20 3 people had access [0], hsbt, deivid and colby. If you compare to aug 24, there was also andre, sebgiddins and rubymorillo (no idea who that is). So that leads me to believe they had the intention to keep him, even more so because he was still contracting with them. AFAICT the intent was to remove accesses to former employees who left to start their own consultancy. So to me, that post from RC checks out, and I think they were very well aware of who was contributing what. [0] https://web.archive.org/web/20250920140646/https://rubygems.org/gems/bundler https://web.archive.org/web/20250920140646/https://rubygems.... [1] https://web.archive.org/web/20250824033341/https://rubygems.org/gems/bundler https://web.archive.org/web/20250824033341/https://rubygems.... Edit: answering myself on who rubymorillo was, it's someone who didn't commit in that gem since 2018: https://github.com/rubygems/rubygems/commits?author=rubymorillo https://github.com/rubygems/rubygems/commits?author=rubymori... So yeah, permission management at Ruby Central did indeed seem to have been a huge mess. Not excusing the extremely poor rollout, but some cleanup was definitely overdue...
      - skywhopper 1y ago
        Have they ever explained why a contributor agreement is crucial? Will it assign copyright to RubyCentral?
        byroot 1y ago
        Not to my knowledge. But I may have missed something. My understanding is that having a legally enforceable contract help dissuade malevolent actions (easier to sue for breach of contract? But IANAL). As for copyright attribution, I doubt it. That ship has sailed, that code base already contains contributions from hundreds of people, and I can’t really imagine a business model that would rely on relicensing.
      - justinclift 1y ago
        > they did revoke everyone GitHub access, but with the intent to give it back to some maintainers after they signed some sort of contributor agreement. That sounds like someone or some people spontaneously deciding they're going to become gatekeepers, without any kind of warning and/or Community discussion/agreement first. > Not excusing the extremely poor rollout, but some cleanup was definitely overdue... While true, what they should have done is discuss it with the maintainers _first_ and agree to a plan. Not just seize control, especially from active contributors. :(
ipaddr 1y ago
"Unlike open-source projects that are simply distributed “as-is” with no warranties, but similar to other infrastructure projects, these codebases underpin a service operated by Ruby Central, and its canonical clients, relied on by millions of developers every day to securely download and publish gems. " Are they offering warranties? What new privacy laws demand them signing some handcrafted legal document? Is what they did legal? Couldn't they fork to provide a secure version. That one guy maintaining so many rubygems is the same guy who is offering a competing software solution that could reduce their profit stream is that the real reason?
- bilalq 1y ago
  I did a double-take when I read that as well. I went and checked the license under rubygems, and sure enough, it's standard MIT with no warranties. https://github.com/rubygems/rubygems/blob/master/LICENSE.txt https://github.com/rubygems/rubygems/blob/master/LICENSE.txt
  - bpt3 1y ago
    I'm willing to bet the people who published that have no idea what they just said, and probably don't understand what the MIT license contains.
    - byroot 1y ago
      They are talking about the rubygems.org package hosting service...
      - onionisafruit 1y ago
        It comes with a 100,000 mile drive train warranty.
        collingreen 1y ago
        Yeah we've been meaning to talk to you about that warranty actually
knzai 1y ago
I love how this isn’t even posted to their socials, cause they don’t want the dragging to link their official accounts. Like the last BlueSky post is still cancelling (“postponing” is only the right verb if you end up actually doing it) the Q&A 7 days ago…
ljm 1y ago
[flagged]
- bhouston 1y ago
  That is what I understand this was part of the reason behind this, no? Basically DHH had some right wing posts and some people took offence and then Shopify (on whose board DHH serves and whose CEO is a friend of DHH and shares his right leaning political views) swooped in and demanded those people who criticized DHH be removed from the project? Lots of FUD was spread about Andrei in the wake of this in order to justify his removal.
bpt3 1y ago
Seems like a bunch of bureaucrats overplayed their hand and are now trying to prevent the people whose work they depend on from abandoning ship. This is poor, even by corporatese standards.
Modified3019 1y ago
Smoke, mirrors, and buzzwords.
mijoharas 1y ago
Seems to boil down to "we don't trust Andre[0] and btw Shopify totally didn't make us do this[1]". I still don't understand the mistrust of Andre though. Also, the second point seems a bit disingenuous when their own board member speaks about a specific deadline[2]. He says it's something they agreed to, so it's necessarily external. That and the teams of reports of other people saying they've heard it's Shopify putting pressure for this specific point makes me look for a higher standard of rebuttal than "dude trust me". Explain why it was urgent. Explain what the deadline was. [0] A recent access review had revealed that many systems were under the control of a single individual, which we determined presented a risk to the security and operational sustainability of those systems. [1] The Board acted independently, and financial support was NOT conditioned on taking these steps. [2] https://apiguy.substack.com/p/a-board-members-perspective-of-the https://apiguy.substack.com/p/a-board-members-perspective-of...
- baobun 1y ago
  If it was just Andre, what about the several other removed maintainers who were treated equally, except for the recent public hitting on socials? To me it seems A is an easy target to use as distraction for public drama and justification.
  - krainboltgreene 1y ago
    The part you're missing is those people really liked André.
- mosura 1y ago
  What I don’t get is if there is one actor in the Ruby ecosystem that absolutely needs it all to be run in a responsible way it is Shopify, so quite why so many people are concerned about some mysterious back room dealing by Shopify is beyond me. They are not Oracle.
  - mijoharas 1y ago
    For me, most people that are involved (e.g. simi, a, now former, maintainer[0]) seem to point to this post by Joel drapper as a canonical and accurate accounting of events, and I have no reason to doubt them[1]. Most of the article says it's due to pressure from Shopify. [0] https://gist.github.com/simi/349d881d16d3d86947945615a47c60ca https://gist.github.com/simi/349d881d16d3d86947945615a47c60c... [1] https://joel.drapper.me/p/rubygems-takeover/ https://joel.drapper.me/p/rubygems-takeover/
Aeolun 1y ago
Damn, if I ever needed a reason to stay away from that whole ecosystem this is it. Sounds like it’s either some enterprise, or a bunch of volunteers that see an opportunity to be little tyrants. Love how they simultaneously decided that this had been going on for years, that nothing bad had happened, and that they had to act now without any prior consultation.
- edoceo 1y ago
  Rushed plans always have a (sometimes obvious) ulterior motive. Not that I see an obvious one here (very unfamiliar with specifics); but its always present in a rush-job.
  - tbrownaw 1y ago
    I have seen things that were rushed because they started late (because someone dragged their feet wrt budget approval).
krainboltgreene 1y ago
Look I'm just a web developer, but in my experience when the security team notices that there's a single point of failure for a lot of key projects they don't swoop in and make an insane mess.
mostlysimilar 1y ago
This hasn't gotten as much traction but I think adds some interesting additional context here: https://joel.drapper.me/p/ruby-central-security-measures/ https://joel.drapper.me/p/ruby-central-security-measures/ (https://news.ycombinator.com/item?id=45428812 https://news.ycombinator.com/item?id=45428812)
skywhopper 1y ago
This is a really poorly written update. Yes, we get that there is a need for security of the infrastructure services. That’s a given. But it’s overexplained here, while the actual mechanisms of what they are doing are never justified. But worse, there’s just some random things thrown in that make no sense. Like “the README says rubygems code is managed by RubyCentral”. “Managed” does not mean owned. And how it should be managed ought to be up to the community, not board members acting in secret. And this shows just remarkably poor editing: “some maintainers had long periods of inactivity (Least Privileged Access), changed the timeline.” Is that parenthetical a reminder to the original drafter to expand on that topic? Because it makes no sense in context. Then there’s this line: “We could have communicated earlier and in more detail. And we won’t stop apologizing for the confusion that caused.” That’s the closest they ever get to admitting they did anything wrong, and although they say “we won’t stop apologizing”, I’ll note that they never do apologize. But, absolutely everything they’ve done since this started has been wrong, and ultra defensive. Just own up to your mistakes and start from scratch.
- plorkyeran 1y ago
  > although they say “we won’t stop apologizing”, I’ll note that they never do apologize. Well, technically true that they haven't stopped.
  - dullcrisp 1y ago
    They will neither start nor stop apologizing.
woodruffw 1y ago
I find this post pretty unsatisfying: it sticks very closely to factual claims that aren’t particularly controversial (see: access control) while avoiding the elephant in the room, which is that the Ruby community sees any legitimate security concerns as pretextual for a sponsor-backed takeover. I think it’s pretty hard to avoid acknowledging this, which gives the distinct impression that the post (and by extension Ruby Central’s current leadership) are not particularly committed to transparency on the issue. I’d love to be wrong about that.
12_throw_away 1y ago
My god this is badly written and confusing. At least an actual person signed it this time? I'm not sure if this was LLM-written because I don't think an LLM would write a missive almost entirely in bullet points - but it has many of the hallmarks. Like, these sentences almost sound reasonable, but don't actually make sense or represent a coherent train of thought: A recent access review had revealed that many systems were under the control of a single individual, which we determined presented a risk to the security and operational sustainability of those systems. We had intended to resolve this over time. However, the departure of key maintainers and contribution data showing that some maintainers had long periods of inactivity (Least Privileged Access), changed the timeline.
- bpt3 1y ago
  There is no coherent train of thought that they want to share publicly because their actual motives appear to be very unpopular and self-serving, so they offered up this nonsensical content instead. Press releases/open letters like this one have existed long before LLMs for that reason.
- PapaPalpatine 1y ago
  I’m sorry, but how is that not a coherent train of thought? You may not agree the conclusion, but there is a complete train of thought.
  - justinclift 1y ago
    These two sentences don't actually join together well logically: > A recent access review had revealed that many systems were under the control of a single individual, which we determined presented a risk to the security and operational sustainability of those systems. We had intended to resolve this over time. and: > ... the departure of key maintainers and contribution data showing that some maintainers had long periods of inactivity (Least Privileged Access), changed the timeline. As the 2nd doesn't really change anything about the 1st. If that "single individual" has been acting maliciously or similar then it might, but they don't present evidence of that being the case. So there's nothing about the 2nd statement which has anything to support changing any kind of timeline. ie this all seems to be bullshit
bradly 1y ago
> In practice, we focused first on contacting the team members directly affected and left our broader communication for business hours. Is this contradictory to what others involved have said? It also implies the first set of actions were taken outside of business hours which seems odd.
fmajid 1y ago
One possible trigger for this fiasco is that André Arko and the Spinel Coop are working on rv, a Rust-based replacement four the Rubygems client. If it is as successful as uv has been for Python, it could disintermediate rubygems. Joel Draper says as much (see the penultimate section of https://joel.drapper.me/p/rubygems-takeover/ https://joel.drapper.me/p/rubygems-takeover/) although that would be more of a motivation for RubyCentral than for Shopify.
justinclift 1y ago
Whatever they're doing and have written this in response to, it sounds like they already know they're doing it wrongly and/or in bad faith. They should stop whatever it is they're doing, and work with the other Community members to resolve _the actual problem_ constructively. Otherwise they'll probably just cause an alternative to Ruby Central to emerge and/or be adopted widely.
- bpt3 1y ago
  Right. It seems like they're concerned about rv taking off and becoming that alternative, and it's hard to imagine anything else they could have done to make that more likely to occur.

91 points by baggy_trough 1y ago

Better late than never I guess.

I still find it rather baffling that they just removed David Rodríguez outright without trying to work this out in advance. He did most of the work in recent times. Seems like max damage approach.

mijoharas 1y ago
Has deivid spoken about any of this publicly yet? I was looking to see his take, but didn't find anything (other than some posts confirming that he'd had his access revoked too)
byroot 1y ago
They didn't. They initially left him as owner of the bundler gem after they removed 3 other owners, indicating they wanted for him to continue to be a maintainer. He posted on the rubygems slack that he left and is conditioning his return on all other maintainers being reinstated.
- baggy_trough 1y ago
  He said this on Slack earlier: "The immediate reason for this is simple: my commit access to the repository has been revoked, so I can no longer do the job anymore." Do you mean that he removed himself?
  - byroot 1y ago
    There are two different things, GitHub access, and gem ownership (permission to publish packages). Based on previous posts, they did revoke everyone GitHub access, but with the intent to give it back to some maintainers after they signed some sort of contributor agreement. However on the package publishing side, you can see that on Sept 20 3 people had access [0], hsbt, deivid and colby. If you compare to aug 24, there was also andre, sebgiddins and rubymorillo (no idea who that is). So that leads me to believe they had the intention to keep him, even more so because he was still contracting with them. AFAICT the intent was to remove accesses to former employees who left to start their own consultancy. So to me, that post from RC checks out, and I think they were very well aware of who was contributing what. [0] https://web.archive.org/web/20250920140646/https://rubygems.org/gems/bundler https://web.archive.org/web/20250920140646/https://rubygems.... [1] https://web.archive.org/web/20250824033341/https://rubygems.org/gems/bundler https://web.archive.org/web/20250824033341/https://rubygems.... Edit: answering myself on who rubymorillo was, it's someone who didn't commit in that gem since 2018: https://github.com/rubygems/rubygems/commits?author=rubymorillo https://github.com/rubygems/rubygems/commits?author=rubymori... So yeah, permission management at Ruby Central did indeed seem to have been a huge mess. Not excusing the extremely poor rollout, but some cleanup was definitely overdue...
    - skywhopper 1y ago
      Have they ever explained why a contributor agreement is crucial? Will it assign copyright to RubyCentral?
      - byroot 1y ago
        Not to my knowledge. But I may have missed something. My understanding is that having a legally enforceable contract help dissuade malevolent actions (easier to sue for breach of contract? But IANAL). As for copyright attribution, I doubt it. That ship has sailed, that code base already contains contributions from hundreds of people, and I can’t really imagine a business model that would rely on relicensing.
    - justinclift 1y ago
      > they did revoke everyone GitHub access, but with the intent to give it back to some maintainers after they signed some sort of contributor agreement. That sounds like someone or some people spontaneously deciding they're going to become gatekeepers, without any kind of warning and/or Community discussion/agreement first. > Not excusing the extremely poor rollout, but some cleanup was definitely overdue... While true, what they should have done is discuss it with the maintainers _first_ and agree to a plan. Not just seize control, especially from active contributors. :(

ipaddr 1y ago

"Unlike open-source projects that are simply distributed “as-is” with no warranties, but similar to other infrastructure projects, these codebases underpin a service operated by Ruby Central, and its canonical clients, relied on by millions of developers every day to securely download and publish gems. " Are they offering warranties? What new privacy laws demand them signing some handcrafted legal document? Is what they did legal? Couldn't they fork to provide a secure version. That one guy maintaining so many rubygems is the same guy who is offering a competing software solution that could reduce their profit stream is that the real reason?

bilalq 1y ago
I did a double-take when I read that as well. I went and checked the license under rubygems, and sure enough, it's standard MIT with no warranties. https://github.com/rubygems/rubygems/blob/master/LICENSE.txt https://github.com/rubygems/rubygems/blob/master/LICENSE.txt
- bpt3 1y ago
  I'm willing to bet the people who published that have no idea what they just said, and probably don't understand what the MIT license contains.
  - byroot 1y ago
    They are talking about the rubygems.org package hosting service...
    - onionisafruit 1y ago
      It comes with a 100,000 mile drive train warranty.
      - collingreen 1y ago
        Yeah we've been meaning to talk to you about that warranty actually

knzai 1y ago

I love how this isn’t even posted to their socials, cause they don’t want the dragging to link their official accounts. Like the last BlueSky post is still cancelling (“postponing” is only the right verb if you end up actually doing it) the Q&A 7 days ago…

ljm 1y ago

[flagged]

bhouston 1y ago
That is what I understand this was part of the reason behind this, no? Basically DHH had some right wing posts and some people took offence and then Shopify (on whose board DHH serves and whose CEO is a friend of DHH and shares his right leaning political views) swooped in and demanded those people who criticized DHH be removed from the project? Lots of FUD was spread about Andrei in the wake of this in order to justify his removal.

bpt3 1y ago

Seems like a bunch of bureaucrats overplayed their hand and are now trying to prevent the people whose work they depend on from abandoning ship. This is poor, even by corporatese standards.

Modified3019 1y ago

Smoke, mirrors, and buzzwords.

mijoharas 1y ago

Seems to boil down to "we don't trust Andre[0] and btw Shopify totally didn't make us do this[1]". I still don't understand the mistrust of Andre though. Also, the second point seems a bit disingenuous when their own board member speaks about a specific deadline[2]. He says it's something they agreed to, so it's necessarily external. That and the teams of reports of other people saying they've heard it's Shopify putting pressure for this specific point makes me look for a higher standard of rebuttal than "dude trust me". Explain why it was urgent. Explain what the deadline was. [0] A recent access review had revealed that many systems were under the control of a single individual, which we determined presented a risk to the security and operational sustainability of those systems. [1] The Board acted independently, and financial support was NOT conditioned on taking these steps. [2] https://apiguy.substack.com/p/a-board-members-perspective-of-the https://apiguy.substack.com/p/a-board-members-perspective-of...

baobun 1y ago
If it was just Andre, what about the several other removed maintainers who were treated equally, except for the recent public hitting on socials? To me it seems A is an easy target to use as distraction for public drama and justification.
- krainboltgreene 1y ago
  The part you're missing is those people really liked André.
mosura 1y ago
What I don’t get is if there is one actor in the Ruby ecosystem that absolutely needs it all to be run in a responsible way it is Shopify, so quite why so many people are concerned about some mysterious back room dealing by Shopify is beyond me. They are not Oracle.
- mijoharas 1y ago
  For me, most people that are involved (e.g. simi, a, now former, maintainer[0]) seem to point to this post by Joel drapper as a canonical and accurate accounting of events, and I have no reason to doubt them[1]. Most of the article says it's due to pressure from Shopify. [0] https://gist.github.com/simi/349d881d16d3d86947945615a47c60ca https://gist.github.com/simi/349d881d16d3d86947945615a47c60c... [1] https://joel.drapper.me/p/rubygems-takeover/ https://joel.drapper.me/p/rubygems-takeover/

Aeolun 1y ago

Damn, if I ever needed a reason to stay away from that whole ecosystem this is it. Sounds like it’s either some enterprise, or a bunch of volunteers that see an opportunity to be little tyrants. Love how they simultaneously decided that this had been going on for years, that nothing bad had happened, and that they had to act now without any prior consultation.

edoceo 1y ago
Rushed plans always have a (sometimes obvious) ulterior motive. Not that I see an obvious one here (very unfamiliar with specifics); but its always present in a rush-job.
- tbrownaw 1y ago
  I have seen things that were rushed because they started late (because someone dragged their feet wrt budget approval).

krainboltgreene 1y ago

Look I'm just a web developer, but in my experience when the security team notices that there's a single point of failure for a lot of key projects they don't swoop in and make an insane mess.

mostlysimilar 1y ago

This hasn't gotten as much traction but I think adds some interesting additional context here: https://joel.drapper.me/p/ruby-central-security-measures/ https://joel.drapper.me/p/ruby-central-security-measures/ (https://news.ycombinator.com/item?id=45428812 https://news.ycombinator.com/item?id=45428812)

skywhopper 1y ago

This is a really poorly written update. Yes, we get that there is a need for security of the infrastructure services. That’s a given. But it’s overexplained here, while the actual mechanisms of what they are doing are never justified. But worse, there’s just some random things thrown in that make no sense. Like “the README says rubygems code is managed by RubyCentral”. “Managed” does not mean owned. And how it should be managed ought to be up to the community, not board members acting in secret. And this shows just remarkably poor editing: “some maintainers had long periods of inactivity (Least Privileged Access), changed the timeline.” Is that parenthetical a reminder to the original drafter to expand on that topic? Because it makes no sense in context. Then there’s this line: “We could have communicated earlier and in more detail. And we won’t stop apologizing for the confusion that caused.” That’s the closest they ever get to admitting they did anything wrong, and although they say “we won’t stop apologizing”, I’ll note that they never do apologize. But, absolutely everything they’ve done since this started has been wrong, and ultra defensive. Just own up to your mistakes and start from scratch.

plorkyeran 1y ago
> although they say “we won’t stop apologizing”, I’ll note that they never do apologize. Well, technically true that they haven't stopped.
- dullcrisp 1y ago
  They will neither start nor stop apologizing.

woodruffw 1y ago

I find this post pretty unsatisfying: it sticks very closely to factual claims that aren’t particularly controversial (see: access control) while avoiding the elephant in the room, which is that the Ruby community sees any legitimate security concerns as pretextual for a sponsor-backed takeover. I think it’s pretty hard to avoid acknowledging this, which gives the distinct impression that the post (and by extension Ruby Central’s current leadership) are not particularly committed to transparency on the issue. I’d love to be wrong about that.

12_throw_away 1y ago

My god this is badly written and confusing. At least an actual person signed it this time? I'm not sure if this was LLM-written because I don't think an LLM would write a missive almost entirely in bullet points - but it has many of the hallmarks. Like, these sentences almost sound reasonable, but don't actually make sense or represent a coherent train of thought: A recent access review had revealed that many systems were under the control of a single individual, which we determined presented a risk to the security and operational sustainability of those systems. We had intended to resolve this over time. However, the departure of key maintainers and contribution data showing that some maintainers had long periods of inactivity (Least Privileged Access), changed the timeline.

bpt3 1y ago
There is no coherent train of thought that they want to share publicly because their actual motives appear to be very unpopular and self-serving, so they offered up this nonsensical content instead. Press releases/open letters like this one have existed long before LLMs for that reason.
PapaPalpatine 1y ago
I’m sorry, but how is that not a coherent train of thought? You may not agree the conclusion, but there is a complete train of thought.
- justinclift 1y ago
  These two sentences don't actually join together well logically: > A recent access review had revealed that many systems were under the control of a single individual, which we determined presented a risk to the security and operational sustainability of those systems. We had intended to resolve this over time. and: > ... the departure of key maintainers and contribution data showing that some maintainers had long periods of inactivity (Least Privileged Access), changed the timeline. As the 2nd doesn't really change anything about the 1st. If that "single individual" has been acting maliciously or similar then it might, but they don't present evidence of that being the case. So there's nothing about the 2nd statement which has anything to support changing any kind of timeline. ie this all seems to be bullshit

bradly 1y ago

> In practice, we focused first on contacting the team members directly affected and left our broader communication for business hours. Is this contradictory to what others involved have said? It also implies the first set of actions were taken outside of business hours which seems odd.

fmajid 1y ago

One possible trigger for this fiasco is that André Arko and the Spinel Coop are working on rv, a Rust-based replacement four the Rubygems client. If it is as successful as uv has been for Python, it could disintermediate rubygems. Joel Draper says as much (see the penultimate section of https://joel.drapper.me/p/rubygems-takeover/ https://joel.drapper.me/p/rubygems-takeover/) although that would be more of a motivation for RubyCentral than for Shopify.

justinclift 1y ago

Whatever they're doing and have written this in response to, it sounds like they already know they're doing it wrongly and/or in bad faith. They should stop whatever it is they're doing, and work with the other Community members to resolve _the actual problem_ constructively. Otherwise they'll probably just cause an alternative to Ruby Central to emerge and/or be adopted widely.

bpt3 1y ago
Right. It seems like they're concerned about rv taking off and becoming that alternative, and it's hard to imagine anything else they could have done to make that more likely to occur.