On today's episode, we're diving
into open source sustainability,

which apparently means way more
than just, please donate to my Kofi.

We got to chat with Hazel, who somehow
managed to explain the entire economy

of open source in about 20 minutes.

Well, making us question everything.

Everything we thought we
knew about sustainability.

I mean, David asked just one rage bait
question about whether open source

can be sustainable and Hazel just.

Answered like comprehensively
with citations to Eleanor

Ostrom and everything.

Yeah, I may have taken some notes.

There were at least eight principles of
sustainability communities mentioned, and

I'm sure that Hazel had them memorized.

We covered trust.

Reciprocity VC funding models,
ego, death of authors, and why

browsers should basically be
treated like public utilities.

You know, like light topics.

And I'm glad you said
'cause I can't see it.

I also learned that if you don't want
to be woken up at 3:00 AM by nation

state, actors maybe don't maintain
critical infrastructure packages.

And yeah, David actually managed
to avoid asking about rust for

once, but did squeeze in a question
about the Chrome DOJ case because

apparently we're doing hard mode today.

And Hazel's answer, we need to scale
collective ownership up to humanity.

No big deal.

Just your average Tuesday conversation
about the future of human civilization

through the lens of package managers.

And join us episode.

Thank you for joining us.

Hazel, could you please take
a moment to introduce yourself

to the cloud of Compass?

Do.

My name is Hazel Weakly.

I have thoughts, lots of thoughts.

They never stop thinking that.

They never stop thinking, and I am
very much looking forward to being

here and I'm on the deaf and out of
hearing group at the CNCF, and I'm

a fellow of the Nivenly Foundation.

And one of the things that I've
done a lot of my time is trying to

figure out how to help open source
communities and ecosystems and people

figure out how to do what they enjoy
in a way that's sustainable and grow

and build something beautiful that
the entire world can benefit from.

How do we teach the world to be better
at taking care of our communities and

help our communities grow to become more
collective and more beneficial, more

wholesome and inspiring for everyone?

I don't know that we
can follow up with that.

Just like perfectly
encapsulated right there.

Should we just show the
podcast right there?

Yeah.

Thank you all for listening folks.

We'll see you Allall later.

That was single.

No, we're really excited to have you on.

So I'm looking forward
to this conversation.

Um, but of course David and I, we
never actually prepare questions

'cause we're great like that.

Um.

Do you wanna start there?

It's a conversation.

It's not an interview.

Right?

I know.

We're here to talk with people we
like, people we aspire to be and

people that are, are kicking us.

That's true.

He's just a little bit of all of that.

Um, but I do love that you started with
saying open source and sustainability

and the same sentence and you meant it.

I mean, can open source be sustainable?

I mean, we can talk
about numerous, oh geez.

Open source issues.

That's the starter that have
happened in the last 12 months.

But let's just go straight
into the hard question.

Like what?

How does this work?

Yeah.

How do you make open source sustainable?

Let's talk, should we start there?

So, when people talk about sustainability
of open source, I think it's important

to understand where they're coming from
when they talk about sustainability and

what they're wanting to get out of it.

So if you think of open source
from the sort of semi empire global

perspective of a common shared resource.

Then you can think of how do common shared
resources become self-sustaining, become

self organizing, and become, you know, not
exploited, and not, you know, trained out.

And how do you make them work long term?

And you can look at that.

And there's some really great research
by Eleanor Ostrom who talks about that

and who has about eight to 10 sort of
properties and principles of sustainable

self-governing, self-organizing.

Shared common resource groups
and how to see build governance

structures that do that.

Um, but a lot of people it
turns out go, oh, that's neat.

Um, but how do I do that?

Or, what does that mean for me?

Or what does that mean for my project?

And so for them, open source
sustainability often become sort of

a very personal question of if you
have an ever-growing pile of work,

if you have an ever-growing pile of
obligations and request from people.

How do you as a maintainer
not feel burned out?

Or how do you as a maintainer
give more maintainers?

Or how do you grow your product to
have enough energy in it to continue?

Or maybe people go, well, I have the
energy and I have the motivation.

I just can't afford to.

So, but then the question is, how
do you translate this enormous

amount of energy and interest
in the project that art exists?

Turn that into something that
people are willing to pay for,

that people are willing to fund and
sustain beyond just, that's great.

Here's a PR or, that's great.

Um, thumbs up emoji.

Um, you, you're doing good.

You're doing good work there.

And so for other people, open
source sustainability is actually

