This is the GitHub podcast, a show

dedicated to the topics, trends,

stories, [music] and culture in and

around the open source developer

community on GitHub. I'm one of your

hosts. My name is Abby from the open

source programs team, and I'm joined

with my lovely co-host, Andrea.

>> I am Andrea Griffith, senior developer

advocate at GitHub, and I am delighted

to be here today because we are talking

to the amazing Mike McUade. And if you

ever use Mac for development, you've

probably used his work without knowing

it. Mike is the project leader of

Homebrew, the packet manager that's

installed on tens of millions of Macs

worldwide. A project he's been

maintaining for over 16 years, I think

longer than anyone else. So that makes

him one of the most experienced open

source maintainers in the world. And

we're just delighted to have Mike here

with us today. We're going to talk about

Homebrew, his evolution and growth as a

maintainer throughout the years, and

also the open-source zone upcoming to

GitHub Universe.

>> Hey Mike, welcome to the show.

>> Hey, thanks for having me.

>> Can you tell us a bit about like why did

you start contributing to Homebrew, what

it is? Yeah. So, Homebrew, my like

oneliner to describe what it is, I

guess, for the probably fairly savvy

group who would be listening to this

would be it's basically like a pack app

store for open source software in your

terminal. Um, so we have other

non-opensource software and stuff in

there as well, but that's like what most

people use it for most of the time. And

also, I guess another way would be

saying if you're like a developer and

you're on a Mac, chances are you install

a bunch of stuff, all the stuff that you

don't install like mpm or ruby gems or

pi or whatever, you're probably

installing with homebrew. So like your

database and all that type of stuff.

>> So you're likely to have used homebrew.

Some people that might be listening to

this or watching us now are probably

as old as homebrew or younger than

homebrew, which is kind of a wild,

right? Uh yeah, homebrew is all they

known. What did people have to do like

what what were we suggested to then?

>> Uh so homebrew was made by a guy called

Max Howell originally. So he was working

at a startup in London. Uh and he was

complaining about Macports, a package

manager, still very good package manager

around to this day. Uh he was

complaining in the pub in London, as you

do when you're in London. Um, and I

think apparently one of his co-workers

eventually snapped and said like, "Well,

if you know so much, why don't you just

go and make your own package manager,

right?" So, he went home, uh, having had

some beer and then wrote up his design

for a beer themed package manager, which

then became homebrew. So, I guess my

involvement was maybe a few months into

having created homebrew, like a few

people were starting to use it, mainly

in the Ruby community to begin with. Um,

and I heard about this from like a

friend and friend. I was also at a tech

startup in London at the time. Um, and I

tried to build a thing on top of

Macports to sort of make it work in a

more what I didn't realize at the time,

more homerewy way. And then I came

across homebrew and I was like, "Oh,

this is cool. I'm going to use this,

right?" And I didn't start using it

thinking I was going to contribute code

or maintain or anything like that. But

I'd done bits and pieces in open source

over the years with like KD and Linux

and various other bits and pieces. So

when I had a problem like it was fairly

natural for me to go and be like okay

I'm going to go and like submit a change

to homebrew. I was going to say submit a

pull request but actually homebrew

predates pull requests being on GitHub.

So the way it started is me and Max

would both be on IRC and I would like DM

him on IRC with a link to my commit on

GitHub in my fork which he would then

you know check out locally and pull that

in and then push it and whatever right

and eventually it got to the point that

like I contributed a few bits and pieces

and he was like hey like why don't you

be a maintainer and help me do some of

this. Uh, so I think I was the third

person to join uh with Max being the

first and yeah and then I just sort of

never got around to not doing that and I

still am doing it to this day.

>> I didn't realize there was a time that

GitHub didn't have pull requests. So

that's news to me.

>> That's amazing. You joined this team,

you became a maintainer. Uh, at the time

it was only the two of you. How many

maintainers are there now? I'm actually

I need to check because it like varies

from week to week, month to month. Um,

and we just had some we're about to have

some new people join and we just had

some people leave. Uh, so we've got,

let's see, 29 people as of today. Um,

and yeah, and I I would say like on a

day-to-day basis, not all of those

people are involved, but like on a week-

toeek basis, probably like at least

