I'd like to start the talk by figuring out who some of you are, because I don't always
know what the makeup of the people in the room are.
So we're just going to go one by one and everyone's going to introduce themselves.
So can you stick your hands in the air?
Do you identify primarily as a dev rel person?
Okay.
An engineer?
And another assorted business person?
Oh wow, lots of business in the house.
That's good.
And anyone else want to just randomly shout out a thing that you consider yourself that
I've not put in one of the buckets already?
Infrastructure.
Great.
Thank you for infrastructuring us all.
Yeah so I'm trying to make this talk like a wee bit of a kind of whistle stop tour of
just some stuff that I feel like I've found useful over the years with my forays into open
source land and I'm going to try and do a little bit of hand raising on occasion to see
what you're thinking and if you ever just want to stick up your hand just for no apparent
reason then do that as well.
I've also got, well done.
Someone's listening.
Great.
One person at least.
So at the bottom of the slides as well I have like a little link shortener situation going
on.
But I try to like link to as much stuff as possible.
If anything I say is interesting and you actually want to read more about that but if you don't
please don't.
Save this bandwidth for everyone.
So, right me.
I'm Mike McQuade.
I still kind of identify as an engineer technically I guess I'm like a co-founder of a business
situation right now.
I'll tell you more about that later.
I'm based in Edinburgh in Scotland.
My open source main kind of thing for the last while has been home group.
I've been maintaining that.
Thank you.
I've been maintaining that since 2009 and I'm now the like project leader which means I
stand for election every year.
No one else has ever run.
Please someone in this room run.
It's certainly free.
So we've worked with maintenance and contributors all over the world over this kind of 15 year
period mostly over text sometimes occasional video calls and occasionally in person.
We've started meeting at Fosdown in the last few years as well as a group which is quite
nice.
I was also principal engineer at GitHub for 10 years.
Well, I wasn't principal engineer for all that time but hey resume padding is okay.
I worked for my home in Edinburgh mostly working for teams on the west coast of the
US which taught me lots about that you don't tend to learn in the UK such as talking about
your feelings and avoiding conflict.
I'm now the CTO of a startup called Workbrew which as you might guess from the slightly
convoluted name is somewhat adjacent to Homebrew.
We're trying to do stuff around like big companies who want things from Homebrew that
Homebrew volunteers don't want to do.
We're going to try and commercialize some stuff around that.
I'll talk more about that a little bit later.
With two ex-git hub people who are on the east coast of the US.
So my talk is going to be based on three B's.
The first B I'm going to talk about is boundaries.
So is anyone able to spot what this lovely bit of text is from?
Anyone want to raise their hand and shout out if you're that much of a licensed geek?
No shame here.
So good.
This is the...
Yes, MIT license.
Congratulations, you win nothing.
I'm not a lawyer but my summary of what this part of the license at least says is and don't
worry about reading all my license summary.
Essentially the software you get is the software you get.
If it's buggy, that's your problem.
Tough luck.
Maintainers, don't promise you that the software has ever, does or will ever work for any user
or use case, even the ones that we say that they do.
Maintainers are never responsible for any problems that anyone experiences even if they
cause them deliberately by themselves because they think it will be funny.
And if you disagree with any of this, you're not allowed to use the software.
So I wrote a little post about this a while ago called Open Source Maintainers or You
Nothing, which a lot of people who are maintainers or Open Source adjacent really like the title
and everyone else hated the title.
And you can see some good discussion of that and I'm not actually even joking here.
If you Google for Mike McQuade asshole, there's a variety of people who think that this is
not the correct way to approach Open Source.
But to me, like this is, I mentioned boundaries before, like there's a lot of talk about kind
of burnout, I'll kind of mention that later.
But like a lot of people ask me like how have you been able to do this for 15 years without
going any more mad than I already am?
And for me, it's boundaries, right?
Like I don't do things I don't want to do.
And I think it's a really important thing for anyone in Open Source to internalize that
unless you're getting paid to do it and then even then that doesn't necessarily always apply.
If someone is rude, if someone is mean, you don't have to do what they say.
I will close issues that are legitimate problems because the person who has opened them is
just being nasty.
And people don't like this, but that's how me and other people in Humberoo have actually
stayed involved for a decent amount of time.
Does anyone know who this lovely lady is?
Brené Brown?
Yes, some enthusiasm in the room.
Good, good.
If anyone who hasn't discovered her, she's social worker, researcher, author, podcaster,
talks a lot about like just generally how to be a better human.
And one of her courses she does, she talks about this kind of braving acronym for like
the seven elements of trust.
So the ones that jumped out to me were when I kind of, we're listening to this and kind
of thinking about how this might apply to my job and Open Source and stuff like that,
or like boundaries, reliability and integrity.
Because if you want to trust people, you cannot be someone who is untrustworthy.
And if you want to be trusted, you need to be trusted by others as well.
So for me, the way I kind of think about this, because I'm primarily an engineer, is by turning
all human problems into computer problems.
So I think about like instead of how I might deal with computers and how I might deal with
humans being separate, like let's try and conflate the two a little bit.
So bad APIs are APIs with inconsistent and unpredictable behavior.
So if you go and repeatedly ask for the same stuff and you get radically different results
back, that generally sucks.
If you are documented that you do one thing and you do something completely different,
that generally sucks.
And an API that every time you call it, it will try and do some overly complex query
and then time out, generally sucks as well.
And a lot of this applies in my experience to human relationships as well.
So humans who are more consistent and predictable in their responses are more pleasant to deal
with.
If you are someone who at work, when your co-workers ask you to do something, if it's your big,
big, big boss, you say it will be done in a day and if it's the person in your team
you don't really like, you say it will take a month, that's not a great API.
If you say to your co-workers or people on your open source project that on holiday I
am not to be disturbed for the next week and then you are on Slack or email every five
minutes answering questions because you feel like you're too important to actually go on
holiday and let other people do their job, that's not a great API.
So to me, your boundaries are what your API are and that helps you figure out how you
should be treating others and how others should be treating you and that consistency makes
it easier for people to understand you and generally probably makes it easier for your
life as well.
A nice experience I had in the past at GitHub is I had a manager who rather worryingly for
me at least start my performance review with, Mike is very strict with his boundaries and
I thought oh no, I'm going to get criticized for the fact that like I insist on having
dinner with my kids like most nights of the week.
But he went on to say that this made it easier to work with me because he knew when he could
ask me to do things and when he couldn't and it modeled that behavior for new parents in
the team that it's okay to do these things.
So I would encourage you as well, those of you who might feel that it's overly indulgent
to exercise your boundaries around these things, that you're not just doing it for yourself
but you're also doing it to help model those around you particularly if you're in a position
of more experience or authority or power or whatever, you can enable it for other people
to do those things.
So I think like I don't want to get too deep on this but I think one of the key things
with setting boundaries is how comfortable you are about saying no to things.
Like I talk about front loading disappointment quite often which is a lot of the times if
you're someone who is very willing and able to say no to things sooner or later, you're
making that person maybe disappointed straight away instead of being disappointed in three
months when you're not able to deliver or do whatever they thought you were going to do.
So if you want to read more about that, there's a little link down there.
And more specifically to open source, there was a big movement a few years ago about trying
to make things really, really easy for first time contributors to projects and I think
that's really valuable from the perspective of like documentation and teaching resources
and smoothing like onboarding floors and stuff like that.
What I don't think scales very well is like hand holding first time contributors through
how they get involved with a project because if someone doesn't know how to use Git for
example and you're having to teach them every command and your project has like tens of
thousands of contributors, you're probably not going to be able to do that for tens of
thousands of people.
But when people kind of express interest and they kind of come back again and again, then
that's often like a nice time to maybe get a little bit more involved and help them out.
So the next B is burnout.
So as I mentioned before, I'm someone who's been lucky enough to not really have ever
felt burnout with open source.
I've definitely had periods of temporary large amounts of irritation.
I'm sure many people who work with me have as well, but I've managed to sort of stay
involved and for me what that's looked like is over the years kind of prioritizing my
own kind of mental and physical health and like as I mentioned before boundaries and stuff
like that.
Something I found very helpful personally is seeing a therapist like I started seeing
one during COVID and it has really helped me to figure out kind of how to manage this
stuff.
We probably have a lot more sessions than my therapist expected talking about like a particular
pull request on Homebrew and someone who is trying really hard to be nice and helpful
but are not doing that and actually being deeply unpleasant to a lot of people and how
I handle this and all these types of things.
So if it's something that you've considered or not tried, I would encourage you to.
I've written a little kind of step-by-step guide if you're like how do I even go about
finding one that might be useful to you.
Another thing I found really helpful with kind of avoiding preventing burnout in myself
and others is kind of having like decent relationships like inside, outside work.
But in work or in open source land, I try and have something that looks a little bit like
this.
I guess I call it like the mentorship diamond.
So it's this idea that I used to be religious, I kind of stole it from religion originally,
like I don't know what it was, something like, I can't remember any of the words anymore,
but anyway, I stole this idea, it's not mine.
But this idea that essentially for anyone, it's a good thing to have people above you,
people beside you and people kind of below you who you can speak to.
So if you're in an employment situation, like your mentor might look like someone who has
the job that you would like to have in five or ten years and your peers would be someone
who has like maybe a similar job or someone in your team or whatever and your mentee could
be anyone.
The nice thing about this is I do say like unless you're literally the most experienced
person at literally everything in our entire industry, then you can always find a mentor
and similarly like unless you were literally, unless you were born during this talk, you
can probably find a mentee who you have more experience than them and you can help them
with some stuff.
And I just, I also think the other thing, those of us who have kind of jobs in more
kind of formal corporate environments, often like an org chart looks quite a lot like
it's structured like this.
So you might think, oh, this comes from me automatically, but I think this is something
that's really worth like putting a little bit of effort into to actually like find these
people yourself and not essentially rely on like, wow, my manager can be my mentor and
my mentees can be the people who report to me or whatever because it just makes it a
little bit more fluid and you can help find things a little bit more easily that way.
Another thing I guess I've thought about with kind of avoiding burnout with open sources,
trying to find people who will replace me.
Who's, I don't know if any people have done any sales stuff.
Have people are familiar with sales funnels?
Yeah, like a few people.
So I guess the idea is basically that you generally get lots of people at the top of
the sales funnel, like potential leads who have no interest in you or what you're doing,
but you haven't figured that out yet.
So you send them all about a million emails and then some tiny proportion of them reply
with something other than go away, leave me alone.
And there was Michael Crossbacks because they've shown like some sort of interest and then
some time proportion of them may actually end up paying you money one day and there's
people who are sales.
So in open source, I think we have somewhat a similar thing that I call like the contributor
funnel, which is like generally most projects will have lots more users than they have
contributors and lots more contributors than they have maintainers.
Last time I count the numbers on this for Humbrew, the numbers are roughly like we have
roughly 30 million Humber users, we reckon from my analytics data, got like 12,000 contributors
total in the last 15 years.
And we've got about 30 current Humber maintainers and about 50 lifetime, which is
apparently 0.0015%.
So when you're being yourself up, your project that kind of is used by a few hundred or a
thousand people doesn't have like most of those people wanting to help you contribute or
maintain or whatever, like cut yourself a little bit more slack.
But at the same time, do bear in mind that like, you know, if you could, the more you
can grow this funnel and the more easy you can make it for a user to contribute or
contribute to kind of come and join you as a maintainer, that may well end up taking
some load off you as well.
Right.
So the last thing I'm going to talk about is business.
And don't worry, as despite the emoji, like I'm not a very suit and tie
businessy, businessy person, but I guess like it was a third B and money in open
source feels like a kind of relevant thing for us to be kind of talking about
nowadays.
So homebrews kind of had an interesting like money journey, basically.
So when I joined, it was very much like Humber didn't have any money.
It didn't need any money.
It was just a random project on GitHub.
People submitted PRs.
This is in the days before you've equal to see I when we start with Humber, it
didn't have any C.I.
at all.
It was all just verified on someone's machine.
And the first thing we kind of did when we sort of realized like, Hey, we maybe
need some money here.
We figured we kind of could benefit from having some max, which would like
automatically kind of run some C.I.
I'm poor request from GitHub.
So because it was 2013, the way you went and asked for money on the internet
was a Kickstarter raised the 14,859 pounds.
And that was then used to kind of buy some hardware, which was like physically
taken on a train by me and installed in a data center on by good stuff.
2016, we joined the software free return C, which provides like fiscal
hosting for us.
Does anyone anyone familiar with what fiscal hosting means?
Yeah.
So essentially it's like providing a bank account and like legal services
and someone who can let whole trademarks or anything like that for
European source projects.
So that made us, well, it made us a part of a 501 C three, like a US
nonprofit essentially.
So we could go and like receive tax deductible donations in the US and all
that stuff and give us a bank account.
So then after that, we kind of had somewhere to put our money.
We had somewhere to receive new donations and somewhere like a process
for like paying out stuff like that.
2017, we start using a Patreon to kind of try and get some monthly
donations and stuck that in our read me.
2018, we started asking for donations on Twitter.
But 2019 was the big kind of exciting time when we made humbrew itself.
Like when you first installed it, or if you had had it already installed,
you would see a one time nag message that says essentially homebrew is
run entirely by volunteers, mostly in the spare time.
Please consider donating and then 20,000, one meter collective.
See if you can spot when we added the message to our.
Yeah.
So almost immediately, our kind of incoming money went up by a lot.
So no one has really complained about the message.
You get some people get kind of a little suspicious or paranoid about
asking for money as an open source project.
But I would strongly encourage you if you're an open source project and
you need the money, then do consider like having a one time nag or whatever.
And I also think I've found that people are a lot more responsive to that
often than kind of like advertising and things like that.
Another thing to think about with open source is like, again, I've heard a
lot of people talking about open source economics in the last few years.
So I kind of wrote a blog post about this and sort of spoke to my father in
law, who's a professor of economics, who just because he's a very clever
manager says it depends a lot about like, okay, help me understand like,
what is economics?
How does it define it?
Blah, blah, blah.
So like he sort of said, well, you know, we're mainly capitalist economies here.
So it's the allocation of capital and how that throws through businesses and stuff
like that.
And then I kind of thought, well, whenever I see people talking about open
source economics, they're all talking about money and like how
open source projects get money and spend money and stuff like that.
So is that what it's about?
Well, like if you make everything about money and I guess, you know, no shade
on our lovely American friends in the room, but I often find when I talk to
kind of American folks about open source and European folks about open
source, often I find like, sometimes on the American side, there can be more
of a focus on like, we need to get money, money will solve all the problems.
The lack of money is all the problems more than I do over here.
But like the idea that kind of money fix all the problems, it's like,
Humbrew is kind of an interesting phase right now because we have quite a lot
of money in the bank.
You can go in our open collective and see that we have, you know, six figures
of funding, which is like both far too much money to spend on stickers and also
unless you get really good stickers, like if anyone knows the best stickers,
then let me know.
But also like not enough to like sustainably actually pay like people
to work full time on Humbrew.
So in our case, we have quite a lot of money and that doesn't fix all our
problems.
And that's when I guess like told to my father-in-law kind of helped where it's
like, well, actually economic problems are generally like, we generally consider
them to be like allocation of limited resources, which is normally money,
particularly in like capitalist economies, et cetera.
But arguably the open source economic problem is allocation of like limited
maintainers or like people, right?
If you want to have stuff done, there are relatively small number of people who
can do those things and you don't necessarily have enough resources to get
those people to do those things.
And if you have more money, does that somehow automatically add more of that?
Well, I guess not really because for some people they have a full time job and
the amount of money they would need to have to quit their full time job and then
do the open source thing full time is a lot more than your project can have or
guarantee or whatever.
So it's tricky.
But then for me, I think like, again, it feels like a weird thing to kind of
frame in terms of economics, but I think the best economic thing you can do for
your project to kind of maintain the amount of maintainer time you have and
increase it is to make it actually an enjoyable place.
If open source is a place where people want to go, if we come to events like
this, we see each other, we make friends, we make friends on our project, then we
want to work more with those people, we want to help those people out and we're
having a good time.
If open source is like a horrible drudgery place where people on the
internet just shout at you all day, which it also could be, then you're
probably going to want to spend less of your time doing that.
And if you're like me, then you will probably be shocked when on a Saturday
night, you're spending like your time smashing out some code from the
European source project, look completely miserable and your wife's like,
why do you do this again?
Like, are you sure you want to do this?
So yeah, so try and make it an enjoyable space for other people.
Again, final note, like I've seen kind of concerning stuff around AI where, I
guess, including some of the existing talk where there's a worry right now that
we're moving to a world where everything is kind of open source underneath the
hood, but then everything is very proprietary in the front and we maybe
have open source data models or whatever, but you don't have any of the
training data and is this going to mean sort of the death of open source?
But to me, the only thing I've seen that looks close to failing in the last few
years is open source is like a business model where there's a bunch of projects
who have, I'm not going to name any names, but you know who they are, who had
this sort of approach, either they fell into this trap or this was forced upon
them by their maintainers or investors or whatever.
But I would argue, and this is the model I'm trying to take and we'll see
whether it works or not, is that like this is a better model for open source
business, which is instead of trying to have like the open source side and the
financial side in direct competition with each other, you have something where
the business side and the open source side kind of contribute nicely to the
same kind of ecosystem. I remember I had a job and I will name them because they
were a lovely bunch of people, a company called K-Dub a few years ago.
It's my first job kind of working primarily on open source stuff.
I was very excited that I was like, great, I work on K-D, now I work at this
company who has lots of K-D maintainers and I can get paid to work on K-D stuff.
But I found quite quickly that the problems that often open source
consultancy companies are paid to work on are actually in fact not the most
interesting problems, but the most boring problems because people who will do
them for fun don't want to solve those problems, so you have to pay people to
do them. And to me, like this is the, I mean, it's not a very inspiring pitch to
kind of come and work with me, I guess, at the company. But I do think there's a
class of problems where you can't expect volunteers to solve them and you do
want big companies to be involved with them. The big companies, sorry, expect
this stuff to be solved, but the volunteers don't want to do it and
they're, that's where, to me, it feels like a good fit. And very interesting,
what I'm doing with this stuff, then we've got a little website at
workgroup.com and a demo and all this type of stuff. So, in short, quick summary,
boundaries, remember open source maintainers and volunteers or you're
nothing. Remember, you can say no to things and you don't need to mentor
first-time contributors for burnout, considering a therapist if you don't
have one already, or change you one if you hate your current one, which is
also a thing, it seems, consider the kind of mentorship diamond of mentoring
above, below, side by side and that if you can get more users and make
it easier to become contributors, make it easier to become maintainers, then
that might make your life easier. And I talked a bit about making
hungry financial sustainable and how that's about often making maintainers
happy and avoiding them burning out as much as it is about money and what I
thought about open source business. So, feel free to answer any questions
now, but if you don't want to ask in front of the room, then here are my
contact eats and stuff like that. And thank you very much for having me.
Thank you for the talk. Over here. I really like your analogy with the API
in terms of humans and machines and I'm curious if you, like good APIs are
well publicly documented, I guess, and so I wonder if you have taken that
analogy to that point of like having sort of a document, I used to have a
colleague who would have like a Google doc that would be like how to work
with me. Yeah, I actually do. I was polishing it like hopefully my company
have our first employee in the kind of coming month. So I've been taking my
old one from GitHub and I'm repolishing it for the current day. Yeah, for
anyone who hasn't done this before, it's a really nice resource in companies
and I guess it could work in open source as well. It's the way I saw it
framed as like a human user guide where it's like things you might not know
about me, things that I really like, things that when my co-workers do this,
it makes me happy, things when my co-workers do this, it makes me sad.
Like those types of things. Yeah, so I agree with you. Like I think, yeah,
trying to publicly document that or at least internally document that, but
there's nothing mind one that I wouldn't probably want to put on the public
internet just yet. But yeah, I mean, you've inspired me. I might even make
a public version of this. So we can. A follow up question to that. So if you
write such a document, how do you find the boundary between like kind of
being honest and setting, actually setting the boundaries and not coming
across as rude as in setting those boundaries?
Well, so the best way I found to avoid coming across as rude when I worked
with Californians is who had not worked with Scottish people before. It's just
to say, oh, oh, Scottish people are like this.
But yeah, I mean, as pretty much all of my friends and family and co-workers of
all time would tell you, I am not the person to ask on how to avoid coming
across as rude. But I guess I would say like, as a middle ground, I guess,
maybe not quite rudeness, but something I've been dealing with like at work
with like a small start up with kind of, you know, impassioned people is you
quite often end up in situations where someone maybe needs to hear something
and you know it's going to hurt their feelings. And to me, like the two
failure states for that are either you don't tell them what they need to
hear because you're worried it's going to hurt their feelings or you say, well,
it's going to hurt their feelings anyway. So yellow like, and yeah, I guess my
thing is, as long as you're willing to kind of try your hardest to be as nice
as you can and hurt their feelings as little as you can and be willing to
admit you're wrong and apologize and these types of things, then you can get
away with being rude, I guess. Yeah, don't have the us that one.
Thank you. Thank you. Over here. Thank you so much for your talk. I'm Canadian,
so I fall somewhere between American and European philosophies. I think you
alluded to this, but the biggest economic problem for open source projects is
actually the free rider problem where so many people can use software that they
don't end up contributing to or paying for. And I'm wondering if you have any
examples of open source projects that have achieved kind of a hybrid model of
being able to keep things open source and free for people who can't pay, but
for those who can. And we know there are so many large companies that do have
incredible ability to pay for stuff that don't. How do we incentivize them? Yeah,
that's a great question. Thank you. So on the free rider problem, I have maybe a
slightly contentious take, which is that I think if you completely eliminated the
free rider problem, you kill open source because open sources, I mean, I guess
we've seen this in the last few years with the kind of the varying licenses and
I'm maybe a bit more of a purist in terms of, I think, if you say, well, Mike can
use this because he doesn't have lots of money, but Amazon can't because they've
got lots of money. You kind of kill what makes open source what it is. So for me,
it's about kind of thinking about creative ways of solving that. So some of
it, I think it's like you're going to have a certain amount of free riders and
you're going to have. And also, I think what makes open source interesting is,
you know, I include my own projects and work in this as well is that I think if
we end up with a culture where everyone is expected to pay their way to kind of
be involved with open source, I'm not saying that you're saying this, but I
have seen some people who have, then we, why would a company almost like want to
use open source so they can just build everything internally as they were doing
20, 25 years ago? So I don't see like an easy solution to that. I wish I did. But
I guess the solution, as I said, I'm trying to do right now is the idea of
you maybe just don't provide support for free for the things that are massively
six important to big companies. Like, I don't know how many of you have the
misfortune of reading hacker news comments on occasion, but every so often
there's like a manifesto there of like, it's very important that we as an
industry start doing this thing. And I really like those because 50% of them
convinced me to do the exact opposite of what the person is trying to convince
me to do. And there was this website called SSO.tax that essentially talked
about how look at all these companies who are outrageously gouging people who
want to use like single sign on and stuff like that. And I saw that and I
thought that's a really good idea because that's a way to essentially be like,
well, if you're a big organization who has the requirement for this for some
ISO certification or like whatever it may be, then you say, well, we're going to
charge you a lot more. And if you're like an individual user, we're going to
charge you a lot less or nothing. And I wonder if that could work with some
open source models as well that if you have features in your project that you
know are only going to be used by the biggest of the biggest corporations,
then you say, well, that stuff you have to pay us for or it's under a license we
know you don't want to use, but you can pay us to have it under a more liberal
license or I don't know. Lots of ideas, no solutions. Thank you.
We're at time. Thanks folks. Thanks Mike.