October 31, 2025 • 50 mins
In this solo episode of Ruby Rogues, I’m unpacking one of the biggest stories in the Ruby world right now: the tension between Ruby Central and core RubyGems contributors. I share what I’ve learned from talking to people across the community and why this issue is more complex than it looks on social media. From the origins of Bundler and Ruby Together to the recent creation of gem.coop, I trace how we got here—and why both sides have valid points but also made serious missteps.
I also open up about what this means for the Ruby ecosystem going forward, why transparency and trust matter more than ever, and how we as a community can respond productively. Toward the end, I lighten things up with some picks, including a clever deduction card game and a heartfelt call for more understanding in our world—both in code and beyond.
🔗 Links & Resources
Become a supporter of this podcast: https://www.spreaker.com/podcast/ruby-rogues--6102073/support.
I also open up about what this means for the Ruby ecosystem going forward, why transparency and trust matter more than ever, and how we as a community can respond productively. Toward the end, I lighten things up with some picks, including a clever deduction card game and a heartfelt call for more understanding in our world—both in code and beyond.
🔗 Links & Resources
- Ruby Central
- gem.coop – the new RubyGems mirror/community alternative
- Top End Devs – get involved or create your own dev content
- Email Chuck: chuck@topendevs.com if you’re interested in co-hosting or authoring a series
Become a supporter of this podcast: https://www.spreaker.com/podcast/ruby-rogues--6102073/support.
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:04):
Hey, folks, welcome back to Ruby Rogues this week, it
looks like it's just me. We kind of took a
break from recording for a little while, but I'm back
at it and I had some stuff to talk about.
So I'm going to just jump in and talk about
some of the stuff that's going on out there in
the Ruby community, just to give a little bit of
(00:25):
context on how I expect this to flow effectively. I'm
just going to kind of explain what I've been able
to gather is happening. I'll probably interject my opinion or
feelings on things as I go, and then at the end,
I'll give some conclusions as far as what I think
we ought to be thinking or doing regarding the situation
(00:46):
with Ruby Central and Ruby Gems. I'm also going to
be gearing up and recording more episodes, and I'd like
to add another host or two to this show, so
if you're interested, feel free to email me Chuck at
topendevs dot com. I've also got some other stuff coming
just to kind of give you all a heads up.
(01:07):
I'm going to start recording a Ruby Tip of the Day,
and so that'll be a daily podcast. It'll probably be
five to ten minutes, and I'll just explain some stuff,
and I'm planning on putting out some video content related
to that, right, So I'll explain the concepts behind a thing,
and then and you know, hey, you probably want to
do this, or you probably want to do this instead
(01:28):
of that, and then do a quick video demo and
show you what the difference is. But in the meantime,
let's go ahead and dive in and talk about the
situation with Rocky Mountain Ruby or sorry, with Ruby Central.
I kind of Freudian slipped, I guess with mentioning Rocky
(01:48):
Mountain Ruby. I was at Rocky Mountain Ruby a week
or so ago. There were a number of people who
are involved in the whole Ruby Central situation that we're there.
I'm not going to attribute anything to anyone person, because
I kind of got the story from a handful of
people that are involved, and then another handful of people
who have been following things pretty closely. And I don't
(02:08):
want to represent that what I've gathered is necessarily the
opinion or you know, any kind of statement from anybody
who's involved, because honestly, I'm not sure if I remember
which details came from which people, and so anyway, I
feel like I've been able to gather more information than
(02:31):
what's kind of out there at the moment, so we
can dive into that. One other thing is is that
if you're looking for me to take sides on, you know,
these people did everything right and these people did everything wrong.
I don't feel like that's the case in this case.
I feel like both sides have made decisions that definitely.
Speaker 2 (02:50):
Could have been made better.
Speaker 1 (02:52):
And I don't think anybody comes out of this looking like, oh, well,
we did everything right and they screwed us over. So anyway,
I'm just gonna just kind of wanted to put that
out there as we get into it. So anyway, so
let me back up and give some historical information for folks.
I know that there are a lot of people that
are newer to the community and haven't been around for
(03:15):
all of the things that we've kind of lived through
over the last fifteen or twenty years. I've been programming
Ruby for around twenty years, and so I've kind of
seen a lot of the things that add up to this,
and you know, and so I want to give that
context as well. Essentially the situation, I'll just give a
(03:36):
little bit of that, and then I'll go back historically,
you know, so that you can kind of see where
it's headed. But the situation is that a few weeks ago,
maybe a month or so ago, sounds like it was
in early September or maybe late August, ruby Central. So
some people came out who work on some of the
(03:58):
projects like ruby jumps dot org, the Ruby Gems command
line interface, and Bundler, and they said that they had
had their access to the repositories revoked, that the organizations
that on GitHub that those repositories belonged to had been
reassigned to Marty HoTT, who's the developed director of open
(04:21):
source at Ruby Central. And then I guess they got
their access back for a little bit, and then they
had their access finally revoked. So then people were saying, well, hey,
you're essentially taking these projects that people work on for
the community out of their hands, and so people were
(04:45):
saying it was a hostile takeover and things like that.
I'm finding that there's a lot more context here, right So,
like I said before, I think the reasons that Ruby
Central's doing what it's doing are understandable, and I think
there are which could have been much much, much much better.
And I also understand where the contributors are coming from
(05:07):
because they've been working on this stuff for a really,
really really long time. So let's rewind way back, right,
and let's talk about the way things worked when I
started doing Ruby back in like two thousand and six.
Speaker 2 (05:20):
So I was working for a company that.
Speaker 1 (05:23):
I was actually running their tech support department, and we built,
we built the infrastructure for our support teams in Rails,
me and another guy that were running the support team.
And back then, when you built a Ruby or Rails application,
there was no gem file right, no bundler didn't exist,
(05:44):
and so what you would do is you would do
a gem install on your machine and it would run
whatever version of Ruby you had on your machine. And
there weren't these convenient switchers like RVM or OURBND, and
so you just had to have the right version on
your computer, have the right gems installed, and then you
would require them and it would pull them out of
wherever you had them installed.
Speaker 2 (06:06):
And so.
Speaker 1 (06:08):
If you had jim incompatibilities, you would get errors.
Speaker 2 (06:12):
When you ran your Ruby code.
Speaker 1 (06:14):
And as applications got more complicated, especially for Rails, applications,
dependency management became a huge nightmare, and then when you
upgraded from one version of Rails to another, it became
even more of a nightmare. So when we transitioned from
Rails two to Rails three, and Yahuta Katz and Carl Lerchie,
(06:41):
I can't remember how to say his name, anyway, they
were ya hootah did most You know, he was kind
of the front man for a lot of the work.
He was the one that was out there, given the
talks and things like that, and so I kind of
want to give him more credit, but I don't know
how much of the work was done by either of
those guys. And I can't remember if Tom Dale was
involved in that or not, or if he just got
involved later and was more of an influence in Ember,
(07:04):
which is a JavaScript framework. But anyway, so they they
did this work in the eight they had been working
on a competitor to Rails called MERB and Rails and
Merb decided to merge, and so they merged, and that
that upgrade was kind of a big, big, big move.
(07:24):
But a few of the things that came out of
that were eventually we got Bler from a lot of
that work and I think Carl and Yehuda were the
ones that started it. For a really really long time,
andre Arco was the one that was kind of spearheading
the work on that, and so we got Buler from that.
(07:45):
It changed a lot of things because then you could
just put stuff into the gem file and Butler would
figure out what dependencies you needed and it would align
all that stuff, and then if it couldn't find compatible
versions with everything that you've ad for, then it would
tell you. And so anyway, that became kind of this
critical thing. Ruby Gems the cli and ruby Gems the
(08:09):
server were around before I was programming Ruby, and so
a lot of that work was done by Eric Hodle
and some of the other folks around there. And my
understanding is is that for the RubyGems dot org service,
somebody had to pay the server bills, right, and Ruby
(08:31):
Central had kind of informed to run Ruby komf and
rails comp and so it's my understanding that they just
took that under their wing kind of formed something that
looks like a foundation. I'm not sure if they're organized
in the same way as kind of like the Rails
Foundation or some of the other open source foundations like
Linux Foundation, but ultimately they have corporate sponsors, and I
(08:54):
think they were actually making money from the conferences and
anyway they were able to pay for the infrastructure to
run regems dot org and so you know they've hosted
those servers and things like that. And then of course,
you know, over the years, people have become more sophisticated
(09:14):
in the way that they try and compromise people software,
and one of them are supply chain attacks, and so
you know, they've had to become much more sophisticated in
the way that they handle requests or you know, posting
of Ruby gems and things like that to make sure
that when you pull in a gem that it's what
you expected to be and it doesn't have any malicious
(09:35):
code in it or you know, open up vulnerabilities in
your application and things like that, and I think they
do a pretty good job of that. I can't think
of any major problems that you know, that have come
from ruby gems itself, and if they have been issues,
they've been on top of fixing those.
Speaker 2 (09:53):
Right.
Speaker 1 (09:53):
Most of the time, it's oh, we overlooked a thing
in you know, a gem or something, right, and so
then you get a patch.
Speaker 2 (09:59):
To ray or something like that.
Speaker 1 (10:01):
But anyway, so that's where a lot of this comes from.
And then a few years ago, I say a few,
but I think it was probably like ten or more
years ago, a lot of these folks were spending quite
a bit of time maintaining a lot of these projects
for the Ruby community, right, so rubygms dot org and
Bundler in particular, and so, and it's all open source software,
(10:25):
and they weren't really getting paid. This was before you
could sponsor people on GitHub, and there really weren't other
terrific mechanisms for people to say, hey, I'm doing this
work that benefits you. Do you want to throw me
a few bucks? And so they founded a group called
Ruby Together. And what Ruby Together did is it it
(10:47):
collected a fund similar to Ruby Central, right where you
have these companies that are donating to them. And then
they were able to pay the open source maintainers at
least something for kind of the above and beyond amount
of time that they were spending on Bundler and ruby
gems and RubyGems dot org so that they could provide
us with secure, functional tools that do the job that
(11:10):
we need them to do.
Speaker 2 (11:12):
And then you know, and that all made sense, right.
Speaker 1 (11:16):
It was kind of in a time where I felt
like some of the social agendas were starting to crop up,
and they were a little bit vocal on that. But
for the most part, they you know, they mostly were
just raising money for you know, for the the infrastructure
work that they were doing, right, and so, you know, great,
we still get all of the goodies for free.
Speaker 2 (11:35):
They're doing work that we all need done.
Speaker 1 (11:38):
You know, they're getting paid for it, which I think
is great, and so more power to them. And so
my understanding is about three three to five years ago,
Ruby Central and Ruby Together figured out that they were
basically going and asking for support from the same groups,
from the same folks, right, because the folks that support
(12:01):
Ruby Central or companies that use Ruby on a regular basis,
you know, so Shopify and you know, base Camp and whoever, Right,
they all run on Ruby and use the Ruby infrastructure.
And so they were giving money to Ruby Central. But
then a lot of the infrastructure that's supported by Ruby
Central runs on software that's being developed by Ruby Together,
(12:21):
and so they decided to merge, and so they did,
and they merged, and so what wound up happening was
now Butler rubygms, dot org and Rubygms are all maintained
by Recentral, along with the.
Speaker 2 (12:36):
Conferences that they are no longer going to do.
Speaker 1 (12:38):
I don't know if they're going to still do ruby COFF,
but they publicly announced that they are not going to
do rails COMF so so anyway, so that's kind of
where we wind up sitting for a while, right is,
Ruby Central is paying the developers you know as contractors basically,
(12:59):
so they're paying a lot of these people to work
on the Ruby GM's infrastructure and the Bundler infrastructure and
a lot of this other stuff that we use all
the time. And Ruby Central is now responsible for all
of this infrastructure and our supply chain to get us
gems right. And so you can kind of see where
(13:19):
we're headed with this, right So, if they have a
responsibility for that, then they might have some liability if
there's a supply chain attack and you know, the problems
aren't handled properly. And so it's my understanding. And again
(13:41):
this is I talked to a whole bunch of people.
I can't really name anyone source for this. It's it's
been gathered over a number of conversations. But my understanding
is is that the board Ruby Central started getting legal
advice that indicated that they could have some level of
(14:01):
vulnerable or of liability if there was.
Speaker 2 (14:06):
If there was a supply chain attack.
Speaker 1 (14:08):
And the other concern was that the developers that work
on these systems didn't really have the kinds of liability
protections that they ought to, right, so if somebody made
a mistake building ruby gems the CLI, and somebody else
was able to exploit that and do a mass supply
(14:29):
chain attack, they might be personally liable. And so there
were these concerns that were coming up, but mainly, if
Ruby Central gets sued and gets taken down, then who's
going to run RubyGems dot org and who's going to
do the work to protect the supply chain and things
like that. So, and here's where I'm not going to
(14:50):
represent anything that I haven't heard or don't know, but
it's my understanding that they determined that they needed to
amend the agreements they had with these other open source
maintainers so that Ruby Central could protect itself in the
case of, you know, something going really badly, and on
(15:15):
the other side, provides some level of indemnification to the
Ruby The Butler and Ruby Gems maintainers, right, so that
if something happened and they got personally sued, that Ruby
Central would be in a position to help protect them
(15:35):
from legal jeopardy. And so the other thing is is,
and I've seen this in other open source systems where
if you contribute to a project, so legally under US law,
if you write code, you own the code. And so
usually if you're working on some kind of system that's
out there at all, then especially if it has a license,
(15:59):
it's not like MIT, right, because if it's MIT license,
the license basically says take this and do whatever you
want with it, right, And so then there's there's not
really any like I can't come after you for using
my code because it's MIT license.
Speaker 2 (16:13):
Right.
Speaker 1 (16:13):
If I license an MIT, it says explicitly in there
you can do whatever you want with it, and so
I'm essentially giving over my copyright protection on the code
and allowing you to do what you want with it.
But some of the other licenses out there don't allow that.
And so then what happens is a lot of times
you'll have a contributor agreement that says, if you contribute
(16:34):
to our code base, then we own the code, and
we control the license, and we're able to write, we're
able to put it out however we want, right and
so then they can continue to maintain it under an
Apache license or things like that, and they don't have
any obligation to you to you know, they don't forget
(16:55):
your permission if they want to do something else with
the project leader, and so it gives the project owner
of flexibility. And so it's my understanding that that's kind
of the direction that Ruby Central was looking to go to,
where they could then have these kinds of contributor agreements
that would allow them to operate and have a little
more control over how rubygms, RubyGems dot org and things
(17:20):
like that we were managed. But if you look at
it from the other side, I mean, some of these
folks have been working on these projects for more than
ten years and have done a ton of work, and
they've kind of operated in this arena where they didn't
have as much oversight and they didn't have people telling
(17:40):
them what they could and couldn't do, and you know,
they felt a sense of ownership over the project, which
you know, I think is terrific. And so Ruby Central
coming in and saying hey, guys, we need you to
sign these agreements and do X, y and z in
order to continue to work on this project. And you know,
(18:04):
we're going to take a more active and controlling role
on this open source project that you've just worked on
and contributed you know, hours and hours and years of
your life to. Right, we're taking a level of ownership
away from you. I totally understand these people going, whoa, whoa,
Wait a minute, right, we don't remember signing up for this, right,
(18:26):
we signed up for Hey, you know, let's fund this
stuff in the way that it gets funded.
Speaker 2 (18:32):
Right.
Speaker 1 (18:32):
But I also can see the side of things from
Ruby Central's angle where they're looking at it and going,
if we own and are responsible for the code in Bundler,
in the Ruby gmc l I and rubygms dot org,
and something bad happens even though we didn't do it, right,
(18:53):
it's it's a contributor that's here, that's contracted through us.
We bear the brunt of that liability, and so we
need to have certain guarantees in order to be able
to say no, we've done everything we can, because then
if they get sued and they say, look, you know,
we've done we did everything we could, We followed all
(19:14):
the best practices. Right, we shouldn't be held liable for
a thing that is impossible to foresee and uh, where
there's not really a good practice for protecting against it, right,
then then they can they can put together a much
more sound defense because at the end of the day,
they can tell the court, no, we did everything we
(19:34):
were supposed to do, right, and it's not it's not
negligence or malice on our part, and so we can't
be held liable. Right And and so I understand. I
understand both sides. I understand the push and pull. So
here's here's where things kind of get a little dicey
for me on the Ruby Central side, right, because for
(19:55):
the most part, I understand where Ruby Central is coming from,
and I support them in what they were doing as
far as their motivations and things like that. Right, I
haven't seen any evidence that suggests that this was some
kind of hostile takeover, that there's some ego involved, or
that there's some kind of you know, malicious intent to
(20:16):
screw over the community, or some political gamesmanship that has
to do with these contributors. I haven't seen any evidence
of that at all. And so for the most part,
I think Ruby Central was just trying to do the
right thing, and they did.
Speaker 2 (20:29):
It really really really really really really.
Speaker 1 (20:30):
Really really poorly, right, because the first thing they should
have done is they should have been doing all of
this in public, right. I understand that maybe they don't
want to public publicize, Hey, we have this legal exposure, right,
you know, if this, if any of this happens, then
(20:50):
we're legally liable, and so we're trying to fix it. Hey, folks,
don't sue us in the meantime, Right that maybe that's
not the best.
Speaker 2 (20:56):
Way to go.
Speaker 1 (20:57):
But what they could do could have done, is they
could have said and they could have come out and announced, right, hey,
we are putting a new policy in place for contributors
so that you know, so that we have these kinds
of guarantees on the work that they do, and we're
providing these kinds of protections for the contributors on the
(21:20):
work that they do. And we're we're just trying to
kind of button up some areas so that we can
protect the community and that we can protect the we
can protect rev Central, right, and that way we can
continue to provide services, we can continue to work on
these libraries and we can continue to give people what
they need, right and maybe you know, not in so
(21:42):
many words, tell us, you know that they're they're trying
to they're trying to for the longevity of the of
the system to make these changes and then acknowledge right
that this may be painful and that the contributors are
probably used to working under different constraints, and we're working to.
Speaker 2 (22:01):
Make sure that this is as painless as possible. Because
then when you go in and you.
Speaker 1 (22:06):
Eventually revoke access or you know, try and get really
you know, maybe even push twist arms a little bit
to get them to sign these agreements, then people know
it's coming.
Speaker 2 (22:19):
They know what's up.
Speaker 1 (22:21):
They know that the Ruby Central I keep wanting to
say the foundation, but again I don't know if it's
organized that way.
Speaker 2 (22:27):
But at the end of the.
Speaker 1 (22:28):
Day, right, just so that people can see this coming
and go, oh, well, they obviously wouldn't agree to the
you know, the terms on Ruby Central, and yeah, I'm
frustrated on behalf of these folks, but you know, it
was all done above board, It was all transparent. We
all knew it was coming, right, and then they can
(22:50):
come out and they can make similar announcements because these
people are people that we all really rely on and
in a lot of cases at least trust, right, we
trust their code and things like that. So, you know,
they had to know that these folks have a little
bit of pull and that you know, if if it's
painful for them, we are all going to know and
(23:11):
a lot of us are going to be sympathetic to them, right,
and so, and again I don't know what level they
had communication with the contributors themselves. It sounded like they
were somewhat blindsided or completely blindsided, and that's not okay, right,
And so what what Ruby Central should have done is
they should have done this all above board and transparently
so that people could kind of connect the dots and
(23:33):
see it all coming. And they definitely, definitely, definitely should
have been talking to contributors, right. This should not have
been a surprise of contributors. It should have been a hey, look,
this is this is the contributor agreement that.
Speaker 2 (23:45):
We're gonna we're going to enforce.
Speaker 1 (23:49):
If you have any concerns or you think we could
change things in it, right, we're welcome to talk through it.
Speaker 2 (23:56):
Right.
Speaker 1 (23:57):
You know, this is what we're trying to do with
liability and longevity and things like that. And so ultimately
we're just trying to do the best by you, but
also make sure that we're doing right by the community.
And so then at least then you might have some
of the contributors coming out and saying, no, they told
us a while ago, and we've been negotiating on the
(24:24):
on the contributor agreement, and you know, and so you know,
these are the areas where it broke down. These are
the couple of things in the agreement that I didn't like,
and so you know, ultimately I wound up not signing
it and resigning right that that it just changes the
whole tenor of the thing, right, And and then on
(24:45):
the other side, right then we can also see that
they're negotiating in good faith right anyway. So so Ruby's
Central just screwed this up like massive, big time. And
then the other thing I understand is that somebody in
them in who was one of the major contributors left
(25:07):
or be Central, and so they had to replace somebody anyway.
Speaker 2 (25:10):
And so my understanding is is.
Speaker 1 (25:12):
That that caused the board to want to accelerate the
timeline because whoever they brought in was going to be
working on some pretty major stuff, and if they brought
them in, they could just have them under the agreement
to begin with. And so it's my understanding that they
started looking at that, and then that's when the board
essentially directed the folks that run the infrastructure to start
(25:38):
removing access and you know, changing the GitHub organization and
things like that, and so that kind of happened in
a hurry all at once. And again that was something
that they really shouldn't have done, because there's no reason
that they can't bring the new people on under the
under some kind of agreement and keep the old people
(25:59):
on under you know, and just tell them, look, you know,
we're bringing we're starting to bring you know, more important
players in the in this system in under the agreement.
So we need to get you on the agreement by
this date, right and then and then work with the contributors.
So so anyway, so that you know that that's that's
(26:20):
kind of the mess. Now, a couple of other things
that happened. We're so RubyGems dot org got forked and
I need to go look up. I think it's Ruby
dot coop. I'll have to find it. I was reading
up on it the other day anyway, So so yeah,
(26:44):
so uh kind of the way that things are looking now, yeah,
I'll find I'll find the link. But anyway, feel free
to go check it out. I'm personally not uh, I'm
I'm gonna keep using Ruby gems until until I feel
like I have a real reason to switch. Right now,
(27:06):
I think again, you know, I think they're trying to
act in the best interest of the the the community.
But at the end of the day, yeah, and anyway,
it might it might not be Ruby dot coop, but
it might be like co op is the way that
they're looking at it.
Speaker 2 (27:21):
Anyway, So gem dot coop. There we go.
Speaker 1 (27:23):
Okay, so it's gem dot coop. It's at gem dot
co op. So it's a new Ruby gem server. Looks
like Mike McQuaid is helping them set it up, and
it kind of follows the homebrew model. And then yeah,
you can swap in your bundle, bundle, your gem file.
(27:46):
You can swap out Ruby gems dot org to gem
dot coop. So anyway, and yeah, you know, so, so
the contributors are upset.
Speaker 2 (27:55):
They went and started their own thing.
Speaker 1 (27:58):
But this is where it gets a little it weird
on the contributor side. So apparently, and there was a
whole write up on this on Ruby Central and all
linked to it in the show notes. But apparently, so
they went and they revoked everybody's access to the the repos, right,
(28:18):
and but they're all they're all public.
Speaker 2 (28:20):
Reposts, so you can go and you can fork it, right,
not a big deal.
Speaker 1 (28:24):
And so I'm assuming that that's what gem dot coop
is doing, is that they just forked RubyGems dot org
and then you know, they're seeding it with whatever Gem
information they have. But it's all hosted on AWS. And
apparently the route access certificate or credential wasn't rotated when
(28:49):
they removed people's access to the other stuff, and so
a lot of folks were still able to access the
RubyGems dot org servers and so and so this is
the other part of the drama. And you know, and
a lot of people have weighed in and said no
ruby jams, blah blah blah. I've heard some people try
(29:10):
and pin a lot of this on shopify. I don't
find any of that evidence compelling. I really think that
it was just the Ruby gems board and then really
screwing it up anyway. So a lot of the contributors
who had helped maintain the systems still had access to
the ruby gems servers, and so the folks at Ruby
(29:34):
Central actually posted some of the emails that they got
from Andre Arco and where he was saying, Hey, maybe
we could monetize or otherwise lease the log information from
RubyGems dot org and you know, work out some kind
of arrangement where they could use that. And Ruby Central
told them no, told him and whoever was working with
(29:57):
him no. But then they show Mode that and he
told him he still had access to the servers, and
apparently they didn't solve that in a timely manner, right,
there was a few days and he still logged in,
and they imply that it was him without actually directly
saying it. They implied that it was Andre that was
(30:18):
getting in. The evidence really does point that way, But
I haven't seen the logs firsthand or anything to be
able to definitively say no, this really, you know, really
implicates Andre. So I'm a little uncomfortable putting his attaching
his name to it. But somebody who had that level
(30:40):
of access logged in and then they started changing credentials
on the ruby jem server, and so the folks at
Ruby Central couldn't get in, They couldn't get into the
AWS setup, and so they wound up having to contact
AWS and doing a credentials reset, and then they went
in and they fixed it all up. But they could
see that whoever it was it logged in several times
(31:03):
had accessed a bit of information. It didn't look like
they had copied anything off, but.
Speaker 2 (31:11):
He did.
Speaker 1 (31:12):
Anyway, there are a couple of things here that just
kind of really make me scratch my head, I mean.
And then Andre came out later and actually and so
this is where it really looks like it was him.
He said in his blog post that he went in
and was changing the credentials so that the system wouldn't
get a compromise. But the way that it was explained
(31:34):
on Ruby Central, and you know, the logs that they
presented and things like that, some of that just doesn't
quite add up to what Andre says he was doing
in there. And the other thing is is that I
think he probably could have done more to just kind
of force them around, because yeah, I mean, at some
(31:57):
point you're gonna, you know, you could get enough public
out cry from the community saying, you guys are putting
us all at risk if you don't change this. But anyway,
but the flip side is is than anybody who wants
to go in and try and hack it right might
be able to get in. So I don't know, I
don't know what the answer would have been, but I
think there were better ways for him to handle it.
(32:18):
And the other thing is is that if he wanted
that data because it would help them set up gem
dot coop and make gem dot coop you know run better,
or know what kinds of performance aspects or you know,
access patterns or anything else. I mean, all of that
stuff would have been in those logs and probably could
(32:42):
have helped them get that set up. And so that
that doesn't sit quite right with me.
Speaker 2 (32:48):
And just you know, getting in and accessing stuff that.
Speaker 1 (32:52):
Way when you've been you know, when they've basically let
you go from the organization and stuff like that, that
doesn't sit right with me either, And so I have
some really really grave concerns there. I've also seen Andre
do some other things where he's gone on the attack
(33:12):
for against other people, and so he seems like as
far as like a maintainer of Butler, I think he's
done a terrific job.
Speaker 2 (33:21):
But as a member of the community.
Speaker 1 (33:23):
I think sometimes he is a little bit of a
loose cannon and the way that he approaches some of
these issues, and so I'm I'm very not comfortable with,
you know, letting him off the hook either. In fact,
if I were Ruby Central, I would I would be
giving a serious look to you know, what repercussions can
(33:47):
you know, come against him. I don't know that I
necessarily want them to sue him or anything, but you know,
it's like, hey, look, you know, how do we how
do we curb this so that other bad actors aren't
going to do this kind of thing, right, that they'll
play ball in a way that actually is ethical, because
I think it was unethical for him to log in
(34:08):
and do any of the stuff.
Speaker 2 (34:09):
That he did.
Speaker 1 (34:12):
But again, you know, I mean, he said he was
just trying to change the credentials, and if that's true,
then maybe he deserves the benefit of the doubt. But
some of the other things that were done on the servers,
I just I don't know, but it does look like
he didn't actually compromise the systems and so anyway, I'm
going back and forth mostly because I don't know if
I want them to throw the book at him. But
(34:32):
I don't think he should get away with it either,
because I don't think what he did was right. So anyway, whatever,
whatever the appropriate outcome is there, I don't know if
I have a proper recommendation, but anyway, so that's where
things are sitting. I've told a few people at Ruby
Central at this point that what they need to do
is they need to just come out and come clean
on all this stuff, right, just say, hey, look, this
(34:55):
is where the decisions were made, These are the strains
we were working under, These are the concerns that we had,
and so this is what we did, and this is
the stuff we got right, this is the stuff we
got wrong, and these are the procedures that we're going
to put into place to make sure that we don't
mess it up again. Right, And that way the contributors
(35:17):
can all be comfortable that they're not going to pull
anything where they feel like they're getting screwed over. And
then also you know, feel like the the GEM repositories
and stuff like that are all in good hands, right
that hey, look, yeah, we should have changed the credentials
and rotated the credentials, and.
Speaker 2 (35:38):
So we have a procedure for that now.
Speaker 1 (35:40):
And you know, we just go through the whole list
of things whenever somebody you know is no longer a contributor,
right to make sure that only authorized people have access,
and yeah, just stuff like that, right, and just make
sure that everybody knows. And then yeah, just do a
big Maya culpa to say, hey, look, you know, we
(36:01):
know we messed up, and so this is what we're
doing to be more transparent so that people don't have
to be concerned over the infrastructure or over the treatment
of the contributors because the contributors are working for us
for free in a lot of cases, or if they
are getting paid by Ruby Central, I don't think it's
full time, and he's just part time, and so they've
got to go figure out other stuff in order to
(36:22):
make stuff work. And so you know, do right by
those guys, right. And then on the other side, I
think we deserve a much better explanation from Andre regarding
accessing those servers. Honestly, it makes it really hard for
me to trust him, just because it seems like there
(36:43):
are some kinds of ulterior motives here, but I don't
know what they are. I don't know if gem dot
coop is supposed to have some kind of commercial backing
or right, so maybe they'll offer like private GEM repositories
and stuff like that like NPM eventually wound up doing
(37:04):
or stuff like that, and so anyway, I'd like to
see a lot of that. And then I think, I think, honestly,
we need to have an honest discussion in the community
and just be like, Okay, so at the end of
the day, what you know, what's our expectation from these
organizations that are are doing this work and from contributors
(37:24):
to our our kind of core offerings.
Speaker 2 (37:28):
In the community.
Speaker 1 (37:31):
And then we need to make sure that these folks
know that these are the expectations we all have. And
then lastly, when they do stuff, right, I think we
have to show a little more appreciation.
Speaker 2 (37:42):
Right, So, like I said, you know.
Speaker 1 (37:43):
The work that's been done on Butler and Ruby, gems
and reegms dot org, right, regardless of you know, some
of maybe the bad things that we're done. I mean
I've befit benefited from that work, and so you know,
a hearty thank you to the people that are doing
making those gone ttributions. And at the same time, you know,
(38:05):
I have a friend that kind of messed his life
up making some poor decisions, and so, you know, as
he was going through some of the consequences for the
things that he did, you know, I went to lunch
with him multiple times. I tried to support him as
best I could, but I looked at him and I said,
(38:27):
You're never going to get me to give you a
pass on what you did right. But at the same time,
I'm going to support you in moving forward in the
right way to make things right. And that's kind of
where I feel like I'm at with these folks. Right
It's like, look screwed up. I'm not giving you a pass.
Speaker 2 (38:45):
You know.
Speaker 1 (38:47):
I think I can eventually forgive you if you prove
out that you're going to do it right. And in
the meantime, you know, let me support you in doing
the right thing.
Speaker 2 (38:59):
And so.
Speaker 1 (39:02):
Anyway, hopefully that that helps kind of paint a little
bit more of the picture for people so that you
all understand, you know, what's going on and where things
are at. And then yeah, at this point, besides kind
of supporting people and doing the right thing. I personally,
I mean, I don't feel like it's picking sides to
(39:23):
say that I'm sticking with Ruby gms until you know,
they prove that I can't trust them and then you know,
the behavior as far as like logging into the servers
and stuff.
Speaker 2 (39:35):
I just I don't think that using gem dot coop is.
Speaker 1 (39:42):
Necessarily dangerous or you know that that I can't trust
them to take care because I think they have an
interest in making that service work and work as.
Speaker 2 (39:51):
Best it can.
Speaker 1 (39:52):
But it does create a trust issue for me with
with Andre So yeah, some of that would probably have
be resolved before I'm full throated endorsing, you know, switching
or adding them as a source in your gem file.
So anyway, that's that's kind of where things sit for me.
I'm sure that there are things that you know will
(40:13):
come out later or that I haven't heard, that are involved.
There are a lot of other opinions that have come
out on this stuff. You know, Ara Howard came out
and you know, it was pretty vocally upset with Ruby Central.
You know, I've seen other people come out and say
I'm not taking sides. You know, they kind of took
(40:33):
the tack that I did and said both sides screwed up.
I've heard people come out and say both sides screwed up.
But I still trust Ruby Central and have kind of
defended them, and I feel like I guess I've kind
of done that to some degree. But at the end
of the day, you know, do your homework, go figure
out what's going on, figure out if this changes anything
(40:55):
for you, and then let's go and write beautiful code
that makes us happy. All right, So I'm gonna switch over.
I'm going to do some picks. So my first pick
I always pick a game. I might have picked this
one on the show before. I'm and pick it again
if so, and if not, then you're hearing about a
terrific game. It is called infiltrators, and it's not spelled
(41:17):
like infiltrators the regular word. It's spelled like infiltrators. If
the last part of the word was spelled like traders,
like people who betrayed their country and so anyway, so
it has an extra eye in it. Basically, it is
a card game and it has essentially it comes with
(41:37):
a deck of cards, not face cards. It has its
own cards and they're all I think there are five
colors numbered two to fifteen. And what you're doing is
you have traders that are.
Speaker 2 (41:54):
Basically cards. You're trying to figure out what they are,
and so each player will pick.
Speaker 1 (42:00):
So you have a you have a hand of cards,
and then you have a card in front of you
that's face down, and so people can hand you a
card that you use as a clue to let them
know what the card.
Speaker 2 (42:12):
Is that's face down in front of you. And so if.
Speaker 1 (42:17):
You put it sideways, it means it has nothing in
common with the card that's face down, right, So if
it's a blue two, then it means that the card
is not blue, and it's not a two, but the
two has all of its multiples on it, so it
has two, four, six, eight, ten, twelve, and fourteen on it,
And it means that your card that's face down is
(42:39):
not a blue, and it's not a two, four, six, eight, ten,
twelve or fourteen.
Speaker 2 (42:43):
Right.
Speaker 1 (42:45):
If you hand you the blue fifteen, then it has
the factors of fifteen on it, and so you know
that it's not a three or five or a fifteen,
then you know it's not blue. If it's faced the
other way, then you know it's a blue or A three,
a five or fifteen or both, right, But there's only
one copy of every card, and so if it's the
blue fifteen, you know it's not the blue fifteen, right,
(43:06):
does that make sense? So anyway, so you clue until
you get the cards. There's a prop gun and you
get so many bullets because you execute the traders. Eventually,
we just got to the point where we just point
and say that's the red three, right, and so we
sometimes people would pick up the gun and use it,
but I'm.
Speaker 2 (43:25):
Executing, but most of the time people just point.
Speaker 1 (43:27):
So if you don't you don't like the gun in imagery,
you don't have to have it, and you can use
other markers instead of bullets. But anyway, there's a little
dry erase card that has all the numbers and all
the colors on it, so you can mark off the
ones you know that.
Speaker 2 (43:42):
It's not.
Speaker 1 (43:45):
Anyway, it's super fun game. It's a deduction game. You're
working together to you know, expose all the traders. It
has different levels that you play through kind of like
what is it the crew?
Speaker 2 (44:00):
So anyway, fun game.
Speaker 1 (44:03):
So yeah, I definitely go check that game out Board
game Geek has it weighted at two point one one
I always tell people too is kind of complicated enough
to be interesting, but simple enough that a casual, not
hardcore gamer would enjoy it. So I'm going to pick
infiltrators as that. And then the other thing I wanted
(44:24):
to just put out there is there are two things
that have happened over the last month, maybe you know
since we were recorded last that I just wanted to
talk about briefly. So one of them is the hostages
in Israel were returned. And I get that there are
people that have feelings about the whole conflict in Israel
(44:45):
right on both sides, and I'm not going to wait
into that. I have my own opinions on it, but
you know, the hostages look like they were mistreated. It
is terrific that they get to come home to their families,
and it looks like the killing has stopped for a while,
which is also a good thing, regardless of which side
(45:05):
you come down on. And so I am going to
pick peace because I just I'm all for it. I've
seen some people saying we want peace, but we don't
want Donald Trump to negotiate it. I frankly don't care
who negotiates it as long as we get it right
and as long as we can make it last. So
you know, if it raises Donald Trump's status, fine, if
(45:31):
it raises somebody else's status, right, if it's Barack Obama
over there negotiating it, and that's what's effective.
Speaker 2 (45:36):
Right.
Speaker 1 (45:37):
We're not killing people as much anymore so, which is
a good thing. We got hostages back, which is a
good thing. And hopefully the bodies that the other hostages
come back and those families can have closure.
Speaker 2 (45:48):
It's a good thing. And then the other one.
Speaker 1 (45:51):
And this affected me much more deeply, and a lot
of it's because it occurred here at Utah Valley University,
which is like fifteen minutes away from where I'm sitting
in my house. Maybe twenty minutes depends on traffic, I guess.
And that was the Charlie Kirk assassination. And you know,
this kind of speaks a little bit to what we're
(46:11):
talking about here, except you know, nobody's getting killed over
Ruby Jims.
Speaker 2 (46:16):
But we go out a lot.
Speaker 1 (46:18):
Of times and we just demonize the other people on
the other side, and I think a lot of that
rhetoric was what led to somebody shooting him here.
Speaker 2 (46:28):
And it's it's sad.
Speaker 1 (46:30):
Right, It's like for me, it's hey, look, you know,
and I agree with Charlie on a lot of the
things that he.
Speaker 2 (46:36):
Talked about, right, But at the end of the day.
Speaker 1 (46:40):
We need to be good to each other. We need
to understand each other. Right, this kind of violence, celebrating
that somebody got killed, you know, the way that we
treat each other sometimes because you're on the other side
of the political aisle, it's not okay. And I think
a lot of times if we just go talk to
people and understand where they're coming from and what they're
(47:01):
worried about and what they're dealing with and all of
that stuff.
Speaker 2 (47:05):
Things get a whole lot better.
Speaker 1 (47:08):
And sure, you know, maybe I don't come around to
the other person's way of thinking, but at least I
can understand them, right, at least I can think about
it and say, Okay, you know, do they have a
good argument or do they not have a good argument?
Speaker 2 (47:20):
Why?
Speaker 1 (47:21):
And then maybe I can argue my understanding better next time,
or maybe I change my mind, or maybe I just
change it a little bit. Right, It's like, no, they're
generally not right about this stuff, but these couple of
points tell me that, yeah, maybe there's a little bit
more nuance here or there within within this space. And
(47:44):
I think if we can understand each other that way,
you know, maybe we can heal. I hear too about
like people's families being porn apart, because you know, people
do or don't like Donald Trump or Kamala Harris or
whoever else, and you know, it's like, hey, you know,
there are so many more important things, so many more
important things that we have in common. And so I
(48:06):
really am just I guess I'm picking piece again, but
mostly I just I want I want people to understand,
come to understand each other, right, show some respect to
each other, be good to each other, and anyway, So yeah,
sorry to end on kind of a low note, but yeah,
hopefully this helps some folks get some context on this stuff.
Speaker 2 (48:28):
I guess one last pick.
Speaker 1 (48:31):
So I am getting things together on top end devs
so that we can relaunch Ruby Geniuses. I had Ruby
Geniuses running before and it kind of fizzled out a
little bit, so I'm bringing it back.
Speaker 2 (48:47):
I want to be doing the Ruby book club.
Speaker 1 (48:49):
I try to do like a general programmer book club,
and I just figured out that that's not really I mean,
we read some interesting stuff, but I think they're I
think doing a Ruby focused one is a much better
approach because then we can get into stuff that's relevant
to stuff that you're working on at work. And then
I'm going to be putting out videos for the Ruby
(49:12):
tip of the day. I'm going to be putting out
a series kind of like Go Rails or Rails casts
or Drifting Ruby that is essentially AI on Ruby. And
I'd like to get some series going on just Ruby
or just rails right, or some blend. And so if
(49:32):
you're interested in authoring something like that, I am actually
I'm happy to talk through some of that with you.
And then I'm also looking at putting courses and stuff
up on top end devs. I kind of want to
make it the Netflix for programmers, and so then you
can come in and instead of like horror and comedy
and you know whatever, you can come in and it's Ruby, JavaScript,
(49:54):
you know, DevOps, infrastructure's code, right, and so then you
can kind of pick your topic and then you can
find whatever it is that you're looking for, right, And
so I'm working through that and I'm looking for authors,
So if you want to author a series on that,
or if you just listen to Ruby rogues and you
mostly write go or something like that. I'm looking at
(50:15):
pulling some stuff together and some of those other areas
like Go, React, JavaScript.
Speaker 2 (50:21):
And and things like that.
Speaker 1 (50:22):
So and I really want to kind of become the
central place for people to come to get up to
date information on how to build AI and you use
AI tools in development. So anyway, that's what I'm kind
of heading toward here. Maybe I'll give like the full
vision and a little bit of the history on that,
(50:43):
but anyway, in the meantime, be good to each other.
You know, we'll get past this as a community and
until next time acts out
Hey, folks, welcome back to Ruby Rogues this week, it
looks like it's just me. We kind of took a
break from recording for a little while, but I'm back
at it and I had some stuff to talk about.
So I'm going to just jump in and talk about
some of the stuff that's going on out there in
the Ruby community, just to give a little bit of
(00:25):
context on how I expect this to flow effectively. I'm
just going to kind of explain what I've been able
to gather is happening. I'll probably interject my opinion or
feelings on things as I go, and then at the end,
I'll give some conclusions as far as what I think
we ought to be thinking or doing regarding the situation
(00:46):
with Ruby Central and Ruby Gems. I'm also going to
be gearing up and recording more episodes, and I'd like
to add another host or two to this show, so
if you're interested, feel free to email me Chuck at
topendevs dot com. I've also got some other stuff coming
just to kind of give you all a heads up.
(01:07):
I'm going to start recording a Ruby Tip of the Day,
and so that'll be a daily podcast. It'll probably be
five to ten minutes, and I'll just explain some stuff,
and I'm planning on putting out some video content related
to that, right, So I'll explain the concepts behind a thing,
and then and you know, hey, you probably want to
do this, or you probably want to do this instead
(01:28):
of that, and then do a quick video demo and
show you what the difference is. But in the meantime,
let's go ahead and dive in and talk about the
situation with Rocky Mountain Ruby or sorry, with Ruby Central.
I kind of Freudian slipped, I guess with mentioning Rocky
(01:48):
Mountain Ruby. I was at Rocky Mountain Ruby a week
or so ago. There were a number of people who
are involved in the whole Ruby Central situation that we're there.
I'm not going to attribute anything to anyone person, because
I kind of got the story from a handful of
people that are involved, and then another handful of people
who have been following things pretty closely. And I don't
(02:08):
want to represent that what I've gathered is necessarily the
opinion or you know, any kind of statement from anybody
who's involved, because honestly, I'm not sure if I remember
which details came from which people, and so anyway, I
feel like I've been able to gather more information than
(02:31):
what's kind of out there at the moment, so we
can dive into that. One other thing is is that
if you're looking for me to take sides on, you know,
these people did everything right and these people did everything wrong.
I don't feel like that's the case in this case.
I feel like both sides have made decisions that definitely.
Speaker 2 (02:50):
Could have been made better.
Speaker 1 (02:52):
And I don't think anybody comes out of this looking like, oh, well,
we did everything right and they screwed us over. So anyway,
I'm just gonna just kind of wanted to put that
out there as we get into it. So anyway, so
let me back up and give some historical information for folks.
I know that there are a lot of people that
are newer to the community and haven't been around for
(03:15):
all of the things that we've kind of lived through
over the last fifteen or twenty years. I've been programming
Ruby for around twenty years, and so I've kind of
seen a lot of the things that add up to this,
and you know, and so I want to give that
context as well. Essentially the situation, I'll just give a
(03:36):
little bit of that, and then I'll go back historically,
you know, so that you can kind of see where
it's headed. But the situation is that a few weeks ago,
maybe a month or so ago, sounds like it was
in early September or maybe late August, ruby Central. So
some people came out who work on some of the
(03:58):
projects like ruby jumps dot org, the Ruby Gems command
line interface, and Bundler, and they said that they had
had their access to the repositories revoked, that the organizations
that on GitHub that those repositories belonged to had been
reassigned to Marty HoTT, who's the developed director of open
(04:21):
source at Ruby Central. And then I guess they got
their access back for a little bit, and then they
had their access finally revoked. So then people were saying, well, hey,
you're essentially taking these projects that people work on for
the community out of their hands, and so people were
(04:45):
saying it was a hostile takeover and things like that.
I'm finding that there's a lot more context here, right So,
like I said before, I think the reasons that Ruby
Central's doing what it's doing are understandable, and I think
there are which could have been much much, much much better.
And I also understand where the contributors are coming from
(05:07):
because they've been working on this stuff for a really,
really really long time. So let's rewind way back, right,
and let's talk about the way things worked when I
started doing Ruby back in like two thousand and six.
Speaker 2 (05:20):
So I was working for a company that.
Speaker 1 (05:23):
I was actually running their tech support department, and we built,
we built the infrastructure for our support teams in Rails,
me and another guy that were running the support team.
And back then, when you built a Ruby or Rails application,
there was no gem file right, no bundler didn't exist,
(05:44):
and so what you would do is you would do
a gem install on your machine and it would run
whatever version of Ruby you had on your machine. And
there weren't these convenient switchers like RVM or OURBND, and
so you just had to have the right version on
your computer, have the right gems installed, and then you
would require them and it would pull them out of
wherever you had them installed.
Speaker 2 (06:06):
And so.
Speaker 1 (06:08):
If you had jim incompatibilities, you would get errors.
Speaker 2 (06:12):
When you ran your Ruby code.
Speaker 1 (06:14):
And as applications got more complicated, especially for Rails, applications,
dependency management became a huge nightmare, and then when you
upgraded from one version of Rails to another, it became
even more of a nightmare. So when we transitioned from
Rails two to Rails three, and Yahuta Katz and Carl Lerchie,
(06:41):
I can't remember how to say his name, anyway, they
were ya hootah did most You know, he was kind
of the front man for a lot of the work.
He was the one that was out there, given the
talks and things like that, and so I kind of
want to give him more credit, but I don't know
how much of the work was done by either of
those guys. And I can't remember if Tom Dale was
involved in that or not, or if he just got
involved later and was more of an influence in Ember,
(07:04):
which is a JavaScript framework. But anyway, so they they
did this work in the eight they had been working
on a competitor to Rails called MERB and Rails and
Merb decided to merge, and so they merged, and that
that upgrade was kind of a big, big, big move.
(07:24):
But a few of the things that came out of
that were eventually we got Bler from a lot of
that work and I think Carl and Yehuda were the
ones that started it. For a really really long time,
andre Arco was the one that was kind of spearheading
the work on that, and so we got Buler from that.
(07:45):
It changed a lot of things because then you could
just put stuff into the gem file and Butler would
figure out what dependencies you needed and it would align
all that stuff, and then if it couldn't find compatible
versions with everything that you've ad for, then it would
tell you. And so anyway, that became kind of this
critical thing. Ruby Gems the cli and ruby Gems the
(08:09):
server were around before I was programming Ruby, and so
a lot of that work was done by Eric Hodle
and some of the other folks around there. And my
understanding is is that for the RubyGems dot org service,
somebody had to pay the server bills, right, and Ruby
(08:31):
Central had kind of informed to run Ruby komf and
rails comp and so it's my understanding that they just
took that under their wing kind of formed something that
looks like a foundation. I'm not sure if they're organized
in the same way as kind of like the Rails
Foundation or some of the other open source foundations like
Linux Foundation, but ultimately they have corporate sponsors, and I
(08:54):
think they were actually making money from the conferences and
anyway they were able to pay for the infrastructure to
run regems dot org and so you know they've hosted
those servers and things like that. And then of course,
you know, over the years, people have become more sophisticated
(09:14):
in the way that they try and compromise people software,
and one of them are supply chain attacks, and so
you know, they've had to become much more sophisticated in
the way that they handle requests or you know, posting
of Ruby gems and things like that to make sure
that when you pull in a gem that it's what
you expected to be and it doesn't have any malicious
(09:35):
code in it or you know, open up vulnerabilities in
your application and things like that, and I think they
do a pretty good job of that. I can't think
of any major problems that you know, that have come
from ruby gems itself, and if they have been issues,
they've been on top of fixing those.
Speaker 2 (09:53):
Right.
Speaker 1 (09:53):
Most of the time, it's oh, we overlooked a thing
in you know, a gem or something, right, and so
then you get a patch.
Speaker 2 (09:59):
To ray or something like that.
Speaker 1 (10:01):
But anyway, so that's where a lot of this comes from.
And then a few years ago, I say a few,
but I think it was probably like ten or more
years ago, a lot of these folks were spending quite
a bit of time maintaining a lot of these projects
for the Ruby community, right, so rubygms dot org and
Bundler in particular, and so, and it's all open source software,
(10:25):
and they weren't really getting paid. This was before you
could sponsor people on GitHub, and there really weren't other
terrific mechanisms for people to say, hey, I'm doing this
work that benefits you. Do you want to throw me
a few bucks? And so they founded a group called
Ruby Together. And what Ruby Together did is it it
(10:47):
collected a fund similar to Ruby Central, right where you
have these companies that are donating to them. And then
they were able to pay the open source maintainers at
least something for kind of the above and beyond amount
of time that they were spending on Bundler and ruby
gems and RubyGems dot org so that they could provide
us with secure, functional tools that do the job that
(11:10):
we need them to do.
Speaker 2 (11:12):
And then you know, and that all made sense, right.
Speaker 1 (11:16):
It was kind of in a time where I felt
like some of the social agendas were starting to crop up,
and they were a little bit vocal on that. But
for the most part, they you know, they mostly were
just raising money for you know, for the the infrastructure
work that they were doing, right, and so, you know, great,
we still get all of the goodies for free.
Speaker 2 (11:35):
They're doing work that we all need done.
Speaker 1 (11:38):
You know, they're getting paid for it, which I think
is great, and so more power to them. And so
my understanding is about three three to five years ago,
Ruby Central and Ruby Together figured out that they were
basically going and asking for support from the same groups,
from the same folks, right, because the folks that support
(12:01):
Ruby Central or companies that use Ruby on a regular basis,
you know, so Shopify and you know, base Camp and whoever, Right,
they all run on Ruby and use the Ruby infrastructure.
And so they were giving money to Ruby Central. But
then a lot of the infrastructure that's supported by Ruby
Central runs on software that's being developed by Ruby Together,
(12:21):
and so they decided to merge, and so they did,
and they merged, and so what wound up happening was
now Butler rubygms, dot org and Rubygms are all maintained
by Recentral, along with the.
Speaker 2 (12:36):
Conferences that they are no longer going to do.
Speaker 1 (12:38):
I don't know if they're going to still do ruby COFF,
but they publicly announced that they are not going to
do rails COMF so so anyway, so that's kind of
where we wind up sitting for a while, right is,
Ruby Central is paying the developers you know as contractors basically,
(12:59):
so they're paying a lot of these people to work
on the Ruby GM's infrastructure and the Bundler infrastructure and
a lot of this other stuff that we use all
the time. And Ruby Central is now responsible for all
of this infrastructure and our supply chain to get us
gems right. And so you can kind of see where
(13:19):
we're headed with this, right So, if they have a
responsibility for that, then they might have some liability if
there's a supply chain attack and you know, the problems
aren't handled properly. And so it's my understanding. And again
(13:41):
this is I talked to a whole bunch of people.
I can't really name anyone source for this. It's it's
been gathered over a number of conversations. But my understanding
is is that the board Ruby Central started getting legal
advice that indicated that they could have some level of
(14:01):
vulnerable or of liability if there was.
Speaker 2 (14:06):
If there was a supply chain attack.
Speaker 1 (14:08):
And the other concern was that the developers that work
on these systems didn't really have the kinds of liability
protections that they ought to, right, so if somebody made
a mistake building ruby gems the CLI, and somebody else
was able to exploit that and do a mass supply
(14:29):
chain attack, they might be personally liable. And so there
were these concerns that were coming up, but mainly, if
Ruby Central gets sued and gets taken down, then who's
going to run RubyGems dot org and who's going to
do the work to protect the supply chain and things
like that. So, and here's where I'm not going to
(14:50):
represent anything that I haven't heard or don't know, but
it's my understanding that they determined that they needed to
amend the agreements they had with these other open source
maintainers so that Ruby Central could protect itself in the
case of, you know, something going really badly, and on
(15:15):
the other side, provides some level of indemnification to the
Ruby The Butler and Ruby Gems maintainers, right, so that
if something happened and they got personally sued, that Ruby
Central would be in a position to help protect them
(15:35):
from legal jeopardy. And so the other thing is is,
and I've seen this in other open source systems where
if you contribute to a project, so legally under US law,
if you write code, you own the code. And so
usually if you're working on some kind of system that's
out there at all, then especially if it has a license,
(15:59):
it's not like MIT, right, because if it's MIT license,
the license basically says take this and do whatever you
want with it, right, And so then there's there's not
really any like I can't come after you for using
my code because it's MIT license.
Speaker 2 (16:13):
Right.
Speaker 1 (16:13):
If I license an MIT, it says explicitly in there
you can do whatever you want with it, and so
I'm essentially giving over my copyright protection on the code
and allowing you to do what you want with it.
But some of the other licenses out there don't allow that.
And so then what happens is a lot of times
you'll have a contributor agreement that says, if you contribute
(16:34):
to our code base, then we own the code, and
we control the license, and we're able to write, we're
able to put it out however we want, right and
so then they can continue to maintain it under an
Apache license or things like that, and they don't have
any obligation to you to you know, they don't forget
(16:55):
your permission if they want to do something else with
the project leader, and so it gives the project owner
of flexibility. And so it's my understanding that that's kind
of the direction that Ruby Central was looking to go to,
where they could then have these kinds of contributor agreements
that would allow them to operate and have a little
more control over how rubygms, RubyGems dot org and things
(17:20):
like that we were managed. But if you look at
it from the other side, I mean, some of these
folks have been working on these projects for more than
ten years and have done a ton of work, and
they've kind of operated in this arena where they didn't
have as much oversight and they didn't have people telling
(17:40):
them what they could and couldn't do, and you know,
they felt a sense of ownership over the project, which
you know, I think is terrific. And so Ruby Central
coming in and saying hey, guys, we need you to
sign these agreements and do X, y and z in
order to continue to work on this project. And you know,
(18:04):
we're going to take a more active and controlling role
on this open source project that you've just worked on
and contributed you know, hours and hours and years of
your life to. Right, we're taking a level of ownership
away from you. I totally understand these people going, whoa, whoa,
Wait a minute, right, we don't remember signing up for this, right,
(18:26):
we signed up for Hey, you know, let's fund this
stuff in the way that it gets funded.
Speaker 2 (18:32):
Right.
Speaker 1 (18:32):
But I also can see the side of things from
Ruby Central's angle where they're looking at it and going,
if we own and are responsible for the code in Bundler,
in the Ruby gmc l I and rubygms dot org,
and something bad happens even though we didn't do it, right,
(18:53):
it's it's a contributor that's here, that's contracted through us.
We bear the brunt of that liability, and so we
need to have certain guarantees in order to be able
to say no, we've done everything we can, because then
if they get sued and they say, look, you know,
we've done we did everything we could, We followed all
(19:14):
the best practices. Right, we shouldn't be held liable for
a thing that is impossible to foresee and uh, where
there's not really a good practice for protecting against it, right,
then then they can they can put together a much
more sound defense because at the end of the day,
they can tell the court, no, we did everything we
(19:34):
were supposed to do, right, and it's not it's not
negligence or malice on our part, and so we can't
be held liable. Right And and so I understand. I
understand both sides. I understand the push and pull. So
here's here's where things kind of get a little dicey
for me on the Ruby Central side, right, because for
(19:55):
the most part, I understand where Ruby Central is coming from,
and I support them in what they were doing as
far as their motivations and things like that. Right, I
haven't seen any evidence that suggests that this was some
kind of hostile takeover, that there's some ego involved, or
that there's some kind of you know, malicious intent to
(20:16):
screw over the community, or some political gamesmanship that has
to do with these contributors. I haven't seen any evidence
of that at all. And so for the most part,
I think Ruby Central was just trying to do the
right thing, and they did.
Speaker 2 (20:29):
It really really really really really really.
Speaker 1 (20:30):
Really really poorly, right, because the first thing they should
have done is they should have been doing all of
this in public, right. I understand that maybe they don't
want to public publicize, Hey, we have this legal exposure, right,
you know, if this, if any of this happens, then
(20:50):
we're legally liable, and so we're trying to fix it. Hey, folks,
don't sue us in the meantime, Right that maybe that's
not the best.
Speaker 2 (20:56):
Way to go.
Speaker 1 (20:57):
But what they could do could have done, is they
could have said and they could have come out and announced, right, hey,
we are putting a new policy in place for contributors
so that you know, so that we have these kinds
of guarantees on the work that they do, and we're
providing these kinds of protections for the contributors on the
(21:20):
work that they do. And we're we're just trying to
kind of button up some areas so that we can
protect the community and that we can protect the we
can protect rev Central, right, and that way we can
continue to provide services, we can continue to work on
these libraries and we can continue to give people what
they need, right and maybe you know, not in so
(21:42):
many words, tell us, you know that they're they're trying
to they're trying to for the longevity of the of
the system to make these changes and then acknowledge right
that this may be painful and that the contributors are
probably used to working under different constraints, and we're working to.
Speaker 2 (22:01):
Make sure that this is as painless as possible. Because
then when you go in and you.
Speaker 1 (22:06):
Eventually revoke access or you know, try and get really
you know, maybe even push twist arms a little bit
to get them to sign these agreements, then people know
it's coming.
Speaker 2 (22:19):
They know what's up.
Speaker 1 (22:21):
They know that the Ruby Central I keep wanting to
say the foundation, but again I don't know if it's
organized that way.
Speaker 2 (22:27):
But at the end of the.
Speaker 1 (22:28):
Day, right, just so that people can see this coming
and go, oh, well, they obviously wouldn't agree to the
you know, the terms on Ruby Central, and yeah, I'm
frustrated on behalf of these folks, but you know, it
was all done above board, It was all transparent. We
all knew it was coming, right, and then they can
(22:50):
come out and they can make similar announcements because these
people are people that we all really rely on and
in a lot of cases at least trust, right, we
trust their code and things like that. So, you know,
they had to know that these folks have a little
bit of pull and that you know, if if it's
painful for them, we are all going to know and
(23:11):
a lot of us are going to be sympathetic to them, right,
and so, and again I don't know what level they
had communication with the contributors themselves. It sounded like they
were somewhat blindsided or completely blindsided, and that's not okay, right,
And so what what Ruby Central should have done is
they should have done this all above board and transparently
so that people could kind of connect the dots and
(23:33):
see it all coming. And they definitely, definitely, definitely should
have been talking to contributors, right. This should not have
been a surprise of contributors. It should have been a hey, look,
this is this is the contributor agreement that.
Speaker 2 (23:45):
We're gonna we're going to enforce.
Speaker 1 (23:49):
If you have any concerns or you think we could
change things in it, right, we're welcome to talk through it.
Speaker 2 (23:56):
Right.
Speaker 1 (23:57):
You know, this is what we're trying to do with
liability and longevity and things like that. And so ultimately
we're just trying to do the best by you, but
also make sure that we're doing right by the community.
And so then at least then you might have some
of the contributors coming out and saying, no, they told
us a while ago, and we've been negotiating on the
(24:24):
on the contributor agreement, and you know, and so you know,
these are the areas where it broke down. These are
the couple of things in the agreement that I didn't like,
and so you know, ultimately I wound up not signing
it and resigning right that that it just changes the
whole tenor of the thing, right, And and then on
(24:45):
the other side, right then we can also see that
they're negotiating in good faith right anyway. So so Ruby's
Central just screwed this up like massive, big time. And
then the other thing I understand is that somebody in
them in who was one of the major contributors left
(25:07):
or be Central, and so they had to replace somebody anyway.
Speaker 2 (25:10):
And so my understanding is is.
Speaker 1 (25:12):
That that caused the board to want to accelerate the
timeline because whoever they brought in was going to be
working on some pretty major stuff, and if they brought
them in, they could just have them under the agreement
to begin with. And so it's my understanding that they
started looking at that, and then that's when the board
essentially directed the folks that run the infrastructure to start
(25:38):
removing access and you know, changing the GitHub organization and
things like that, and so that kind of happened in
a hurry all at once. And again that was something
that they really shouldn't have done, because there's no reason
that they can't bring the new people on under the
under some kind of agreement and keep the old people
(25:59):
on under you know, and just tell them, look, you know,
we're bringing we're starting to bring you know, more important
players in the in this system in under the agreement.
So we need to get you on the agreement by
this date, right and then and then work with the contributors.
So so anyway, so that you know that that's that's
(26:20):
kind of the mess. Now, a couple of other things
that happened. We're so RubyGems dot org got forked and
I need to go look up. I think it's Ruby
dot coop. I'll have to find it. I was reading
up on it the other day anyway, So so yeah,
(26:44):
so uh kind of the way that things are looking now, yeah,
I'll find I'll find the link. But anyway, feel free
to go check it out. I'm personally not uh, I'm
I'm gonna keep using Ruby gems until until I feel
like I have a real reason to switch. Right now,
(27:06):
I think again, you know, I think they're trying to
act in the best interest of the the the community.
But at the end of the day, yeah, and anyway,
it might it might not be Ruby dot coop, but
it might be like co op is the way that
they're looking at it.
Speaker 2 (27:21):
Anyway, So gem dot coop. There we go.
Speaker 1 (27:23):
Okay, so it's gem dot coop. It's at gem dot
co op. So it's a new Ruby gem server. Looks
like Mike McQuaid is helping them set it up, and
it kind of follows the homebrew model. And then yeah,
you can swap in your bundle, bundle, your gem file.
(27:46):
You can swap out Ruby gems dot org to gem
dot coop. So anyway, and yeah, you know, so, so
the contributors are upset.
Speaker 2 (27:55):
They went and started their own thing.
Speaker 1 (27:58):
But this is where it gets a little it weird
on the contributor side. So apparently, and there was a
whole write up on this on Ruby Central and all
linked to it in the show notes. But apparently, so
they went and they revoked everybody's access to the the repos, right,
(28:18):
and but they're all they're all public.
Speaker 2 (28:20):
Reposts, so you can go and you can fork it, right,
not a big deal.
Speaker 1 (28:24):
And so I'm assuming that that's what gem dot coop
is doing, is that they just forked RubyGems dot org
and then you know, they're seeding it with whatever Gem
information they have. But it's all hosted on AWS. And
apparently the route access certificate or credential wasn't rotated when
(28:49):
they removed people's access to the other stuff, and so
a lot of folks were still able to access the
RubyGems dot org servers and so and so this is
the other part of the drama. And you know, and
a lot of people have weighed in and said no
ruby jams, blah blah blah. I've heard some people try
(29:10):
and pin a lot of this on shopify. I don't
find any of that evidence compelling. I really think that
it was just the Ruby gems board and then really
screwing it up anyway. So a lot of the contributors
who had helped maintain the systems still had access to
the ruby gems servers, and so the folks at Ruby
(29:34):
Central actually posted some of the emails that they got
from Andre Arco and where he was saying, Hey, maybe
we could monetize or otherwise lease the log information from
RubyGems dot org and you know, work out some kind
of arrangement where they could use that. And Ruby Central
told them no, told him and whoever was working with
(29:57):
him no. But then they show Mode that and he
told him he still had access to the servers, and
apparently they didn't solve that in a timely manner, right,
there was a few days and he still logged in,
and they imply that it was him without actually directly
saying it. They implied that it was Andre that was
(30:18):
getting in. The evidence really does point that way, But
I haven't seen the logs firsthand or anything to be
able to definitively say no, this really, you know, really
implicates Andre. So I'm a little uncomfortable putting his attaching
his name to it. But somebody who had that level
(30:40):
of access logged in and then they started changing credentials
on the ruby jem server, and so the folks at
Ruby Central couldn't get in, They couldn't get into the
AWS setup, and so they wound up having to contact
AWS and doing a credentials reset, and then they went
in and they fixed it all up. But they could
see that whoever it was it logged in several times
(31:03):
had accessed a bit of information. It didn't look like
they had copied anything off, but.
Speaker 2 (31:11):
He did.
Speaker 1 (31:12):
Anyway, there are a couple of things here that just
kind of really make me scratch my head, I mean.
And then Andre came out later and actually and so
this is where it really looks like it was him.
He said in his blog post that he went in
and was changing the credentials so that the system wouldn't
get a compromise. But the way that it was explained
(31:34):
on Ruby Central, and you know, the logs that they
presented and things like that, some of that just doesn't
quite add up to what Andre says he was doing
in there. And the other thing is is that I
think he probably could have done more to just kind
of force them around, because yeah, I mean, at some
(31:57):
point you're gonna, you know, you could get enough public
out cry from the community saying, you guys are putting
us all at risk if you don't change this. But anyway,
but the flip side is is than anybody who wants
to go in and try and hack it right might
be able to get in. So I don't know, I
don't know what the answer would have been, but I
think there were better ways for him to handle it.
(32:18):
And the other thing is is that if he wanted
that data because it would help them set up gem
dot coop and make gem dot coop you know run better,
or know what kinds of performance aspects or you know,
access patterns or anything else. I mean, all of that
stuff would have been in those logs and probably could
(32:42):
have helped them get that set up. And so that
that doesn't sit quite right with me.
Speaker 2 (32:48):
And just you know, getting in and accessing stuff that.
Speaker 1 (32:52):
Way when you've been you know, when they've basically let
you go from the organization and stuff like that, that
doesn't sit right with me either, And so I have
some really really grave concerns there. I've also seen Andre
do some other things where he's gone on the attack
(33:12):
for against other people, and so he seems like as
far as like a maintainer of Butler, I think he's
done a terrific job.
Speaker 2 (33:21):
But as a member of the community.
Speaker 1 (33:23):
I think sometimes he is a little bit of a
loose cannon and the way that he approaches some of
these issues, and so I'm I'm very not comfortable with,
you know, letting him off the hook either. In fact,
if I were Ruby Central, I would I would be
giving a serious look to you know, what repercussions can
(33:47):
you know, come against him. I don't know that I
necessarily want them to sue him or anything, but you know,
it's like, hey, look, you know, how do we how
do we curb this so that other bad actors aren't
going to do this kind of thing, right, that they'll
play ball in a way that actually is ethical, because
I think it was unethical for him to log in
(34:08):
and do any of the stuff.
Speaker 2 (34:09):
That he did.
Speaker 1 (34:12):
But again, you know, I mean, he said he was
just trying to change the credentials, and if that's true,
then maybe he deserves the benefit of the doubt. But
some of the other things that were done on the servers,
I just I don't know, but it does look like
he didn't actually compromise the systems and so anyway, I'm
going back and forth mostly because I don't know if
I want them to throw the book at him. But
(34:32):
I don't think he should get away with it either,
because I don't think what he did was right. So anyway, whatever,
whatever the appropriate outcome is there, I don't know if
I have a proper recommendation, but anyway, so that's where
things are sitting. I've told a few people at Ruby
Central at this point that what they need to do
is they need to just come out and come clean
on all this stuff, right, just say, hey, look, this
(34:55):
is where the decisions were made, These are the strains
we were working under, These are the concerns that we had,
and so this is what we did, and this is
the stuff we got right, this is the stuff we
got wrong, and these are the procedures that we're going
to put into place to make sure that we don't
mess it up again. Right, And that way the contributors
(35:17):
can all be comfortable that they're not going to pull
anything where they feel like they're getting screwed over. And
then also you know, feel like the the GEM repositories
and stuff like that are all in good hands, right
that hey, look, yeah, we should have changed the credentials
and rotated the credentials, and.
Speaker 2 (35:38):
So we have a procedure for that now.
Speaker 1 (35:40):
And you know, we just go through the whole list
of things whenever somebody you know is no longer a contributor,
right to make sure that only authorized people have access,
and yeah, just stuff like that, right, and just make
sure that everybody knows. And then yeah, just do a
big Maya culpa to say, hey, look, you know, we
(36:01):
know we messed up, and so this is what we're
doing to be more transparent so that people don't have
to be concerned over the infrastructure or over the treatment
of the contributors because the contributors are working for us
for free in a lot of cases, or if they
are getting paid by Ruby Central, I don't think it's
full time, and he's just part time, and so they've
got to go figure out other stuff in order to
(36:22):
make stuff work. And so you know, do right by
those guys, right. And then on the other side, I
think we deserve a much better explanation from Andre regarding
accessing those servers. Honestly, it makes it really hard for
me to trust him, just because it seems like there
(36:43):
are some kinds of ulterior motives here, but I don't
know what they are. I don't know if gem dot
coop is supposed to have some kind of commercial backing
or right, so maybe they'll offer like private GEM repositories
and stuff like that like NPM eventually wound up doing
(37:04):
or stuff like that, and so anyway, I'd like to
see a lot of that. And then I think, I think, honestly,
we need to have an honest discussion in the community
and just be like, Okay, so at the end of
the day, what you know, what's our expectation from these
organizations that are are doing this work and from contributors
(37:24):
to our our kind of core offerings.
Speaker 2 (37:28):
In the community.
Speaker 1 (37:31):
And then we need to make sure that these folks
know that these are the expectations we all have. And
then lastly, when they do stuff, right, I think we
have to show a little more appreciation.
Speaker 2 (37:42):
Right, So, like I said, you know.
Speaker 1 (37:43):
The work that's been done on Butler and Ruby, gems
and reegms dot org, right, regardless of you know, some
of maybe the bad things that we're done. I mean
I've befit benefited from that work, and so you know,
a hearty thank you to the people that are doing
making those gone ttributions. And at the same time, you know,
(38:05):
I have a friend that kind of messed his life
up making some poor decisions, and so, you know, as
he was going through some of the consequences for the
things that he did, you know, I went to lunch
with him multiple times. I tried to support him as
best I could, but I looked at him and I said,
(38:27):
You're never going to get me to give you a
pass on what you did right. But at the same time,
I'm going to support you in moving forward in the
right way to make things right. And that's kind of
where I feel like I'm at with these folks. Right
It's like, look screwed up. I'm not giving you a pass.
Speaker 2 (38:45):
You know.
Speaker 1 (38:47):
I think I can eventually forgive you if you prove
out that you're going to do it right. And in
the meantime, you know, let me support you in doing
the right thing.
Speaker 2 (38:59):
And so.
Speaker 1 (39:02):
Anyway, hopefully that that helps kind of paint a little
bit more of the picture for people so that you
all understand, you know, what's going on and where things
are at. And then yeah, at this point, besides kind
of supporting people and doing the right thing. I personally,
I mean, I don't feel like it's picking sides to
(39:23):
say that I'm sticking with Ruby gms until you know,
they prove that I can't trust them and then you know,
the behavior as far as like logging into the servers
and stuff.
Speaker 2 (39:35):
I just I don't think that using gem dot coop is.
Speaker 1 (39:42):
Necessarily dangerous or you know that that I can't trust
them to take care because I think they have an
interest in making that service work and work as.
Speaker 2 (39:51):
Best it can.
Speaker 1 (39:52):
But it does create a trust issue for me with
with Andre So yeah, some of that would probably have
be resolved before I'm full throated endorsing, you know, switching
or adding them as a source in your gem file.
So anyway, that's that's kind of where things sit for me.
I'm sure that there are things that you know will
(40:13):
come out later or that I haven't heard, that are involved.
There are a lot of other opinions that have come
out on this stuff. You know, Ara Howard came out
and you know, it was pretty vocally upset with Ruby Central.
You know, I've seen other people come out and say
I'm not taking sides. You know, they kind of took
(40:33):
the tack that I did and said both sides screwed up.
I've heard people come out and say both sides screwed up.
But I still trust Ruby Central and have kind of
defended them, and I feel like I guess I've kind
of done that to some degree. But at the end
of the day, you know, do your homework, go figure
out what's going on, figure out if this changes anything
(40:55):
for you, and then let's go and write beautiful code
that makes us happy. All right, So I'm gonna switch over.
I'm going to do some picks. So my first pick
I always pick a game. I might have picked this
one on the show before. I'm and pick it again
if so, and if not, then you're hearing about a
terrific game. It is called infiltrators, and it's not spelled
(41:17):
like infiltrators the regular word. It's spelled like infiltrators. If
the last part of the word was spelled like traders,
like people who betrayed their country and so anyway, so
it has an extra eye in it. Basically, it is
a card game and it has essentially it comes with
(41:37):
a deck of cards, not face cards. It has its
own cards and they're all I think there are five
colors numbered two to fifteen. And what you're doing is
you have traders that are.
Speaker 2 (41:54):
Basically cards. You're trying to figure out what they are,
and so each player will pick.
Speaker 1 (42:00):
So you have a you have a hand of cards,
and then you have a card in front of you
that's face down, and so people can hand you a
card that you use as a clue to let them
know what the card.
Speaker 2 (42:12):
Is that's face down in front of you. And so if.
Speaker 1 (42:17):
You put it sideways, it means it has nothing in
common with the card that's face down, right, So if
it's a blue two, then it means that the card
is not blue, and it's not a two, but the
two has all of its multiples on it, so it
has two, four, six, eight, ten, twelve, and fourteen on it,
And it means that your card that's face down is
(42:39):
not a blue, and it's not a two, four, six, eight, ten,
twelve or fourteen.
Speaker 2 (42:43):
Right.
Speaker 1 (42:45):
If you hand you the blue fifteen, then it has
the factors of fifteen on it, and so you know
that it's not a three or five or a fifteen,
then you know it's not blue. If it's faced the
other way, then you know it's a blue or A three,
a five or fifteen or both, right, But there's only
one copy of every card, and so if it's the
blue fifteen, you know it's not the blue fifteen, right,
(43:06):
does that make sense? So anyway, so you clue until
you get the cards. There's a prop gun and you
get so many bullets because you execute the traders. Eventually,
we just got to the point where we just point
and say that's the red three, right, and so we
sometimes people would pick up the gun and use it,
but I'm.
Speaker 2 (43:25):
Executing, but most of the time people just point.
Speaker 1 (43:27):
So if you don't you don't like the gun in imagery,
you don't have to have it, and you can use
other markers instead of bullets. But anyway, there's a little
dry erase card that has all the numbers and all
the colors on it, so you can mark off the
ones you know that.
Speaker 2 (43:42):
It's not.
Speaker 1 (43:45):
Anyway, it's super fun game. It's a deduction game. You're
working together to you know, expose all the traders. It
has different levels that you play through kind of like
what is it the crew?
Speaker 2 (44:00):
So anyway, fun game.
Speaker 1 (44:03):
So yeah, I definitely go check that game out Board
game Geek has it weighted at two point one one
I always tell people too is kind of complicated enough
to be interesting, but simple enough that a casual, not
hardcore gamer would enjoy it. So I'm going to pick
infiltrators as that. And then the other thing I wanted
(44:24):
to just put out there is there are two things
that have happened over the last month, maybe you know
since we were recorded last that I just wanted to
talk about briefly. So one of them is the hostages
in Israel were returned. And I get that there are
people that have feelings about the whole conflict in Israel
(44:45):
right on both sides, and I'm not going to wait
into that. I have my own opinions on it, but
you know, the hostages look like they were mistreated. It
is terrific that they get to come home to their families,
and it looks like the killing has stopped for a while,
which is also a good thing, regardless of which side
(45:05):
you come down on. And so I am going to
pick peace because I just I'm all for it. I've
seen some people saying we want peace, but we don't
want Donald Trump to negotiate it. I frankly don't care
who negotiates it as long as we get it right
and as long as we can make it last. So
you know, if it raises Donald Trump's status, fine, if
(45:31):
it raises somebody else's status, right, if it's Barack Obama
over there negotiating it, and that's what's effective.
Speaker 2 (45:36):
Right.
Speaker 1 (45:37):
We're not killing people as much anymore so, which is
a good thing. We got hostages back, which is a
good thing. And hopefully the bodies that the other hostages
come back and those families can have closure.
Speaker 2 (45:48):
It's a good thing. And then the other one.
Speaker 1 (45:51):
And this affected me much more deeply, and a lot
of it's because it occurred here at Utah Valley University,
which is like fifteen minutes away from where I'm sitting
in my house. Maybe twenty minutes depends on traffic, I guess.
And that was the Charlie Kirk assassination. And you know,
this kind of speaks a little bit to what we're
(46:11):
talking about here, except you know, nobody's getting killed over
Ruby Jims.
Speaker 2 (46:16):
But we go out a lot.
Speaker 1 (46:18):
Of times and we just demonize the other people on
the other side, and I think a lot of that
rhetoric was what led to somebody shooting him here.
Speaker 2 (46:28):
And it's it's sad.
Speaker 1 (46:30):
Right, It's like for me, it's hey, look, you know,
and I agree with Charlie on a lot of the
things that he.
Speaker 2 (46:36):
Talked about, right, But at the end of the day.
Speaker 1 (46:40):
We need to be good to each other. We need
to understand each other. Right, this kind of violence, celebrating
that somebody got killed, you know, the way that we
treat each other sometimes because you're on the other side
of the political aisle, it's not okay. And I think
a lot of times if we just go talk to
people and understand where they're coming from and what they're
(47:01):
worried about and what they're dealing with and all of
that stuff.
Speaker 2 (47:05):
Things get a whole lot better.
Speaker 1 (47:08):
And sure, you know, maybe I don't come around to
the other person's way of thinking, but at least I
can understand them, right, at least I can think about
it and say, Okay, you know, do they have a
good argument or do they not have a good argument?
Speaker 2 (47:20):
Why?
Speaker 1 (47:21):
And then maybe I can argue my understanding better next time,
or maybe I change my mind, or maybe I just
change it a little bit. Right, It's like, no, they're
generally not right about this stuff, but these couple of
points tell me that, yeah, maybe there's a little bit
more nuance here or there within within this space. And
(47:44):
I think if we can understand each other that way,
you know, maybe we can heal. I hear too about
like people's families being porn apart, because you know, people
do or don't like Donald Trump or Kamala Harris or
whoever else, and you know, it's like, hey, you know,
there are so many more important things, so many more
important things that we have in common. And so I
(48:06):
really am just I guess I'm picking piece again, but
mostly I just I want I want people to understand,
come to understand each other, right, show some respect to
each other, be good to each other, and anyway, So yeah,
sorry to end on kind of a low note, but yeah,
hopefully this helps some folks get some context on this stuff.
Speaker 2 (48:28):
I guess one last pick.
Speaker 1 (48:31):
So I am getting things together on top end devs
so that we can relaunch Ruby Geniuses. I had Ruby
Geniuses running before and it kind of fizzled out a
little bit, so I'm bringing it back.
Speaker 2 (48:47):
I want to be doing the Ruby book club.
Speaker 1 (48:49):
I try to do like a general programmer book club,
and I just figured out that that's not really I mean,
we read some interesting stuff, but I think they're I
think doing a Ruby focused one is a much better
approach because then we can get into stuff that's relevant
to stuff that you're working on at work. And then
I'm going to be putting out videos for the Ruby
(49:12):
tip of the day. I'm going to be putting out
a series kind of like Go Rails or Rails casts
or Drifting Ruby that is essentially AI on Ruby. And
I'd like to get some series going on just Ruby
or just rails right, or some blend. And so if
(49:32):
you're interested in authoring something like that, I am actually
I'm happy to talk through some of that with you.
And then I'm also looking at putting courses and stuff
up on top end devs. I kind of want to
make it the Netflix for programmers, and so then you
can come in and instead of like horror and comedy
and you know whatever, you can come in and it's Ruby, JavaScript,
(49:54):
you know, DevOps, infrastructure's code, right, and so then you
can kind of pick your topic and then you can
find whatever it is that you're looking for, right, And
so I'm working through that and I'm looking for authors,
So if you want to author a series on that,
or if you just listen to Ruby rogues and you
mostly write go or something like that. I'm looking at
(50:15):
pulling some stuff together and some of those other areas
like Go, React, JavaScript.
Speaker 2 (50:21):
And and things like that.
Speaker 1 (50:22):
So and I really want to kind of become the
central place for people to come to get up to
date information on how to build AI and you use
AI tools in development. So anyway, that's what I'm kind
of heading toward here. Maybe I'll give like the full
vision and a little bit of the history on that,
(50:43):
but anyway, in the meantime, be good to each other.
You know, we'll get past this as a community and
until next time acts out
Popular Podcasts
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.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
My Favorite Murder with Karen Kilgariff and Georgia Hardstark
My Favorite Murder is a true crime comedy podcast hosted by Karen Kilgariff and Georgia Hardstark. Each week, Karen and Georgia share compelling true crimes and hometown stories from friends and listeners. Since MFM launched in January of 2016, Karen and Georgia have shared their lifelong interest in true crime and have covered stories of infamous serial killers like the Night Stalker, mysterious cold cases, captivating cults, incredible survivor stories and important events from history like the Tulsa race massacre of 1921. My Favorite Murder is part of the Exactly Right podcast network that provides a platform for bold, creative voices to bring to life provocative, entertaining and relatable stories for audiences everywhere. The Exactly Right roster of podcasts covers a variety of topics including historic true crime, comedic interviews and news, science, pop culture and more. Podcasts on the network include Buried Bones with Kate Winkler Dawson and Paul Holes, That's Messed Up: An SVU Podcast, This Podcast Will Kill You, Bananas and more.