Our stewardship: Where we are, what's changing and how we'll engage | Hacker News Reader

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

rubycentral.org

91 pointsbaggy_trough60 comments

"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?

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

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.

They are talking about the rubygems.org package hosting service...

It comes with a 100,000 mile drive train warranty.

Yeah we've been meaning to talk to you about that warranty actually

What warranty does it come with?

https://rubygems.org/policies

Yep right there in the TOS:

a. THE SERVICE IS PROVIDED STRICTLY ON AN “AS IS” AND “AS AVAILABLE” BASIS, AND PROVIDER MAKES NO WARRANTY THAT THE SERVICE IS COMPLETE, SUITABLE FOR YOUR PURPOSE, RELIABLE, USEFUL, OR ACCURATE.

That’s not the only thing though. E.g. the collect PII, so I assume there are regulations to abide by etc.

They're storing PII in the github repo they kicked the core maintainers out of?

Just stop trying to make excuses for these people. They screwed up, and based on this press release, don't seem to have any interest in actually correcting those mistakes.

Right, take a look at Section 8 of the Terms of Service (https://rubygems.org/policies/terms-of-service):

THE SERVICE IS PROVIDED STRICTLY ON AN “AS IS” AND “AS AVAILABLE” BASIS, AND PROVIDER MAKES NO WARRANTY THAT THE SERVICE IS COMPLETE, SUITABLE FOR YOUR PURPOSE, RELIABLE, USEFUL, OR ACCURATE.

What warranty are they providing exactly?

The license is not an accurate way to check if there is a warranty or not.

I'm not a lawyer, so maybe a silly question: is it possible the software license is different from service warranty? And I guess another thing that comes to mind is that maybe they didn't mean _legal_ warranty, but something that was used colloquially?

The MIT license is a copyright license. The developer is free to offer a warranty or any other contract they want.

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.

> although they say “we won’t stop apologizing”, I’ll note that they never do apologize.

Well, technically true that they haven't stopped.

They will neither start nor stop apologizing.

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.

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://news.ycombinator.com/item?id=45428812)

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.

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.

I have seen things that were rushed because they started late (because someone dragged their feet wrt budget approval).

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…

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.

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.

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.

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

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/) although that would be more of a motivation for RubyCentral than for Shopify.

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.

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)

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.

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?

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.... [1] 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=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...

Have they ever explained why a contributor agreement is crucial? Will it assign copyright to RubyCentral?

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.

> 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. :(

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...

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.

The part you're missing is those people really liked André.

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.

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/349d881d16d3d86947945615a47c60c...

[1] https://joel.drapper.me/p/rubygems-takeover/

Sorry I didn’t mean to express doubt they are behind this. What I don’t understand is why the community are so freaked out by this given the incentives are very much for Shopify to ensure it operates properly.

Got it, makes sense, and I agree (and am also kinda confused).

Their behavior is at odds with that sentiment, though.

I suspect it's because DHH is on the board of Shopify [1] and a lot of people really don't like him [2].

(To be clear, I am not stating my own opinion of DHH or Shopify. I'm just saying I suspect this is why a lot of Rubyists are not OK with RubyCentral being under the thumb of Shopify.)

[1]: https://www.shopify.com/news/david-heinemeier-hansson-board

[2]: https://davidcel.is/articles/rails-needs-new-governance

Shopify has plenty of resources to run their own internal, ultra secure Rubygems mirror.

With no insider knowledge whatsoever I can assure you that they do. Large enterprise shops always have these things cached because why take a hard deploy-time external dependency when you can spin up a rubygems (etc) cache backed entirely by your object storage of choice.

Former Shopifolk here. As of 2022 - 2023 they had some private packages in their SCM and an internal Artifactory deployment that was a caching proxy of Rubygems and other upstream dependencies. This may be changed since, but as far as I’m aware many Shopify devs occasionally volunteer time and fixes to Rubygems and related projects from time to time.

They certainly have the capacity to run their own full on mirror service, but I doubt they have serious incentive to do so given exciting controls and culture re: Ruby and OSS contributions.

There is no way. Shopify is trying to be part of the Ruby community, because it knows if it becomes the community or bypasses the community, then the community are dead.

I think what is most likely is that Shopify is trying to achieve some security goals in rubygems through Ruby Central. That they put a deadline on funding based on some security guarantees.

Shopify knows they are a high value target. I bet they thought they could muscle for whatever they want using funding money, and didn’t anticipate the mishandling and then blowback.

Being a part of the community necessitates that there be a community to be part of. Taking unilateral control is not being part of a community.

Sometimes organisations that are given near veto power over a Community Thing will bend that Thing to be self serving of themselves.

Red Hat -> IBM -> CentOS is an example of this to me.

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.

Smoke, mirrors, and buzzwords.

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.

> 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.

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.

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.

Better late than never I guess.

Reply on news.ycombinator.com