more on the company side of things.

Some more on the
government side of things.

It's a question of how do you build
a economy or an environment or a,

you know, ecology, ecosystem that is
understandable and intelligible, and

they seem like a state perspective.

How does a large organization make sense
of this, and how do they understand it?

How do they navigate it and then be able
to contribute to it in a way that doesn't

extract the resource and in a way that's
still valuable and beneficial for them.

Without joining the resource.

And so it needs to be profitable, it
needs to be understandable, it needs

to be secure, it needs to be compliant.

And that's when you start to get
people saying things like, oh, open

source communities should have S
bombs and they should have these, you

know, bills and articles to make them
able to be consumed by enterprises.

Hopefully with a goal that the
enterprises can then support them.

Because it turns out that it's
extremely difficult for an enterprise

to send someone money because
sending money is very difficult.

Most people cannot absorb the
minimum amount of money that an

enterprise conveniently send.

The enterprises can't send the
maximum amount, amount of money

that an individual can afford.

So there's a weird balance going on there.

And so when people talk about
sustainability in that sense, they

might talk about incorporating,
they might talk about.

Governance structures shows a legality
structures, shows a ways to make

it to where the money relationship
and the power relationship can fit

into existing structures in a way
that lets people take advantage of

a mutually beneficial agreement.

Um, but can Open source be sustainable?

It depends on the perspective.

I think in every different
perspective there's an avenue.

They can be approached and
there's a way to make it happen.

The primary challenge that I see is when
you have so many different people, so many

different practices, and so many different
groups with different perspectives on

what sustainability means for them,
some of which are mutually exclusive or

hostilely exclusive, and then you end up
in a situation where no one's going to be

happy and maybe everyone will be unhappy.

And it's hard to find where to
start approaching this and where to

start solving the problem and where
to start trying to tackle things.

Um, but I think giving people sort of
the landscape and helping them identify

solutions that aren't mutually exclusive
or that aren't to the detriment of

other solutions is a really good way
forward to start making progress.

Makes sense.

There's a lot there.

Uh, obviously, I guess one thing
I, I throw out a rage ba question

and then you just rattle that right
off the top of your head, like,

I mean, fantastic answer.

I mean, even the questions I was thinking
of along the way you were answering.

As you progress through that, you
know, sustainability does have much

more to it than what a lot of people
think off the top of their heads.

And you just delivered a lot of context
there as well as opening some questions

and closing a few others at the same time.

So it's like, yeah,
this, this is a, a hard.

Thing.

There's a lot of different things,
and I'm gonna say thing like 12

more things, but that's fine.

Um, you know, I was gonna be really
flippant right at the start of

it when you started talking about
sustainability and say, I know the

answer to this one and I changed the
license and then I make a lot of money.

But, you know, you then brought
it into the real or serious chat

and then I'm out like, okay,
maybe I should just go to the pub.

I mean, if we wanna talk about
that, we can talk about that too.

Well, I, I actually, I wanna start.

Kind of digging in.

Mm-hmm.

On some of the stuff you said more with,
if I am an open source maintainer, how do

I make that decision of which, like what
way do I get to a sustainable project?

Like a lot of the main open
source maintainers, I know they're

burnout, they're tired, they're
trying to figure out what to do.

Some of them though, can't let go.

They don't know how to kind of let
somebody else take a leadership

role in a project and start to
build out that leadership group

because they know how it works.

They're that single point of failure.

Do you have like advice on how, how
do you make a decision about your best

governance structure, your best way of
getting to that sustainability where

you bring in new people for, especially
for those folks who are burnt out and

they don't have a ton of spoons to, um.

Build up a community that way.

I'm kind of curious.

So when I think of these open source
maintainers, I think my first bit

of advice for them is they need
to do personal reflection and

understand a couple different things.

The first and foremost thing they,
you really need to understand

is what are you looking for and
what are you getting out of this?

And so if you're looking for a funding
source that changes what you need to

approach if you're looking for, you
know, the fame or the acclaim or the,

the personal people valuing you as a
person because you have built this thing.

If you're looking for recognition, that's
another thing, which is not a bad thing.

That's fine, but you should
understand that because it changes

what you mean by sustainable.

Mm-hmm.

If you're looking for s to be
a cornerstone or a foundational

project for a certain domain
that changes your approach.

If you're looking to build a
thing and just build it, then that

changes your approach as well.

Mm-hmm.

And so when I think of classifying these
into sort of different kind of approaches

