[Music]
Hello. Welcome again to PyCon Day Three.
Uh it's my pleasure to announce
Christopher Nogabau with his talk, The
Death of Consequences. Take it away,
Chris.
Thank you.
[Applause]
Hi. I you've come to my opinion talk.
This is a talk I prepared for a
different conference which is slightly
less lax on timing. It is going to run
long. It's not going to run so long that
you'll miss the next talk. But if you're
getting antsy, it's okay. You will get
time to go to another room at the end of
it. Um, so yeah, again, my name
you may know me from the talk I gave
yesterday or the fact that I host
lightning talks or various other things
I do in the Python community. Um, you
may have seen over the last year a lot
of talks about open source
sustainability, the way things are in
open source. And I'm here to set the
stage for those talks that you've seen.
This is a talk about why things are the
way they are in open source. Now, how
this talk is going to work is that I'm
going to start with some background. I'm
going to selectively present some
evidence and then I'm going to present
the conclusions that follow directly
from that evidence.
If you're into rhetoric, you will
recognize this as reductionism.
This is necessary because I have only 30
minutes which I'm going to use up
entirely to try to deliver a clear
message. You have been warned.
So the talk, this talk is about the
first golden age of open source which I
believe everyone here in this room has
lived through
and is now in my view firmly and
indisputably at its end. Two key events
happened last year that I think signal
that downfall. The first, which I spoke
about at Monktoberfest last year. You
can look up the video, stems from us as
a community being unwilling to address
the false and destructive narrative that
being a terrible person makes you a more
effective contributor to open source.
The result of this was almost an
international security incident.
The other is that IBM announced that it
was to acquire Hashi Corp in a
transaction that closed earlier this
year. This acquisition followed the
rejection first by industry and then by
the market of Hashi Corp's decision to
rellic their suite of open-source tools,
notably including Terraform under
non-opensource terms that prevented
cloud providers that Terraform was
designed to interoperate with from
offering services based on those tools.
Hashi Corp's actions were a reaction
like countless other open core companies
to better larger better capitalized
companies launching services that
competed with their revenue streams
using code that they had written. And
while it makes sense to fight back
against such extractive behavior, the
way in which they did so was
comprehensively rejected by people who
care about open source. That rejection
likely caused the drop in share price
that enabled that acquisition. A
complete failure of an open-source pro
uh product business to operate as an
independent entity.
And ultimately the root cause of both of
these things are the same. We as a
movement have created incentives for
people to perform undesirable behaviors.
And today I want to talk about
extractive behavior that leads to
smaller projects becoming unsustainable
and how we as a movement have actively
chosen to incentivize extractive
behavior and how we've thrown away our
ability to fight back.
So extractive behavior is not unique to
open source. Many creative industries
suffer from extractive behavior from
corporations that are not
disincentivized to do so. In 2023, a
group of workers realized that their
industry was likely to be significantly
impacted by the rise of AI. That their
work could be used to train AI models,
which could eventually be used to
devalue their work or worse still,
completely replace their jobs. A threat
that we as software engineers feel all
the time at the moment. And yet, it
wasn't the tech industry that stepped
up. It was the entertainment industry.
Both the writers unions and the actors
unions for film and television in the US
withdrew their labor for more than six
months in protest to changes affecting
their industry and threats that they saw
on the horizon. Entertainment
productions halted for more than 6
months. But as a result, both these
unions achieved long-term protection
against their work or likenesses being
exploited for AI training without their
consent.
Collective action is a balance against
the power dynamics inherent in
employment situations. It's easy for an
employer to compel a single employee to
perform undesirable work because the
employer can threaten that employees
livelihood. By holding each other in
solidarity and acting towards the same
goals using the same tactics, workers
can impose consequences on their
employers for making unreasonable
demands.
The most drastic form of collective
action is the threat to withdraw labor,
a strike. The theory behind it in simple
terms is that collectively workers
demand that their employer materially
improve their conditions. This is a form
of sacrifice on the part of the
employer. If the employer does not meet
the demands of the workers, then the
workers can instead show that there are
potentially worse economic outcomes than
the sacrifice that is being asked of
them collectively. And and key to this
is that the workers show that they are
also willing to make collective
sacrifice. Withdrawing labor means
withdrawing the right to get paid while
they aren't working. And while they are
not direct parties to the dispute,
strike action creates inconvenience for
consumers of the business that is
subject to strike action. And this is
why workers need to educate the
consumers about the reasons for their
action and why demands are reasonable
and necessary. This builds understanding
and hopefully compels long-term
behavioral change. Performing your own
education is key because you can be
certain that the impacted employers will
spend money to make their point of view
known and you have to compete with that.
So it goes without saying that this sort
of action is devastating for everyone
involved. It demands sacrifice. It
hurts. It should only be used when
negotiations completely break down. But
the mere possibility of workers walking
off the job for their needs is a strong
signal that collectively workers are
willing to make sacrifices in order to
create consequences for non-compliance.
And so labor organizing is built around
solidarity, shared sacrifice, and using
inconvenience as moments to actively
educate the public so that they can
change their behavior to disincentivize
poor behavior by employers.
And so we have the Foss uh movement
which is made up of the free software
movement which believes that maintaining
freedoms of users to use their computers
without restrictions is key and the
open- source movement on the other hand
that believes that software produced
collaboratively has a distinct technical
advantage to software that is produced
in isolation. Both movements are
collective responses to power
imbalances. For free software, it's
against developers and distributors of
software who prevent users from
modifying or redistributing code. And
for open-source, it's against management
who prevent developers from releasing
code to be collaborated upon.
The success of both of these movements
depends on how its participants
organize. So, let's go through the
history of these movements with an
organizers lens. We'll start with the
free software movement and the emergence
of copy left. Free software is to put
very simply the philosophy that software
needs to be unencumbered so that users
may freely realize the full utility of
their computers. They argue that users
should be free to run, distribute, and
modify the programs on their computer so
that if a program does not do what they
want, they can modify it to do so and
share those modifications to help their
neighbor.
The free software movement thought of
the need to liberate software as a moral
imperative with proprietary software or
closed source software impeding the
utility of our computers and impeding
the ability of us to help our neighbors
realize the utility of their computers.
The early free software movement
produced two achievements. A technical
project called GNU whose goal was to
create a free software operating system.
That project largely succeeded in
producing free software tools for use
with the operating system but failed to
deliver the operating system itself. And
the more lasting achievement was the new
general public license which is a copy
leftft license. If you wish to modify or
redistribute software under a copy left
license, you would need to distribute
the source code including any
modifications that you make. A copy left
serves as a control on the production
and distribution side of software.
Developers can only use copy left parts
if their product is itself copy left and
distributors can only distribute copy
left software if they also commit to
distributing the source code along with
any binaries. Indeed, if the GNU project
in its formative years did all their
development behind closed doors, copy
left was a distribution tool to them. If
a distributor broke the license, then
GNU had the tools they needed to
penalize that distributor.
In his talk at Linux Confu 2017, RML
left given coined a term app freedom,
which is the argument that the freedom
to make your computer do what you want
is no longer dependent on having access
to the source code. As the means of
distribution of complete apps has become
more streamlined, it's just as easy for
an end user to swap one app for another
one that better meets their needs and
often for significantly lower cost than
finding someone to modify some free
software for you. In the world of app
freedom, that is the freedom to choose a
different app that meets your needs
better, free software becomes just
another option for a user to pick.
Indeed, people who decide to commit to
free software and only using free
software get less utility from their
computers than people for whom free
software is just one of a sea of
options. Take me for example. This is a
Mac. I could be using Libre Office to
write my talks, but I'm using Keynote.
If I bound myself to free software, I
could not make that choice.
And from an organizing perspective, this
is actually quite problematic because in
the labor model, workers, employees, and
consumers are made all to contend with a
moral imperative. In the copy left
model, only developers and distributors
are asked to reckon with the moral
imperative of free software. There is
nowhere in that model where users are
directly presented with a chance to
educate themselves as to why they should
care despite the movement being
ostensibly about user freedom.
So the Linux kernel was the first
massive open-source project to organize
itself online. This is before the norms
of sharing and communicating that we're
familiar with today were established.
Linux wanted developers to organize
under the same project. And copy left in
this example is a stick. It's a stick to
put to put the need to release source
code in terms that businesses
understood. You do it or you get sued.
But it also gives you a carrot. Most
large and longived code bases exhibit a
phenomenon that RML called
lithification, which is the tendency for
software to grow in layers upon layers
built on stable interfaces. If your code
targets an older and more stable
interface, then you have no incentive to
contribute it upstream. you can keep it
to yourself. This happened with BSD.
Linux in those days did not have a
stable interface and so it resisted
lithification.
If you wanted your kernel driver to keep
working, you really did need to have it
merged into mainline to ensure that it
did not suddenly break. So copy left
provided useful guarantees as well. If
you submit a patch to the kernel, you
are protected against someone using your
patch that you've contributed upstream
in an extractive fashion. If they
produce new software using your patch,
they have to release it as copy.
So the copy left side of the free
software movement made a tool that was
successful in compelling much of the
development and distribution side of the
industry to release software with its
source. And the consequence of focusing
on the supply side of the economy was
that there was no opportunity to educate
the user base. Despite the user focused
rhetoric, free software success was a
labor model for developers.
And what's fascinating about Linux is
that Linux Torvalds was a second
generation of copy left users.
He emerged independently of the GNU
project and instead saw that copy left
was a good developer focused tool to
ensure that all contributors fairly
benefited from each other's work. Now
Linux emerged in 1991.
But that year another notable thing
happened. The GNU project had got to the
point where they released enough user
space programs but they were ready to
release a C library which every Unix
system needs. But there were already
many C libraries out there and there was
no real advantage to making it fully
copy left. And so the result was a thing
called the library GPL or the LGPL which
is like the GPL in that if you modified
covered code you would need to release
the source code. But unlike the GPL you
wouldn't have to release the source code
of your own software that was otherwise
closed source. And this makes a lot of
sense for libraries that provide no
competitive advantage to the author.
In 1998, a group of people decided that
we should refer to free software as
opensource as a way to emphasize the
technical advantage that source
availability offered developers and
deemphasize the moral imperative. So the
free software foundation which remember
successfully created a model to compel
developers to produce free or now
open-source software but had no real
success in compelling user behavior
decided that the moral imperative and
user freedom should become their main
focus
and relatively soon after the rise of
open source as an alternative
justification for making source code
available the free software foundation
announced that they were renaming the
library GPL to the lesser GPL. L to make
it clear that not all libraries should
be licensed under the LGPL.
If you as an author want to encourage
more developers to release free
software, you should license your wares
under the GPL so that they can't choose
to use your software unless they use the
GPL. It was a very highly nuanced read.
It spelled out why you should actively
think about your license choices,
which was put under a headline, why you
shouldn't use the library GPL for your
next library.
And the result of this headline was
exactly what you would expect. Library
developers stopped using the library
GPL. However, the result was not the
mass migration to copy left that the
free software foundation recommended.
Because following the rise of open
source a few years earlier, we started
to see a new breed of open source.
Developers at product companies realized
that they could take advantage of the
technical benefits of open source and
would release parts of their web apps
under open- source licenses. This is how
we got Ruby on Rails. It was a byproduct
of a task tracking tool. This is how we
got Django, which was the back end for a
newspaper.
Product companies where they knew a view
of open-source as technically
advantageous realized the trick was not
to open source everything but to open
source the parts of their application
that offered them no differentiation.
If every web app needs to talk to a
database and produce forms then you
commoditize that code leaving product
developers to focus on what their
business perceived as its competitive
advantage.
In this business model, strong copy left
does not make sense as an option. And
that also assumes that developers are
even in a position to make the decision
to release as copy left in the first
place.
And so despite focusing their rhetoric
on user freedoms, free software's core
organizing model that is copy left
binding developers without that
mechanism to educate users, it saw a
real failure. These developers of of
Django and Rails and things like that
were users of open-source and they were
embarking on their first large
open-source projects. These developers
were not predisposed to free software
and free software had thrown away its
tools to welcome people into the
movement.
Weak copy left like the LGPL was the
exact copy left model that translated to
these new developers views of the world.
But with the official line being this,
then it's no surprise that people looked
elsewhere. Django, Rails, and basically
every major library to emerge around
that time used licenses that bind no
behaviors on the lency other than giving
attribution to the original developer.
These are the so-called permissive
licenses. And binding on licenses is the
stick in Linux's organizing model. And
these projects decided from the
information available to them that it
wasn't worth it.
And as for the carrot, well, the the
platform effects of GitHub replicated
for small projects at least the
collaborative effects of the Linux
kernel. If you host on GitHub, when you
fork a library, it's really easy to stay
in sync with mainline. It's trivial to
merge from external contributors who
make bug fixes. There are mildly
punitive behaviors that make it slightly
painful to make your code closed source.
GitHub charged a monthly fee to take
things private.
But the consequence of not participating
in GitHub's commons was inconvenience.
You either spent time or money. And this
is generally speaking enough to keep
most people in line. It does not stop
people with means from maintaining their
own closed source fork.
So by the end of the first decade of
this millennium, we really had the basis
for what we think of as open source
today.
The things that generate value or
represent competitive advantage should
be kept proprietary so that they can be
a source of revenue that others cannot
exploit.
Code that does not differentiate you
from your competitor should be open
sourced so that you can immortalize the
maintenance costs across your entire
industry and that you should use
permissive licensing because copy left
threatened your revenue and weak copy
was somehow inappropriate.
And so open- source code is not revenue
generating code. It is a side effect
with less need to be protected.
And so the model of open source that won
was simple. A commons was built out of
the code that did not constitute a
competitive advantage for its creators.
The code you develop uh you derive
economic benefit from would be
proprietary. Anything that's open source
is a side effect of production. And but
even though it's a side effect, somebody
still has to produce the code. And so
that creates perverse incentives, the
use of permissive licensing means that
consumers are released from all
obligation around the code. And so by
definition, any consumer of a piece of
open-source infrastructure is able to
gain more economic advantage than its
producer because they did not have to do
the work to create it.
And so when we emerged in the era where
open source had won, we had a free
software movement that was focused on
users that created no compelling reason
for for its users to participate.
But it did create a burden for
developers. And we also had an open-
source movement where businesses that
didn't write open-source infrastructure
were at an economic advantage to the
businesses that did.
just let you get that photo.
So that brings us to 2012 which is a
notable year because a bunch of
companies successfully sought venture
funding to produce open-source tools as
a product effort. This was a direction
that ignored the successes in open
source that had emerged the previous
year.
They didn't have the product revenue
streams of the open- source as a side
effect movement and they did this
without the tools to organize against
extractive behavior by organizations
that are not yet motivated to play by
the rules. The business model was to
release open-source code under
permissive licenses as their core
activity and then attempt to build value
added services on top of that.
What those services were actually going
to be was ambiguous at the time.
Hashi Corp started trading publicly in
2022.
That is, they had reached the limit of
what they could do with venture capital
and instead sought market validation for
their products and their business
approach.
And within a year, they decided that
they could no longer meet their owner's
metrics of success by releasing
permissively licensed open-source tools.
They relicensed all of their products
under a source available license that
locked out competitors. The industry and
then the market rejected their choice.
Their stock price precipitously dropped
and within six months they accepted a
buyout offer from IBM for less than
their IPO value.
And sure, businesses get acquired all
the time. But in this case, this created
n and a half years of noise, saying that
they could go it alone and make this
work, producing open-source software as
a business activity that they projected
as being sustainable before the investor
demands came home to roost. And there
are, of course, consequences to
accepting strings attached money. They
couldn't make it work. And as a result,
we've lost 10 years of success. Uh we've
lost 10 years seeing scores of
phosphocused startups founded by a meme
on the myth that merely receiving money
is all it takes to make a project
sustainable.
And this is what I mean when I say that
we're in a golden age. It's now clear
that we can't just find money by saying
that Foss is a product in and of itself.
We have to rebuild with new assumptions.
And it's still not completely clear to
me that there even could be a successful
business model built around open-source
as the product. Because as we've seen
over the course of decades, we as a
movement have made choices to reject
economic tools that give us a fighting
chance of being sustainable. Indeed,
we've seen that we've made a series of
choices that every time results in
producers of open source having to
shoulder a burden that is greater than
that of our consumers.
If our current model of open source was
a business, we would be spending more
than we're taking in. We would be
trading while insolvent.
And because we choose to not bind on our
users, we create a situation where our
users become our competitors.
Licensing without consequences makes us
complicit in creating competitors with
no external baggage. They don't have to
pay to maintain the software that
they're building upon. And so they can
focus entirely on building revenue
streams. You know, businesses, they do
what they're allowed to do. And so, if
we don't penalize behavior, they're
going to do whatever is cheapest and
makes them the most money. That's what
businesses do. And this is a problem
because as a movement, whenever we've
been presented with tools to organize
and ensure that extractive behavior is
not possible, we've chosen the more
convenient option without any
consideration of the consequences of
that choice. And the result is that open
source has no inherent reason to be
sustainable. And at least that's true
for any independent project that hasn't
chosen to organize.
Which leads me to talk about Kubernetes,
which is probably the biggest success in
corporate level collaborative
open-source since Linux. Unlike Linux,
Kubernetes is permissively licensed,
just like most open source tools that
are produced today. So, it doesn't have
the organizing benefits of copy. But
Kubernetes as a project still organizes
to ensure that businesses play fairly.
It just does it in a different way that
businesses understand.
Kubernetes is maintained by the
cloudnative computing foundation which
is a trade organization. This is
otherwise known as a 501c6 organization
which is a sort of nonprofit under US
tax law that allows member corporations
to work together to do work that
improves the conditions in which all of
them trade. Now that sounds a lot like
organizing.
The main thing that the cloudnative
computing foundation sells are seats on
their governing board which appoints a
voting majority of the foundation's
technical oversight committee. And this
committee sets the technical direction
for its projects including Kubernetes.
And those appointed members ensure that
the decisions are made in the best
interests of the corporations that
appointed them. If you don't pay to join
the foundation, you don't get a say in
the technical direction of the project.
and even worse, your competitors will be
able to make decisions in your absence.
Kubernetes has organized effectively.
This governance model is sustainable
because the stakes of not participating
for each individual member organization
is made in terms that these sponsors
understand and the proceeds of
sponsorship pay for things beyond just
governance. Some of the maintenance is
also paid for. The CloudNative Computing
Foundation is a properly successful way
for corporations to organize around a
permissively licensed project with
stakes far greater than we as small
project maintainers are willing to even
consider imposing.
And that's the thing like big tech
corporations that are extractive when it
comes to small and independent projects
organize when it's their own projects.
There are consequences for not
participating. the corporations that
should participate generally do.
And when you look at where corporate
money and support for maintenance is
going, it's not going to the projects
that fail to organize. It's going to the
ones where there is risk in not
participating.
Independent projects with permissive
licensing generates no risk. And if
there's no risk to extractive behavior,
they're going to keep on doing it. And
that leads us to the point we're at now.
We have corporates who understand and
have built structures around preventing
extractive behavior for the projects
that they contribute to. And because we
don't stop them, many of them continue
to apply extractive behavior.
So what do we do about it?
Firstly, we need to accept that the
tools that formed the basis of
organizing back when free software was
new have now been completely defanged.
The primary threat of copy was fear of
being sued by bigname copyright holders.
These days, the corporate stakeholders
in Linux use the same trade association
model as Kubernetes does.
Corporate contributors now have at their
disposal tools that are more useful to
them than the fear of copy suits. And
because we as a community of independent
developers have stopped caring about
copy theft, corporations aren't worried
about being sued by us and routinely
breach copy licenses.
The single most important test case in
copy left history is taking place in
California at the moment. Vizio is a
manufacturer that produces TVs that run
Linux and they failed to produce source
code when requested by users. The
developers who bind distributors to the
GPL have established standing in legal
circles to sue to enforce copy theft,
but it's not currently clear that third
parties have that standing. SFC versus
Vizio is a test case to establish
standing for third parties. If it
succeeds, then owners of devices with
GPL software can demand that software
like the licenses says say they can from
the manufacturer and they can make a
credible threat of legal action if the
manufacturer does not comply.
And from a right to repair perspective,
this would be huge. We would be able to
inspect and modify the software that our
devices run on. But from the perspective
of making open source more sustainable,
this achieves basically nothing. It
doesn't make a new funer of open- source
projects. It doesn't contribute
development time that would ease the
maintenance burden on Linux. It just
compels a TV manufacturer to do a bit
more inconvenient work.
And so while enforcement is entirely
necessary and I donate to conservies so
that they can keep doing this
enforcement work, the fruits of copy
enforcement are increasingly myopic. So
let me revise my statement. Licensing as
an organizing tool is dead. Licensing is
a way to get what you want through the
courts. So unless you have the means to
sue every non-compliant actor, licensing
will not bring about comprehensive
behavioral change. Any movement that
founds itself on license compliance is
going to be doomed to failure because we
as a movement gave up licensing as a
socially acceptable way for us to compel
non-extractive behavior. Extractive
organizations will not take organ uh
licensing seriously.
So what remains for us? The strike
action model asks us to consider what
we're willing to sacrifice in order to
show that we're serious about demands
that we have. Um what could work as a
movement? We've shown we're unwilling to
impose consequences in favor of growth
as a movement and we work in
environments where there is risk in
talking about impeding the revenue
streams of our employers or of our
sponsors. So let's look to labor.
Starting with solidarity and community
building would go a long way to making
safe spaces spaces for us to even start
talking about this. And we need to be
willing to talk about what sort of
consequences we can impose because not
talking about consequences is what got
us here in the first place. As a
movement, we're unwilling to impose
consequences for extracting behavior.
But we need to work together. If just
one project or one community support
provider continues to fail to impose
consequences for extractive behavior,
then that extractive behavior is being
allowed to continue.
And we've seen that the industry and the
market reacts really poorly to shutting
out bad actors with no remedy. If we
create a way to encourage organizations
to stop engaging in extractive behavior,
we absolutely need a way to bring those
organizations back in to engage in a way
that makes the projects more
sustainable. And this is one hypothesis
for why the market completely rejected
these relicicensing.
It locks out a potential revenue stream
or source of collaboration. Terraform's
selling point was that it is a better
way to deploy to AWS. So removing all
chances of them collaborating with AWS
was a terrible idea. The technical
outcomes of these relic licenses are bad
as well as being bad for the business
side of things.
So I entitled this talk the death of
consequences because free and open
source software is a movement that is
clearly not built on caring about the
consequences of our decisions. But not
caring about consequences comes with its
own consequences.
without questioning the basis on which
we're willing to work. Then the tools
for addressing sustainability
operate entirely within the framework
that we've laid out for ourselves.
Feeling confident about any funding
model requires us to ignore the
consequences that we've built into our
system. Every FOST developer that we pay
to produce software in this system
creates more software that can be
extracted.
And that's how I've reached the end of
the first age of go of open source. If
we want a second golden age, well, maybe
let's start by not doing it alone.
So, I don't have time for questions.
If you do want to chat to me about this,
have an argument, whatever, I will be
hanging around the back of the room or
in the hallway for the next few minutes.
Thank you. So, is this one? Thank you so
much, Christopher. What a compelling and
engaging argument presented. One more
time.
[Applause]