probably half of them are involved in

some way. Um but yeah, but still it's

not a lot of people considering Homeu

has we don't have exact numbers but like

you know millions perhaps tens of

millions of users. So yeah of course

>> not bad going for 30

>> and and the OSI did a little blog post

about you. You said the ratio from you

have a 100 to1 contributor to maintainer

ratio which is really impressive. Yeah.

How do you think you got to that place?

You have so many contributors. So the

not to bore the listeners too much with

package management minutia, but the way

most package managers like homebrew kind

of work is you have like one maintainer

for each package. It may well be a

maintainer maintains like multiple

packages or whatever, but essentially

you tend to have like

[snorts] potentially even thousands of

maintainers like packaging things. When

you go to like stuff like mpm, there's

probably literally millions of

maintainers maybe at this point. But at

home, the way we did it is like, okay,

like the goal of the maintainers is not

to do all the work, but essentially to

shepherd the work that is coming in from

other people. So that's been part of it.

Part of it is like the homebrew's I

guess DSL we call like domain specific

language like the way you define what

gets installed and how it gets installed

is like very readable and it's written

in Ruby and it's pretty easy even if

you've never done literally any

programming before let alone any Ruby

before to kind of contribute and fix

things and whatever. And then the other

thing which I'd like to take at least

partial credit for is like I'm I am and

homebrew is very very very into like

automation and tooling and stuff like

that. Right? So uh you can make your

first contribution to homebrew by

running like a single command that will

like change the version and commit it

and make a pull request and open the

pull request for you. Right? So like

we've just made it really really really

easy to make a contribution but not in

the way that some projects have done

where they make it easy but by kind of

maybe keeping issues around that remain

unfixed or essentially like giving

people a scratch pad to play with but

like actually letting people easily

contribute valuable work for us, right?

Um and then the other thing on the

automation side is like we we again try

and have as much human review instead

turned into like automated tests, right?

And to you know I guess this chat in

enterprise software circles about shift

left but basically what that means from

like the homebrew perspective is like

okay so what might have started off as

being a human says hey like I reviewed

your PR please do X then maybe turns

into a CI check that says the same thing

like automatically for you. So a human

doesn't need to be awake but then we we

integrate with like your editor now. So

if you use like VS code making a

homebrew formula or whatever then we

will provide inline in editor without

you having to do anything other than

have homebrew installed like guidance of

like what you should be changing and

what you should be doing and if you have

like auto formatting enabled then you

can literally like do the wrong thing

press save and watch it like all jiggle

around and automatically do its stuff

which I still find very cool. So all all

that stuff basically I guess we've just

tried to make it very very easy to

contribute and try and eliminate that

friction from the process whenever we

can.

>> You've written a ton about being a

maintainer about of course helping

contributors come into the project. Um

some of your my favorite writing of

yours is about contributor funnels and

that myth that maintainers can just tell

people what to work on. The technical

aspects of automation and making it easy

using the tools to get folks to a place

where they're contributing is meaningful

to them is awesome. But also there's a

human perspective there. How do you keep

people motivated? How do you make

volunteers want to do this when you

can't really give them deadlines or say

like, "Okay, well this needs to be done

first." Like I that's always

mind-boggling to me for a project this

size and that is depended on by millions

of developers every day. I mean I think

the the short answer is I guess soft

power instead of hard power right so

like nowadays we have like a governance

structure and I'm the project leader and

I'm elected and blah blah blah so I have

a certain amount of hard power in which

I can say to people I mean I can't

really say you must do this but I can

say we will not do this right we're not

going to move forward what whatever but

in my mind uh every time you do that you

sort of lose something a little bit like

ideally everything is a conversation

negotiation and you convince people that

it's the right thing to do or they

should work on this or whatever rather

than telling people what they have to

do. And I guess one of the nice things

about open source is like you know what

in the workplace people also prefer to

be told like hey I'd like you to do X

rather than being like I command you to

do X right generally people don't like

that very much. Um I I certainly don't.

Um and yeah I think I think that's the

main thing. I guess another big thing we

do on homebrew which has made me in some

ways in some places on the internet a

slightly controversial figure and if you

Google Mike Mcuade low-end swear word

that begins with a uh then you can find

