Live data from Hacker News

A board member's perspective of the RubyGems controversy

apiguy.substack.com

61–70 of 175 posts

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

#61
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…

Everything you're quoting is from one aggrieved person, who clearly felt slighted, and who left out a whole lot of context in their own post. The article above is a lot more reasoned, less emotional, and seems completely reasonable to me. Ruby Central clearly has issues with both internal and external communication. And the above article isn't an official statement either; it's just one person, not involve in the dec…

Everything he quoted is a fact, which can be proven or falsified. Taken together (and if true) they're pretty damning.

You responded with an ad-hominem attack. If you can offer a rebuttal of the facts then please do, otherwise try to refrain from personal attacks.

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

#62

A lot of people are arguing about whether locking down access was justified to resolve the security issues. I guess it's debatable. But I don't see any excuse for not putting out a statement when you do it. You have to know there will be a fight, and you will look like the bad guy. Perhaps I could see directly communicating to the maintainers that you expect that they'll be reinstated. But to say nothing? To let the…

I mean imagine you are at work and you need to so this for SOC2 or something but dont tell your colleagues.

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

#63
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…

Everything you're quoting is from one aggrieved person, who clearly felt slighted, and who left out a whole lot of context in their own post. The article above is a lot more reasoned, less emotional, and seems completely reasonable to me. Ruby Central clearly has issues with both internal and external communication. And the above article isn't an official statement either; it's just one person, not involve in the dec…

Wait, what?

A maintainer of RubyGems was forcibly removed from the RubyGems GitHub org — which was renamed to Ruby Central — along with every other maintainer. Then access was restored, then revoked again. There was no explanation, no communication, and no understandable reasoning for this.

And still! If there is an "official" statement, I can't find one on https://rubycentral.org/.

This wildly transcends "issues with both internal and external communication" or "we're just a bunch of makers who can't be expected to be good at organization or communication" (to highly paraphrase TFA). This is an absolutely disastrous breach of the community's trust.

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

#64
post #55

This is a reasonable perspective but leaves a lot of unanswered questions and creates more questions. Who is the funder threatening to pull funding and why were they not more collaborative or flexible with Ruby Central? Did they know that this is how their request would be handled? How much information and what information did Board members have when making their votes? One thing that hasn’t been addressed is who was…

I don’t know why the funder matters. RC agreed to a contract that provided a fixed date by which these issues needed to be resolved or funding would be terminated. Exploding terms are rare in funding agreements because they don’t make the funder look good when they explode. Back in my non profit board days, I learned that contracts with exploding terms need to go in front of the entire board instantly for action or l…

Actions were taken, at the request of a major funder or group of funders, that have become a PR problem for the entire Ruby language. This is the third article I’ve seen on HN in the last week and it’s not just Rubyists commenting. This is damaging to everyone who uses Ruby and developers who want job security in the future. These funders should want to maintain the reputation of Ruby, and forcing a nonprofit to take an extreme action like this in a pressure cooker situation puts all of Ruby at risk when it explodes into a scandal. These companies need to work transparently in the best interest of the whole community.

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

#65
post #7

I think that if they had been up front and transparent, and cut the PR bullshit corpospeak from their damage-control post, this would have been something that's much less embarrassing for all involved. Something like: "Hey all, RC here: with the very real threat of supply-chain attacks looming around us, one of the critical financial backers of our nonprofit org gave us a deadline around tightening access to the Gith…

This has the advantage of being short and so take way less brainpower to piece what actually happened. Reading between lines is exhausting.

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

#66
post #48

Earlier quoted context omitted.

How you can tell this is all lies from the board is simple: > How do you tell someone that has had commit and admin access to critical infrastructure long after that need has expired that you need to revoke that access without upsetting them? The first thing is they didn't tell them. The second bit is simple: "Hi [x], I'm sure you've seen the news about npm. Given supply chain attacks directed at them and the one rec…

100% Reasonable people would've accepted that fine. And you don't have to worry about unreasonable people, because most people will find them unreasonable and dismiss anything they say.

Exactly.

And communicating [situation], [action(s)], [how this affects you] is one of the most basic professional communication skills you could imagine.

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

#67
post #14

Earlier quoted context omitted.

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.

I'm for least privildge and tightening up perms, reviewing who has access. But it just needed some comms and timeline. Unless there was an obvious immediate threat.

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

#68
post #40

Locking out a guy like David Rodriguez (the main person I see doing bundler commits) in a dramatic fashion just seems like absolute craziness. I can't fathom doing it without a very good reason, which has yet to be revealed if it exists.

Does “lest we lose critical funding because we don’t have proper agreements with our committers” not cut it as a reason for you? Genuinely curious, it seems like a reasonable explanation assuming it’s true.

Then you act in advance or with notice to get those agreements in place. Just dropping an atom bomb on the commit rights of the biggest contributor is very disrespectful.

If you can't work out an agreement after a good faith period... then that can become a good reason.

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

#69
post #58

Earlier quoted context omitted.

It does not, for me. Given that access was cut, then restored, then cut again, then days, then someone finally says "hey were were going to lose critical funding" makes it seem like a post-facto excuse for a hostile takeover. And the whole "oh, well, we're bad at comms" makes it sound even worse! Which is the whole crux of the issue. At no point in any of this did Ruby Central do anything reasonable. The they tried t…

From TFA: > Let's get some kind of committer agreement in place with those folks who need access (the same way many other high profile open source projects have), and remove access from those who don't, while still being fully open to accepting PRs and being open to re-welcoming them as committers if they decide that is how they want to spend their time in the future. > Here's the challenge. How do you tell someone t…

Ruby Central sponsors him to work on the project. They also own the project. Sure it’s not ideal that they’ve apparently come to an impasse of some sort but locking him out is not bonkers.

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

#70
post #69
post #58

Earlier quoted context omitted.

From TFA: > Let's get some kind of committer agreement in place with those folks who need access (the same way many other high profile open source projects have), and remove access from those who don't, while still being fully open to accepting PRs and being open to re-welcoming them as committers if they decide that is how they want to spend their time in the future. > Here's the challenge. How do you tell someone t…

Ruby Central sponsors him to work on the project. They also own the project. Sure it’s not ideal that they’ve apparently come to an impasse of some sort but locking him out is not bonkers.

It sure fucking is bonkers.

Ruby Central as an organization touts that it is responsible for RubyGems. Assuming this narrative is accurate, they needed to get agreements in place with contributors to appease some funding partners.

This shit happens. Especially as an open-source project started by one dude in 2009 turns into critical infrastructure managed by a 501(c)(3) non-profit.

That they failed so fucking spectacularly speaks incredibly poorly of their board.

Post reply on HN