Yeah, no, it's fair, I guess.
Well, when you provide your speaker biosphere, then that is the speaker biosphere.
All right, yeah.
Yeah, yeah, yeah.
I fucked up.
I threw up.
And with that, can we give our formal welcome to Tony?
All right.
Well, first of all, thank you very much for having me.
So today, what I want to talk about is not this year, eh, let's put tomorrow.
Today, what I want to talk about is governance for software engineers.
What I mean by this is a lot of us at some point a project grows to a certain size.
And then we have to stop thinking about governance.
How to organize the work of that project?
And I have ended up doing a lot of this.
And it's sometimes quite a stretch for folks who are developers and engineers at first
to get into that world of governance and figure out how to do it.
And the way that's intuitive and like close to the practices that we already have.
And so the idea of this talk is to show that like it's not a different world where you just
have to blindly sort of like copy paste what others are doing.
But it's actually quite close to coding.
And there's lots of like good practices that are really, really normal for us to
do when we code that really apply to governance too.
And essentially what I'm trying to do here is to get people to write better and more
maintainable governance just like we try to write better and more maintainable code.
So that's kind of the background.
And so we're going to do two things, split up in two parts.
First part is we're really going to talk about what is governance because like so many people
when they talk about governance mean completely different things.
And don't realize that they're talking about completely different things until like halfway through
like the conversation is finished.
And so we're going to talk about what it means for open source projects.
And so what it really means is governance for open source projects.
And then in the second point when actually like give you some really basic,
a basic framework that I think works really well.
And that encourage projects to use rather than a whole bunch of like much larger things.
So yeah, you've heard about who I'm already.
So I ended up as I was saying doing a lot of like governance see things in around open source.
But yeah, anyway.
So what is governance?
So here are three things.
First we're going to look, we're going to build a working definition of open source governance.
And then we want to talk about delegation of authority as a concept.
I think it's something that we don't talk about enough.
And it's like if you actually understand this,
it's a super great tool to understand not only how open source works in software works,
but like more broadly than I think the world.
And then when I want to talk about third point as governance is bounded,
then we'll get into what I mean by this.
So here's a working definition of what governance is.
Again, for open source projects.
And then we want to talk about what governance is,
the formalization of implicit norms and culture in order to scale and collaboration.
And there's a lot in this and so we're going to unpack it.
You know, the first point is about scaling collaboration.
It's the first thing that I find really important about governance.
And at some point because you only start to need governance after a certain sites.
The mistake a lot of projects do is to, you know,
want to formalize a bunch of things way too early.
And that's usually not a good idea at all.
You want to wait until you actually feel the pain of not enough governance
to start adding governance.
And really the purpose of governance is to,
yeah, say this in a second was the right slide.
That's the purpose of governance.
The purpose of governance is to scale collaboration by really
formalizing the implicit norms and cultures.
And what I mean by implicit norms and cultures is,
every project, whether it has written down governance or not,
has governance, right?
But it's implicit.
It's in the culture.
It's how you do things, right?
Maybe it's like, you know, this person who, like,
reviews poor cost, right?
That's governance.
It's not written down, right?
But if it's, you know, there's an unwritten way of doing something
that is governance, right?
And as you scale, as a project becomes bigger,
what you want is to encode those, so that you can,
so that they no longer are just implicit,
but that they are explicit.
That's also important because when you have explicit norms,
they're the same for everyone, right?
Whereas if they're implicit, like they're only those that know,
and then the other ones are kind of lost, right?
And it creates like some really unbalanced structure.
Yeah, and then, you know, that's the last bit, right?
Is that you want to formalize it, right?
You want to write it down in a way that is easy for everyone
to understand and agree about what it means, right?
And so, you know, those really are the, for me,
the key things about governance, which is, again,
happens when you do need a scale.
It is essentially encoding the existing practices,
so that they're the same for everyone,
and everyone agrees about them.
But, on, I think, that's super important.
All of this, like, happens in a system of authority
delegation, and I'm going to explain what I mean by this.
Now, so, when we write software,
we tend not to think about all these things,
but there is a concept of delegation of authority that happens,
kind of a regardless, and of what, you know,
as a fact that we don't like to think about it,
and usually there is someone thinking about it, right?
And I'm of the opinion that it is better when everyone actually thinks about these things,
because then you don't have bad surprises down the road,
where someone was, you know,
cunningly thinking about this while the rest of the community wasn't, right?
So, thinking about, like, who owns what,
and what authority gives them,
and how they're delegating that authority to the community,
is really important.
And, you have, you know,
so, the thing is that we all live in countries that have legal frameworks,
and an open source,
this really materializes itself around copyright and licenses,
trademarks, right, and to some degree, hopefully,
very little degree pathets, right?
But those are important, and actually who owns those,
and, like, how, you know, that group of personal company or nonprofit
is allowing others to use or reuse these things,
matter quite a bit,
and there's implicit delegation of authority that happens through this,
right, consider a project,
you know, let's say the FUBAR project, right,
that I create, right,
and you'll contribute to it.
Well, I own the FUBAR trademark, right,
so you can't just go run around and say,
and I own it by virtue of it.
I don't have to do anything specific, really, right?
I own it by virtue of, like, having started the project,
and the project name is kind of, like, I made it, right?
So these things have an impact then down the road,
if I decide that, well, you know,
I don't want your contributions anymore.
You can work the code through the lessons, right?
But you can't use the name, that's an example, right?
So these frameworks exist,
whether they're, you know, explicit or implicit.
And, yeah, you know, sometimes they're quite explicit,
like you have a foundation that owns a bunch of things,
and it has a, you know, a structure,
and you see, oh, you know, there's a board,
and all of these things, that's quite clear.
But even, you know, in the case where it's implicit,
this still matters, right?
And sometimes those, you know,
the legal framework around it can be very, very simple,
and sometimes it can be very, very complex.
The example I was using when I made the top of the first time
was opening an icus, that was, like, fresh at the moment.
And they had, like, this whole, really, like,
wild structure of, like, a for-profit, a foundation,
and a whole bunch of things.
And, you know, at the end of the day, what really mattered
was, like, who actually, and I'll get to this in a second,
but who actually, the power was not the same
on paper as it was in reality, right?
So a few examples, right?
You know, sort of, like, a very basic structure.
You have the legal system, trademark law.
You know, your BDFL, who owns the trademark,
whether, you know, they know it or not, right?
That's how it works.
And then, you know, delegates authority through, like, a governance
that MDF all and whatever it is, to a core team,
that then, like, you know, continues to delegate
that authority to the broader community through a country
contributing that MD and a code of conduct, right?
I mean, this is literally what's happening.
We don't think of it that way, right?
But this is really how the world actually organizes
the way we build software.
So, funny story, as I'm like, I'm going to have to say this out.
And then, I was just like, wait, what does this stand for already?
And so, I'm going to, oh, maybe this is going to work out
and then what's going to ask?
And so, I don't remember, I know what it means,
but if someone can spell it out for me, that would be great.
Thank you.
Benevolent dictator for life.
Thank you for asking the question.
And yes.
I saw it, that was just like, a mile panic.
Maybe it's going to go ahead, it's going to work.
Thank you.
So, yes, if there's other acronyms, I'm sorry.
Please do ask.
And for those who know, please help me out.
All right.
So, this is a much bigger sort of structure, like a legal system legislation
that creates a family that allows you to have a foundation structure.
That foundation has bylaws and executive director board.
Through a charter, it has like project leadership.
And then, like, through those, you know, all of these different files,
you sort of like delegating this authority footer.
And this is like an even, this is a foundation of foundation structure.
Like CNCF, for example, right.
It's like, you have like a foundation and it has like a foundation project.
Oh, yeah.
CNCF.
Oh.
Cloud native.
Computing foundation.
Yeah.
Uh.
See, I spotted out right below God.
This is bad.
So, anyway, you see how do you have these complex structures.
I mean, I'm trying to, like, to take away of these things, right?
It's like, um, all of these different pieces that look like completely
disjoint, right?
Like a code of conduct till like a governance.md or something like this.
They're all part of the system that actually starts in like legislation
at, you know, national and international level.
And it all goes now.
This is how it works.
Right.
So, I think it's super important to be aware of this because, uh,
whenever things go really badly and sometimes like they do, right?
Like understanding like where you set makes, helps you make right decisions
for you and your company and like the community and the project.
All right.
And so, the last thing I want to say is governance is bounded.
Right?
People will talk about governance.
And I'm here to tell you, like governance happens in this place in the middle
where people are willing to work together, right?
Um, and, you know, there's places where people are telling you what to do, right?
And, you know, and that can be through legislation.
You might have a board.
You might have like, you know, there are social norms, right?
For example.
Um, and then on the other side, it's like, well, you know,
uh, you can also just like not be interested in leave, right?
Like there's, you know, if everyone leaves your project,
oh, you know, this was the open AI situation, right?
It's like if everyone leaves, you can like yell,
governance governance, like there's no one that's listening to you.
Right?
Um, so essentially, like, there was this small, uh, middle place
between what people tell you to do and like, you know,
what, um, you know, people being willing to work with you, right?
That's like, where we can work together,
and this is where governance of open source projects happen.
Right?
So it's really important to understand that.
If someone doesn't like it, and, you know, they won't,
they can leave and like fork, right?
And if everyone leaves, well, then whatever governance
you've set up no longer matters.
And then a bunch of examples in, you know,
in our communities, uh, in the past of things like this happening.
Right?
Um, so I think it's really important to remember,
um, it's governance happens in this bound, right?
Um, and so, yeah, you know,
as long as there's, and the slides are available, by the way,
um, if you want to dig a bit more into it.
Um, so essentially, like governance exists as long as
this is willing as to collaborate, right?
Um, and I like to think of governance as the organization
of willing collaboration, right?
Um, and if you're being unreasonable, people will leave.
Uh, I think it's super important to remember.
Um, but that said, like you still, you know,
you can write all of the governance that you want.
You still remain subject to, on the authority of entities
that are above you, right?
The law, um, etc.
Um, and yes, again, you know,
those authorities, they might be like very explicit.
It might be like a legal framework,
but it also might just be like if you're being really annoying
to like the, your core contributors, like they have authority over you, right?
Um, if you're being really annoying was a very large corporate
member that actually is like funding a whole bunch of things,
they can decide to just leave, right?
So governance happened in that space.
All right.
So, key takeaway is from point one, then I'm going to have to start
hurrying up a little bit.
Um, so governance is the organization of willing
collaboration, right?
It's bounded by delegated authority and others
willingness to collaborate with you.
Um, it fits within an existing system.
Um, and, um, yeah, at the point about it,
fitting an existing system is just right the part of that,
no, that part, right?
You don't need to rewrite the whole of like a European legislation
to explain why trademarks, blah, blah, blah,
give you all of this stuff.
You need to know what's there,
and just like write the governance that actually is where,
where you actually have authority over something, right?
Um, yeah, governance should be proportional to projects
reaching complexity.
Like, uh, you know, make it as simple as you can.
Um, like, I've never seen a project.
I've never seen, um, two little governance.
I've seen like too much like so many times.
And as soon as there was too much governance,
people are just stopping attention to it and make their own rules.
And then you have like this complete,
this joint, it's completely disjointed between like what is written
and what people do and that's really bad.
It yields to, you know, creates really bad outcome.
Um, aspirational governance.
Like people are just like, you know, kind of disorganized
and they're kind of like, and they're like,
oh, we got to write this stuff of how it would be
if we did it well, right?
And that never works.
Like, write what it is and then bit by bit
move through something better from there.
But start by actually just saying what it is that you do.
Um, and oh, last thing, I think that's super important.
You want to convey intent, right?
Don't just write rules, right?
Explain what you're trying to do with those rules.
So important, right?
Because down the road, even yourself, you're behind.
Why does it, you know, why did I make this rule of like not do,
you know, XYZ, right?
Think of it as like comments in code.
All right.
Um,
you know, an updated working definition for me is governance
as the formalization of implicit norms and culture in order
to scale willing collaboration.
Right?
So I think this captures quite a lot of the things that we've talked about.
Um, and, you know, that's for me like open source project governance.
Um, and then just like shorter and less formal.
It's just governance as the organization of willing collaboration.
Right?
This is what you essentially do to get people that want to contribute
to something to work together well.
All right.
So now, how you actually do this concretely in a way that is,
you know, is less, it's a little painful as possible.
Um, so, um, think about this for a second.
Right?
Um, you know?
Right?
Um, and so, but the good part of like this, right?
The good point of, sorry, I'm going to read it out.
The good point of governance is code that has to be interpreted by humans.
Is that everything you know about writing good quality code,
like is even more relevant, right?
You have like a squishy interpreter, right?
Um, and you have to be like super explicit about what you do, right?
And I mean, code is essentially writing things for human beings, right?
So, it should be fine.
Um, so, you know, I'm going to talk about, um,
how do you write and maintain governance?
I'm going to look at common issues,
best coding practices as a solution to this.
I've hinted at that already.
A simple framework to get you started and then some additional tips.
And I think there's a bunch of examples in there too.
Um, so common issues, uh, you see in governance,
and then the same as you see in code, right?
We've got a code copy, paste governance.
Like the number of times I see governance for a project,
that's copied from a project that is structured completely differently,
and doesn't work at all, like it's like so common, right?
Um, hike up, coupling and location, uh,
same thing, like everything is like kind of like stuck together
in really weird ways.
And if you want to change anything,
it's really, really hard because you have all of these like weird
connections between things that are not explicit.
Um, and it's generally ends up to be poorly structured
because everyone kind of writes a bit here and there.
And we don't have frameworks, right?
Like in, you know, we're right software where we usually tend to have
like some form of framework and structure that we rely on
and governance we don't.
And so, you know, this is kind of the goal of this as to give you
like a basic framework.
So of course, this leads in governance as it doesn't code
to those, you know, those horrible things.
Uh, maintain this nightmare, governance that's hard to modify
and update, uh, governance that's difficult to understand and follow.
All right.
Um, and then you also, as I was handing out before you started having
two realities, right, what's on paper and what actually happens?
Um, none of those, uh, desirable outcomes.
Um, and so, you know, best coding practices as a solution, right?
So every time you bump into something like this,
just think about how you would do it in code, right?
And you probably have a really good answer to this, right?
Um, so simple framework to get you started, right?
Like, limit yourself to these five kinds of documents.
You handle the leg delegation of authority through charters, right?
A charter is, you know, the board charters like the TSC to do these things, right?
And it gives like scope of what the TSC can do.
Um, and, um, it, um, you know, creates accountability in return, right?
Um, and then I think something that's really important is you want to split policy
and process and you can call these different ways, if you want, right?
But essentially, um, policy is kind of like the what, right?
What is it that you want to make sure it happens a certain way or doesn't happen?
Um, and that can be kept like super high level, right?
Um, and then process and I know these like names and terms sound like really, uh, uh,
might rub people in a wrong way, right?
Process policy etc.
That's what governance is about.
Um, I have to learn to deal with it and I'm sure you can too, right?
Like it's a little unpleasant at first and then if you embrace it, it's fine.
Um, and so yeah, if you separate the what from their how, right?
So if you separate the, um, what is it that you're trying to, to organize from like,
how you do that?
Um, that's really good.
Um, and I give a quick examples of that.
And then like the two extra things are guidelines, right?
The idea of guidelines is sometimes there's a bunch of things that are very complicated
and a guideline helps address like a common use case, right?
And then, you know, documentation for everything else, right?
Um, and so the way I think about these things, right, is a charter is kind of like your framework
or your config file or like your main, right?
So this is like way you run the whole thing, right?
Um, and then policy think of it as like, uh, API ahead of files,
type deaths, interfaces, depending on what language you come from, right?
This is like, this is like, you know, the functions are going to do this, right?
And then process is like that's where you write the actual implementation code.
For me, like, that like entirely, once I found this is like everything started being so much easier.
Right?
Um, and then, you know, think of guidelines as like, um, you know, the facade, uh, a seat, I'm French.
Like a nice, uh, city here.
Um, I don't know how that happened.
Uh, you know, the facade, the facade pattern.
Um, like, essentially, like, you have like a complex, the main model that's, um,
design, like, you know, very low level.
And then, like, there's a common use case that you do all the time, right?
And you just write an API for that.
That's the facade pattern.
Um, high level API, right, on the web, like, uh, something that you can do just in
HTML versus it's like writing like 29s of JavaScript, something like that, right?
Uh, so think of guidelines as that.
Super useful tool.
Um,
Yeah.
The last thing that's important, right, is like, who owns what?
Right.
And so essentially, um,
think of it, like, there's a authority that delegates power to you.
And you can delegate some of that power, uh, to, like, say, like, a dedicated working
group with something, right?
Um, and so shorter, um, and policy, the delegating authority wants to, to, um, right?
And then the process, uh, you want to keep it really close to the people who are actually
doing the work.
So they own it.
Right.
So that separation is also super useful to actually make things effective.
Oh, boy, I have to hurry up.
All right.
Um, so how this works in practice, I'm going to do that real quick.
So, you know, you can have, um, uh, let me, yeah, examples, right?
Uh, moderation policy forget how, right?
You write the policy about your goals for community,
monitor, and general, right?
Um, where you explain where this is important, et cetera.
You charter a GitHub moderation group to handle it, right?
And then that GitHub moderation group, like, figures out how to implement this in the way
that makes sense for GitHub, right?
And what's really nice, right?
Um, is that if you want to do the same thing for discord, you don't have to rewrite a
charter.
You don't have to rewrite, like, um, uh, policy, right?
It's just like now implementation for discord, right?
So that's super effective.
All right.
I'm going to rush for the last, uh, I'm going to jump the examples,
bug charging, same thing.
You have the slides.
You can look at it and you can come ask questions.
Um, and so why is it good?
High level goals was the leadership, right?
Um, and you, um, you essentially empower the people who are doing the work to do it in
the way that they want, right?
The separation is really clearly articulated between both.
And, um, like this, um, you also have, you can have, like, really great conversations between folks
because they know what they need to talk about.
And in 26 seconds, um, I'm going to jump this.
Yeah.
So why is it good?
Flexible, maintainable and simple as a system, right?
Um, and I'm going to let leave you with two additional tips about governance in general, right?
It's like, don't think that engineering anything is going to save you from having
hard conversations with human beings, right?
You have to have those.
Um, and when you have to have those, call people up, right?
And do it one on one.
Don't, like, fix things in public or, like, enlarge your circles, right?
And yeah, sorry, rushed a little bit at the end.
Hope that was useful.
Slides will be online.
Um, and if you have any questions, come and talk to me.
Thank you very much.
Thank you.