and so different difficulties, there's the
funding difficulty, there's the direction

of the budget difficulty, and then there's
the personal stewardship and your personal

relationship with the project, and you
can go into different areas, but those

are kind of three big ones for the funding

one.

If that's your biggest problem, then
you really need to start looking at

what are successful advantages that
are funded, how do you get funded, and

what does that funding mean for you?

And you have to start diving
very deep into trademarks and

legal structures, governance
structures that make this possible.

Billing models, funding models, and
basically you have to become okay with the

fact that you are going to be a business
and sales and marketing person first.

Mm-hmm.

And then a programmer, a distant fourth.

Right.

You're not really building a
program anymore, you're taking

your program and you're making it.

Sustainable fiscally.

You make it intelligible fiscally,
you're building that, and at some point

you might get to program it, right?

And people go, well, I, I don't want that.

I'm like, so you don't care
about financial stability, right?

Like, no, no, no.

I'm like, well, is it
the most important thing?

Yeah.

You have to know that.

You have to know it.

This is the most important
thing to where you're going.

I don't care if I write code for two years
until I figure out the funding pipeline.

Mm-hmm.

Amazing.

Now you're ready and you're prepared
for what that's gonna look like.

If you are, on the other hand, looking
for un struggling with this personal

identity thing of how do they share,
maintainership, how do they share the

vision of the project with that one?

That one can be tricky because
I think a lot of people are

much worse at collaboration
than they think.

Because it feels like something
that comes very naturally.

We do it our entire life, but it's
not natural and we're all bad at

it until we practice it a lot.

Right?

And so with the collaboration,
one of the things that I really

look at is this notion of

trust and reciprocity.

And so with that, you
have the trust element.

Can you trust each other?

Can you trust the team?

Can you trust people?

You can't build a foundation and a
vision for them, or you trust the

decision that they make, or you trust
where they're going to take the project.

They shouldn't be in the project.

Or you need some therapy, maybe both.

When you, you have to get to the
point where you can trust them.

Hands off.

And really, really lean into that trust.

And so if you're not to a point
emotionally where you have a collective

group of people building the project
with you and they wanna take it in

a different direction and you don't
like that, you don't trust them, you

need to go back into the trusting
part, figure out how to trust them.

Mm-hmm.

Figure out how to build that.

And the second element of
that, the reciprocalness.

That's the idea of if I do something,
you do something in return.

A lot of the times when we talk
about trust, we also mean that, but

they're actually different, right?

When I talk about trust,
it's more, do I trust you?

Do I trust that you have your
my best interest higher and

your best interest higher?

And like, do I trust that
we can work together?

Do I believe in decisions that you made?

But there's no obligation of a turn.

And if you're going to build a open source
project or an open source community,

the community itself needs to shift
into this mode of communal caretaking.

A communal caretaking means that when
people give to the project and they

take, but with that to always happen.

If I take, then I give.

If I give, then I also take,
I can't just keep giving,

giving, giving without taking.

That's not reciprocalness.

That's me dropping off a PR for
a new feature and saying, Hey,

here, maintain this forever.

Right?

Let's skip that without taking, if I
give Anna a take, I might say, Hey,

I'm going to give you this feature.

I'm gonna do a lot of work for you
and it's part of the specificness.

I wanna trust that you'll maintain this.

And they say, absolutely,
but I wanna trust that you'll

be there with me to help me.

Right?

And you have to have a reciprocal notion,
and that drives and generates that.

But the ego death of the
author has to happen first.

If you can't shift from an
individualistic, the United States from a

perspective of, it's my software, if you
can't shift out of that mindset, you're

never going to get to communal caretaking.

Right?

Which is the heart of sustainable
ecosystems and sustainable communities.

Makes sense?

Alright.

So now that you've covered the
entire economy of Open source, and

let's cast aside the people that
are doing it for the Eagle, right?

Because I'm not interested in
that kind of conversation, but

we're in this world now where.

Even if money isn't their motivation
for why someone builds an open source

project and then potentially a company
around it, it's always a motivation

because we all have homes, we all have
bills, we all have families and friends

and activities and hobbies, et cetera.

So money's always in a conversation,
which means that at some point someone

builds a really cool open source
project, they then want to have trust,

which you've covered, but money.

For both aspects of the sustainability
there, or at least two prongs

of that sustainability model
you kind of discussed already.

Now.

For the money thing, they can do what
most people do and they go raise a VC

