Cool, I like to do people putting their hands in the air in the talks because it stops
you from falling asleep and it makes me more visibly aware that people are actually listening
to what I'm saying.
So put your hand in the air if you've ever used homebrew, okay, reasonable number of people,
put your hand in the air if you ever contributed to homebrew, put your hand in the
air if you ever tried to contribute to homebrew and I closed your PR, okay, sorry, yeah,
so I'm, we've been, I've not been able to hear what we've talked today, I do follow
try as much as I can, closely, what's going on in Package Management World, shout out
to Andrew's written a lot of very good, comparative blog posts on this stuff this year that
I've enjoyed.
So I'm going to try and talk about today, it's like a bit more high level than I might say
with homebrew stuff about, okay, what we've been doing in homebrew now and why and what
can we maybe learn about it in other Package Management.
So who am I?
Hello, I'm Mike McLeod, if you want to know about me now, my website is the best place, it's
all connected to social media and stuff, I don't read anything on social media anymore,
so email me if you want me to actually see it or personal social media if you want to
talk shit about me behind my back and feel great about it.
My background, I guess, like how I've gone to homebrew and stuff, so I've worked
myself where for almost 20 years, I've been working on homebrew for 17 years this year,
I'm the project leader, which is an elected sort of dictatorship, sort of position thing.
I'm a CTPO in my normal life day job, whatever and that sort of vaguely overlaps with
the homebrew, but not very directly.
So why should anyone care about homebrew, Package Manager is why I have to say, I mean, who
can hear cares about Package Manager is, okay, good, I'm glad that someone does other than
Andrew, because otherwise you'll probably cry, but I guess, in my life, the thing that's
great and terrible that homebrew is that it's somewhat taken for granted, like a lot
of Package Manager is just part of the infrastructure of how the internet works, how
I do my job, whatever, right?
So if you go and run, who's run Brewing Stole in the last week, say, okay, right?
Like, you probably didn't really think very much about it, right?
Because you probably just run something and then hopefully it worked.
But then when it doesn't work, then everyone gets upset.
Like most of the time, it only specific things are broken in specific ways for specific
people, but then when it's all broken for everyone, then everyone gets very concerned.
And the emotional reaction that people tend to have to when these tools break is heavy,
because they're so reliant on these tools, like it's really important that it works.
And in some ways, if I can be a little bit philosophical, it scares people a little bit when
they are forced to actually think how many bits of the internet and tools that they rely
on by all these people at all these places all around the world, that they are completely
unable to do their job, unless all of these things connect together.
And often, the people who are the most involved with open source are the people who are
the most forgiving when hungry breaks and the people who are the most disconnected
from open source are the people who are the most angry and sometimes abusive when
hungry breaks.
It's a bit like your toilet, really, because what it's working, you probably don't spend
a lot of time deeply thinking about your toilet unless, like me, you've recently been
in Japan and you're like, wow, they're toilets are so much better here, why is my
toilet like that?
But then, when you toilet breaks, then we just get shit everywhere, like there's chaos,
no one knows what they're doing, no one knows how to fix it, no one really wants to stick
their hands in there, our friends at the beginning of the toilet, we may be at the end.
So most people get very frustrated when they're too slow, another one, bundler is slow,
like everyone often complained about that for a good many years, right?
And then, what gets done, people gets frustrated.
So in, I feel like in many ecosystems, people get the same feedback about things being
or feeling slow, they maybe don't even know why, but then sometimes the reason why it feels
slow is because we get new tools.
So cargo is often held up as an example of a package manager that feels fast, right?
And I've not done huge amounts of rest up, so I'm not super familiar, but it's, you
know, that reputation for speed is something that's appreciated in the community, it's
sort of found the community's expectations of what these two should be like, how they
should behave, how fast they should feel, how responsive they are, in some ways it kind
of helps to buy into like, what does that language community care about?
Like, the, the Rust community seems to care deeply about building lots of tools that are
responsive and fast, well, paralyzed and all these type of things, you know, a lot of the tools
that, like, one of my favorite tools that's embedded just about everywhere now is like
RIP grip, which, if you were like, how many people went down the path of like, oh,
act, and then the silver structure and finding the perfect tool to search through your code
base increasingly quickly, like, yeah, so if you went down that line, then you learn
a few years ago, like a lot of these two will start to be built in Rust, and they're
just became this little niche of people in the Rust ecosystem who really cared deeply
about just being like, I'm going to make the fastest version of X, or I'm going to make a really
parallelized version of some existing Unix tool that hasn't really been updated in 20
or 30 years.
Right?
UV.
Obviously, that's not an example now, right?
Well, that in the Python ecosystem is kind of reshaped expectations of what speed we
should be expecting from these tools, like, what we can do, and I think UV's an interesting
example, because, again, I'm not super-officer, so excuse me if I miss speaks slightly
on this, but my understanding is some of the reasons why they've been able to be faster
is because they've kind of dropped some support for legacy things, which tools like
people, whatever, might still have to rely on, right?
And, again, like, this is where things get a little bit more tricky, and a bit more
murky for us as, like, package manager, like, developers, it's like, okay, so what, to
what extent do we prioritize speed, or backwards compatibility, or following the
reason why the tools, or maybe we have multiple tools in the same ecosystem, who can
say it, right?
So, bundler, right?
Like, I feel like bundler was a tool that 10 years ago, I heard people complaining about
how slow it was all the time, and then a lot of work went into it, and then now it's
a tool where, you know, it's not the fastest thing in the world, but it's still, like, it
does not seem to get that complete, levied against it, nearly as often as it once did, right?
And I think bundler is a nice example, because they didn't, throughout everything that
they were doing, a lot of just time and effort went into it, behind the scenes, that
meant that the tool ended up just being fast, you can add a few more things, then you
have time send it don't work, then 5% don't work, and if you want to get 100% of the
batches working, 100% of all the time, you essentially have to re-imple that most of
a brew, and that's probably going to be a bit slower than you have right now, right?
So, I ask is all to be collectively both inspired, but cautiously skeptical of some of
these tools that appear out of nowhere, and say, hey, we've been able to do this 10
x-fost and everyone else, because there's some stuff you can learn from that for sure,
like, we have learned from that in Hobroo, but there's also, it's very easy to make a prototype
version of this, which never quite gets around to, if they're writing into something that
works reliably, I can be used at scale.
Thank you.
Why do people do that, not?
In some ways, this reminds me, like, I don't know, how many people will ever sort of like
the legendary Stack Overflow answer that descends into madness about parsing HTML with
rejects?
Yeah.
It reminds me a bit of this, because it's like, you can parse HTML in a simple way
with rejects really quickly and easily, and it's like, look how low code this took,
and it was really quick and efficient, and, like, I'm 90% of the way to solving this problem,
and then I just need to put a bit more time, oh, I'm almost there, I'm almost there,
but then if you know, essentially enough about the problem stays, you know that, like,
fundamentally, you are trying to do something that is, with most of Ajax parses, I know
this pearl does some special things, it's fundamentally impossible, right?
And it's a similar sort of vein here, right, where what they are trying to do is
amrable, but they have taken a shortcut to do so that makes the end result essentially
fundamentally impossible.
So back to home, like, so the, the big thing we did recently in the last year, essentially
was, if you've used home, where you've seen, we do this kind of concurrent downloading
stuff, right?
So, in fact, the person who didn't much of the work, Marcus, is in the room with us right
now.
That's off to Marcus.
And we also have done some work on, like, a slimmer, like, internal API, and stuff
like that, to try and focus on this stuff with speed, when I, as Ruby 4.0.1, like, the
time it takes to out-pahello-wall to a terminal is dramatically slower than the time things
back to do the same thing.
And, okay, most people, like, someone literally with the home-ruh performance stuff, I
personally want social media.
Someone replied saying, in what world this home-ruh performance actually matter to end
users anyway.
Like, yes, this is a good point, but we still get people whining when, like, their shell
initialization takes 0.1 seconds longer than it should have done or whatever, right?
And then, pointing stuff to bash, make things, you know, in our case, sometimes 100 times
faster than just by the time you spin up the Ruby interpreter, right?
So, again, like, it's a weird thing, and it's very project-specific, and it's not
general advice.
But, again, for all of you working-package managers, probably your three items are completely
different, and some naive person from the outside looking in will probably have ideas
of why you're slowing what needs to be fixed.
But you will know what these things are, and you need to make sure you put these things
in front of your team, and in front of contributors you might want to come in, so that
they actually know how they can improve the stuff in a meaningful fashion.
So, as a result of that, like, I think Humbru, with the five point overlice, like, people
are complaining about it less.
I think we've done a bit of a bundle of things, where Humbru's definitely not fast compared
to his competitors, but it certainly feels a bit faster than it was before, and I think
we have now room for understanding and improvement of how we can move forwards.
So, act 2 is, let's think about, like, what we're doing in package manager land, okay,
we talked about, like, user expectations and performance and things like that.
But, I think another big part of software in general, right, like, I've taken over as, like,
a CTO of relatively recently, and one of my big things is, like, how can I make things
go faster?
And one way of making things go faster is performance and profile, like an optimization,
and let's, like, do that.
Another way of making things go faster is thinking about what are we doing today, and what
are the things we can stop doing, and if you can just do fewer things that you get this
combinatorial explosion of, once you have these different options in ways of building
packages and their dependency trees and everything like that, such that it became almost
impossible to debug these issues in a meaningful way and support them and stuff like that.
Because, again, we have limited CIO infrastructure, so we're not able to just go and
say, okay, well, we're going to build everything in every combination every time for
every dependency and figure out if that works.
So, instead, we moved essentially to a model of, like, our binary packages, where instead
of going from room to composite, much of your machine, it's, when we get to a table, there's
or we've been about somewhere else and extracts that, right?
So, that was dramatically faster for users, which dramatically less error for users,
but for power users, that results in an all-spacey being like, hey, there's a bunch of stuff
that you could do with homeboom before that you now can't really do, or at least, to be
more exact.
If you want to do this, you need to go over there and do the work yourselves, because we're
not going to do that work for you, which, as far as a lot of room to do, source users
have concerned, is the same as saying, this is now fundamentally impossible.
But the tricky thing with this is now we're in the situation where, because no, everything's
being built on individual user machines, we need to figure out, like, well, what we're
going to support and what we're going to build and all that type of stuff.
So, it's so, no, we're just like, okay, we build one package and one platform, we pick
a macOS version, we build on X8664, great, then eventually we add the Linux support, then
Apple came along with Apple Silicon, and then we have to do, well, I'm 64 support, and
then we decided, because we hate ourselves, we're going to do, oh, I'm 64 support and Linux
as well, and then I'm sure at some point there will be something else, right?
So, like, yeah, we're at risk, we'll come, I'm sure, you can run homeboom in your
poster, whatever, right?
So, if hands up, any folks in here who support, like software on multiple platforms, or more
platforms than they did 10 years ago, it's a bit of a pain in the ass, right, about what
works for 90% of people, most of the time, right, and then that was their primary focus,
right?
So, in homeboom, we've tried to do the same thing, right?
We tried to focus on, like, what the most of our users actually do, and what that looks
like is getting to a point where you realize, well, we're supporting a bit too much, right?
So, we used to support, in theory, at least, every macOS version, and then a few years
ago, we decided we're going to support three, we're going to support the current one,
and the two preceding ones, right?
This makes people upset sometimes, because they're still using their old Mac, and they
feel like apples abandon them, and now we abandon them, and this is really unfair.
But then even then, even with these three versions, without looks like it's, okay, well,
does that mean we have to support all this?
Or actually all of this, which just gets into madness, right, because every, like, line
here, if you're going to support that, like, we're saying, we expect all of 10,000 packages
that we claim that work on these, we're going to work on these all the time, and then when
it doesn't, it's a bug, we're going to fix it, and it's going to break whatever, and then
this comes back to the, like, well, homeboom is slow, right?
And maybe this isn't slower in terms of the behavior, but homeboom is slower to fix bugs,
there's slower to larger PRs, because we have this matrix of issues that we have to deal
with all of the time, right?
Well, that means is you end up having this limit done, right?
So we say, okay, well, we're not going to support everything all the time.
So we now don't build binary packages for the newest versions of macOS, because we're, like,
well, hey, we don't need to necessarily hyper optimize for that.
Be, we probably get reasonable matrix coverage from the otherwise, and see, like, Apple
is dropping this, right?
So on the 9th September, so on September, 2026, we're going to stop building binary
packages for Intel all together, right, on macOS, still on Linux, because that's the
majority architecture there.
But it's like, well, why are we doing this?
Could we indefinitely build this?
Sure we could, but it's going to make the project slower, and we're at a point where
Apple will have announced their plans to get off this.
So again, multi-billion-dollar corporation, 30 volunteers, right, who receive a small
slide-pend, like, we should not be holding ourselves so higher standard than multi-billion-dollar
corporations, right?
On this, we have to fight harder and harder against that in order to have something that
works for our users.
And eventually we get to a point where we're like, well, this is a security feature
anyway.
No, no, we're not interested in doing this anymore, right?
So we used to just go, okay, we have these features that we turn them off, and then now
we have, like, with a major or minor release, we dedicate, then we disable, then we delete
that code, right?
And again, that, if you don't already do something like this in your project, and you
have, like, a clear cadence, please, it's so satisfying, going, and having a little
bit of that code that goes to your pain in the ass, and knowing, putting little markers
and then being like, in six months, I can just delete all of this mess and not have to
think about this ever again.
Okay, yes, it breaks backwards compatibility, but then, if only we, like, one day, I think
someone will invent something, let's hypothetically call it a version control system, where
if they wanted an old version of some code, they could, in fact, go back in time.
It's a crazy idea, but I think, one day, it might pay off, but, you know, people, again,
it's this thing, it's entitlement, we don't have to deal with that, and we shouldn't
have to deal with that, right?
Rust isn't a nice good example of this, right?
Where they just stay, okay, here's our platform support, here's what we have, we have Tier
1, Tier 1 targets, can be thought of as guarantee to work, and in the spirit of open source,
we almost directly stole this, and we now have our own support, here's our group, where
we say, here, we have our Tier 1 platforms, these are what we expect to work, Tier 2 is
like, maybe this is going to work, Tier 3, it's probably going to be broken, and then,
it's two hundred-sucking, we want you to know, like, hey, we told you to do it this
way, you were doing it a different way, someone said, you are sucking, for those
of the back, I will neither confirm or deny that, but yeah, but it's important, right?
If you can just write this stuff down, you will find people are more likely to accept
a thing which you put in a document or a section on your website, even if you repeat yourself
verbatim in issue clients all day long, they will argue with you until the sun goes home,
but if you say, here's our support document, you can submit a PR with a proposal of why
this should be changed, they will never do that, and they will stop arguing with you.
So, there we go, really, we're going to answer the, I, I thought I had to
slamer here, but I think it's maybe gone, but, no, if I, no, it's coming, right, let's skip
over that for a second, right? So, act 3, sustainability stuff, right? So, what do we think
is the most important thing in open source sustainability, right? Money, put your hands
up if you think it's money, the hacklers are the fun of ruining this delightful cell, I
run a thing to hacklers and the fun, have given them a lot of money to do that.
But we live without any money for many years and I work fine, code, like, let's just
fix all, but we can fix human problems with code, right? We just need to write enough,
no, no, no, okay, yeah, okay, yeah, yeah, we don't like, yeah, humans, okay, the humans
we are what matter, right? Like, if you were a maintainer or an open source project,
no matter how much money you have, no matter how much code you have, no matter how many
users you have, if you decide and you're the so maintainer, you're not going to work
in this anymore, this project is effectively dead, right? Someone can fork and they can
take it on and lead from where you left off, sometimes people do that, a lot of the time
they do not, right? So, what this means is we need to take care of the humans, right?
If you're in a project where you've got multiple maintainers, take care of each other,
if it's just you take care of yourself. I apologize in advance, there's a lot of cell
promotion coming because I've written a bunch about this stuff, it's a double-eye care
and awful lot about, and I'm not going to reiterate all my blog posts, but I am just going
to put them on the screen, so you can go and look them up if you're really that bored.
Right, so the first one, I wrote this thing a while ago, I wrote it before AI stuff,
robot-pedantry human empathy, so this idea of like what we should try and do in our projects
is automate as much as we possibly can, but also not automate the stuff that humans are
actually good at. Like, I remember I wrote this colleague in response to seeing projects
that were like automating their messages of being like, you have made a new PR, good job,
you are valued as a human, and it's like, well, that doesn't really mean a lot to people.
What? Let's have the robots do as much as we can, get them to do, again, pre-AI.
This is mainly talking about CI when I'm talking about this, I love an AI, I'm not going to get it to AI today.
And that's, as humans, right, we can tell people like, good job, thank you, you've kicked us,
I'm looking forward to seeing another PR for me, because you did such a good job in this stuff.
That really makes a difference. There are people who contribute to open source for a long time,
just because of nice things one or two people did. Right, all right, there's a guy here at this
conference, most years, Cornelius Schumacher, he was my mentor on Google Summer of Code 2006,
when I worked on Katie, I can say there's absolutely no way I would have done any work on her
brew, where it not for him being a really good, you know, Summer of Code Mentor, right, there's so many
people throughout this entire conference, it's entire industry, that's stories like that, where this
one person made a difference, I'm probably not sure exactly, right, that person could be you,
by just being nice, saying nice things, encouraging people, right, and I know we have to deal with a lot of
toxicity, and it's hard, you can get a thick skin, I have a very thick skin, but trying to free
yourself out for those moments, where you can connect with someone else, can be like,
good job, well done, it makes a big difference, right, next thing, contribute to funnel, right,
very brief TLDR of this, think about you have a nice funnel on your project, right, a bit like
a sales funnel, any of you know what that is, but basically this idea of like the people who use
your project, some small proportion of them will end up contributing to your project,
and then some small proportion of them will contribute enough that you want to make them
containers, right, but like, if you can get that funnel to be as effective as transitioning
between each stage, that's going to be really good. So one of the things, when we're really
early on, there's so many expectations that like, this is not a project run by us for you,
this is a project run by all of us together, right, whom we had no way of doing automatic version
bumps or anything like that, but it first created max, the greater it was just like, right,
I'm not going to point maintainers for every package, I'm just going to say, if you notice this
is outdated, submit a poor first to fix it, right, that did a really good job of getting a
whole brew, a really, really decent number of contributors for the number of users we had,
and we have a tiny number of maintainers relatively, we have like 30, so that's way better than it
was like 10 years ago. Over to our economics, again, just restaying the stuff about like money,
right, like money is not really what matters, like money helps with some problems, if you want to
come to my Ruby James talk later today, you'll hear me talk about how money creates some other
problems. But what we want to use is the money to help humans, right, so we can help the humans
do the right things, because ultimately I think the scarce resource in open source is maintainer,
not even maintainer time, maintainer motivation, right, and if you have a project where the
environment and the users and the support structure and whatever makes you go, this fucking sucks,
I don't want to do this anymore, then that project will die very soon. Cool, so how do you do that?
Say no to things, say no to most things, most of the time, right, like chances are, unless you hear
a feature request a bunch of times or you strongly disagree, you can say no, that's fine,
you're allowed to do that, because ultimately you owe no one anything, read the licenses of
yourself where it says pretty much, and I'm not a lawyer, so please don't do this. If I fuck
up your shit on purpose, you still can't sue me, because you agreed to the license.
Again, I'm not a lawyer to not do this. So what do we talk about today?
Default to fast, right, like, performance, people care about it,
particularly when other tools have lost in the yours, it's not about idea to think about
performance, even if you're just thinking about performance from the scope of what you do with
the support, right, having a support reality that you can publish and you can use that to
set expectations, and then finally, optimize for the maintainers, because they are the people who
you can project a live. So, one change is enough, right, just think about today, the projects you
work on, what's something you could do to help one of these three things. Makes something faster,
maybe clarify even if it's one sentence and you're reading what you support and what you don't,
or set a boundary for yourself or other maintainers for how you can, like, best to support
yourself as a human. That's all who's going to do one of these three things in the next month.
Some people put up their hand while saying, no, we're just confusing.
If you have questions, I don't know if we've got time for any now, we don't, but semi-anymell,
go my love so you've got to have to contact me, and thank you very much for coming.