Live data from Hacker News

A board member's perspective of the RubyGems controversy

apiguy.substack.com

11–20 of 175 posts

Re: A board member's perspective of the RubyGems controversy

#11
post #5

> [The Ruby Central board] is a small group of volunteers is somewhat at odds with > Some [...] companies specifically pay Ruby Central to ensure the security and stability of that part of the supply chain, but not so much. Then the sentence goes on with > but then discovered that people with no active affiliation or agreement in place had top level privileges to some of this critical infrastructure. So something has…

Not really -- non-profit boards are usually volunteers, even ion the non-profit has revenue used for operations.

Re: A board member's perspective of the RubyGems controversy

#12
It's such a weird thought process to have gone through, to write this. The sentiments expressed are basically:

"I WANT to apologize ... that I feel awful."

"How can you possibly talk to someone about changing access, when multiple people tell you no, you are wrong?! A coup is the only way!"

"Because funding deadline, we executed a coup, which will keep everyone safe from hostile actors... Taking over accounts and access"

Re: A board member's perspective of the RubyGems controversy

#13
This story is missing any context around what occurred. The only thing I was able to find was by searching, and I came to this PDF statement.

https://pup-e.com/goodbye-rubygems.pdf

> On September 9th, with no warning or communication, a RubyGems maintainer unilaterally:

> renamed the “RubyGems” GitHub enterprise to “Ruby Central”,

> added non-maintainer Marty Haught of Ruby Central, and

> removed every other maintainer of the RubyGems project.

> On September 18th, with no explanation, Marty Haught revoked GitHub organization membership for all admins on the RubyGems, Bundler, and RubyGems.org maintainer teams

Which is important context that was left out of this board member's statement.

Re: A board member's perspective of the RubyGems controversy

#14

Very reasonable other side to this story, which doesn’t come as much of a surprise. Too bad it didn’t hit the front page. People went WAY too far WAY too fast on this. There HAS to be urgency to this, the software supply chain is presently, undeniably, under attack. Frankly, everyone blasting RubyCentral the last few days should feel shame and embarrassment. These aren’t evil suits at Microsoft, they’re normal people…

What? This article is absolutely damning re: RC's leadership and the utter lack of proper transparency, strategic planning, marketing/PR, and solid OSS governance. Did we read the same article?!

i read the article, but didn't see anything damning about it. how big of a staff do you think a tiny 501c3 like RubyCentral is? RC shepherds a pretty small community around a niche DSL with a shoestring non-profit budget that mostly goes towards running conferences.. you can see their financial reports here https://projects.propublica.org/nonprofits/organizations/300...

expectations around "strategic planning" and "marketing/PR" are not realistic. You should just be glad these randos don't have admin access to the Github org anymore. Any one of them were huge targets for adversaries who want to ship malware in Rubygems, supply chain attacks are very real and having commit access directly to rubygems/bundler is too powerful for a rando.

my main takeaway from reading all this is why were so many assorted people given such high levels of access..

Re: A board member's perspective of the RubyGems controversy

#15
I don't know more about the controversy than what's explained here, but, reading between the lines, it sounds like companies want Ruby Central to operate more like a for-profit company, where people carry out defined tasks in exchange for getting paid, than like a jury or the American Medical Association, where people do what seems best to them in exchange for a harder-to-define sense of collective social obligation. (When they work, of course; sometimes those institutions don't work very well.)

I am skeptical that the model where people carry out defined tasks in exchange for getting paid can properly discharge the obligations of trustworthiness and disinterest that are necessary for the proper functioning of software supply chains. I'm thinking that probably people whose motivation is primarily personal gain will seek out ways to exploit their users' trust for additional personal gain, for example by bundling adware and other malware into their software the way Microsoft does with Windows, or only releasing security updates to paying customers.

Open-source licensing provides some protection against this problem, because it guarantees you the legal right to switch to a non-malicious fork; but the whole reason we're talking about open-source supply chain security in the first place is that your vulnerability to your chosen upstream is still far from nonzero.

Re: A board member's perspective of the RubyGems controversy

#16

It's such a weird thought process to have gone through, to write this. The sentiments expressed are basically: "I WANT to apologize ... that I feel awful." "How can you possibly talk to someone about changing access, when multiple people tell you no, you are wrong?! A coup is the only way!" "Because funding deadline, we executed a coup, which will keep everyone safe from hostile actors... Taking over accounts and acc…

> Ruby Central has been responsible for RubyGems and Bundler for a long time. This isn't a new development, and I'm honestly very confused about the confusion.

That's the opposite claim from a coup. It's not fair for you to put those words in his mouth.

Re: A board member's perspective of the RubyGems controversy

#17
> Either Ruby Central puts controls in place to ensure the safety and stability of the infrastructure we are responsible for, or lose the funding that we use to keep those things online and going.

Seems pretty clear after reading this. If 1-2 companies pulling funding is enough for them to force you to to what they want, its hard to stay independent.

Re: A board member's perspective of the RubyGems controversy

#18
post #13

This story is missing any context around what occurred. The only thing I was able to find was by searching, and I came to this PDF statement. https://pup-e.com/goodbye-rubygems.pdf > On September 9th, with no warning or communication, a RubyGems maintainer unilaterally: > renamed the “RubyGems” GitHub enterprise to “Ruby Central”, > added non-maintainer Marty Haught of Ruby Central, and > removed every other maintain…

It was not left out of the statement. I understood that was essentially what happened by the time I got to the end of his piece. The only exception being the “with no warning or communication” part. Obviously there is disagreement about whether that is true or not.

Re: A board member's perspective of the RubyGems controversy

#19
Agreeing with most of the other comments here that this discussion needs more context which we don't have...

If the request for additional access controls/access cleanup came from one of the Ruby Central funders, could we not know who that was and what exactly their ask consisted of? I am interested in knowing their side of the story, and what the motivation was. (But in general, cutting off long-time maintainers' access seems like a bad choice - as presumably they have long since proven their good will toward the ruby community as shepherds of these projects.)

Re: A board member's perspective of the RubyGems controversy

#20
post #14

Earlier quoted context omitted.

What? This article is absolutely damning re: RC's leadership and the utter lack of proper transparency, strategic planning, marketing/PR, and solid OSS governance. Did we read the same article?!

i read the article, but didn't see anything damning about it. how big of a staff do you think a tiny 501c3 like RubyCentral is? RC shepherds a pretty small community around a niche DSL with a shoestring non-profit budget that mostly goes towards running conferences.. you can see their financial reports here https://projects.propublica.org/nonprofits/organizations/300... expectations around "strategic planning" and "m…

"These randos" are our friends and fellow contributors. Probably everybody in the Ruby community has worked with theme in one capacity or another. The article provides no reason why they should have had their contribution permissions revoked. Just because you think of Ruby as a "niche DSL" and the people maintaining its core infrastructure as "randos" doesn't mean the rest of us do.
Post reply on HN