round because they've got, you know, 32
GitHub stars and a few hundred users or

whatever the requirement is these days.

Putting AI in the title again, I'll
try not to be too flippant because

you know, there's some serious
conversations and topics here.

Um, so they raise their money and now
they've got that, they've got their

runway, they've got their open source
project, they're happy, it's MIT

licensed, but they don't have trust
and a lot of ways the companies go

for trust is the foundation model.

And I think what we're seeing in
recent years, again, I won't go into

specific examples, is that they're
maybe not the best of friends.

Having your open source project be
part of the foundation and having VC

funding, but it is very, very prominent.

And I'm curious to understand
your thoughts on whether, you

know, is this the right model?

Is there a better model?

Like let's understand, you know.

How, how can we fix this in a way
that it's sustainable across all

motivations without leading to burnout
or without leading to rug pills, um,

without leading to, well, I don't
really care about the VCs, but Right.

But, you know, someone's gotta make money
to pay my bills or their bills, et cetera.

So, um, I know there's a couple
of questions in there, but I'd

definitely love to hear your thoughts.

So that one is a fun topic to dive into.

I would say that.

Going back sort to the fundamentals
and abuses, that notion of reciprocity,

that reciprocal behavior has to be the
underlying foundation of how you build an

ecosystem that is resistant and resilient
in the face of multiple people interacting

with it and multiple people behaving
with it and consuming or taking so on.

When you look at a VC funding model, one
of the problems with it is that there's

no notion of this reciprocal nature, a VC
funding model, ESTs an artificial amount

of money into a situation in order to
create a flywheel effect and sort of.

The notion of a flywheels that you
have this cumulative exponential growth

of a product or growth of a solution,
growth of a brand, then that becomes

an organic capture of the market.

Instead of VC idea is if you artificially
grow the flywheel really, really big, very

fast, and then you roll it down the hill,
then that momentum can starts and you can

shave off, you know, the first 15 years
of the normal organic flywheel effect.

And it works sometimes, and the reason
why it's only kind a sometimes is because

it's inherently about market capture
and capturing the value of an ecosystem,

which is inherently unsustainable.

And so if it works in a situation.

Typically that situation is
one where there was no existing

ecosystem to integrate with.

There is no other market to
capture, and you're able to fill the

space of the market very quickly.

So a good example of VCs such in that
regard would be something like Uber

or Lyft where you have a existing
model of taxi, but you didn't have a

ride share style application thing.

They're able to find a new market
and artificially expand into

it 20 years ahead of schedule.

There's no way they could have done
it without the massive amount of

inflation, but they needed a large
amount of momentum for it to work.

So the VC money faces the
boots stamping problem.

But for something like most open source
projects, there's an existing ecosystem.

There are existing products, there
are existing open source projects,

there are things that already
happened, things that already exist.

Typically, you're not needed to
solve a boot stamp in effect.

So what ends up happening is people take
the VC money and then the funding works.

If you have this expandes of growth,
what it ends up meaning is you build

this trust of the community and you say,
Hey, we're not gonna screw you over.

And the only way to pay the bills
is to get that 1,000 revenue.

And the only way that happens is if
every single market might capture

or person using a product converts
into a high paying customer.

It does not work economically
otherwise, and so you end up with

the inevitable rock pool because
they had to make the finances work.

The only other option is to get
acquired by another company for

average sum money, and then they will
do the same thing, but with less of

a dramatic rock pool because they can
spread and amortize the finances out.

The VC people won't, but
it's the same rock pool.

It's not, I don't like to think of
it as a wealth pool because it's

them operating under an economic
model that's incompatible with how

Open source culturally views itself.

And that's really all that's happening.

And it's the conflict between those
com communities and those economies

that causes the cultural clash.

It's not a VAP poon when you expect it,
but people come in not expecting VAP pools

and when they feel personally betrayed.

That's because they assume that open
source communities are there for the

taking for unlimited consumption, and
they can just take and take and take

and grab your, grab a grab and use
a consume NPM, install everything.

Just use everything.

And that doesn't work.

The VC fits into that expectation
for the first five years or so.

So it's a natural fit for adoption in
terms of one of the other mistakes that

people make with VC funding or projects in
general when they're looking for financing

is the foundation model and the MIT
license or permissive licenses in general.

The reason for that is because both
of those, that foundation model

does not make your project resistant
to certain types of economic and

political and corporate capture.

MIT license and permissive licensees also
make it easier for those types of capture