quite a lot of people talk about how I'm

not very nice to deal with. But the

reason why I'm sometimes not very nice

to deal with is because sort of the

reverse of that contributor funnel,

right? So all of the maintainers of

homebrew use homebrew, right? And we can

exist and happily use homebrew and find

homebrew to be a useful tool even if no

one else does. Right? But the problem is

is if all of these maintainers who are

doing this primarily in their spare time

primarily either completely unpaid or

essentially with a very small stipend

that in no way like matches any sort of

reasonable hourly wage. Most children

delivering newspapers are probably

getting a better hourly wage than a

hover does for their work. Um but like

as a result they need to want to do this

stuff right and if you deal with really

unpleasant people being unpleasant to

you then you don't want to do it

anymore. So in her brew we have a very

very low level of tolerance for people

being unpleasant and we would rather

lose a potential future contributor

maintainer advocate for home brew

whatever than we would lose a maintainer

right because as I mentioned before when

you have millions of users like and 30

maintainers sorry we can afford to lose

some users we can't afford to lose

maintainers who burn out just because

people are being unpleasant to them. So

for me it's, you know, like if you know

me in my open source life or personal

life or whatever, like my take is like

I'm going to try and be nice and

friendly and I try and let people maybe

treat me a little bit worse than they

should. But like if you come after my

peeps, right, like they're my people and

I'm going to be defensive over my people

and I'm going to look after them. And to

me, like that's how you keep people

involved, right, is people knowing that

you have their back uh when other people

might be being unpleasant to them. And I

guess the second piece of that that's a

little bit more recent that I feel like

in

>> you know postcoid remote culture etc

that I think has been super important is

like we try and get together. We

generally have a homebrew like AGM that

we try and coincide with like FOSM every

year just because it's most of our

maintainers are in Europe. It's a free

conference and it's unticted and people

can just turn up and do as much as they

want and yeah that like getting to meet

people and know people face to face is

always helpful. I mean that's a huge

part of open source right is that like

ultimately and you know you could say

wider startup product development etc is

like most of the time you're going to

have more people who want more stuff

than you can do and [snorts] there's two

ways generally of handling that one is

to just tell them upfront no and people

don't tend to like that but it saves

everyone's time and they move on or you

make promises which you just break right

uh and sometimes you break those

promises by essentially having an issue

that sits open for 10 that looks like

and someone's like, "Yeah, we we're

definitely going to do this." And then

no one ever does, right? And is it not

better to be told, "No, actually, turns

out we're not going to do this." Right?

And sometimes that stirs people into

action as well because again, in open

source, like as I'm sure people hate it

when I say this, but I had never written

any meaningful about Ruby before I'd

been involved with homebrew. I'd never

really been a maintainer that reviewed

anyone else contribut.

And like you can just do this stuff and

learn it, right? And if you really

really want it bad enough, like you'll

find a way to like learn it and do it

right. And we'll help you get there.

>> You mentioned Fostm and I absolutely

love stopping by the homebrew booth at

Fostam. Sometimes you can get a shiny

sticker, I think, if you ask the right

person.

>> We have non-shiny stickers and we have

shiny stickers for people who have

either contributed or people who donate

any amount of money. So if you want a

shiny, that's how you get one.

>> Oh, that's the that's the secret. Uh but

you'll also be Homebrew will be at the

open source zone at GitHub Universe this

year. So GitHub Universe is at the end

of October, October 28th and 29th and

Homebrew was in the open source zone

last year and you're making a lovely

return this year. How was it last year?

>> Last year was great. Uh so it was myself

and Patrick who is one of the homebrew

maintainers were there last year. This

year it will be Patrick and Izzy. Uh and

they're going to have a really good time

there, I suspect. I guess one of the

nice things about open source stuff in

person is like rarely on the internet do

people say like, "Oh, hey, I use your

tool every day. I like it." Whereas when

people walk past a booth, they say that

stuff and that makes you feel good

because often you don't get a lot of

that. but also just like talking to uh

users of homebrew and like problems

they've had and things they maybe don't

know about and things that we can kind

of do to improve and like yeah it's it

again it's it's good from my perspective

to get kind of a sense with your project

of maybe higher level things like so

