Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A board member's perspective of the RubyGems controversy

apiguy.substack.com

Post reply on HN
Print view View original

51–60 of 175 posts

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

#51

Post by rubiest2010 »

rubiest2010 wrote: post #44

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…

To add, did Ruby Central consider going to the community and asking for funding so they wouldn’t have to be beholden to one or a small group of key funders? If they were at risk of shutting down without this funding source I think the community might have rallied around them so they could make more independent decisions in the best interests of the community.

This is not to say that they didn’t act in the best interests of the community by tightening security, but an organization of this nature should be able to act more independently.

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

#52

Post by anyonecancode »

What I'm missing is what, if any, communication Ruby Central had with maintainers.

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

Start by letting go of the goal of not upsetting them. Make sure you do communicate clearly. Just say what you said a paragraph earlier: open source ecosystems, including ours, are increasingly suffering supply chain attacks. To guard against this, we need to tighten access that has traditionally been fairly loose. Starting , we're going to remove general access and ask that contributors sign before re-enabling access.

I mean, maybe that is what happened -- as the OP says, he wasn't part of the conversations so can't say. From the earlier public posts, it doesn't _sound_ like that's what happened. But I'd say as a general rule, it's important to communicate disruptive changes ahead of time to those affected and give a clear path to how they can mitigate the disruption.

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

#53

Post by ryoshoe »

khamidou wrote: post #34
stickfigure wrote: post #31

Earlier quoted context omitted.

However it started, there's a big hosting bill and somebody has to pay it.

For sure – but maybe it doesn't have to be the side project of a non-profit whose main thing is RailsConf.

To be fair to RubyCentral, this year's RailsConf was the last one they have planned, though it's likely that they'll shift focus to on RubyConf in its place

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

#54

Post by blibble »

reenorap wrote: post #21

The only reason why Ruby and other open source projects survive is because large companies can trust them to do the right thing. Given the critical nature of the supply chain attacks, what the board did was 100% right. Like he said, some people's egos got hurt but if no one can trust the maintainers, then Ruby has no future in the industry and it will die quickly. This is basically like fixing technical debt. It's pa…

was it even their project?

just because they host it doesn't mean it's theirs

my webhost doesn't own the community around my projects simply because it's on their server

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

#55

Post by hluska »

rubiest2010 wrote: post #44

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 lawyers will get paid.

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

#56

Post by hluska »

rubiest2010 wrote: post #51
rubiest2010 wrote: post #44

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…

To add, did Ruby Central consider going to the community and asking for funding so they wouldn’t have to be beholden to one or a small group of key funders? If they were at risk of shutting down without this funding source I think the community might have rallied around them so they could make more independent decisions in the best interests of the community. This is not to say that they didn’t act in the best intere…

This program is public and has been for a very long time - it’s called the Community Support Program because Windows devs don’t have enough nightmares of the acronym CSP.

Do you contribute? I can send you a link if you don’t.

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

#57

Post by actionfromafar »

nightpool wrote: post #3

So Ruby Central, by their own admission, agreed to take $$$$$ of funding on the premise that they would "secure RubyGems against supply chain attacks", and then sat on their hands not doing anything about it until a few days before the deadline, when it was too late to seek community consensus or figure out a good transition plan. So they ended up screwing over everybody who was actually doing work on the project in…

To my untrained eye it looks like a board with a bunch of money and perhaps a fork on their hands.

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

#58

Post by lloeki »

generalk wrote: post #49
padjo wrote: post #40

Earlier quoted context omitted.

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.

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

deivid-rodriguez's last commits were Sept 18: https://github.com/rubygems/rubygems/commits/master/?since=2...

With 7873 commits since 2018 he's 2x over the second one and crushingly the most active contributor since then: https://github.com/rubygems/rubygems/graphs/contributors

However you slice it, none of that fits into TFA's above narrative.

His access being revoked can only be described as complete bonkers.

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

#59

Post by nenenejej »

I hate the style of write up. It feels a bit gaslightly (it may or may not be but feels like it). And defensive.

Just drop all the facts. Acknowledge you fucked up. Or dont say anything at all?

A board position means responsibility not just "head down coding". And that means communicating with people.

For clarity I wasnt super keen on the original submission this is responding to, for similar reasons.

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

#60

Post by gorbachev »

x0x0 wrote: post #48
sc68cal wrote: 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…

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.

Post reply on HN