to happen and don't protect against it.

So if you look at a shared resource
and you think of the product as a

shared resource in a larger, you know,
ecosystem of shared resources, if

everybody consumes it, then you know
it, it cannot sustain itself if runs

out of any energy that it had to, to
keep itself going, and then it dies.

It's like if everybody picks all the
food off of a tree to the point where

the tree's no longer gonna reproduced
because all of the fruit that was

buried, the seeds got taken away.

Eventually the orchard will die.

And you see the same thing with
open choice projects that have these

permiss licensees with these foundation
models that are building things.

They make it very easy for
certain types of value capture

to happen because they're not.

Playing in the same model and mental
understanding of like the culture

values, the economic values, the
government values and everything else.

If you're inside the open source
sphere, the cultural values of

open source, the cultural values
of how the communities work, how

things work, works, and all works.

If you can ignore the real world economy
for 20 years, it all works out great.

The problem is, previously you could,
um, but now even if you decide to try

and ignore the real world economy, the
real world economy, the other companies

out there, the other governments out
there, the other organizations out there.

We'll find your project and
we'll use it and we'll consume

it and we'll operate with it.

And you don't get to build a
sustainable ecosystem before it gets

essentially looted for spare change.

And there's looting takes all
the sustainability mechanisms

out of the project, and that's
what a lot of people went into.

So if they're looking for, how do I
make a VC funded thing sustainable?

That's a very different question.

And that one typically comes down to how
do you take an unnatural and unrealistic

expectation of value delivery and set
the expectations for the community before

the community gets, you know, a feel is
portrayed by you or open source budget

in general, what you're looking for is

understanding that they exist in a
market, whether they exist in economy,

and they don't get to pick the economy
or the market or the governance.

They exist in the world.

And so there's multiple players,
multiple other economies, multiple

competing understandings of everything.

And if they want to be resistant or
resilient to certain types of value

capture, what are certain types of

draining of the life of that
community, then they need to build

that resilience and that immune system
into the fabric of the project itself.

Interesting.

I mean, David, you started down this path.

Do you have any more I could ask.

I could ask more too, but
I'll let you go first.

I mean, I'm tempted to
take a bit of a segue.

I mean, honestly, you've
covered everything I would

even want to consider asking.

I feel like you know, as far
as the economy, the VC funding.

Aspect of it.

I mean, I don't have anything else.

I've learned a ton just from listening to
you over the last 20 minutes, you know,

but as we said at the start, there's many
things we could talk about with regards

to open source and, and your skillset.

And I want to push the VC side away
now and like talk about just you're

an an open source maintainer who has a
project that's seen exponential growth.

And you know, I know you like to talk
about leadership within these communities

and fostering the communities and
such, but I'm curious, like when I've

got a project that's being used by a
hundred thousand people, millions of

downloads, I've got hundreds if not
thousands of contributors, you know,

what is the, how do you keep these
projects safe from toxic behavior, from

corruption, from burnout, you know,
sustainable from all the other aspects

that we haven't really covered so far?

I mean, you've touched
on some of them, right.

But you know, the successful projects
that on the outside as a, a consumer

sitting here, NPM installing or, you
know, using Pacman or whatever, right?

You don't really think about it,
but behind the scenes there is a

lot of activity, there's a lot of
momentum, there's a lot of changes,

there's a lot of security risk from
bringing on your maintainers and

contributors, like, you know, what
advice do you have for the people that.

And that, I mean, it doesn't have
to be hundreds of thousands of

millions of downloads, right?

Even tens of thousands of downloads
is a successful open source project.

So what advice do you
have for these people?

Like just to get more sleep
and not have to worry about a

lot of the potential bad cases?

And I know that's a vague question,
but I mean, I don't have any doubts

that you won't be able to give some
great tips and advice for people.

So when it comes to things like this
for a project, you can break it into,

I think the value capture resilience
for that and then you can break it

into the governance on the project.

And how do you keep the governance
in the community sustainable?

And then there's sort of the project
overhead and the organization of the

project, like the security risk or
burnout of people and things like that.

And so if you break into those
sorts of things, you can approach

it from a couple different angles.

For capture, you need to understand what
types of capture you are looking to be

resilient at and how do you structure
the governance of the project, the legal

structure of the project, and other things
of that nature to make the capture harder.

Um, and Lilly Baker actually, um, works
meer and has a really fantastic article

on governance and open source and ways
to think about this and approach it and

some strategies we're trying to defend it.