rarely do you get an issue that's just

like homebrew feels slow right whereas

when you talk to lots of people and like

that's their main cause of concern

they're like hey I like it it just feels

slow right

>> so then we went away from universe last

year. We had our HGM at fall them and we

were like, okay, like one of the main

things we want to focus on is Homer

feels slow. Let's make it not feel slow,

right? And we worked on a bunch of stuff

in that direction and some of it is

already landed and some of it's probably

going to land like maybe just before

Universe actually um in ways to make

homebrew both feel and be like much

faster. So like that type of feedback is

really lovely to kind of get and be able

to turn that all the way through to like

actual stuff that people are going to be

able to use. I love that. That's

amazing.

>> I love that. So, see folks, when you go

to these conferences and you talk to the

maintainers, things actually happen like

you actually take it all in and take it

back to the teams and then listen, you

still say no when you need to say no

because you have to. But I'm looking

forward to to meeting EC and Patrick.

>> Yeah. So, the open source zone is a

lovely corner of GitHub universe where

all different open source projects get

featured. Um, every year there's a call

for applications. So there's a chance

for any open source project to to get a

booth at GitHub Universe, which is

amazing. Um, my favorite thing about the

open source zone was just the

conversations that sparked. I remember

just standing in the open source zone.

Mike, you called me over and you

introduced me to this researcher I had

to meet and she's been amazing and she

did a lot of great work with uh

different GitHub people since universe.

So just the connections that happened in

that space were great. I love the

serendipity of this stuff and I mean I

think it's something that's kind of

wonderful about open source and tech in

general right is that often so many

people are willing to help so many

people right and you know I I've had a

couple people reach out to me in the

last few weeks and be like hey can you

like homebrew did this thing we're a

smaller open source project can you give

us some guidance I would encourage again

anyone listening to this um you know if

you have questions like that and you

want to connect with another human and

want them to maybe help you out then

just ask right they're they're going say

yes probably a lot more than you think

and also people like me will reply to

your email a lot more than you think and

yeah we'll do what we can to help you

out

>> okay going into this topic because I

think for folks that are listening to

this and have you in the same pestil I

do Mike as the goat maintainer right uh

and so you've been maintaining this

project for so long of course things

have changed earlier in the call we're

talking about how a lot there's been a

lot of happening obviously in span was

16 years. So I have two questions there.

For one, I think how does your the way

that you maintain this project change um

especially let's say back then to now

since you become a father too like

obviously priorities changed everything

shifts a bit. Um, how has the way that

you approach maintainership evolved and

and then for folks who are coming in the

new maintainers? You mentioned there's

going to be some new ones coming in. Uh,

passing the baton in a way and helping

people become active maintainers,

handing off responsibilities and grow in

this projects without losing that

institutional knowledge is a challenge.

How do you do that? That's definitely

front of mind and that's definitely a

thing that has changed over the years is

how much I'm concerned about like I

guess what they might call the bus

factor. I guess for anyone who hasn't

heard that it's a slightly grizzly

definition which is essentially like how

many people need to get hit by a bus

before the project dies. [laughter] Uh,

and yeah, that there's certain parts of

homebrew where I I wouldn't say the boss

factor is one on anything, but there's

definitely bits where, you know, you

have a maintainer who is on holiday for

a few weeks and you realize like no one

really knows how to fix this without

them. And it's, you know, you're like,

okay, this probably [snorts] means we

need a bit more documentation or

whatever. I don't really like writing

very much, uh, particularly

documentation, but it's often like just

really necessary to do. And often I find

myself in a situation where it's like

actually like okay I could write a bunch

of code or whatever but like probably

the most valuable thing for me to do is

to like write down a dog right like so

for example something that's on my to-do

list right now is like we are a package

manager and we package software right

and on the internet people use software

to do a wide variety of things and we

have been historically like on a case by

casis case by case basis deciding okay

like what might be too much violence or

what might be too much like stuff with

like sex or whatever for us to package

it or not package it, right? And and

again like you get the the fun fact of

being like an international project

where you come in not just like what the

project should be doing but like

individual maintainers views on like wow

my country thinks like sex is no big

deal and violence is a big deal or my

country thinks the other way around or I

work in a big corporation and we're

