October 7, 2025 • 50 mins
In this episode of C4, Andrew Mason and Rachael Wright-Munn join Drew to unpack recent controversies surrounding Ruby Central and its alleged takeover of Ruby Gems and Bundler. The trio delves into the timeline of events, conflicting narratives, communication failures, and the underlying security concerns. They address theories and facts, scrutinize the governance of Ruby Central, and discuss the implications for the Ruby community. The episode emphasizes the importance of asking questions and seeking clarity, while advocating for a balanced and constructive approach to resolving the community's issues.
Sources discussed*:
- Ellen's first post on the RubyGems controversy
- A board member's perspective on the RubyGems controversy
- An Update From Ruby Central (Video)
- Investigation (allegedly) reveals Shopify manipulated Ruby Central to force takeover of Bundler and RubyGems
- Strengthening the Stewardship of RubyGems and Bundler
- Martin Emde's post on Bluesky
- Reddit post for "An update from Ruby Central"
- Bundler Policies on GitHub
- Ruby Central "About" page
- Advocacy for Reduced Rails Usage
- Alpha-Omega Project
- Organization & Structure of Open Source Software Development Initiatives - Cyberlaw Clinic
- Ruby Central News Post: Alpha-Omega support
- StepSecurity: npm supply chain compromise
- Socket: npm supply chain attack
- Palo Alto Networks Unit 42: npm supply chain attack
* Some sources include unverified information being presented as fact. Read with caution.
HoneybadgerHoneybadger is an application health monitoring tool built by developers for developers.
Judoscale
Autoscaling that actually works. Take control of your cloud hosting.
Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you.
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
SPEAKER_03 (00:00):
Welcome to a special code and the coding coders who
code it.
I'm your host, AI Drew Bragg.
The real Drew is on the roadthis week.
So here's a Remote Ruby Collabpodcast that Drew was on talking
about all the Ruby centraldrama.
Enjoy.
SPEAKER_02 (00:15):
Hello everyone.
Welcome back to Remote Ruby.
I am Chrisless today, whichfeels weird.
I feel almost naked because Ihave never done this without
Chris, I don't think, or Jason.
But in order to not be trulyexposed today, I have brought
two friends to the show and Iwill let them both introduce
themselves now, starting withDrew.
SPEAKER_03 (00:36):
Hello, everyone.
I'm Drew.
You may know me from the host ofCode and the Code Encoders Who
Code It.
I will be releasing this episodealso on my timeline.
So maybe you're hearing me fromthat timeline.
But if not, you're listening toRemote Ruby, my favorite
podcast.
So welcome.
SPEAKER_00 (00:54):
Hi, I'm Rachel Reitman.
I go by Chail Codes Online,longtime listener, first time on
the podcast.
SPEAKER_02 (00:59):
I met Rachel at a conference recently, and I was
like, you're a cool person.
I'm gonna keep you in the backof my mind for like whenever a
situation like this arises.
So it's perfect.
So we're just gonna kind of begoing over what's been happening
in Ruby the past few weeks.
Why did something happen?
SPEAKER_03 (01:18):
Maybe I'll give a quick timeline of what happened
and then whose timeline?
This is my problem with what'sbeen going on is depending on
your source, the timeline is alittle different every time.
So I'm interested to hear yourtimeline.
And then I want to hear Rachel'stimeline.
And we'll give the publictimeline.
(01:39):
Okay.
Go ahead, Rachel.
SPEAKER_02 (01:41):
What were you gonna say?
SPEAKER_00 (01:42):
I was gonna say I feel like the timeline for this
starts way before any of thesepeople are setting it, way back
when when the merger betweenRuby Together and Ruby Central
happened.
SPEAKER_02 (01:51):
I would agree with that.
That's why I also wanted morepeople on the show because
there's a lot of context to thisthat like I don't have because
of how long I've been in thecommunity.
And there's a lot of context,let me tell you, depending on
who I've been talking to peoplefor the past two weeks about
this.
And depending on who you talkto, depending on how long
they've been in the community,depending on who they know, you
(02:12):
hear very different things.
It's and that's why we're hereto talk about it.
But here's what happenedtimeline.
All right.
So with air quotes, don't forgetwith air quotes.
Yep.
Like Rachel said, there's a lotof stuff that happened prior to
this, right?
But what happened?
So Ruby Central is being accusedof a hostile takeover on
(02:35):
RubyGems and Bundler.
On September 9th, a maintainerof RubyGems renamed RubyGems on
GitHub, the GitHub organizationto Ruby Central and added Marty
Hot to the admins, and all theother admins were removed.
All the other maintainers wereremoved.
On the 15th, permissions weremostly restored after some
(02:56):
outcry.
And Marty still retainedownership of the GitHub
Enterprise account.
On September 18th, permissionswere revoked for all maintainers
for the repos and the packages.
And that's when we startedseeing posts from Ellen where
they're like Ruby Central hasjust executed a hostile takeover
over RubyGems and Bundler.
(03:18):
That's the timeline-ish of whathappened, quote unquote.
SPEAKER_03 (03:23):
And then everyone went crazy.
I feel like was the next stepbecause that's where things got
a little weird afterwards, whereit wasn't just this happened,
all of a sudden everyone had athought, an opinion, a theory on
why this was happening, but theywere presenting it like this is
what happened, this is why RubyCentral did this, but with no
(03:48):
source, no, here is who I spoketo at this organization, that
organization that confirmedthis.
It was just theories, and itbecame really difficult to
determine what actually wasgoing on because there were so
many people that are pretty wellknown in the community that had
a thought and opinion, but waspresenting it as fact.
(04:11):
And that's where I think most ofyou and and me talking was about
like, hey, did you read this?
What do you think about that?
Because it contradicts thisreport or that.
What were you seeing, Rachel?
SPEAKER_00 (04:23):
I saw a lot.
I think one of the big things,at least for me, is like
tracking back even like priortimeline stuff, going back to
like the Ruby Together merger.
Like there was talk about like,oh, the Ruby Together merger
doesn't have like Ruby gems init and stuff like that.
I think one of the things thatwe haven't talked about is
supposedly Joel Draper has, andI kind of believe this, a
(04:46):
recorded video from a meetingthat happened on September 17th
between the maintainers andMarty, where Marty kind of steps
in and says, Hey, y'all need tosign an operator agreement.
And they claim that RubyGems andRubyGems.org are two separate
entities, that they don't needto sign the operator agreement.
And that happened a day beforethe existing maintainers were
(05:08):
removed permanently for thesecond time.
That one is one they agree with.
But also there's like anotherone that I think is actually
kind of important here.
September 14th is when thatRubyGems governance PR shows up,
the one that they're working onwith Mike McQuaid.
I think that's an importantpoint as well.
I would also say that that oneoccurred after everybody was
(05:30):
removed from the repository.
SPEAKER_02 (05:33):
The reason that Ruby Central said that they did this
was for supply chain security.
That's their thing.
They've been sticking to it.
They're like, we are doing thisto ensure the supply chain
security.
Now there's financial thingsbehind the scenes that we'll get
into, but also going back notonly to the Ruby Central Ruby
(05:54):
Together merger, but also RubyCentral lost a large$250,000 a
year sponsorship that they weregetting.
And that sponsorship then leftthem pretty much solely
dependent on Shopify as the solebank, I guess, for like a lot of
these services and like whatRuby Central is doing.
SPEAKER_00 (06:16):
I think that's agreed upon by pretty much both
sides.
Everybody agrees.
Ruby Central put out a blog postbasically on August 1st saying
that they're relying on Shopifysidekick and grants as their
main source of income.
They were straight up like, hey,we need individual sponsors.
And I think it's somewhere wasthe$1,000,$3,000,$5,000 tiers
(06:37):
where they were like, hey, ifyou as an individual company can
chip in this way, that wouldhelp support us.
And from what I've heard, theydid not get the support that
they needed from that.
SPEAKER_02 (06:46):
Well, then you can take this all the way back to
the Atlanta Rails Conf where atthe very final keynote, Ruby
Central got on stage and they'relike, hey, by the way, we have
this like personal sponsorshipthing.
If you do it, like you'll getaccess to this Discord.
And it kind of left everyonelike, what the heck just
happened?
Like, is there a problem?
Is like Ruby Central needfunding?
Like this was like out ofnowhere.
(07:06):
There was no communication aboutit, which I feel like no matter
how you're gonna slice thisstory of who's at fault for what
and like who did what, RubyCentral poorly communicated at
every aspect.
And that's not something new,like that's something that has
been an ongoing thing.
SPEAKER_03 (07:24):
Yeah, big time.
I think Ruby Central'scommunication issues is sort of
what got them anywhere close toa funding issue from the get-go.
Like when I found out that whatRuby Central was doing with the
funds they were raising fromconferences or sponsorships, I
was surprised as a member of theRuby community, not knowing and
(07:46):
understanding what they did.
And I started assuming no oneelse knew.
And it turned out I was prettymuch right because almost
everyone I spoke to about whyconference tickets were
expensive, why supporting RubyCentral was important, all of
this stuff.
When I was like, oh yeah, theyhelp pay for the RubyGem service
and they help pay maintainers ofRubyGem and Bundler and support
(08:08):
the development, people werelike, Oh, I didn't know that.
And it was like, Yeah, neitherdid I, because Ruby Central was
really bad about communicatingwhy they're important.
So it's not necessarilysurprising that this whole
debacle, even if you believeevery version of the story out
(08:29):
there, even the false ones, likethey all stem from Ruby Central
did a shit job communicatingthat something was happening and
needed to be done and all thisstuff.
And then it was like all afterthe fact.
There was a blog post, thenthere was a recording, and then
like two weeks later, there wasanother blog post.
And everything they said in theblog post seemed reasonable, but
(08:49):
it was just so far after thefact, it was like, did you guys
need to come up with the excuseof why this was important?
Not that like you said, Andrew,they said this was supply chain
security stuff, which I think issuper important.
I don't think that's an excuse,but saying it so far out, like,
hey, before we remove anyone'saccess, in the next few weeks,
(09:13):
we're gonna be cracking down onsecurity, just a heads up.
Oh well, I don't know why thatwasn't said from the get-go.
SPEAKER_00 (09:20):
And I feel like the supply chain security, I feel
like that's very valid.
And I'm also of the opinion, andI know this is something that's
been really hotly debated, andlike I know this is a
controversial take, but Istrongly believe that RubyGems,
Bunler, and RubyGems.org allbelong to Ruby Central since the
Ruby Together merger.
(09:42):
If they didn't, then that meansthat Ruby Together
misrepresented to the communitywhat they were doing and the
responsibilities they had.
I would even go so far as to saythat the merger, which happened
because RubyTogether ran out ofmoney.
I would even go so far as to saythat that merger probably would
not, may not have happened ifRubyTogether hadn't represented
(10:03):
themselves as the maintainers ofBunler and RubyGems.
Whether or not Ruby Together'sownership is valid, I strongly
believe that Ruby Central, whenthey took on Ruby Together,
believed that RubyGems andBunler and RubyGems.org were
entering their responsibilityand ownership.
SPEAKER_02 (10:27):
So that's one of the reasons why I wanted some people
on who had more time in thecommunity, shall we say?
Because in my mind, as someonewho has been in this community
since 2018-2019, Ruby Central isin charge of RubyGems and
Bundler.
From my understanding, like theypay for the service, they pay
the maintainers, they contractmaintainers, this and that.
(10:50):
And it wasn't until this wholedebacle where it was like, oh,
well, there's a differencebetween the RubyGems.org service
and the RubyGems.org code andthe Bundler and the RubyGems
code.
I'm like, wait, wait, what,what, what, what?
So, and like Drew said, like,depending on who you talk to,
like, some of them may knowthat, or some of them may not.
And from Ruby Central side, whatthey've said specifically is
(11:12):
that they carry all the legalliability, the financial
exposure, and the operationalrisk of the RubyGems service.
And to me, it's like, okay,well, the service is directly
tied to the code, is it not?
So that was like my initial takeon it.
It was like, we saw whathappened with NPM recently.
They went under massive supplychain attacks, right?
(11:34):
So Ruby Central is claiming thatlook, our corporate sponsors,
and we now know they kind ofonly have one, are pressuring us
into doing like we have thissystem of governance where it's
like this is a community, peoplehave been doing it for a long
time.
A lot of things are unspoken.
You know, people are in thepositions they are, not because
they were elected necessarily,but because of like time in the
(11:55):
community or like just noveltyor experience or whatever.
And RubyGem seems to be pushingmuch more to this corporate
governance structure where likewe need SLAs, we need these
things, we need contributoragreements, and we need these
things because corporations arerequiring us to be able to prove
that we are secure and not openthese supply chain attacks, and
(12:17):
we have a timeline, and that'swhy we have to do this now.
That was another thing that wasdebated, which was maintainers
were saying we were blindsidedby this, but Ruby Central have
been saying, no, we were intalks with them, and this was
supposed to be temporary, butthese talks had stalled out and
this deadline was approaching,and like people weren't giving
in, and there was some ego inthere, and we had to take this
(12:39):
drastic action because we justdidn't get to a consensus.
And our hope is that all thesepeople who no longer have access
get their access back, but theyneed to sign these contributor
agreements, these SLAs, allthese things to like have access
to these things, so much morecorporate governance structure.
SPEAKER_03 (12:58):
Which sounds, I don't know, as stupid, might be
the wrong term, but like youhear like this corporate red
tape BS and you kind of getfrustrated with it.
But I think it's also importantto note that like many of the
executive directors of RubyCentral in the past have been
Rubyists who just loved thecommunity and wanted to help and
were willing to step up intothis ridiculously difficult role
(13:21):
and do the best they could.
They're engineers and they'redevelopers, and they're not
someone familiar with running anonprofit organization.
And now, since Adarsh left, wenow have a new executive
director who's less than a yearin, who is much less technical
(13:42):
than past directors, but is waymore experienced with running
nonprofits and all of thecompliance that comes along, not
just from like, hey, we'retaking money from corporate
sponsors and stuff, but just,hey, we have money, and here's
how we have to keep our books,and here's how we have to ensure
that we maintain our nonprofitstatus and stuff.
So there are things that RubyCentral may not have been in
(14:05):
compliance for some of thesethings for the longest time.
And she comes in and goes, Oh,we need to fix stuff.
That could be one of the mainmotivators here, too.
In addition to, yeah, hey, we'redown to like one major sponsor,
and they've got their like, youneed to get your compliance in
order by X date.
Because I'm sure Shopify usesRubyGems a lot.
SPEAKER_00 (14:27):
Well, it's interesting because we're
talking about Shopify and we'retalking about compliance, but
there's actually another reallybig sponsor at play here, which
is Alpha Omega, and they'rereally focused on security.
Also, Alpha Omega is part oflike a group that talks about
the stewardship of open sourcepackage managers.
So they signed on on January1st, and that's when Marty
(14:50):
actually became full-timedirector of open source and
full-time started working onBundler and RubyGems and became
the lead of those two projects.
And they also ensured that SamGiddens could stay on.
But we're talking aboutcompliance and like bringing
things up to compliance.
March 20th was when they added aterms of service privacy notice,
(15:11):
acceptable use and copyrightpolicy to RubyGems.org.
That's wild to me because I havelike a little side project that
has like 15 users, and I'mlooking at a terms of service.
So the fact that RubyGems, whichis like the backbone of our Ruby
infrastructure, did not havethis prior to March of this
(15:33):
year.
I really want to point out thatMarty is the one who like
started working with legal andlike started to bring that in
and operationalize this.
So clearly he does have aresponsibility and he is working
on security and he is engagingwith these teams and talking to
them.
He's not an outsider.
Like he is involved withRubyGems and Bundler and making
(15:56):
sure that they are secure andbringing them into the secure
policy position.
SPEAKER_03 (16:01):
And for what it's worth, and this is completely
personal opinion, but Marty'sbeen in the community forever
and cares deeply about thecommunity.
So when people were talkingabout it being a hostile
takeover and that Marty wasinvolved, I was like, there is
no way that it was like thismalicious, hostile takeover.
I curse on my show, so I'm gonnacurse on this one.
(16:22):
Fuck you all.
Move if Marty was involved,because he cares deeply about
this community and he caresdeeply about the ecosystem and
keeping Ruby an extremelyaccessible language for
everybody.
And there's just no way he wouldbe part of any kind of like
malicious intent takeover.
(16:42):
Not saying that there wasn'tcommunication breakdowns or that
it could have been done better,but again, Marty is an engineer
by trade.
He's not necessarily, I believe,is his first time being like an
open source manager director ofanything.
It sometimes learning hurts.
SPEAKER_02 (17:00):
Yeah, I think when this all started to unfurl, like
I know Marty.
Like I've talked to Marty, I'vemet him at conferences, like
I've seen him at everyconference.
I just didn't believe right outthe gate, it was like I just
don't see Marty as a maliciousperson at all.
Do I think that he could havedone what he did because he was
(17:22):
told to, because of a board votethat was possibly malicious,
maybe, but I don't believe thatanything Marty did was out of
maliciousness at all.
So once everything got revoked,people started posting online,
we started hearing claims aboutthis is happening.
I think everyone in thecommunity first got an idea,
(17:44):
like, oh crap, this is even athing.
Like I didn't even know this isa thing because it kind of came
out of nowhere.
And then we got a lot ofdiscussion about whether or not
people behind the scenes aredoing this for security, or if
this is actually a front fortaking over the repositories,
for kicking out certainmaintainers, for doing
something.
(18:04):
And I've seen a lot of takes onthat, and I guess they're
plausible.
I've yet to see a convincingargument as to why the
motivation behind why that wouldbe something they would want to
do.
SPEAKER_03 (18:16):
Some of those takes feel conspiracy theory-like,
where it's like, oh, this personand that person never got along.
So if this person is nowinvolved or contributing money,
they might be contributingenough money to say, I'll only
contribute this if you get ridof this maintainer.
And I don't know.
Maybe there's a level of moneythat someone could contribute to
(18:39):
make that happen, but it doesn'treally sound like something that
would happen at Ruby Centralscale.
Maybe I'm wrong, but again,without proof, without someone
from Ruby Central confirming,yeah, we were getting rid of
this person because our newsponsor doesn't like them,
that's your theory.
(19:00):
That's not a fact.
And I think that's an importantthing that everyone needs to
remember as they're commentingon this is like anything you
think may be going on is yourtheory.
It is not a fact until you getit verified from multiple
sources.
SPEAKER_02 (19:15):
Right out the gate, there was a lot of claims, there
was a lot of emotion is seenmixed into it.
And at the end of the day, wedon't know who the trustworthy
narrators are.
We know some of these people whoare putting out this stuff,
we've had interactions withother people, we've heard things
about them.
So, depending on who posts what,I take a very different like
stance because of built-inbiases towards that person.
(19:36):
So we don't really know.
Like, we've had a lot of claims.
Now, I think like one of themain things was that this kind
of all comes down to who ownsthis community project.
Ruby Central claims that theyhave the responsibility after
the Ruby Together merger, andthat's directly contradicted.
(19:56):
There's like this weirddistinction between the service
and owning the code, and likethe service not being the code,
which to me, the service is thecode that you just put on a
server somewhere.
So that was the other thing thatgot really confusing about all
this.
It was like, well, you guysdon't own the code, the
community owns the code, or weown the code.
And it's like, but who'sresponsible for it?
(20:18):
And that's where this all gotweird.
It's like, well, Ruby Centralruns a service, and that's not
the same as the code.
And that's gotten reallyconfusing for me.
unknown (20:27):
Yeah.
SPEAKER_00 (20:28):
To me, that governance PR and its timing is
really an important point in thetimeline because that governance
PR was added after they wereremoved and Mike McQuaid stepped
in to like speak on behalf ofthe maintainers, which to me
signals that there was nogovernance in place, which
matches kind of like what we'reseeing, where there are some
(20:51):
operational issues with RubyGemsand RubyGems.org, where people
have elevated permissions thatthey really shouldn't have for
something that can like.
I want to be like super clearhere.
If RubyGems.org goes down,Bundler does not work, and the
entire Ruby ecosystem stopsuntil it comes back up again.
None of the GitHub actions arerunning, none of the like CI is
(21:15):
running, people can't set up acode base for the first time.
Really, the whole Ruby ecosystemgrinds to a halt when this is
down.
And we actually saw that happena few years back where there was
an issue where it went down andeverything.
I'm trying to remember exactlywhen it was, but we did actually
see it go down and how thatimpacted it.
SPEAKER_02 (21:35):
And governments relying on this code, right?
Like, let's be very clear.
Like, there is Ruby running insatellites, there's Ruby
powering government websites andlike across the world.
It's not a small thing to belike, oh, well, it's down.
SPEAKER_03 (21:50):
It's like that XKCD comic where it's like the
entirety of the internet andit's a stack of blocks, and it's
this one little block over here.
It's like some unknown, unpaid,underappreciated maintainer.
We had this, what was it?
The was it the left pad incidentwhere like someone yanked a
version of a I think it was anNPM package, and it just blew up
(22:12):
half the internet.
It was crazy.
And we can't let that happenwith RubyGems.
To be clear, I'm very much prohey, security and compliance and
like reasonable securitymeasures for RubyGems the
service, RubyGems the code,bundler code, and all that.
My concern in this entiresituation is like the
(22:36):
communication, what actuallyhappened?
Why was it done the way that itwas?
I don't know if we're ever goingto get those answers.
I hope we do, but it's been acrazy couple of weeks.
SPEAKER_00 (22:47):
Yeah, I think the communication around this was
really rough.
And the execution could probablyhave been improved as well,
because it looks like one ofthose previous maintainers still
remained retained access toproduction systems.
But I think the idea of lockingdown security and I think the
ownership of Ruby jumpsbelonging to Ruby Central, like
both of those are incrediblyreasonable things.
SPEAKER_02 (23:10):
When I was thinking about this more, I was like,
when you think about it, onesingle maintainer was allowed to
rename the GitHub organization,the Enterprise Organization.
They were allowed to removeevery other person from the
project and install a new admin.
And that by itself isproblematic to me, right?
Because if that person hadaccidentally clicked on the
(23:32):
wrong link one day, that couldbe executed maliciously.
But that's just kind of argumentto the fact of like, look, there
are some holes in the securityof the system, and like there's
definitely valid reasoning forwanting to like clamp down on
that.
Now, is that valid reasoningjust an excuse, or is that just
(23:54):
what is actually happening?
SPEAKER_00 (23:56):
And I think that we can use Ruby Central's past
actions, adding that terms ofservice, ensuring they have a
security engineer, all of that.
We can use that to indicate thatRuby Central was focused on
securing RubyGems and they havethis prior work that proves that
that is what they've been doing.
And actually, if you go look attheir blog and you look at their
(24:18):
posts, ever since Marty Joy andthey've started like really
upping the posts that they haveabout RubyGems.org and what
they're doing and the changesthat they're making.
So we're seeing a lot moreinsight into what was happening
than we were before.
SPEAKER_02 (24:30):
It's just a shame the marketing person that they
had recently left.
And you, Rachel, you mentionedSam Gidden the other earlier as
the like main security person.
He's also left from RubyCentral.
And one of the arguments wasthat doing this, you did this
all in the claim of security,but you've actually made
everything less secure becauseyou've let go of the people who
(24:52):
had the most knowledge of thatsecurity, not just Sam, but like
specific maintainers who arelike, they know the security of
RubyGems.
Like that's what their thing.
So you've let go of thesepeople, and people are claiming
that RubyGems is effectivelyunmaintained right now.
Ruby Central is claiming theopposite.
There were claims that Shopifyengineers were put on call at
(25:14):
Ruby Central to like handlethese services, but I don't
think we really know whetherthat was true or not.
But at the end of the day, likeeveryone was removed, so you
kind of have to start fresh.
And if you need thesecontributor agreements signed,
then if people don't want tosign them, which I've seen takes
from people who are like, I'mnot signing that, and I don't
(25:34):
really understand that, butwhatever floats your boat, I
guess.
Then it kind of all boils downto like, I think Ruby is in
general kind of considerthemselves to be like this
scrappy little hobby language,and we're on the frontier and
we're cowboys and we do whateverwe want.
But at the end of the day, likeit's kind of grown a lot more
than that.
Like there are corporationsdepending on this.
(25:56):
There's money involved, there'slitigation involved, there's
responsibility involved, andit's almost like, oh, remember
back in my day when people arelike, this was a community
thing.
Well, it's not anymore becausethings rely on this.
We have to have this up, and ithas to be secure.
SPEAKER_03 (26:13):
We also used to install gems by running a curl
command that would just bringstuff from the internet to our
system and run a shell script toinstall it.
So maybe some progress herewould be a good thing for
security.
Also, from a couple of thedifferent timelines I read, Sam
left prior to this incident,right?
(26:33):
He left early September beforethis all happened.
SPEAKER_02 (26:36):
I think he actually might have even left in late
August.
Okay.
SPEAKER_00 (26:41):
I haven't on my timeline at September 5th.
SPEAKER_02 (26:43):
September?
Okay.
Okay.
I think he announced that he wasleaving in August and had like
served out like a month orsomething.
Yeah.
SPEAKER_00 (26:51):
I'd like to step back to this idea that Ruby Jams
is unmaintained.
They have kept two people whowere employed by Ruby Central,
Hiroshi and Colby for sure.
And I think they were talkingabout others.
But from what I can tell, fromthe list of maintainers that I
got, and the problem is likethere's a group of maintainers
(27:11):
that's got like 38 people on it,and there's a shorter
maintainers.txt.
And if you look at the shortlist of maintainers, the
shortest one I could find,pretty much all of them were
paid by Ruby Central at somepoint.
Which means that like the onesthat were removed were people
who were like ex-Ruby Central orleft afterwards.
But at least two of them areformer maintainers.
(27:34):
They do have the coverage.
And Marty himself has actuallymade merge some PRs.
Not many, but a couple.
Did y'all see the posts thatMike McQuaid posted where he
went through each of thecontributors and like basically
ran homebrew stats on them?
SPEAKER_03 (27:49):
No, I didn't.
Yes, I did.
I didn't go deep into his postkind of like ran the numbers and
then sort of stopped.
And I didn't do my own analysison the numbers.
I was sort of like waiting forpost number two where he's like,
here's from my very experiencedperspective what this means.
(28:10):
But I did see the post, yeah.
SPEAKER_00 (28:13):
Yeah, his summary was basically like there were
people in all groups, peoplethat were removed that shouldn't
have been, people that weren'tremoved that should have been,
people that were removed andshouldn't have been.
Basically, like according tohomebrew's rules of who a
maintainer is, there were peoplein all of those categories.
SPEAKER_02 (28:32):
It seems like at least the three of us agree that
security is important.
Right?
We can all agree.
SPEAKER_03 (28:41):
I'd like to think more than just the three of us
would agree on that, but is thatnot the argument?
SPEAKER_02 (28:46):
Is the argument like, okay, what they did isn't
necessarily so much the problemas how they did it.
SPEAKER_03 (28:53):
Sure.
I mean, that definitely could bean argument.
And I think it even goes back tomore of did Ruby Central have
the right to do what they did?
That depends on how theownership of RubyGems and
Bundler was described to RubyCentral during the RubyTogether
(29:15):
merger, which there areconflicting reports on whether
or not RubyGems and Bundler wereincluded in that merger if Ruby
Together had the right toinclude it in the merger.
All I know is for as long as Ican remember, Ruby Central has
been putting money towards themaintenance and ongoing
(29:36):
development and security ofRubyGems and Bundler.
So it sounds to me like they hadat least a reasonable claim.
SPEAKER_00 (29:46):
Yeah, and the README for both RubyGems and Bundler,
both of those, and by the way,Bundler is inside RubyGems, but
the README says that thisproject is managed by Ruby
Central.
To me, in the Absence ofadditional governance documents
that say, like, this belongs tothese people, and here's how we
define these people, and here'show we remove these people.
(30:08):
To me, that says what it is.
And also, I've seen reports frompeople who are like, Yeah, I
found out that I still had AWSaccess, or through this, I was
actually removed as well, and Ihadn't worked on this in years.
So this does sound like it was apermissions cleanup.
It does follow right on theheels of two major project
leaders leaving Ruby Central.
(30:30):
And so I think in my eyes,that's kind of what triggered
this is they sat there andthey're like, hey, we have these
people who are leaving RubyCentral.
We should really lock downsecurity over who owns this and
who can take over this repo.
Because, like you said, Andrew,it's kind of scary that like one
maintainer was able to take overthe backbone of the Ruby
(30:50):
ecosystem.
Everybody was just like, okay, Iguess we're locked out now.
According to principles of leastprivilege, that's how it should
go.
And also, from a securitymindset, I think sitting there
and looking and saying, like,hey, these are ex employees of
Ruby Central, we should reallymake sure that they don't have
access if they don't need it.
SPEAKER_02 (31:09):
I mean, I keep harking back to this point that
Ruby Central carries the legalliability, the financial
exposure, and the operationalrisk for it.
But like he's it's a weird, it'sa one of those things, you know.
It's like there's this communityaspect of it, and that kind of
seems to have been basicallydesecrated and destroyed by this
(31:30):
player.
We've had key maintainers aregone.
It seems like a lot of trust isbroken.
And Ruby Central knew they hadalternatives to do this, right?
Because they even talked aboutforking the repo.
Now, when I think about that,that to me seems like a bigger
problem/slash hassle than whatthey did.
Like to me, forking the repo isalmost even a bigger issue of
(31:52):
like something's wrong, wronghere.
But we have to pay for theservice.
And if companies aren'tsponsoring Ruby Central to pay
for this service, which itobviously seems like there's
not, if they're basicallybeholden to one main sponsor,
then we either accept thatcorporate governance or I even
hesitate to say this, build analternative.
SPEAKER_00 (32:15):
A lot of people have talked about a hard fork.
This is purely like my opinionon this one.
I think that if they'd done ahard fork, people would have
been just as upset because theybasically would have stepped in
and said, like, we've hardforked, and I think people would
have claimed that they werestealing the code.
And I think it would have alsolent legitimacy to the idea that
Ruby Central does not haveownership over Ruby Gems in one
(32:37):
layer.
I think that people probablywould have said, like, oh, you
know, that's their code, youneed to continue doing that.
And I think part of this islike, I think you're right.
I think it's the communicationaspect.
And I think the containers werelike really upset to be locked
out of this.
But I don't think a hard forkwould have fixed anything.
I think part of it is like,you're locked out, you're no
(32:59):
longer responsible for this.
You spent a large portion ofyour life working on it.
And I think they would have feltthat way if it was just like, we
forked it, we've taken the code,you're no longer invited, and
we're deploying this version ofit, and Ruby is pulling this
version in.
So now you're over there workingon an outdated fork that isn't
being used or deployed or pulledby anyone.
SPEAKER_02 (33:22):
Yeah, and then that code could diverge.
Who knows?
That just opens up a whole newswath of issues versus the ones
that they opened by doing this.
SPEAKER_03 (33:31):
Right.
It's the same intense emotionsgoverning everyone's reactions
rather than looking at it asthis needed to get done for
security, for compliance.
There's money to pay maintainersand run the service involved
here.
And not saying that the way theywent around doing it was the
best way, their communicationobviously sucked and they
(33:55):
probably shot themselves in thefoot, hopefully, not in an
unrecoverable way, butdefinitely in the short term, in
a big way.
But I think that if you look atit without the emotion of I've
poured my blood, sweat, andtears into this repo, and you
just yanked my permissions, thatemotion's going to exist,
whether the permissions areremoved or we hard fork it.
(34:16):
If you avoid the emotions thatcome along with that, I think it
becomes a lot more of a wow,Ruby Central, you kind of suck
at communicating.
Please do better and less of ahostile takeover.
SPEAKER_02 (34:31):
Yeah, because now you have these maintainers who
are burnt out and they feelalienated from this long, like
they're maybe even life work,but they're at least long-term
work.
I've also heard a bunch ofpeople say there's this big
disconnect between the RubyCentral board, Ruby Central
leadership, and then the peopleactually doing the work at Ruby
(34:52):
Central.
SPEAKER_03 (34:53):
Yeah, I can definitely understand that.
It's been brought up before howwhenever there's a spot open on
the board, it's the leadershipteam that kind of goes through
the applicants and kind of picksthe one that they think fills
the role the best, which I canunderstand, but also to a point
(35:13):
where it's like maybe that's nothow it should be done.
Maybe the board should becommunity vote of we want this
person on the board to representus as the community so that the
leadership team is not alsocontrolling the board.
And maybe that will help improvethings.
I don't know.
I've never run a nonprofitbefore.
I'm just a developer.
SPEAKER_02 (35:34):
It is a good point to the argument that a lot of
people are claiming, like, I'mnot even gonna sugarcoat it,
that Shopify is doing all this,that they're creating these
things, and that DHH is behindthe scenes because he's on the
Shopify board.
And I'm not even gonna bring himinto this because he's got
nothing to do with this.
He's got nothing to do with theimmediate facts of this, as far
(35:54):
as I can tell.
But a lot of the people onleadership or on the board,
people are arguing are from acertain company that also
happens to sponsor, basicallypay for this service.
Well, how did they get there?
Is it not impossible to get onthe board?
Like, I don't know.
SPEAKER_00 (36:14):
Ruby Central has actually done two different
rounds of like recruiting boardmembers.
Because if you think about it,this is unpaid work.
Like, this is all volunteer workbeing on the board.
When Ruby Central actually hadmoney, there was like a small
stipend that they would kind oflike offer people, but that's
been gone for the last couple ofyears because they haven't had
money.
Everybody on the board isvolunteered.
(36:35):
Also, Ruby Central like cannotdo right in the eyes of the
community, basically.
People are either ignoring whatthey're doing or they're angry
about what they're doing.
There's no in-between.
There's no like, hey, you know,we would like, no, it's just
we're super angry or we don'tknow what you're doing, we don't
pay attention, we're not buyingmemberships.
SPEAKER_03 (36:55):
Because everything's working.
SPEAKER_00 (36:57):
Exactly.
And I'm kind of sitting here andlike you're talking about having
a vote for board members.
I'm kind of sitting herethinking, like, if we were to do
a vote, maybe it would makesense for that to be a vote from
members of Ruby Central over whoshould represent them.
And maybe that offers acompelling reason to have that
$20 Ruby Central membership.
SPEAKER_02 (37:18):
I could agree with that.
I could definitely get on boardwith that.
That's a really good point.
Someone should be taking noteson that.
Unless I'm missing anything, andI'm both of y'all can chime in
if I have, I think we've kind ofreached the overall like kind of
timeline of like what's happenedand the theories as to why.
SPEAKER_03 (37:38):
I mean, at least from my understanding and the
things that I've read.
Again, I haven't talked toanyone one-on-one that was
directly involved with this.
All I'm basing all of mythoughts and theories on are all
of the blog posts that I'veread, whether they were hardcore
Ruby Central's the villain, orhardcore you all need to
(38:01):
understand Ruby Central's notthe villain, this person's the
villain, or you're just notunderstanding, or some mix in
between and my understandings ofthe people involved.
I see it as a very graysituation where a lot of people
involved screwed up and it couldhave been done better at
(38:23):
multiple levels, but I have yetto see evidence supporting that
this was malicious.
So that's my take.
SPEAKER_00 (38:31):
I think a lot of people are painting this as like
a takeover.
It's hostile, it's this, it'sthat.
I do think it was securityfocused.
And also, I think we shouldprobably cut Ruby Central some
slack because I'm even seeingpeople call for like the end of
Ruby Central or a replacementfor Ruby Central.
And like I'm on board for likeadding more to the Ruby
community, more fundingorganizations, more support,
(38:54):
more package managers, all thatsort of stuff.
When it comes to ending RubyCentral, I'm kind of like, I
don't think that they should bedestroyed for having poor
communication around somethingthat they did have the right to
do.
SPEAKER_03 (39:09):
Agreed.
And I would love to see oneperson calling for the end of
Ruby Central who has beenwilling to step up in the past
and serve in that executivedirector position that they were
hiring for, who has tried to geton the board, who's made any
kind of good faith effort toparticipate in Ruby Central in
(39:29):
order to help steer it in thedirection they want this new
organization to go towards.
I don't know.
A lot of people have a lot ofopinions, and some of them suck.
SPEAKER_02 (39:45):
When I started this, I was like, look, I'm gonna try
to give an unbiased take on whathappened, and I think we've
mostly done that.
And I guess my core takeaway islike this is sad.
It doesn't feel as big as thePython two to three like
debacle, but it feels like thisis definitely created a rift in
(40:06):
the community.
The dust has definitely notsettled on this, things are
still up in the air.
Like, I had been talking aboutdoing this episode since like
last week, right?
And I'm glad that we waited tillnow to actually do it because so
much has come out in that timefrom both sides.
So, like, this is an ongoingthing.
There's a lot of emotions andthere's ego involved, there's
(40:28):
money involved, there'scorporate sponsors involved,
there's a lot of questions andlike motives that we are getting
hypotheses on, but don't trulyknow.
There's a lot of people tryingto stir up drama, and some of
that it makes a lot of sensebased on who they are.
But at the end of the day, thisis kind of like it feels like a
cautionary tale for any opensource ecosystem that relies on
(40:53):
corporate funding.
Because at the end of the day,whether they're being forced to
or they're just being like, hey,you should do this, and maybe if
you don't, we'll revoke thatfunding.
It forces us to ask thisuncomfortable question about the
power and the money and whotruly gets to decide over the
future of these tools, who trulyowns code that's been built by
(41:15):
the community.
And I guess I'm just kind oflike, what's next?
Are we going to be able torecover from this?
Is this going to continue to bea rift?
At the end of the day, it's anet loss for the community
overall because we've lost allthese maintainers.
There are other people who arelike, Yeah, I was a provider
operator and I'm no longerwilling to do that.
I'm not willing to sign thecontributor agreements or
(41:37):
whatever.
So at the end of the day, it'sjust sad all around that this
had to happen.
I don't know who's at fault.
It seems like everyone's atfault so far.
And everyone's just pointing thefingers at each other.
SPEAKER_03 (41:49):
And to your point of like, we waited at least a week,
if not longer, from when wefirst talked about potentially
recording our take, not even ourtake, just like our
interpretation of the timelinesand blog posts and everything.
So much has come out.
I'm sure more stuff's going tocome out.
I reserve the right to change myopinion and my take on
everything that I've said,because this is just my
(42:10):
understanding based on theinformation I've been receiving.
If some of that informationcomes out and it's like, this
was wildly false, and here'scontradictory real evidence.
I a hundred percent reserve myright to change my opinion.
It's a strong opinion, but it'svery loosely held.
And I think that's an importantstance for everyone to take is
(42:31):
like read all you can, takeeverything with a grain of salt,
question everything, and beready to change your opinion on
this very continually ongoingsituation.
SPEAKER_00 (42:42):
I think everyone involved is like a good person
who's trying their best for theRuby community.
On one side, we have people thatare trying to make it more
secure.
On the other side, we havemaintainers who've contributed
their lives and like a hugechunk of their careers to
improving this service.
It's just in this particularcase what they wanted and what
(43:04):
their goals were were inconflict.
Ruby Central is over there andthey're like, we need to secure
this.
We need operator agreements, weneed to make sure that nobody
can come in and take over thisrepo and we need to protect it
as strongly as possible.
Ruby already has this reputationas a dead language, as a slow
language, and we cannot affordto be an insecure language as
(43:29):
well.
And I think on the other side,you have maintainers who care
about who we're paid to, right?
So there's a job aspect of thisas well, and who wanted to drive
this forward and make it better.
And maybe there was some poorjudgment involved on the best
way to do that.
And also some poorcommunication.
(43:50):
Like I'm sure having your accessrevoked and then having someone
come in and say, like, hey, we'dlike you to sign contributor
agreements to get it back.
That's not a fun way to havethat happen.
And I think that we don't havethe full timeline from Ruby
Central either.
And there's been some likeconflict around what
communication they did do.
We know one recording exists ofthis meeting.
(44:14):
We don't know what othermeetings happened before it or
what other conversationshappened before or around it.
We just know that this onemeeting exists, and we know it
exists from the side that isupset at Ruby Central as well.
SPEAKER_02 (44:27):
Why aren't these board meetings public?
Why don't we know about them?
Like, why can't we know what'sgoing on?
SPEAKER_03 (44:36):
I don't know the answer to that.
Maybe because of the sensitivenature of the development of I
don't know.
SPEAKER_02 (44:44):
See, I would want to but see that would open up more
questions.
But again, like I said, they'revery gonna no matter what, Ruby
Central has a communicationissue.
No matter what, no matter howyou slice this, they fucked up.
I'm sorry to the childrenlistening.
You leave my F-bombs in there,Paul.
SPEAKER_01 (45:06):
Those kids, they're just hungry for Ruby drama, they
care deeply about like packagemanagers and the security of the
community, those six-year-olds,Andrew.
SPEAKER_02 (45:15):
I just specifically remember a comment that Jason
harped on one time because itwas like, I listened to this
show with my kids in the car andy'all cussing, blah, blah, blah,
blah, blah.
Anyway, we can bring this traininto the station.
Drew, do you have any finalthoughts?
And if not, tell people wherethey can find you online and
(45:36):
keep up with you.
SPEAKER_03 (45:38):
My final thought is less of a thought because I feel
like I've made my thoughtsclear, but a more of a request,
and it kind of piggybacks off ofsomething you were saying.
Is like there's still a lot ofquestions.
So ask questions, keep askingquestions, keep asking questions
of both sides.
Ask the questions in good faith,but don't run with wild
(46:02):
accusations.
Don't have a theory and post itlike it's a fact.
Don't post a timeline where youput something in that is
unverified because you're justmuddying the water.
You're making everything moredifficult.
And we as the community need toget this figured out so we can
move forward.
Whatever that looks like, Idon't know.
I'm not that smart, but we doneed to move forward in whatever
(46:23):
way that looks like.
And wild baseless accusationsaren't helping, but questions
do.
I can be found.
My website's drbrag2gs.dev.
I have a podcast code and thecode encoders who code it.
I help run Philly RB.
I work at podia with Andrew.
I can be found a variety ofways.
SPEAKER_00 (46:44):
Had everybody a little bit of Slack.
If you want the Ruby CentralBoard to start sharing minutes,
give them a little bit of spaceand a little bit of trust and a
little bit of slack so that theyfeel safe enough to do so.
Everybody in this cares aboutthe Ruby community and they want
to make it a better place.
So give them a little bit oftrust in that.
(47:07):
If you agree with my takes, youcan find me at Shell Codes on
Blue Sky and Twitch.
If you disagree with my takes,you can find me at Andrew M.
Codes.
SPEAKER_02 (47:17):
Oh that's good.
That's a good one.
Whoa.
That's a Jason level troll rightthere.
I want to thank both of y'allfor coming on like immensely.
Like, I have been thinking aboutthis for a while, and I was
like, I don't want to do thisalone.
And you both were like, yeah,I'll do it with you.
(47:38):
So I just want to say thank youboth for coming on and sharing
your takes and doing theresearch and I don't know, just
caring, I guess.
We all three of us care aboutRuby and RubyGems and Bundler,
and we care about thesemaintainers because we know how
much we owe them.
And we also care about securityand the service staying up.
(47:59):
So I guess my final take is thatthings are still up in the air.
Drew, I think said it perfectly.
Like you are allowed to demandaccountability and to ask
questions.
And I don't think that'sunhealthy at all.
But a lot of the dramafear-mongering stuff, I think,
is unhelpful.
But at the end of the day, thisis something that is important,
(48:22):
right?
Because this could fundamentallytear the ecosystem if we're not
careful.
And I don't think any of us wantthat to happen.
So I think more people need tostop blogging about things and
start trying to figure out whatthey can actually do to help
improve the community, improvethe situation, improve the
services, et cetera, et cetera.
So that's the end of this.
(48:44):
Hopefully, Chris comes back soonbecause I miss him, but I hope
he is enjoying his time off.
Thank you everyone to listeningfor Ruby, and I will catch you
all next week.
Welcome to a special code and the coding coders who
code it.
I'm your host, AI Drew Bragg.
The real Drew is on the roadthis week.
So here's a Remote Ruby Collabpodcast that Drew was on talking
about all the Ruby centraldrama.
Enjoy.
SPEAKER_02 (00:15):
Hello everyone.
Welcome back to Remote Ruby.
I am Chrisless today, whichfeels weird.
I feel almost naked because Ihave never done this without
Chris, I don't think, or Jason.
But in order to not be trulyexposed today, I have brought
two friends to the show and Iwill let them both introduce
themselves now, starting withDrew.
SPEAKER_03 (00:36):
Hello, everyone.
I'm Drew.
You may know me from the host ofCode and the Code Encoders Who
Code It.
I will be releasing this episodealso on my timeline.
So maybe you're hearing me fromthat timeline.
But if not, you're listening toRemote Ruby, my favorite
podcast.
So welcome.
SPEAKER_00 (00:54):
Hi, I'm Rachel Reitman.
I go by Chail Codes Online,longtime listener, first time on
the podcast.
SPEAKER_02 (00:59):
I met Rachel at a conference recently, and I was
like, you're a cool person.
I'm gonna keep you in the backof my mind for like whenever a
situation like this arises.
So it's perfect.
So we're just gonna kind of begoing over what's been happening
in Ruby the past few weeks.
Why did something happen?
SPEAKER_03 (01:18):
Maybe I'll give a quick timeline of what happened
and then whose timeline?
This is my problem with what'sbeen going on is depending on
your source, the timeline is alittle different every time.
So I'm interested to hear yourtimeline.
And then I want to hear Rachel'stimeline.
And we'll give the publictimeline.
(01:39):
Okay.
Go ahead, Rachel.
SPEAKER_02 (01:41):
What were you gonna say?
SPEAKER_00 (01:42):
I was gonna say I feel like the timeline for this
starts way before any of thesepeople are setting it, way back
when when the merger betweenRuby Together and Ruby Central
happened.
SPEAKER_02 (01:51):
I would agree with that.
That's why I also wanted morepeople on the show because
there's a lot of context to thisthat like I don't have because
of how long I've been in thecommunity.
And there's a lot of context,let me tell you, depending on
who I've been talking to peoplefor the past two weeks about
this.
And depending on who you talkto, depending on how long
they've been in the community,depending on who they know, you
(02:12):
hear very different things.
It's and that's why we're hereto talk about it.
But here's what happenedtimeline.
All right.
So with air quotes, don't forgetwith air quotes.
Yep.
Like Rachel said, there's a lotof stuff that happened prior to
this, right?
But what happened?
So Ruby Central is being accusedof a hostile takeover on
(02:35):
RubyGems and Bundler.
On September 9th, a maintainerof RubyGems renamed RubyGems on
GitHub, the GitHub organizationto Ruby Central and added Marty
Hot to the admins, and all theother admins were removed.
All the other maintainers wereremoved.
On the 15th, permissions weremostly restored after some
(02:56):
outcry.
And Marty still retainedownership of the GitHub
Enterprise account.
On September 18th, permissionswere revoked for all maintainers
for the repos and the packages.
And that's when we startedseeing posts from Ellen where
they're like Ruby Central hasjust executed a hostile takeover
over RubyGems and Bundler.
(03:18):
That's the timeline-ish of whathappened, quote unquote.
SPEAKER_03 (03:23):
And then everyone went crazy.
I feel like was the next stepbecause that's where things got
a little weird afterwards, whereit wasn't just this happened,
all of a sudden everyone had athought, an opinion, a theory on
why this was happening, but theywere presenting it like this is
what happened, this is why RubyCentral did this, but with no
(03:48):
source, no, here is who I spoketo at this organization, that
organization that confirmedthis.
It was just theories, and itbecame really difficult to
determine what actually wasgoing on because there were so
many people that are pretty wellknown in the community that had
a thought and opinion, but waspresenting it as fact.
(04:11):
And that's where I think most ofyou and and me talking was about
like, hey, did you read this?
What do you think about that?
Because it contradicts thisreport or that.
What were you seeing, Rachel?
SPEAKER_00 (04:23):
I saw a lot.
I think one of the big things,at least for me, is like
tracking back even like priortimeline stuff, going back to
like the Ruby Together merger.
Like there was talk about like,oh, the Ruby Together merger
doesn't have like Ruby gems init and stuff like that.
I think one of the things thatwe haven't talked about is
supposedly Joel Draper has, andI kind of believe this, a
(04:46):
recorded video from a meetingthat happened on September 17th
between the maintainers andMarty, where Marty kind of steps
in and says, Hey, y'all need tosign an operator agreement.
And they claim that RubyGems andRubyGems.org are two separate
entities, that they don't needto sign the operator agreement.
And that happened a day beforethe existing maintainers were
(05:08):
removed permanently for thesecond time.
That one is one they agree with.
But also there's like anotherone that I think is actually
kind of important here.
September 14th is when thatRubyGems governance PR shows up,
the one that they're working onwith Mike McQuaid.
I think that's an importantpoint as well.
I would also say that that oneoccurred after everybody was
(05:30):
removed from the repository.
SPEAKER_02 (05:33):
The reason that Ruby Central said that they did this
was for supply chain security.
That's their thing.
They've been sticking to it.
They're like, we are doing thisto ensure the supply chain
security.
Now there's financial thingsbehind the scenes that we'll get
into, but also going back notonly to the Ruby Central Ruby
(05:54):
Together merger, but also RubyCentral lost a large$250,000 a
year sponsorship that they weregetting.
And that sponsorship then leftthem pretty much solely
dependent on Shopify as the solebank, I guess, for like a lot of
these services and like whatRuby Central is doing.
SPEAKER_00 (06:16):
I think that's agreed upon by pretty much both
sides.
Everybody agrees.
Ruby Central put out a blog postbasically on August 1st saying
that they're relying on Shopifysidekick and grants as their
main source of income.
They were straight up like, hey,we need individual sponsors.
And I think it's somewhere wasthe$1,000,$3,000,$5,000 tiers
(06:37):
where they were like, hey, ifyou as an individual company can
chip in this way, that wouldhelp support us.
And from what I've heard, theydid not get the support that
they needed from that.
SPEAKER_02 (06:46):
Well, then you can take this all the way back to
the Atlanta Rails Conf where atthe very final keynote, Ruby
Central got on stage and they'relike, hey, by the way, we have
this like personal sponsorshipthing.
If you do it, like you'll getaccess to this Discord.
And it kind of left everyonelike, what the heck just
happened?
Like, is there a problem?
Is like Ruby Central needfunding?
Like this was like out ofnowhere.
(07:06):
There was no communication aboutit, which I feel like no matter
how you're gonna slice thisstory of who's at fault for what
and like who did what, RubyCentral poorly communicated at
every aspect.
And that's not something new,like that's something that has
been an ongoing thing.
SPEAKER_03 (07:24):
Yeah, big time.
I think Ruby Central'scommunication issues is sort of
what got them anywhere close toa funding issue from the get-go.
Like when I found out that whatRuby Central was doing with the
funds they were raising fromconferences or sponsorships, I
was surprised as a member of theRuby community, not knowing and
(07:46):
understanding what they did.
And I started assuming no oneelse knew.
And it turned out I was prettymuch right because almost
everyone I spoke to about whyconference tickets were
expensive, why supporting RubyCentral was important, all of
this stuff.
When I was like, oh yeah, theyhelp pay for the RubyGem service
and they help pay maintainers ofRubyGem and Bundler and support
(08:08):
the development, people werelike, Oh, I didn't know that.
And it was like, Yeah, neitherdid I, because Ruby Central was
really bad about communicatingwhy they're important.
So it's not necessarilysurprising that this whole
debacle, even if you believeevery version of the story out
(08:29):
there, even the false ones, likethey all stem from Ruby Central
did a shit job communicatingthat something was happening and
needed to be done and all thisstuff.
And then it was like all afterthe fact.
There was a blog post, thenthere was a recording, and then
like two weeks later, there wasanother blog post.
And everything they said in theblog post seemed reasonable, but
(08:49):
it was just so far after thefact, it was like, did you guys
need to come up with the excuseof why this was important?
Not that like you said, Andrew,they said this was supply chain
security stuff, which I think issuper important.
I don't think that's an excuse,but saying it so far out, like,
hey, before we remove anyone'saccess, in the next few weeks,
(09:13):
we're gonna be cracking down onsecurity, just a heads up.
Oh well, I don't know why thatwasn't said from the get-go.
SPEAKER_00 (09:20):
And I feel like the supply chain security, I feel
like that's very valid.
And I'm also of the opinion, andI know this is something that's
been really hotly debated, andlike I know this is a
controversial take, but Istrongly believe that RubyGems,
Bunler, and RubyGems.org allbelong to Ruby Central since the
Ruby Together merger.
(09:42):
If they didn't, then that meansthat Ruby Together
misrepresented to the communitywhat they were doing and the
responsibilities they had.
I would even go so far as to saythat the merger, which happened
because RubyTogether ran out ofmoney.
I would even go so far as to saythat that merger probably would
not, may not have happened ifRubyTogether hadn't represented
(10:03):
themselves as the maintainers ofBunler and RubyGems.
Whether or not Ruby Together'sownership is valid, I strongly
believe that Ruby Central, whenthey took on Ruby Together,
believed that RubyGems andBunler and RubyGems.org were
entering their responsibilityand ownership.
SPEAKER_02 (10:27):
So that's one of the reasons why I wanted some people
on who had more time in thecommunity, shall we say?
Because in my mind, as someonewho has been in this community
since 2018-2019, Ruby Central isin charge of RubyGems and
Bundler.
From my understanding, like theypay for the service, they pay
the maintainers, they contractmaintainers, this and that.
(10:50):
And it wasn't until this wholedebacle where it was like, oh,
well, there's a differencebetween the RubyGems.org service
and the RubyGems.org code andthe Bundler and the RubyGems
code.
I'm like, wait, wait, what,what, what, what?
So, and like Drew said, like,depending on who you talk to,
like, some of them may knowthat, or some of them may not.
And from Ruby Central side, whatthey've said specifically is
(11:12):
that they carry all the legalliability, the financial
exposure, and the operationalrisk of the RubyGems service.
And to me, it's like, okay,well, the service is directly
tied to the code, is it not?
So that was like my initial takeon it.
It was like, we saw whathappened with NPM recently.
They went under massive supplychain attacks, right?
(11:34):
So Ruby Central is claiming thatlook, our corporate sponsors,
and we now know they kind ofonly have one, are pressuring us
into doing like we have thissystem of governance where it's
like this is a community, peoplehave been doing it for a long
time.
A lot of things are unspoken.
You know, people are in thepositions they are, not because
they were elected necessarily,but because of like time in the
(11:55):
community or like just noveltyor experience or whatever.
And RubyGem seems to be pushingmuch more to this corporate
governance structure where likewe need SLAs, we need these
things, we need contributoragreements, and we need these
things because corporations arerequiring us to be able to prove
that we are secure and not openthese supply chain attacks, and
(12:17):
we have a timeline, and that'swhy we have to do this now.
That was another thing that wasdebated, which was maintainers
were saying we were blindsidedby this, but Ruby Central have
been saying, no, we were intalks with them, and this was
supposed to be temporary, butthese talks had stalled out and
this deadline was approaching,and like people weren't giving
in, and there was some ego inthere, and we had to take this
(12:39):
drastic action because we justdidn't get to a consensus.
And our hope is that all thesepeople who no longer have access
get their access back, but theyneed to sign these contributor
agreements, these SLAs, allthese things to like have access
to these things, so much morecorporate governance structure.
SPEAKER_03 (12:58):
Which sounds, I don't know, as stupid, might be
the wrong term, but like youhear like this corporate red
tape BS and you kind of getfrustrated with it.
But I think it's also importantto note that like many of the
executive directors of RubyCentral in the past have been
Rubyists who just loved thecommunity and wanted to help and
were willing to step up intothis ridiculously difficult role
(13:21):
and do the best they could.
They're engineers and they'redevelopers, and they're not
someone familiar with running anonprofit organization.
And now, since Adarsh left, wenow have a new executive
director who's less than a yearin, who is much less technical
(13:42):
than past directors, but is waymore experienced with running
nonprofits and all of thecompliance that comes along, not
just from like, hey, we'retaking money from corporate
sponsors and stuff, but just,hey, we have money, and here's
how we have to keep our books,and here's how we have to ensure
that we maintain our nonprofitstatus and stuff.
So there are things that RubyCentral may not have been in
(14:05):
compliance for some of thesethings for the longest time.
And she comes in and goes, Oh,we need to fix stuff.
That could be one of the mainmotivators here, too.
In addition to, yeah, hey, we'redown to like one major sponsor,
and they've got their like, youneed to get your compliance in
order by X date.
Because I'm sure Shopify usesRubyGems a lot.
SPEAKER_00 (14:27):
Well, it's interesting because we're
talking about Shopify and we'retalking about compliance, but
there's actually another reallybig sponsor at play here, which
is Alpha Omega, and they'rereally focused on security.
Also, Alpha Omega is part oflike a group that talks about
the stewardship of open sourcepackage managers.
So they signed on on January1st, and that's when Marty
(14:50):
actually became full-timedirector of open source and
full-time started working onBundler and RubyGems and became
the lead of those two projects.
And they also ensured that SamGiddens could stay on.
But we're talking aboutcompliance and like bringing
things up to compliance.
March 20th was when they added aterms of service privacy notice,
(15:11):
acceptable use and copyrightpolicy to RubyGems.org.
That's wild to me because I havelike a little side project that
has like 15 users, and I'mlooking at a terms of service.
So the fact that RubyGems, whichis like the backbone of our Ruby
infrastructure, did not havethis prior to March of this
(15:33):
year.
I really want to point out thatMarty is the one who like
started working with legal andlike started to bring that in
and operationalize this.
So clearly he does have aresponsibility and he is working
on security and he is engagingwith these teams and talking to
them.
He's not an outsider.
Like he is involved withRubyGems and Bundler and making
(15:56):
sure that they are secure andbringing them into the secure
policy position.
SPEAKER_03 (16:01):
And for what it's worth, and this is completely
personal opinion, but Marty'sbeen in the community forever
and cares deeply about thecommunity.
So when people were talkingabout it being a hostile
takeover and that Marty wasinvolved, I was like, there is
no way that it was like thismalicious, hostile takeover.
I curse on my show, so I'm gonnacurse on this one.
(16:22):
Fuck you all.
Move if Marty was involved,because he cares deeply about
this community and he caresdeeply about the ecosystem and
keeping Ruby an extremelyaccessible language for
everybody.
And there's just no way he wouldbe part of any kind of like
malicious intent takeover.
(16:42):
Not saying that there wasn'tcommunication breakdowns or that
it could have been done better,but again, Marty is an engineer
by trade.
He's not necessarily, I believe,is his first time being like an
open source manager director ofanything.
It sometimes learning hurts.
SPEAKER_02 (17:00):
Yeah, I think when this all started to unfurl, like
I know Marty.
Like I've talked to Marty, I'vemet him at conferences, like
I've seen him at everyconference.
I just didn't believe right outthe gate, it was like I just
don't see Marty as a maliciousperson at all.
Do I think that he could havedone what he did because he was
(17:22):
told to, because of a board votethat was possibly malicious,
maybe, but I don't believe thatanything Marty did was out of
maliciousness at all.
So once everything got revoked,people started posting online,
we started hearing claims aboutthis is happening.
I think everyone in thecommunity first got an idea,
(17:44):
like, oh crap, this is even athing.
Like I didn't even know this isa thing because it kind of came
out of nowhere.
And then we got a lot ofdiscussion about whether or not
people behind the scenes aredoing this for security, or if
this is actually a front fortaking over the repositories,
for kicking out certainmaintainers, for doing
something.
(18:04):
And I've seen a lot of takes onthat, and I guess they're
plausible.
I've yet to see a convincingargument as to why the
motivation behind why that wouldbe something they would want to
do.
SPEAKER_03 (18:16):
Some of those takes feel conspiracy theory-like,
where it's like, oh, this personand that person never got along.
So if this person is nowinvolved or contributing money,
they might be contributingenough money to say, I'll only
contribute this if you get ridof this maintainer.
And I don't know.
Maybe there's a level of moneythat someone could contribute to
(18:39):
make that happen, but it doesn'treally sound like something that
would happen at Ruby Centralscale.
Maybe I'm wrong, but again,without proof, without someone
from Ruby Central confirming,yeah, we were getting rid of
this person because our newsponsor doesn't like them,
that's your theory.
(19:00):
That's not a fact.
And I think that's an importantthing that everyone needs to
remember as they're commentingon this is like anything you
think may be going on is yourtheory.
It is not a fact until you getit verified from multiple
sources.
SPEAKER_02 (19:15):
Right out the gate, there was a lot of claims, there
was a lot of emotion is seenmixed into it.
And at the end of the day, wedon't know who the trustworthy
narrators are.
We know some of these people whoare putting out this stuff,
we've had interactions withother people, we've heard things
about them.
So, depending on who posts what,I take a very different like
stance because of built-inbiases towards that person.
(19:36):
So we don't really know.
Like, we've had a lot of claims.
Now, I think like one of themain things was that this kind
of all comes down to who ownsthis community project.
Ruby Central claims that theyhave the responsibility after
the Ruby Together merger, andthat's directly contradicted.
(19:56):
There's like this weirddistinction between the service
and owning the code, and likethe service not being the code,
which to me, the service is thecode that you just put on a
server somewhere.
So that was the other thing thatgot really confusing about all
this.
It was like, well, you guysdon't own the code, the
community owns the code, or weown the code.
And it's like, but who'sresponsible for it?
(20:18):
And that's where this all gotweird.
It's like, well, Ruby Centralruns a service, and that's not
the same as the code.
And that's gotten reallyconfusing for me.
unknown (20:27):
Yeah.
SPEAKER_00 (20:28):
To me, that governance PR and its timing is
really an important point in thetimeline because that governance
PR was added after they wereremoved and Mike McQuaid stepped
in to like speak on behalf ofthe maintainers, which to me
signals that there was nogovernance in place, which
matches kind of like what we'reseeing, where there are some
(20:51):
operational issues with RubyGemsand RubyGems.org, where people
have elevated permissions thatthey really shouldn't have for
something that can like.
I want to be like super clearhere.
If RubyGems.org goes down,Bundler does not work, and the
entire Ruby ecosystem stopsuntil it comes back up again.
None of the GitHub actions arerunning, none of the like CI is
(21:15):
running, people can't set up acode base for the first time.
Really, the whole Ruby ecosystemgrinds to a halt when this is
down.
And we actually saw that happena few years back where there was
an issue where it went down andeverything.
I'm trying to remember exactlywhen it was, but we did actually
see it go down and how thatimpacted it.
SPEAKER_02 (21:35):
And governments relying on this code, right?
Like, let's be very clear.
Like, there is Ruby running insatellites, there's Ruby
powering government websites andlike across the world.
It's not a small thing to belike, oh, well, it's down.
SPEAKER_03 (21:50):
It's like that XKCD comic where it's like the
entirety of the internet andit's a stack of blocks, and it's
this one little block over here.
It's like some unknown, unpaid,underappreciated maintainer.
We had this, what was it?
The was it the left pad incidentwhere like someone yanked a
version of a I think it was anNPM package, and it just blew up
(22:12):
half the internet.
It was crazy.
And we can't let that happenwith RubyGems.
To be clear, I'm very much prohey, security and compliance and
like reasonable securitymeasures for RubyGems the
service, RubyGems the code,bundler code, and all that.
My concern in this entiresituation is like the
(22:36):
communication, what actuallyhappened?
Why was it done the way that itwas?
I don't know if we're ever goingto get those answers.
I hope we do, but it's been acrazy couple of weeks.
SPEAKER_00 (22:47):
Yeah, I think the communication around this was
really rough.
And the execution could probablyhave been improved as well,
because it looks like one ofthose previous maintainers still
remained retained access toproduction systems.
But I think the idea of lockingdown security and I think the
ownership of Ruby jumpsbelonging to Ruby Central, like
both of those are incrediblyreasonable things.
SPEAKER_02 (23:10):
When I was thinking about this more, I was like,
when you think about it, onesingle maintainer was allowed to
rename the GitHub organization,the Enterprise Organization.
They were allowed to removeevery other person from the
project and install a new admin.
And that by itself isproblematic to me, right?
Because if that person hadaccidentally clicked on the
(23:32):
wrong link one day, that couldbe executed maliciously.
But that's just kind of argumentto the fact of like, look, there
are some holes in the securityof the system, and like there's
definitely valid reasoning forwanting to like clamp down on
that.
Now, is that valid reasoningjust an excuse, or is that just
(23:54):
what is actually happening?
SPEAKER_00 (23:56):
And I think that we can use Ruby Central's past
actions, adding that terms ofservice, ensuring they have a
security engineer, all of that.
We can use that to indicate thatRuby Central was focused on
securing RubyGems and they havethis prior work that proves that
that is what they've been doing.
And actually, if you go look attheir blog and you look at their
(24:18):
posts, ever since Marty Joy andthey've started like really
upping the posts that they haveabout RubyGems.org and what
they're doing and the changesthat they're making.
So we're seeing a lot moreinsight into what was happening
than we were before.
SPEAKER_02 (24:30):
It's just a shame the marketing person that they
had recently left.
And you, Rachel, you mentionedSam Gidden the other earlier as
the like main security person.
He's also left from RubyCentral.
And one of the arguments wasthat doing this, you did this
all in the claim of security,but you've actually made
everything less secure becauseyou've let go of the people who
(24:52):
had the most knowledge of thatsecurity, not just Sam, but like
specific maintainers who arelike, they know the security of
RubyGems.
Like that's what their thing.
So you've let go of thesepeople, and people are claiming
that RubyGems is effectivelyunmaintained right now.
Ruby Central is claiming theopposite.
There were claims that Shopifyengineers were put on call at
(25:14):
Ruby Central to like handlethese services, but I don't
think we really know whetherthat was true or not.
But at the end of the day, likeeveryone was removed, so you
kind of have to start fresh.
And if you need thesecontributor agreements signed,
then if people don't want tosign them, which I've seen takes
from people who are like, I'mnot signing that, and I don't
(25:34):
really understand that, butwhatever floats your boat, I
guess.
Then it kind of all boils downto like, I think Ruby is in
general kind of considerthemselves to be like this
scrappy little hobby language,and we're on the frontier and
we're cowboys and we do whateverwe want.
But at the end of the day, likeit's kind of grown a lot more
than that.
Like there are corporationsdepending on this.
(25:56):
There's money involved, there'slitigation involved, there's
responsibility involved, andit's almost like, oh, remember
back in my day when people arelike, this was a community
thing.
Well, it's not anymore becausethings rely on this.
We have to have this up, and ithas to be secure.
SPEAKER_03 (26:13):
We also used to install gems by running a curl
command that would just bringstuff from the internet to our
system and run a shell script toinstall it.
So maybe some progress herewould be a good thing for
security.
Also, from a couple of thedifferent timelines I read, Sam
left prior to this incident,right?
(26:33):
He left early September beforethis all happened.
SPEAKER_02 (26:36):
I think he actually might have even left in late
August.
Okay.
SPEAKER_00 (26:41):
I haven't on my timeline at September 5th.
SPEAKER_02 (26:43):
September?
Okay.
Okay.
I think he announced that he wasleaving in August and had like
served out like a month orsomething.
Yeah.
SPEAKER_00 (26:51):
I'd like to step back to this idea that Ruby Jams
is unmaintained.
They have kept two people whowere employed by Ruby Central,
Hiroshi and Colby for sure.
And I think they were talkingabout others.
But from what I can tell, fromthe list of maintainers that I
got, and the problem is likethere's a group of maintainers
(27:11):
that's got like 38 people on it,and there's a shorter
maintainers.txt.
And if you look at the shortlist of maintainers, the
shortest one I could find,pretty much all of them were
paid by Ruby Central at somepoint.
Which means that like the onesthat were removed were people
who were like ex-Ruby Central orleft afterwards.
But at least two of them areformer maintainers.
(27:34):
They do have the coverage.
And Marty himself has actuallymade merge some PRs.
Not many, but a couple.
Did y'all see the posts thatMike McQuaid posted where he
went through each of thecontributors and like basically
ran homebrew stats on them?
SPEAKER_03 (27:49):
No, I didn't.
Yes, I did.
I didn't go deep into his postkind of like ran the numbers and
then sort of stopped.
And I didn't do my own analysison the numbers.
I was sort of like waiting forpost number two where he's like,
here's from my very experiencedperspective what this means.
(28:10):
But I did see the post, yeah.
SPEAKER_00 (28:13):
Yeah, his summary was basically like there were
people in all groups, peoplethat were removed that shouldn't
have been, people that weren'tremoved that should have been,
people that were removed andshouldn't have been.
Basically, like according tohomebrew's rules of who a
maintainer is, there were peoplein all of those categories.
SPEAKER_02 (28:32):
It seems like at least the three of us agree that
security is important.
Right?
We can all agree.
SPEAKER_03 (28:41):
I'd like to think more than just the three of us
would agree on that, but is thatnot the argument?
SPEAKER_02 (28:46):
Is the argument like, okay, what they did isn't
necessarily so much the problemas how they did it.
SPEAKER_03 (28:53):
Sure.
I mean, that definitely could bean argument.
And I think it even goes back tomore of did Ruby Central have
the right to do what they did?
That depends on how theownership of RubyGems and
Bundler was described to RubyCentral during the RubyTogether
(29:15):
merger, which there areconflicting reports on whether
or not RubyGems and Bundler wereincluded in that merger if Ruby
Together had the right toinclude it in the merger.
All I know is for as long as Ican remember, Ruby Central has
been putting money towards themaintenance and ongoing
(29:36):
development and security ofRubyGems and Bundler.
So it sounds to me like they hadat least a reasonable claim.
SPEAKER_00 (29:46):
Yeah, and the README for both RubyGems and Bundler,
both of those, and by the way,Bundler is inside RubyGems, but
the README says that thisproject is managed by Ruby
Central.
To me, in the Absence ofadditional governance documents
that say, like, this belongs tothese people, and here's how we
define these people, and here'show we remove these people.
(30:08):
To me, that says what it is.
And also, I've seen reports frompeople who are like, Yeah, I
found out that I still had AWSaccess, or through this, I was
actually removed as well, and Ihadn't worked on this in years.
So this does sound like it was apermissions cleanup.
It does follow right on theheels of two major project
leaders leaving Ruby Central.
(30:30):
And so I think in my eyes,that's kind of what triggered
this is they sat there andthey're like, hey, we have these
people who are leaving RubyCentral.
We should really lock downsecurity over who owns this and
who can take over this repo.
Because, like you said, Andrew,it's kind of scary that like one
maintainer was able to take overthe backbone of the Ruby
(30:50):
ecosystem.
Everybody was just like, okay, Iguess we're locked out now.
According to principles of leastprivilege, that's how it should
go.
And also, from a securitymindset, I think sitting there
and looking and saying, like,hey, these are ex employees of
Ruby Central, we should reallymake sure that they don't have
access if they don't need it.
SPEAKER_02 (31:09):
I mean, I keep harking back to this point that
Ruby Central carries the legalliability, the financial
exposure, and the operationalrisk for it.
But like he's it's a weird, it'sa one of those things, you know.
It's like there's this communityaspect of it, and that kind of
seems to have been basicallydesecrated and destroyed by this
(31:30):
player.
We've had key maintainers aregone.
It seems like a lot of trust isbroken.
And Ruby Central knew they hadalternatives to do this, right?
Because they even talked aboutforking the repo.
Now, when I think about that,that to me seems like a bigger
problem/slash hassle than whatthey did.
Like to me, forking the repo isalmost even a bigger issue of
(31:52):
like something's wrong, wronghere.
But we have to pay for theservice.
And if companies aren'tsponsoring Ruby Central to pay
for this service, which itobviously seems like there's
not, if they're basicallybeholden to one main sponsor,
then we either accept thatcorporate governance or I even
hesitate to say this, build analternative.
SPEAKER_00 (32:15):
A lot of people have talked about a hard fork.
This is purely like my opinionon this one.
I think that if they'd done ahard fork, people would have
been just as upset because theybasically would have stepped in
and said, like, we've hardforked, and I think people would
have claimed that they werestealing the code.
And I think it would have alsolent legitimacy to the idea that
Ruby Central does not haveownership over Ruby Gems in one
(32:37):
layer.
I think that people probablywould have said, like, oh, you
know, that's their code, youneed to continue doing that.
And I think part of this islike, I think you're right.
I think it's the communicationaspect.
And I think the containers werelike really upset to be locked
out of this.
But I don't think a hard forkwould have fixed anything.
I think part of it is like,you're locked out, you're no
(32:59):
longer responsible for this.
You spent a large portion ofyour life working on it.
And I think they would have feltthat way if it was just like, we
forked it, we've taken the code,you're no longer invited, and
we're deploying this version ofit, and Ruby is pulling this
version in.
So now you're over there workingon an outdated fork that isn't
being used or deployed or pulledby anyone.
SPEAKER_02 (33:22):
Yeah, and then that code could diverge.
Who knows?
That just opens up a whole newswath of issues versus the ones
that they opened by doing this.
SPEAKER_03 (33:31):
Right.
It's the same intense emotionsgoverning everyone's reactions
rather than looking at it asthis needed to get done for
security, for compliance.
There's money to pay maintainersand run the service involved
here.
And not saying that the way theywent around doing it was the
best way, their communicationobviously sucked and they
(33:55):
probably shot themselves in thefoot, hopefully, not in an
unrecoverable way, butdefinitely in the short term, in
a big way.
But I think that if you look atit without the emotion of I've
poured my blood, sweat, andtears into this repo, and you
just yanked my permissions, thatemotion's going to exist,
whether the permissions areremoved or we hard fork it.
(34:16):
If you avoid the emotions thatcome along with that, I think it
becomes a lot more of a wow,Ruby Central, you kind of suck
at communicating.
Please do better and less of ahostile takeover.
SPEAKER_02 (34:31):
Yeah, because now you have these maintainers who
are burnt out and they feelalienated from this long, like
they're maybe even life work,but they're at least long-term
work.
I've also heard a bunch ofpeople say there's this big
disconnect between the RubyCentral board, Ruby Central
leadership, and then the peopleactually doing the work at Ruby
(34:52):
Central.
SPEAKER_03 (34:53):
Yeah, I can definitely understand that.
It's been brought up before howwhenever there's a spot open on
the board, it's the leadershipteam that kind of goes through
the applicants and kind of picksthe one that they think fills
the role the best, which I canunderstand, but also to a point
(35:13):
where it's like maybe that's nothow it should be done.
Maybe the board should becommunity vote of we want this
person on the board to representus as the community so that the
leadership team is not alsocontrolling the board.
And maybe that will help improvethings.
I don't know.
I've never run a nonprofitbefore.
I'm just a developer.
SPEAKER_02 (35:34):
It is a good point to the argument that a lot of
people are claiming, like, I'mnot even gonna sugarcoat it,
that Shopify is doing all this,that they're creating these
things, and that DHH is behindthe scenes because he's on the
Shopify board.
And I'm not even gonna bring himinto this because he's got
nothing to do with this.
He's got nothing to do with theimmediate facts of this, as far
(35:54):
as I can tell.
But a lot of the people onleadership or on the board,
people are arguing are from acertain company that also
happens to sponsor, basicallypay for this service.
Well, how did they get there?
Is it not impossible to get onthe board?
Like, I don't know.
SPEAKER_00 (36:14):
Ruby Central has actually done two different
rounds of like recruiting boardmembers.
Because if you think about it,this is unpaid work.
Like, this is all volunteer workbeing on the board.
When Ruby Central actually hadmoney, there was like a small
stipend that they would kind oflike offer people, but that's
been gone for the last couple ofyears because they haven't had
money.
Everybody on the board isvolunteered.
(36:35):
Also, Ruby Central like cannotdo right in the eyes of the
community, basically.
People are either ignoring whatthey're doing or they're angry
about what they're doing.
There's no in-between.
There's no like, hey, you know,we would like, no, it's just
we're super angry or we don'tknow what you're doing, we don't
pay attention, we're not buyingmemberships.
SPEAKER_03 (36:55):
Because everything's working.
SPEAKER_00 (36:57):
Exactly.
And I'm kind of sitting here andlike you're talking about having
a vote for board members.
I'm kind of sitting herethinking, like, if we were to do
a vote, maybe it would makesense for that to be a vote from
members of Ruby Central over whoshould represent them.
And maybe that offers acompelling reason to have that
$20 Ruby Central membership.
SPEAKER_02 (37:18):
I could agree with that.
I could definitely get on boardwith that.
That's a really good point.
Someone should be taking noteson that.
Unless I'm missing anything, andI'm both of y'all can chime in
if I have, I think we've kind ofreached the overall like kind of
timeline of like what's happenedand the theories as to why.
SPEAKER_03 (37:38):
I mean, at least from my understanding and the
things that I've read.
Again, I haven't talked toanyone one-on-one that was
directly involved with this.
All I'm basing all of mythoughts and theories on are all
of the blog posts that I'veread, whether they were hardcore
Ruby Central's the villain, orhardcore you all need to
(38:01):
understand Ruby Central's notthe villain, this person's the
villain, or you're just notunderstanding, or some mix in
between and my understandings ofthe people involved.
I see it as a very graysituation where a lot of people
involved screwed up and it couldhave been done better at
(38:23):
multiple levels, but I have yetto see evidence supporting that
this was malicious.
So that's my take.
SPEAKER_00 (38:31):
I think a lot of people are painting this as like
a takeover.
It's hostile, it's this, it'sthat.
I do think it was securityfocused.
And also, I think we shouldprobably cut Ruby Central some
slack because I'm even seeingpeople call for like the end of
Ruby Central or a replacementfor Ruby Central.
And like I'm on board for likeadding more to the Ruby
community, more fundingorganizations, more support,
(38:54):
more package managers, all thatsort of stuff.
When it comes to ending RubyCentral, I'm kind of like, I
don't think that they should bedestroyed for having poor
communication around somethingthat they did have the right to
do.
SPEAKER_03 (39:09):
Agreed.
And I would love to see oneperson calling for the end of
Ruby Central who has beenwilling to step up in the past
and serve in that executivedirector position that they were
hiring for, who has tried to geton the board, who's made any
kind of good faith effort toparticipate in Ruby Central in
(39:29):
order to help steer it in thedirection they want this new
organization to go towards.
I don't know.
A lot of people have a lot ofopinions, and some of them suck.
SPEAKER_02 (39:45):
When I started this, I was like, look, I'm gonna try
to give an unbiased take on whathappened, and I think we've
mostly done that.
And I guess my core takeaway islike this is sad.
It doesn't feel as big as thePython two to three like
debacle, but it feels like thisis definitely created a rift in
(40:06):
the community.
The dust has definitely notsettled on this, things are
still up in the air.
Like, I had been talking aboutdoing this episode since like
last week, right?
And I'm glad that we waited tillnow to actually do it because so
much has come out in that timefrom both sides.
So, like, this is an ongoingthing.
There's a lot of emotions andthere's ego involved, there's
(40:28):
money involved, there'scorporate sponsors involved,
there's a lot of questions andlike motives that we are getting
hypotheses on, but don't trulyknow.
There's a lot of people tryingto stir up drama, and some of
that it makes a lot of sensebased on who they are.
But at the end of the day, thisis kind of like it feels like a
cautionary tale for any opensource ecosystem that relies on
(40:53):
corporate funding.
Because at the end of the day,whether they're being forced to
or they're just being like, hey,you should do this, and maybe if
you don't, we'll revoke thatfunding.
It forces us to ask thisuncomfortable question about the
power and the money and whotruly gets to decide over the
future of these tools, who trulyowns code that's been built by
(41:15):
the community.
And I guess I'm just kind oflike, what's next?
Are we going to be able torecover from this?
Is this going to continue to bea rift?
At the end of the day, it's anet loss for the community
overall because we've lost allthese maintainers.
There are other people who arelike, Yeah, I was a provider
operator and I'm no longerwilling to do that.
I'm not willing to sign thecontributor agreements or
(41:37):
whatever.
So at the end of the day, it'sjust sad all around that this
had to happen.
I don't know who's at fault.
It seems like everyone's atfault so far.
And everyone's just pointing thefingers at each other.
SPEAKER_03 (41:49):
And to your point of like, we waited at least a week,
if not longer, from when wefirst talked about potentially
recording our take, not even ourtake, just like our
interpretation of the timelinesand blog posts and everything.
So much has come out.
I'm sure more stuff's going tocome out.
I reserve the right to change myopinion and my take on
everything that I've said,because this is just my
(42:10):
understanding based on theinformation I've been receiving.
If some of that informationcomes out and it's like, this
was wildly false, and here'scontradictory real evidence.
I a hundred percent reserve myright to change my opinion.
It's a strong opinion, but it'svery loosely held.
And I think that's an importantstance for everyone to take is
(42:31):
like read all you can, takeeverything with a grain of salt,
question everything, and beready to change your opinion on
this very continually ongoingsituation.
SPEAKER_00 (42:42):
I think everyone involved is like a good person
who's trying their best for theRuby community.
On one side, we have people thatare trying to make it more
secure.
On the other side, we havemaintainers who've contributed
their lives and like a hugechunk of their careers to
improving this service.
It's just in this particularcase what they wanted and what
(43:04):
their goals were were inconflict.
Ruby Central is over there andthey're like, we need to secure
this.
We need operator agreements, weneed to make sure that nobody
can come in and take over thisrepo and we need to protect it
as strongly as possible.
Ruby already has this reputationas a dead language, as a slow
language, and we cannot affordto be an insecure language as
(43:29):
well.
And I think on the other side,you have maintainers who care
about who we're paid to, right?
So there's a job aspect of thisas well, and who wanted to drive
this forward and make it better.
And maybe there was some poorjudgment involved on the best
way to do that.
And also some poorcommunication.
(43:50):
Like I'm sure having your accessrevoked and then having someone
come in and say, like, hey, we'dlike you to sign contributor
agreements to get it back.
That's not a fun way to havethat happen.
And I think that we don't havethe full timeline from Ruby
Central either.
And there's been some likeconflict around what
communication they did do.
We know one recording exists ofthis meeting.
(44:14):
We don't know what othermeetings happened before it or
what other conversationshappened before or around it.
We just know that this onemeeting exists, and we know it
exists from the side that isupset at Ruby Central as well.
SPEAKER_02 (44:27):
Why aren't these board meetings public?
Why don't we know about them?
Like, why can't we know what'sgoing on?
SPEAKER_03 (44:36):
I don't know the answer to that.
Maybe because of the sensitivenature of the development of I
don't know.
SPEAKER_02 (44:44):
See, I would want to but see that would open up more
questions.
But again, like I said, they'revery gonna no matter what, Ruby
Central has a communicationissue.
No matter what, no matter howyou slice this, they fucked up.
I'm sorry to the childrenlistening.
You leave my F-bombs in there,Paul.
SPEAKER_01 (45:06):
Those kids, they're just hungry for Ruby drama, they
care deeply about like packagemanagers and the security of the
community, those six-year-olds,Andrew.
SPEAKER_02 (45:15):
I just specifically remember a comment that Jason
harped on one time because itwas like, I listened to this
show with my kids in the car andy'all cussing, blah, blah, blah,
blah, blah.
Anyway, we can bring this traininto the station.
Drew, do you have any finalthoughts?
And if not, tell people wherethey can find you online and
(45:36):
keep up with you.
SPEAKER_03 (45:38):
My final thought is less of a thought because I feel
like I've made my thoughtsclear, but a more of a request,
and it kind of piggybacks off ofsomething you were saying.
Is like there's still a lot ofquestions.
So ask questions, keep askingquestions, keep asking questions
of both sides.
Ask the questions in good faith,but don't run with wild
(46:02):
accusations.
Don't have a theory and post itlike it's a fact.
Don't post a timeline where youput something in that is
unverified because you're justmuddying the water.
You're making everything moredifficult.
And we as the community need toget this figured out so we can
move forward.
Whatever that looks like, Idon't know.
I'm not that smart, but we doneed to move forward in whatever
(46:23):
way that looks like.
And wild baseless accusationsaren't helping, but questions
do.
I can be found.
My website's drbrag2gs.dev.
I have a podcast code and thecode encoders who code it.
I help run Philly RB.
I work at podia with Andrew.
I can be found a variety ofways.
SPEAKER_00 (46:44):
Had everybody a little bit of Slack.
If you want the Ruby CentralBoard to start sharing minutes,
give them a little bit of spaceand a little bit of trust and a
little bit of slack so that theyfeel safe enough to do so.
Everybody in this cares aboutthe Ruby community and they want
to make it a better place.
So give them a little bit oftrust in that.
(47:07):
If you agree with my takes, youcan find me at Shell Codes on
Blue Sky and Twitch.
If you disagree with my takes,you can find me at Andrew M.
Codes.
SPEAKER_02 (47:17):
Oh that's good.
That's a good one.
Whoa.
That's a Jason level troll rightthere.
I want to thank both of y'allfor coming on like immensely.
Like, I have been thinking aboutthis for a while, and I was
like, I don't want to do thisalone.
And you both were like, yeah,I'll do it with you.
(47:38):
So I just want to say thank youboth for coming on and sharing
your takes and doing theresearch and I don't know, just
caring, I guess.
We all three of us care aboutRuby and RubyGems and Bundler,
and we care about thesemaintainers because we know how
much we owe them.
And we also care about securityand the service staying up.
(47:59):
So I guess my final take is thatthings are still up in the air.
Drew, I think said it perfectly.
Like you are allowed to demandaccountability and to ask
questions.
And I don't think that'sunhealthy at all.
But a lot of the dramafear-mongering stuff, I think,
is unhelpful.
But at the end of the day, thisis something that is important,
(48:22):
right?
Because this could fundamentallytear the ecosystem if we're not
careful.
And I don't think any of us wantthat to happen.
So I think more people need tostop blogging about things and
start trying to figure out whatthey can actually do to help
improve the community, improvethe situation, improve the
services, et cetera, et cetera.
So that's the end of this.
(48:44):
Hopefully, Chris comes back soonbecause I miss him, but I hope
he is enjoying his time off.
Thank you everyone to listeningfor Ruby, and I will catch you
all next week.
Popular Podcasts
Las Culturistas with Matt Rogers and Bowen Yang
Ding dong! Join your culture consultants, Matt Rogers and Bowen Yang, on an unforgettable journey into the beating heart of CULTURE. Alongside sizzling special guests, they GET INTO the hottest pop-culture moments of the day and the formative cultural experiences that turned them into Culturistas. Produced by the Big Money Players Network and iHeartRadio.
The Joe Rogan Experience
The official podcast of comedian Joe Rogan.
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.