Um, I'm forgetting the
name of the article.

Um, but I, it's on the internet.

That works.

People can find it if that that works.

Um, there's another article that'll be
coming out soonest at some point that

we'll go into more detail that I'm
looking forward to and I've been as

well and have a little talk on that.

Um, when, when it comes to governance
for the community and the health of the

community, the health of the community and
the health of individuals is at the same

time the same thing, but also kind of not.

So for the health of the community, I
really, really look into Elinore Ostrom's,

um, self-organizing principles of like
healthy and long-term communities.

Because at that point, the community
itself is working on a project and

the collective energy of the humans
is the resource that you need to

make sure you don't over exhaust.

And so she has eight principles of
healthy sustaining communities and

if you look at these principles,
they're actually very lovely.

So one of them is user boundaries.

Do you have a clear boundary between a
legitimate user and a non-legitimate user?

Or a non-user?

Do you have a resource boundary?

A clear set of boundaries define what is
in the resource of the system and what

is not in the resource of the system.

So for an open source project, that
would be who are the committers,

who are not the committers, who are
the people that you know can make

requests, who can't make requests?

Do you have an understanding of how much
time people have, how much money the

project has, and can you separate that
and make sure that you can understand it?

Do you have a congruent environment
where the actual set up of how

the open source project runs
ones, matches large environment

if it's trying to be a foundation?

Does it look like a foundation?

If it's trying to be a little hobby side
pocket, is it clear that it's a hobby

side project or is it trying to set up all
these weird things and then go, oh, but

we don't, she care about the legal setup?

And then I go, well, if we don't
care about the legal setup, then

why do you have a legal governance?

Um, or for example, the MIT license means
anybody can use your budget, including.

People using the PON that may
make it a target for, you know,

state actors and state violence.

So for example, the utils package
was maintained by some random person

and they became a target of a three
year attack, my nation state, in

order to gain a vulnerability DB two
system because their package just

ended up in basically every dish on
the planet because it was used by SSH.

If you don't wanna be woken up
Sunday at three in the morning by a

nation state actor, you should make
sure your project is very clear.

Do not ever use this in anything
important, and then people won't.

Before we could pretend that
we didn't need to do that,

but now we do need to do that.

Like going back into some of these other
principles, I think one of the most

important ones is solution mechanisms
and also elective choice arrangements.

So there, there's others in there as well.

But for the collective choice
arrangements, that one is, can people

and groups, subgroups of people within
the project make their own rules?

Can the project self organize?

Can the project say, you know what,
this is how we've done it, but we

shouldn't be doing it right here,
right now in this way, and we

should change thrones in the game.

We should change the rules of the project.

We should change the values of
the project maybe, or we should

change the shape of the project.

Different groups of users can't do
that without need full consensus

and buy-in from the entire project.

It won't be so sustainable, and you
can look at that very clearly when

you see like Kubernetes as an example.

How many people in Kubernetes agree
with everything about the project?

How many sub projects of Kubernetes.

So that when the sub projects
operate differently than other sub

projects, that's not, you know,
undesirable, that's actually desirable.

That is a sign that the Kubernetes
project has figured on a self

organizing structure and the culture

Conflict solutioning mechanisms are
probably the most important part.

So that one is how do
you surface conflict?

How do you recognize it?

How do you understand it?

And then how do you solve it?

If you don't know how to solve
it and you're just gonna figure

it out, you're gonna do it wrong.

Something's gonna happen.

And this is where a huge amount
of drama in the open source,

open source community comes from.

People say, I don't need
to worry about this.

I don't need to think about this.

Emotions are, emotions are reform other
people, and then they throw hesitant.

Or they absolutely lose it, or they
drag on for pages and pages on pending

disagreements and the whole budged
part, and none of that needed to happen.

You need conflict resolution agreements.

You need to understand them deeply
and you need to put them into

the fabric of project itself.

Going back into the personal element,
the individual element, keeping project

safe from burnout and the security risk.

So for burnout, one of the things
that I think is interesting there is

burnout comes typically from when people
are investing into project with the

expectation that they're going to get
something out of it, and then they don't.

If you're overinvesting with the
expectation that you get something

back and then you don't get something
back, you're gasoline yourself, and

then you're just overworking yourself.

But expectations that nobody promised,
and that's where the Mr. procasity

comes from, which I will learn
how to pronounce that one date.

Um.

But that, that's where that
comes from in the trust, right?

And so if you are putting something
in and you're not getting something