going to probably block this and we

don't want homes to get blocked or and

then people being like well if they

block for that type of thing then good.

So like all of these type of

negotiations and generally like that is

best suited by like writing down a

document and then we can discuss

something written down and then that can

be almost like it settled and moved on.

I guess related to that uh I have become

particularly since becoming a father and

spouse and stuff like that like I try to

do less arguing with people on the

internet as satisfying as it can

sometimes be uh it rarely achieves very

much right and I try to again like I'm a

pretty liberal use of the kind of lock

thread feature not because I'm like oh

my goodness if anyone else speaks here

the worst thing would happen but just

because it's like okay look sometimes we

get to a point where it's like you're

not going to change my mind. I'm not

going to change your mind. Like let's

not go back and forth on this. Like

that's just move on and you can take

this to another place. For me, homebrew

still is not something which at least

directly has ever kind of driven money

into my pocket. So it's like it has to

be something I actually enjoy doing and

I don't really enjoy dealing with people

who are shouting at me or calling me

names. So as a result, there's times

where I mean literally for me other

maintainers have different views. It's

like if someone files a legitimate bug,

right, and they're just being really

mean about it, I'm just going to be

like, well, I don't have any desire to

fix that, right? If someone else comes

along and says like, "Me too. I'm

affected by this." And they can say it

in a nice way, then cool. I might help

them. People say, "Oh, it's a marathon,

not a sprint." But I I kind of genuinely

think that about like open source,

right? And lots of I maybe have a blog

post brewing at some point about doing

things for a long time. I was at GitHub

for 10 years. I've been with my now wife

for 23 years. My best friend comes

around to my house every week. We've

been friends for like 30 years. Um, and

like I want to be able to still doing

homebrew, still be doing homebrew when

for 20 years, maybe even 30 years. Who

knows? Maybe even more if it still even

exists at that point. And what's going

to keep me doing that is enjoying it and

not burning out and all that good stuff.

And that also I feel like helps me

provide an example to other maintainers

>> inside or outside Homebrew to assimilate

like how to survive long term in what's

not always easiest environment.

>> Absolutely. Let's print all of that out

and put it on a t-shirt. You know, I

haven't stopped and thought about the

fact that yeah, this is obviously a

global project and you're dealing with

not just your own the way that you

approach building software, but how it's

done anywhere else in the world. And you

have to take all of that into account of

how you manage a project, the size.

>> So that necessary community management

key. And listen folks, Mike's been doing

it for 16 years. So if you want to do

something for a long [laughter] time, I

would take some notes. You definitely

know what you're talking about.

>> Um, you mentioned GitHub and Homebrew

sort of growing up together and like you

were one of GitHub's early employees.

I'm really curious to hear your thoughts

on how GitHub's relationship with open

source projects like Homebrew have

changed over the years. Yeah, I feel

like it's sort of goes up and down,

right? Like like anything does. But I

mean, fundamentally for me, I think the

open source community is in some way

forgotten that like it and I guess from

having been on the on call rotations on

GitHub and stuff, right? Lots of people

use GitHub

>> and lots of resources are given away for

free for open source, right? And I feel

like in some ways I can be more

defensive of GitHub in that way than I

was maybe as an employee when people are

like, "Oh, you're just paid to say

that." And now I'm not paid to say that.

But like particularly now with GitHub

actions minutes and stuff like that,

like there's a huge amount of

infrastructure that is available. Like

between I don't know GitHub actions and

copilot and repo hosting or whatever

like in the early days in which I was

doing open source like all of that stuff

had to be built individually for each

project, right? like and it had to be

maintained by people and they were

getting woken up in the middle of the

night if things went down and all this

type of stuff and like now you don't

have to do that for the vast majority of

projects and you have a vast amount of

very high level impressive technology

available mostly for free and that's

great like I I think to me like that's

the the foundation of the relationship

between GitHub and open source is just

like the stuff that is given away for

free and used for free and you know

GitHub benefits from that as well

because that's how GitHub grew like

GitHub grew essentially by convincing a

bunch of open source projects you should

use this and then a bunch of business

followed from that right I also think I

guess the relationship like it's yeah

it's you know depends what GitHub is

particularly passionate about at any

