[Music]
We all doing well.
Louder.
Wow, that was awesome. I'm very excited
to introduce our first speaker here,
Justin Warren. He works for or runs,
sorry, Pivot 9 and has more than 20
years of experience in the open-source
space. Does everybody here like open
source? Do you want to see it? Keep
going. And please give a very big round
of applause for Justin Warren.
[Applause]
Thank you very much for that kind
introduction. Hello everyone. I know
we're after lunch so I'm going to try to
g you up so we're not too tired. And how
how many people carbloded over
lunchtime? Yeah. Okay. Nap time in 20
minutes maybe. Uh I'm going to try to
hoover through this thing really kind of
a bit quicker than normal. Uh because I
really want to get to some questions if
we can. Uh hoping we can do questions at
the end. So let's let's go. Um this is
me. I'm the principal consultant at
Pivot 9, but you already heard that. We
don't need to look at my face.
Where to begin? Sustaining open source
software. It's a big topic. Uh so I am
not going to go through all the details.
I'm going to summarize and gloss over
things. I'm going to skip a lot of the
nuances and so on. If you want to come
and argue with me about nuance, more
than happy to buy me a drink first.
Four things I want you to get out of
this talk. I want you to understand that
maintenance matters more than creation.
That ecosystems matter more than
artifacts. That systems are more
powerful than individuals. And finally,
that humans matter more than computers.
And summing up all of that idea is this
concept that I love to promote, which is
that the purpose of a system is what it
does. Yes, you can buy the t-shirt.
So, how did we get into this position? I
would argue that this is the problem.
This is what everyone is complaining
about. Yes, this is an
oversimplification, but broadly people
are grumpy about where all the profits
are going from what we call loosely free
and open source software. It's not
really going to the maintainers and we
need to talk about why that happened
before we can start to diagnose what we
should do about it. Uh there have been
many other talks today that I recommend
that you go and talk about you go and
listen to. uh but particularly I want to
focus on this idea that maintenance
matters more than creation. I think
there was a mistake that was made right
back at the beginning of the open source
movement related to that concept.
There are four types of goods in
economic theory. Who who knows anything
about the four types of goods? Anyone
seen this before? No. Okay. Uh broadly
private goods, toll goods, public goods,
and common pool resources, which is a
thing that you may not have heard about
before. And that's what I'm going to be
talking about a little bit.
Of those four ideas, what do you think
software is? Show of hands if it's a
private good.
Okay. Show of hands about toll good.
Okay. Show of hands for public good.
Show of hands on common pool resource.
Ooh, interesting. Okay. Correct answer
is all of them. Uh,
yeah. which is not everyone put their
hand up all the time.
And the thing that I really want you to
to concentrate on here is the two axes
are important. Subtractability of use
and exclusion difficulty. I'll refer to
them as I go when it's important. But
the top of this diagram I think is
something I really want you to focus on.
I think free and open source software
belongs up here in the top right. And on
the top left is a different kind of open
source software which I would call
reference software things like Eliza
that happens to be public domain. But I
think the reference versus living
software is an important distinction
that's kind of been overlooked and that
was part of the maintenance versus
creation mistake right back at the
beginning. So why is it like this?
I recommend that you go and uh look at
some other talks which I'll I'll give
you some links at the moment. Largely
this picture demonstrates one of the
reasons for about 20 years the entire
tech industry has been trying to do a
Google i.e. create a thing and then
either IPO for lots and lots of money or
like many of these companies get bought
by Google. The reason for that is that
VC funding was very important in the
foundation of many of the organizations
that started off this last 20 25 years
worth of industry they were VC funded
and the important part of VC funding is
that the reason to fund something is to
get your money back. What the company
actually does matter what matters is
whether you get your money back and the
ways that you do that generally are you
IPO i.e. sell it to the public or you
get bought by someone else, sell it to a
private company.
And that led to this mistake. Many
companies thought that if you were
popular, that was the same as being
profitable. Turns out that's not true.
It was true enough for a few companies
that they got very popular and then
figured out how to make the money later.
And lots of people copied that idea
without really thinking about it. And
because this doesn't always apply, it
didn't really work for them, which led
to a lot of conversations like this,
particularly in the last couple of years
where companies who had encouraged all
of their customers to please use my
product for free as much as possible.
And everyone said, "Yep, awesome. We'll
do that." And then they thought, "Hang
on, where's the money? We can't keep
paying all of our staff. We can't keep
building this stuff. We can't keep
maintaining our company and our software
if there's no money in it.
But we built this system to do this. And
the purpose of a system is what it does.
If we don't like what that system is
doing, then we need to change the system
so that it will do something else.
And that's where ecosystems come in. So
remember back couple of slides ago where
I said Eliza and free and open source
software are different. That's because
Eliza is an artifact. it exists as a
static thing whereas ecosystems are
dynamic. They change. They evolve. They
need to be maintained.
This is a talk that Christopher Noabau
is sitting over there. Uh I have this
link that you should go and watch which
is a talk that he did at Monktoberfest
last year. Uh because his current talk
isn't up yet because he only just gave
it earlier today. Otherwise, I would
have linked to that. Do go and look at
this. I'm not going to reprise all of
it, but he broadly goes into how we got
into this kind of state and his last
talk also does a bit more of that which
is excellent because I don't have to do
it now. But I do want to highlight this
particular aspect. This is a slide from
Christopher's talk previously which is
about the ecosystem. It's not about the
code. The mistake a lot of the licensing
uh conversations that we have about
talking about particular companies they
are talking about very specific things
and the focus on the code the open
source and the free nature of the
software
overlooks everything else that is
involved in the process of making and
maintaining software the ecosystem in
which your software lives and that's
vital not understanding that I think is
at the at the core core of a lot of what
is uh causing this sustainability
challenge because um this is newish
data. This is from October of 2024 uh
research by the sovereign tech agency uh
which broadly shows that about 30% of
projects are maintained by one person
and two to three are maintained sorry uh
and another 40%ish are maintained by two
or three people. So around 70% of free
and open source software is maintained
by three or fewer people.
That's not many, particularly given that
there are millions of these projects.
I've gone and had a look at the
ecosystems data set. It's a little bit
opaque and I haven't had time to go
through it in great detail, but it
broadly aligns with this. If anything,
it kind of skews more towards the one
person maintained projects depending on
how alive they are. And this is
difficult to see because unfortunately
their their slide wasn't particularly
great. Uh but broadly it's if you sum up
all of the numbers and when they were
asked are you getting paid enough to
maintain open source software about 77%
of people said no. Some of the getting
paid a bit but most of them are not
getting paid either at all or not enough
for me to be doing this as my job which
means it's being cross-subsidized by
something else.
Now why would you do that? Why would you
work on this stuff for free?
Partly it's because we as an ecosystem
have pushed people to do this. All these
VC companies have been pushing out stuff
for free. They have been setting the
expectation that open source software
should be free and that you should work
on it for free. Not that you should
create something and give it away and
here is an artifact. Please have it.
It's great. It's Eliza. Reference it.
Look at it. That's different.
They're saying that not only do you
release it once, but you have to keep
working on it for free forever.
People do this because they think their
expertise is going to be useful. That
it's kind of a marketing exercise. And
that sounds a lot like working for
exposure. And even penguins die of
exposure.
So maybe we shouldn't do that because
this is what the costbenefit allocation
generally looks like for the people in
this ecosystem. Again, I'm not going to
go through this in massive detail, but
if you look here, people who are
hobbyists or just general contributors,
they kind of contribute a bit. It's not
a bad deal for them, but for
maintainers, it's not a very good deal
at all. For vendors, it's awesome. And
one particular thing I want to point out
here is the different kind of
maintainers. For most maintainers, this
is a raw deal. But people do it because
like other uh like the entertainment
industry where you have lots of
maintainers who are well, we can call
them actors who are working as waiters
or they have a day job that subsidizes
this thing that they do hoping that one
day they will be famous ignoring the
fact that for every good kind of famous
like maybe Lionus or Guido Van Rossom,
there is the bad kind of famous i.e.
being a woman on the internet.
This is the purpose of the system that
we have created and we need to change
it. But what do we change it into?
Coming back to this different type of
good. I argue that free and open source
software is a common pool resource and
we should maintain it as a common pool
resource not as a public good. And that
means that we can look at governing the
commons and the work of this wonderful
woman Ellena Ostramm who is a Nobel
Prize winner in economics. Uh she won
the Nobel Prize in I think it was 2012
if I remember correctly. No, that's when
she died. Uh 2005.
Uh
I have to mention this briefly because
when I talk about commons generally
people think of the tragedy of the
commons. Go and read that paper and then
never talk about it ever again. The
paper explained why tragedy the commons
is a false and dangerous myth that was
wrong when the paper was originally
produced and Elellanena Ostramm's work
had already proven that. So let's not
talk about that. Let's talk about
Elellanena's work. When you're managing
common pool resources, these are the
eight design principles as as she and
her colleagues call them that you should
be using. Now I say should because if
the the more of these eight principles
that are present in your project or in
your initiative or in in whatever it is
that you're doing, the more of them that
you are doing, the more likely it is
that your project will be successful and
sustainable. You don't have to have all
of them, but the more of them, the
better.
And I'm not going to talk about all of
them because I don't have time. Uh so
instead I'm going to focus on a few of
them because the systems that you use
these design principles to create are
more powerful than the individuals. They
constrain individual behavior and the
systemic design is what I want you to
focus on. We need to look at how the
system functions not about the
individual behavior because the two
things influence one another. And I want
to talk about these three in particular.
The first one is congruence, which is
broadly why people are grumpy.
At the moment, there isn't a lot of
congruence between what people are
putting into a project and what they're
getting out of it. There are people who
are not putting anything into these
projects and extracting a lot of benefit
from it. And there are people who are
not actually extracting very much
benefit, but putting a lot of it into
the projects. That's not very congruent.
Turns out congruence is important. And
the fact that we haven't designed a
system with that in mind is probably
something we need to change.
But how?
Well, we have to figure out what
congruence actually means. So, if
someone isn't putting in as much as
they're taking out and we disagree with
that, we might be in conflict. So, what
do we do about that? How do we resolve
that conflict? I would argue that in the
open source and particularly open
source, but the free and open source um
community, we have done a woeful job of
designing conflict resolution mechanisms
before we need them, before there's a
crisis, even to the point of having
codes of conduct, which we kind of now
do, but not universally. That happened
very late.
We need to design conflict resolution
mechanisms for the conflicts that are
going to exist in our ecosystems, in our
projects before we need them. And I
would also argue that the one that we've
used the most licensing
is the wrong one or it's it's one
choice. It's not the only choice and
it's actually one of the less powerful
ones and we need to have other choices.
Austramm particularly values things that
are local, lowcost and fast. At the
moment when we lean on the legal
mechanisms that work for private
companies, they are incredibly slow,
very heavy. they in they incur a massive
cost on the participants of that and
also the rest of the ecosystem. They're
not welld designigned. They're not
congruent. They're not the way that we
should be managing common pool
resources.
But when I say we, well, I'm talking
about who's actually in charge of these
things. Many of the projects that we
part of the reason that we're here,
these projects are run by companies.
They're not really run by people. I hate
to break it to you, but uh corporations
are not democracies.
They're actually authoritarian
dictatorships
and that's how they function. So if
you've got three maintainers for a
project and they're all employed by the
one company, guess who's in charge of
that project?
You're not making collective choice
arrangements. There isn't much
collective choice going on. So I would
argue that we need to get into much more
collective choice. We need to be
designing those mechanisms into our
projects from the outset, not trying to
impose them later on. Having a
benevolent dictator for life might be
very quick and efficient at the very
beginning, but we need to move away from
that model very very quickly. And in
fact, most projects that are sustainable
have done that. They've just done it
much later. We need to design that in at
the beginning because the purpose of a
system is what it does. So if we want a
different outcome from our system, we
need to design it differently.
But change is coming and change is not
coming from within the tech industry.
It's coming from outside because humans
matter more than computers. Particularly
to people who don't like computers or
don't use them very much, i.e. most
people in the world.
It's not coming from in the tech
industry because we don't make very good
computers. They break a lot. They're
getting worse. People are trying to do
things with their computing devices. I
was talking to my mother only this
weekend and she is incredibly frustrated
with her phone because Apple moved where
the delete email button went and she
can't work out how to do something that
simple. And this is a company that
broadly has a reputation for being very
good about user experience and user
interface design. That's what our
perception is from the broader industry.
We also managed to take down a lot of
important infrastructure systems all
over the world in a single day because
one company pushed out an update a
little bit too quickly without testing
it. Whoops.
That's the industry that everyone else
has to deal with and they're not happy
about it. So, they're starting to make
it more difficult for companies to do
this. It's particularly coming to the
IoT device section of the uh of the
industry mostly for national security
reasons. It turns out governments don't
like it when it's really easy for you to
take out an entire country's
infrastructure. So they're passing
various laws about critical
infrastructure and how that needs to be
man maintained. It's also being passed
in laws around IoT and I want to point
you at particular couple of bits of
legislation that I recommend that you
familiarize yourself with particularly
the EU cyber resilience act but there
are some elements around IoT and the
Australia's cyber security act
essentially if you are a manufacturer of
a device that can that will be able to
be connected to the internet that
warranty disclaimer thing at the
beginning of software where you've used
the software and if it sets fire to your
data center and your cat too bad uh
that's going away.
We are not going to be able to get away
with that anymore because there are
going to be consequences for doing that.
And interestingly, open source is in a
good position for that. Now, this is
important because when companies incur
consequences for shipping buggy software
that they refuse to fix, governments are
going to start imposing costs on them.
That's going to make them more
interested in paying people to make that
liability go away
by increasing their willingness to pay.
That money can go into the people and
the projects that maintain and look
after that software. Remember what we
had back at the beginning about
maintenance being more important than
creation. It's not about this thing that
exists. It's about how it gets changed,
how the bugs get fixed, how we update it
later on after 5 years have passed. And
it turns out things are different now.
But stable systems resist change. That's
what stable means.
But we have an advantage there. Now, the
current system of doing this where it's
all extractive and we make loads of
money because other people like working
on our stuff for free for reasons that
we don't want to disturb. Shh, don't
tell anyone. They're getting a bad deal.
Turns out this was a great deal for
everyone for a long time. So, open-
source is everywhere.
How many people uh have used a computing
device that includes zero open source
software in the last year?
How would you even know?
But I can almost guarantee that everyone
in this room has used software that
contains open source software in the
last year. In fact, today it's almost
impossible to get away with. And that
means that these companies who need to
make changes have two choices. One, they
can rip out all the open source software
they've been using for the last 25 plus
years basically for free and replace all
of it with proprietary software that
they get from somewhere.
Or they can pay someone to uh maybe fix
some stuff and make the problem go away.
Which one's easier?
There are other options. Turns out
socialism is a thing. Uh, and this one's
gotten a lot more interesting in the
last, let me count how I can't count
from January, but this year because a
lot of people have realized that, oh,
turns out one country is kind of the
center of the tech universe. What if
they're not a reliable partner anymore?
Maybe sovereign technology is a thing we
should look at a bit more. So the
sovereign tech agency from uh Germany
was already doing good work in this
space but it was a bit it was a bit out
here on the edge. Now we have talk of
Euro stack for example where maybe
Europe should have a cloud that isn't
completely welded to one country who may
not actually like us very much today. H
I think we should be doing more of that.
That is collective action. It's not rely
it's a systems change. It doesn't rely
on individuals doing things differently.
Um, we also see a bit of a public health
response. Again, this is mostly coming
from the cyber security angle, not so
much from a wouldn't it be nice if we
actually paid people to do this. Like,
we don't want stuff to break so much.
People are grumpy. They're not really
going fast enough for my liking. They're
going to put stickers on things. If you
would like one of those, you don't have
to take a photo of it, or you can go to
that QR code and you can design one of
these and print it yourself. Please go
and put cyber ratings on all of your
documents. That would amuse me no end.
Um, Australia is actually going to come
up with a cyber rating kind of labeling
scheme. Uh, they haven't finished
designing the labels yet. Um, they
aren't licensing this from me, which is
I think is a shame. Uh, but they will be
doing this. That's fine. This kind of
labeling thing, it does work, but it
takes about 10 years to actually have
any effect. So, it might start working
eventually. It's better than nothing,
but it's not sufficient. Let's not let
them give up on that. But this I think
is the most powerful thing and I don't
think we do this enough.
When someone comes to you and says will
you please maintain your software for
free for me? You should tell them no.
Please sign up for a support contract.
Otherwise I am not going to fix your
bug.
What are they going to do?
Now, for many of us, that will be
difficult because we feel that there is
a moral imperative that we fix security
flaws in software that we gave everyone
for free years ago in some cases, and we
feel like, well, it's I'm responsible
for this. If you're not being paid for
it, no, you're not. You gave something
away for free. No one was under any
obligation to pick it up off the side of
the street, whack it into a commercial
product, which they then push out to
millions of people all over the world,
charging a fortune for it, and uh then
never fixing any of the bugs in it.
Also, you're legally prohibited from
reverse engineering my thing and fixing
it yourself. That's a raw deal. Just say
no.
And at the end of all of that, I think
that we are in a good position to
actually change this because of the leg
the legislation changes that are
happening from outside the industry. We
could do a lot more to fix this
ourselves, but so far it hasn't
happened. But I encourage you to do
everything that you can to push it in
that direction and to support the
endeavors of those who are coming from
outside
to impose costs on the industry to make
it more costly to not do the right
thing. So that if you are a commercial
company putting open source software in
your product, selling that to people and
it's not fit for purpose or it has
security bugs or it doesn't support a
marginalized community or it's not
accessible, they can come at you and
say, "No, that is not acceptable in the
same way that it's not acceptable that
you sell me bread that is full of
sawdust or coffee that is poisoned. We
don't accept it from other products. The
period of time in which we did accept it
for software is coming to an end and
it's coming to an end quickly. Get ready
for it because it's happening. I think
we should encourage it to happen faster
because then we will all be better off
and the software that we make will be
more sustainable. And that is the pretty
much the end of my talk. Remember these
are the four ideas. Maintenance is more
important than creation. Ecosystems
matter more than artifacts. Systems
matter more than indivi sorry systems
are more powerful than individuals. And
humans matter more than computers. The
purpose of a system is what it does.
Thank you.
[Music]
I think we have time for questions.
Thanks very much. Yeah, we do have time
for a couple of questions.
Excellent.
Anybody out there like questions?
One over here.
Please go. While the mic goes back
there, I would like to just point out
this. This is a fabulous book that I am
annoying everyone with. It's called The
Care of Things: The Ethics and Politics
of Maintenance. It's fab. Please read
it. It's great. The authors are French.
It's The book is so French. I'm with a
big corporation, 1600 people with a
gazillion users of Python. What's our
obligation to support Python?
Your obligation according to society is
zero. I think that should change.
uh your moral obligation I think is to
yes support it your fin your how your
company is structured and what risks you
you as a company face if you don't
support it i.e. If the people who do it
suddenly turn around and tell you,
"Yeah, nah, not today. We're not gonna
um what leverage do you have? If you
pick something up for free and the
people who the people who maintain that
decide that no, not going to or like
we've seen in a few places, I'm going to
sell access to Russian hackers today cuz
I make loads of money doing that." Does
that place you at any risk? Have you
hedged against that risk? Something to
consider.
I don't normally do this, but I'm going
to give give a comment. I'm with the
Python.
Please raise your questions in the form
of a question.
If you want to figure out how to give
the Python Software Foundation money and
support Python financially, do come and
speak to me. I'm with the foundation and
we would love to talk.
Please do. So,
any other questions?
Yep. Right.
Uh you mentioned a couple piece of
legislation which as I got it sort of
have liability and consequences for
things not working properly.
Does that imply to just the end product
or also components like little libraries
that'll say this has no warranty express
or implied?
Yes, it does. Um there is some nuance in
it because in the original formulation
it was going to apply to everything
which would have meant that open source
projects would have been liable for
stuff they gave away for free. Uh people
realize that that's not good. That'll
basically kill everything. Also, it's
not workable. Uh they were quite smart
about how they've designed it. Liability
actually flows through um through the
supply chain. If and there's ways to get
around it, but essentially if you're
selling a product for free with and
software is a product, then you are
liable as a manufacturer, but also as
someone who incorporates it. So both
parties are liable and you can't just
contract away the liability either. So
you can't just say, "Oh, we'll sign a
support contract and you are now on the
hook for billions of dollars of
liability." doesn't work that way
either, but there's a bunch of nuance in
it which I'm more more than happy to
talk to people about. Another question
there.
Thank you. Yeah.
Hello. Uh do you have any commentary
about um the balance of I know that
there's things about artists uh creating
um work and then being told to monetize
it straight away and a lot of hobby
programmers are in the same kind of
direction. Do you have any commentary
about the balance of doing something
that you enjoy in your own free time
versus doing something that you then
want people to pay you for versus
something that you feel responsible and
removing the joy from creating uh is
sometimes the effect that I've seen out
of that.
Yeah. So it's it's tricky. Um on the one
hand I would say yes it's like it's fine
if you want to uh to a point.
Um but I would it's nuanced. So on the
one hand, if if that's what you want to
do and it's and it's relatively minor,
it's not a big deal because you're doing
it for joy and for love. It's also a
finished thing that doesn't need to be
maintained. So a thing that needs to be
maintained is a little bit more nuanced.
But you also are part of society. So if
you ignore what the rest of society does
and you particularly if you are
prominent in a field, I would say
there's a greater responsibility. With
great power comes great responsibility.
So if you're a very powerful person in
that particular ecosystem, what you do
matters more. So if you are setting the
precedent that hey all of you should
work for free I'm fine because I have a
trust fund because I inherited wealth.
So I can totally work for free in the
arts or in the library or wherever I
want to do and we have a whole bunch of
industries that are structured more or
less in that way. That's not fair on all
the people who didn't inherit wealth.
There are of course other possible
solutions to inherited wealth that are
possibly beyond the scope of uh this
particular talk but we are on collective
action day today so we can also talk
about that. I remain long guillotine
futures.
I think that's all we have time for for
the questions. All right round of
applause for Justin Warren please. I'd
like to offer you that on behalf of the
convention as a thank you.