out, you need to know that.

And it needs to be clear enough
upfront with what you want out of it.

And if you're not getting that thing
out of it, you need to change something

until you are, or you need to change your
approach to it and your expectations.

A lot of people burn themselves
out because they go, I want this

to be the best project for this.

And I go.

Okay.

Um, that's like 2 million
human hours worth of work.

Where are you going to get that?

And they go, well, people
will just gonna buy it.

I'm like, nobody could buy it.

Yeah.

Well, what if they don't?

You haven't said anywhere that
you want people to buy it.

You haven't said anywhere.

Then you need that to happen.

You haven't said anywhere what
your needs are, and you're just.

Burning away, burning your entire
life force down to the ground for

something that you want, that you
are not even naming and articulating.

So of course they burnout out.

You need to articulate your needs
and desires, and you need to

understand them and make sure that
the project is harmonious with them.

Otherwise, they're going to end up as
looking like an irrational, you know,

benevolent dictator of her life, who
is sort of being wishy-washy with the

protest and they're looking for those
unmet needs that that are unarticulated

and then they get burned out.

And so you really need to
understand that about yourself.

It has for a security risk from
the individual perspective,

that one is pretty interesting.

So it turns out security risks don't
exist or the individual or for the budget.

They exist for the
consumers of the budget.

The budget itself has no
notion of a security risk.

The people using the budget.

If the company's using the
product, people consuming it have

that notion of a security risk.

And by that, you know, reciprocal sort
of give and take notion, it means the

product should reflect them trusting the
product and addressing the security risk.

But the product does not
actually inherently have the

notion of a security risk.

So when maintainers come in, let them
and the people using the project have

a problem with that, that they need
to be involved in the project and

it's contributing to the part that sustain
in it sufficiently to where they're

able to get their, their needs met in
a way that everything is harmonious.

So, as a very concrete example,
actually, as a less concrete

example, I was gonna go too spicy.

Uh, as a less concrete example,
if you have a project that

has a core set of maintainers.

That live in one country with economic
sanctions, that might mean that that

project cannot be used by certain
arts companies or certain arts

corporations or certain governments.

Is that a problem?

Not for the project.

Is that a security risk?

Not as far as the project's concerned.

Is that a security risk for
the company using it or the

enterprise using Absolutely.

What are they gonna do about it?

Typically, they go into the
product, they open up an issue,

they say, blah, blah, blah.

Do a bunch of work about snake pipe.

Then they hate you know, open issue and
then the party maintainer says, um, no.

So that kind of situation's
unproductive for everybody.

The maintainer is not going to win.

They're going to look like an asshole.

The, you know, corporation's
not going to win.

They're going to look like,
you know, a greedy resource.

Stealing, you know, community is trying
to give advantage of the community.

Nobody wins.

But if people say, Hey, how do we hit this
economic concern and if someone says, this

is a concern for me, how do we build this
type of trust if they all work together

collectively, you can manage things and
set things up in a way where that happens.

One possible solution might be
that you have multiple groups of

maintainers in the budget, each
from different economic or political

areas, and if someone submits a match.

Someone from a different clinical
region needs to approve it.

That could be one possible solution,
but no one going to get to that solution

if they all just start rates beating
each other on issues on the internet

and saying, you should just do all
this work for me for nothing because

I want you to, because security risks
don't really exist until they do.

But they only really, really
exist for people consuming them.

See if you don't.

If you don't have that notion of
reciprocal behavior of that trust, that

it stands beyond the boundaries of the
ingroup, it's just not going to work.

In which case, put about it.

If they don't care about
that, feel free to drop it.

State it very clearly, make your
expectations very plain, and then

sleep at night knowing if anybody
cares, it's their problem, not yours.

I have one more question.

No, I think.

We've been very careful not to
use any concrete conversations

so far, even if some people can
work out some of the situations.

But there's something very
topical right now and I'd

definitely love your take on it.

And that is, obviously there's the
DOJ case against Google being a

monopoly with Search and Chrome.

And you know, the answer seems
to be, well, they have to get rid

of Chrome because it drives their
monopoly on search and advertising.

But I'm looking at this, I mean, as a
Firefox user too, which is why I can

sit here and say whatever I want, right?

But I'm not sure any company in the world
can successfully take on the burden of

Chrome without having their motivations
not being too dissimilar from Google.

Um, as much as I would love to see
Firefox have more money and more

attention, but at the same time,
Google are also the 90% of Mozilla's