given time and how much that aligns so

if you're a big fan of copilot which I

am personally um then you're probably

quite excited about what GitHub's doing

with copilot right now If you don't care

about that, if all you live in is GitHub

PRs, then I can understand why you might

get frustrated when the PR page is

either slower or not getting faster

quick enough or whatever it may be. Um,

so yeah, I I I don't know. I think like

that's maybe how stuff changes over the

years. And and I guess finally like you

know, Gab's part of Microsoft now and

it's like a big bigger more grown-up

company and you can't just necessarily

message your friend that works there and

get stuff sorted that way. But you know

there's good things about that and bad

things about that. you written about

using AI as you know good autocomplete

and

you know you just mentioned that

actually yeah you are you are a fan of

copilot um you review thousands of

contributions to the project that they

are saying I don't know how many

thousands probably not even accurate but

uh have have you have you seen the

quality of the contributions change like

what can we do how can we help

maintainers when we're wanting to use AI

tools

>> so I think on the maintainer side,

there's some stuff that's there already.

Like I think like the co-pilot code

review, like it's not a replacement for

a human, but it definitely catches

certain cases, right, in a way that's

really helpful and saves time for a

human sometimes. It's funny like pre all

the current AI wave maybe like 2018 or

whatever I wrote a blog post called like

uh robot pedentry human empathy kind of

about this where I was talking about how

like people will accept like a robot or

I guess now an AI like being super

pedantic about like oh you made a typo

here and here and here and here and here

whereas when your human coworker does

that you tend to think that they're just

rather annoying. Um so I think like

leaning into stuff like that is quite

helpful I guess like different people

have had different experiences. I I feel

like I've had probably a pretty good

experience maybe because I know the

Cobra codebase so well with like

assigning issues to co-pilot. The fun

thing is if you want to go see you can

go and look because it's all in the

public record and the PRs. I think I

just two to three months ago assigned

every bug on homebrew uh on the package

manager side at least to co-pilot just

to see what would happen, right? And

what happened was they all got fixed,

right? Um did co-pilot get 100% of the

way there itself? I don't think in any

of the cases it did, but it certainly

saved me a lot of time. Um, and would

get between 50 and 95% the way there

right on the first time and then with a

couple of prompts get probably 60 to 99%

there. And then what I do is I then just

go and take over take the wheel and then

finish off the last bits. And that was

still very helpful. Um, particularly

we're dealing with I guess people talk

about it with writing, but more like the

kind of blank page problem of like,

okay, there's about 10 different ways of

fixing this bug. Like I can't decide

which one to do and then I'm just like,

okay, write code, you pick and then I'll

fix whatever you try and do.

>> Um, I also think with Homebrew, we maybe

benefit a little bit more with that

stuff because like we were early

adopters of like GitHub's like issue

mandatory issue templates. Um, in fact,

I I feel like part of the reason this

got built is I just whine so much about

it internally for such a long period of

time. But one of the nice things about

that is like, you know, we we get people

to provide step-by-step reproduction

instructions in that and then the AI

model can then go and see that and just

essentially do what the person has told

them to do to find the bug and then do

it again to find the repro uh to to

evaluate the fix even. So yeah, stuff

like that is kind of helpful. Um I guess

on the human side like I think I

wouldn't say we've had a market level of

almost like you know contribution either

improvement or decline. uh probably I

think the cases where people are using

AI tooling locally themselves very well

is not visible and I think that's fine

like personally I don't care if you did

100% of the work or copilot did or code

or cursor or whatever right like as long

as you as the human have given it a once

over and been like okay like this looks

good or I'm going to tweak this or

whatever before you want a homebrew

human to review it that's fine with In

my mind, that's the key to successful AI

usage, right? Is we're still

I think we probably will be forever, but

we're still in the the era where a human

needs to be in the loop somewhere,

right? You you need to have a human

review the output before their

co-workers do it, right? And if you get

very good at code review, then you are

more likely to get better at doing that

with an AI as you would with a human.

But in some ways, the the interactions

feel pretty similar, right? like with

even a human who's not using AI, they we

may go through like five or 10 rounds of

back and forth on a PR and then

eventually provide I have the

permissions on their fork to do so. I'm

just like look, I'll do the last bit,

right? Rather than me trying to tell you

what code to write, I'll just go and

write the code and then we can merge the

PR and we can move on. Sometimes that

final little bit is like it just makes

sense to for the maintainers to jump in

and do So, Mike, bummed we won't see you

at Universe this year, but if someone

listening goes to Open Source Zone,

stops by the Homebrew booth, what should

they say to Y and Patrick? Uh, first,

assuming you use Homebrew, say, "Thanks.

[laughter] Good job." Um, but then,

yeah, after that, I just encourage you

to in a nice, polite, respectful way

like say what what things about Homebrew

would you like to see be better, right?

And they will collect that feedback and

we'll do better with that. My my also

tip for that with feedback for homebrew

or any other technology process is to

try and focus when you're saying that on

the problem that you're experiencing and

not the solution that you perceive. One

of the the perils you have of having

technical users um whether you work at

GitHub or you work on whatever is people

who can write code themselves tend to

jump straight from I have the problem to

I can see in my head what the code

should be to solve the problem. I'm

going to tell you that. But like if you

don't know the homebrew codebase like

the back of your hand, which you

probably don't, uh then it's more

helpful for people to know like what are

the pain points and the problems you're

experiencing rather than what you

perceive the solution to be.

>> Well, let's move to the section where we

all share an open source project that

we're excited about. Uh Mike, you're our

guest. Are you ready to go first?

>> Yeah. So, I've got like a bit of a deep

cut actually right now. So, there's a

tool called SOMO. s o uh and it's under

the GitHub user

uh Theopfr who's Theodore Pifer I think

a 24 year old programmer and student

from Munich. So it is a cool little

application written in Rust that shows

what ports on your local Mac are open

and closed. And this is a very niche

thing that you probably only need every

few months. But like if you accidentally

end up like starting your Rails server

or MySQL server or something like that

on a port and then another thing is like

saying, "Hey, I can't open this port

because this other thing's got the

port." Then this is a very nice easy way

to figure that out. It's a cool little

tool that I've liked recently.

>> Thanks for bringing this up. Starting it

right now. Boom.

>> Andrea, do you have yours?

>> Yes. This just so happened to be a

Microsoft uh open-source project that

was just released I guess a couple of

weeks ago. The spec kit that's toolkit

for us to start thinking about spectrum

development and ut utilizing that

methodology

>> uh with the help of AI to basically ship

faster. I I'm excited to use it. I think

it's great that we're investing on

beyond the AI tools themselves on ways

to help the humans work with the tools

better. So now where we're moving into a

world where yeah everybody has the power

of copilot or whatever your preferred

tool is um the people that are going to

be super successful I think are people

that are really thinking about design

systems thinking and this this kind of

fits into that understanding spectrum

and development understanding the who

the what the how beyond the immediate

problem and the code is huge so if

you're an entrepreneur or if you want to

be I think it's a good approach to

building software. What about you, Abby?

What's yours?

>> Yeah, mine's a deep cut. I came across

it recently. It's it's a super old

project, but my friend um my friend

Luke, he made CSS diner. It's

flukeout.github.io.

Flukeout's his um handle. And it's like

just this fun little tool to help you

learn CSS and has this little animation

of like plates dancing and it tells you

select the plates and then you learn how

to use CSS to like select it. It's

really fun. It's a nice way to learn how

to code, like CSS at least. Um, and it's

kind of old, but I wish I want to see

more projects like this. So, this this

is why I bring it up. I want to see

people make fun educational tools.

>> I love this. This is so cute. And then

it even has a help. I'm stuck. So, it

gives you like a little Yeah, this is a

great little tool. I love this. Shout

out to that human.

>> Well, to everyone who's been listening,

this has been the GitHub podcast where

we talk about the topics, trends, and

culture around the open source community

on GitHub. So, my name's Abby. You can

find me at Abbyss most places on the

internet.

>> I'm Mike Mcuade everywhere on the

internet. Um, pretty much. Um, and yeah,

mikemcuade.com is my blog where you can

find links to various posts and talks

and social stuff and all that good

stuff.

>> I am Andrea Griffith, Alakia Deon Places

and it's been fun to be here with you

too. Thank you. This was delightful.