revenue, which is actually keeping
the lights on at Firefox right now.

So this one's an interesting one.

Um, I think to take a step back,
looking at operating systems is

actually kind of an interesting one.

So if we look at operating systems, we
have Linux as an operating system, and

then you have miscellaneous, and that
is a huge historical fluke, but it's

turned out to be a very advantageous
one because the Linux Foundation.

Foreign limits has ended up being
the closest thing we've ever had in

open source to a international public
utility and is maintained by something

approaching the political neutrality
of the United Nations sidestepping

entirely from the fact that the United
Nations is not politically neutral.

Um, but so you have that kind
of situation that let has ended

up in and that has prevented.

Windows and Mac iOS and Android and
iOS and other different operating

systems from being in the same type
of position of being able to have

a monopoly fat American, and then
using it to outwardly influence

and outwardly shape the trajectory
of how people interacting with it.

But then you might argue that there's a
lot of telemetry in modern operat systems.

And so is this telemetry sort of issue?

Is it not an issue?

And I think ironically, it would
be more of an issue if browser

had not become the true operating
system than most people use.

So if you think of a computer that you use
and how you interface with the computer,

you turn on, you open up your web browser.

Maybe we have your other applications
that you download, which are web

browsers in a different box, and that
application runs in that web browser,

but it's called something else.

So 90% of people, 90% of the time,
basically just use a web browser.

There's a made up stats.

It's true though.

It's probably that right?

When you run into that.

Run into that situation.

I think a lot of the reason why open
systems have avoided this need to

split and these antitrust things
is because of the web browser.

And even when Microsoft had these
huge, you know, lawsuits levied against

them in the nineties and the early
thousands, it was on, it was on explorer,

it was on how they bates the open
system and the white voucher together.

It wasn't necessarily the operating
system, it was the combination.

And so for Chrome, it's now the
defacto operating system for the

world, and that is where I think
most of the anti, you know, trust

and the app, so the issues stem from.

So if I think of the shape of the
problem or the, the safer, the solution

that might sufficiently address this.

I do agree with David.

I don't think a single company can ever
actually host Chrome and keep Chrome open

and funded and do things of that nature.

Um, what I think what actually end up
need to happen is, I don't know if the

Linux Foundation can hold Chrome, but
something in that shape, you would need

a international, global neutral party.

To hold onto Chrome and Mozilla,
and are you please safari too?

And essentially any operating system
or um, any browser in the future?

Probably any urban
system, but any browser.

And essentially what we would
need to do as a human nation, uh,

as a human species is invent and
formalize the notion of a public good.

We've been able to, by and large.

Make public goods a thing informally
by having a very diversified

and disaggregated supply chain.

When we invented steel or when we
invented certain types of materials

and raw resources and computer chips
and all these other fun things,

they're enormously expensive, but
everybody can manufacture them.

And so we're able to split that
up, aggregate it, you know,

separate now and make it to
where people can still innovate.

They're still American.

The web browsers.

Web browsers are one of the few things
that now we've decided due to how

complex they are, how deeply integrated
they are to how we live our life.

We access our banks to them, we access
our email to them, we access our jobs.

You can't apply to a job for
that web browser anymore.

You can't apply to, you
know, government founding.

You can't apply to government benefits.

You can't interoperate with,
you know, your local governance

or your local, how you get any.

Thing that you need for modern life
without a web voucher, which means to

me that the web voucher needs to be
this public good utility and due to the

scale and the size of it, the public
good utility is not something that every

nation could independently recreate,
and so therefore, it needs to be an

international, public good utility.

It needs to be something that we
collectively as species to say.

We need one of these and nobody should
be in charge of it, but everybody should

be in charge of it, and we just scaled
our collective ownership up to humanity.

Well, thank you so much for joining us.

I think everyone really enjoyed the
conversation and hopefully, we'll, maybe,

who knows, maybe we'll get to do this
again some other time in the future,

but we really appreciate you joining us.

Yeah, that'd be great.

I'll keep my answers short so we can
actually have a conversation too.

That's perfectly fine.

Thanks for joining us.

If you want to keep up with us, consider
us subscribing to the podcast on your

favorite podcasting app, or even go
to Cloud Native compass fm. And if you

want us to talk with someone specific
or cover a specific topic, reach out

to us on any social media platform and
tell 'em next time when exploring the

Cloud Native landscape on three on three.

1, 2, 3. Don't forget your compass.

Don't forget your compass.