Okay, ladies and gentlemen, welcome to the first session on Sunday.
I think the title is self-explanatory, but Margaret is going to take us into detail on who
really pays.
Thank you.
All right, thank you, and good morning, everybody.
Thank you for waking up early for being here.
I think we are actually early, at least according to my watch, we are early.
So I expect more people will arrive that they are just cutting it very close.
Or anybody that is watching on the livestream or later on on recording, it's okay
that you didn't wake up early, it's very early, I know.
But yeah, thank you for being here, those that are here.
As it's very early, and I know many of you have not really woken up, let's start with some...
This is not working.
To turn it on.
Yeah, yeah, now it's working.
Yes.
So let's start with a show of funds.
So who here has ever contributed to open source bead with like a bug report, a batch, or a
feature, or maintaining a whole project?
Nice.
Yes, we are at first and we expect open source contributors here.
Now, who here is a core developer, maintainer, cometer, like you are really in charge
of an open source project?
Okay, yes, quite a few.
Now of those that just raise your hands, who of you does this on your spare time, your
nights and weekends, your time that is not paid by an employer?
Okay, quite a few again.
And if you just raise your hand, would you like to be paid for that work?
Okay, yeah, most of you, at some note, don't, and that's fine.
It's fine to want to be paid, and it's also fine to not want to be paid, right?
Like both, both things are fine.
All right, so before we jump into the talk a little bit about me, I'm Marga.
I'm originally from Argentina, but I've been living in Germany for almost 14 years now.
As a sign note, one of the reasons that I moved to Germany was so that I would be able
to attend for them, because coming from Argentina for just two days seemed like way too
much trouble at the time.
And I did attend for them quite a few times since then, but this is actually my first
talk at first and so, yeah, you know, it took me 14 years to make it on stage.
So, thank you.
Anyway, I've been using free and open source software for 25 years.
I've been contributing for almost all of those 25 years, and I've been a deviant developer
for over 20 years, so that's also very much part of my identity.
Professionally, I started work at a company in Argentina, where I was a system administrator
software engineer doing a little bit of everything.
And then, as I said, I moved to Germany to work for Google.
I worked for Google in the team that maintains the internal line of distribution that
is used by Google engineers.
And I worked there for eight years when I finally got tired of the corporate culture, I left.
I showed in a small open source consultancy called Kingfuck, where I worked on flat-care
container Linux.
It was really nice because it was a company that was all about open source, but unfortunately
it got acquired by Microsoft, so that was like the darkest year in my life, where I
worked for Microsoft for a year, but I didn't like it, it really was not for me.
So I eventually left Microsoft and joined ISOValent, which was an open core company in
the Kubernetes space, doing products like Silium and Tetragon, and I worked there until
they got acquired by Cisco.
And I was like, I'm not joining another corporate again.
So fortunately, I landed Egalia, which is also an open source consultancy, but in this case,
it's workers on open source consultancy, so yeah, no risk of being acquired.
All right, so why did I just go over my resume for you?
It's mostly just to give you an idea of the different things that I have experience.
I worked for big companies, small companies, I worked for product companies, for consultancies.
So I kind of seen a bit of everything, of course I haven't seen absolutely everything
that is out there, but I know how it is to work in open source, in different spaces.
So this is kind of like the basis that I'm using for the rest of the talk.
All right, now that's it about me, let's now talk about the problem.
Why did I think this was an interesting topic to talk about?
The problem or not problem starts 40 plus years ago.
So when Richard Stanna created the GNU project, he was creating a project for a small group
of people.
There were about a thousand nodes connected to the internet, the people that were participating
in the movement where sending software via tapes or disks.
They were not downloading it over the internet, and everybody that was participating
was very much an enthusiast.
By 1991, when the GNU scanner was published, there were already around a million nodes connected
to the internet.
So a lot more people were able to participate, but these people were still using use net forums
and downloading software via FTP.
So it was still very much hacker culture, right?
There were geeks, there were people that either knew what they were doing or at least they
were willing to learn to be able to know what they were doing.
And the expectation was that if you were using free software, you were also contributing
to free software.
It was a given, right?
Like, a user and a contributor were the same thing.
Now when we reach current times, this has gone up a lot.
And actually this graph is from Wikipedia, and it's weird that it cups at like 1 billion
nodes.
I've been pondering why it cups there.
I guess it's like most of the nodes are no longer connected to the public internet and
are actually behind proxies and so on and so that's why this doesn't keep going up
because we know that there's more and more devices connected to the internet today.
But that's not relevant.
The relevant part is that open source, unfree software has reached basically everybody, right?
It has expanded together with the internet.
And today you can download thousands and thousands of open source projects from the internet
without ever having to interact with the containers, with the developers of the software,
right?
And there was actually a code audit recently that found that 97% of the software that was
audited has at least one open source dependency.
Basically open source is everywhere, right?
We could say that open source has one, right?
Woo!
Yes, we have one because we are everywhere.
But has it really one when like all modern digital infrastructure depends on the projects
and random person in the vraska is thankfully maintaining in 2003?
Probably not.
And yeah, so no talk about open source sustainability is complete without this awesome comic
from its KCD.
But I do want to know that this comic only shows like one problematic piece and in reality
we have a lot more, right?
This is actually better than our reality.
So open source has one in the objective of being everywhere.
But we have not one in making this a sustainable model that can survive for the future.
This is the part that we need to rethink.
So I've been thinking about this for a while.
Why is it that we are in this conundrum?
And one of the things that I've been thinking about is this illusion of free on the internet
today we get a lot of things for free.
We get a web-made client for free, we get a search engine for free, we get social media for free.
And why is it between quotes?
It's been three quotes because we all know that this is not really for free.
We pay for this by having to see ads and by having our data scraped and sold and bad things
happening, right, without data.
So it feels like it's for free, although we all know that it's not for free.
Because we know it's not for free, we actually demand quality out of this product, right?
That we get for free because we know that companies like Google and Meta are making money out of this product.
And if they are making money, they should publish good products, right?
This is how our minds operate.
And this that makes sense for Google and Meta and other big companies does not make sense.
For a maintainer that is doing this during their nights and weekends, right?
And so this what we get for free is not always the same.
But it's not easy to differentiate between one and the other.
And you all that are here today probably can't tell the difference.
But people that are not involved in the freeze-over movement,
it's a lot harder for them to tell the difference.
And so what happens is that people get in title and they feel like they have the right
to demand quality out of these free things and they are not all the same.
So then we come to the problem of users becoming consumers
that demand quality, the expect service level agreements,
accountability, security fixes, without giving anything back, right?
And I'm not talking about any of you today here that woke up very early to be a twosom on a Sunday.
I'm talking about the companies that are getting rich out of the immense value that has been created
by the open source movement and don't give anything back, right?
Companies that just make money, but don't give back with contributions,
don't give back with donations, don't give back with employing free software containers.
So this all taking and not giving back is creating the problem that I'm talking about today.
And the problem that it's creating is the burnout of containers.
So there's this quote that I found on an article.
I found this article after I have been thinking about this for a long time and I found this article
that talks about the same things. So if you're interested, I would really recommend reading it.
I'll read this quote aloud. The risk of burnout increases when there is an imbalance
between the energy or work demands of us and the resources are available to replenish it.
So burnout is not just having a lot of work to do because if you are motivated and if you feel
like you are replenishing your energy, you can do a lot of work and it's fine.
The problem is when that work that you're doing does not then translate into satisfaction, right?
If you're satisfied with what you're doing, if you have the time and the space to replenish your
energy, it's fine. But when you don't, that's when burnout occurs. So this article,
it was written by a psychologist or sociologist, sorry, something like that.
Identified two major contributors to burnout in open source developers.
The first is developers struggling to make a living and the second one is the toxic behavior
from the community members wearing developers down. So to me, these two reasons, basically,
are based on the same root cause that I was mentioning earlier. The members of the community
are the users, the consumers, that are demanding too much from the developers without giving
luck, without even thinking the developers, right? Like, lots of developers feel like they need
to keep doing the work, but they don't feel like this work that they are doing is appreciated
by the people that are actually receiving all of this value.
And one thing I'd like to highlight is the fact that you can download the piece of software
for free doesn't mean that it doesn't have value, right? And I know all of you probably know this,
but it's also easy to forget. It's like, you download something, it's free and it's easy to forget.
How much value is in that? All the hours, all the effort that was put into creating and
maintaining the piece of software has a lot of value. And it has that value, even if it's
like completely open source, even if the person that did the work did it all in their spare time,
it still has a lot of value, right? It's a valuable piece of the world. And again,
I know we all know this, but it's important not to forget it. And so the next step is to stop
framing maintenance as more of it to you, as like, oh, it's the right thing to do, right?
You created this piece of software and it's now used by hundreds of thousands of people.
And yeah, it's the right thing to do. You should continue doing it for free and you shouldn't
complain because you know, like you want to make the world a better place. So yeah, if you
need to stay up all night fixing that security bag and yeah,
nobody's going to pay you for that, but it's the right thing to do, right? So you should keep doing it.
So that's not healthy. It's fine if this is something that you enjoy. If this is your passion,
if this is something that you'd like to do, yes, that's great. But when it becomes a
nobligation that you have to do out of guilt, then it's not rating more. And then it's when
it leads to burnout, right? And so we need to stop thinking about this like the right thing to do,
and thinking about this as work. And it's great if you like to do this work, but it's still work.
And another factor is the maintainers are treated as vendors. And this means that companies feel
entitled to send them an email saying like, oh, we need to now have compliance with our procurement
of software and we need to know like all the dependencies, what security measures they are taking.
So why don't you tell us what are the security measures that you're taking? These are emails that
people have actually received like free software containers that are paid 0 cents by these companies,
and they get emails from companies asking them to like do some kind of security audit.
Who gives you any right to send me these emails, but they send the emails, right? And
the maintainers don't have any kind of protections. And we all know that the licenses say,
well, these comes with no warranty, right? Yeah, sure. It comes with no warranty.
But companies can still send you these kind of emails, and it's not nice when you are under this
kind of scrutiny. In particular, if there is some kind of security vulnerability in your software,
it can become a lot of pressure from some of these super-entiled companies.
So what happens if we don't fix it? Well, if we don't fix it, there's likely a lot of people that
will learn out, a lot of people have already burned out. And what happens then is that this critical
dependencies, this piece is that we talked about in the XKCD comment, get unmanned. And anything
that can happen, right? Like there can be security vulnerabilities, there can be all kinds of problems,
incompatibilities, and if we don't take care of our maintainers, they will not be able to take care
of the software. All right, so and the other part of the talk is money. So how do we make money with
free software? This was actually one of the first questions I had when I first learned about free software
back in the year 2000. I was like, huh, and how do you make money out of it if you give
this software for free, right? And the answer to that was, well, you charge for features and support.
And surprisingly, or maybe not surprisingly, that's mostly the answer today. Still,
25 years later, 26 years later, that's still the answer today.
And so yes, as I said, like, I work at the consultancy, and this is what a consultancy does. So yes,
you can charge for features and support. It is a thing, but it has a bunch of problems.
One of the problems is that someone has to pay the development cost upfront,
because most customers are not willing to say, oh, well, we want this piece of software.
Yeah, you can develop it from scratch, and we will pay you to develop it from scratch.
That it's very hard for that to happen. Instead, what happens is that someone, it can be you,
or it can be someone else, right? Like, you can give support and develop features for software
that someone has developed. It's fine. That's part of the open source model. And so someone
has to have paid that development cost first. And when I say pay the cost,
like, if you are developing this software in your nights and weekends, you are paying the cost,
right? You're paying the cost with your spare time and your spare energy that you could be
using for something completely different. But you're using it to develop this piece of software.
That eventually, you will be able to sell support and new features and so on.
But you're paying that cost. So someone needs to pay that cost upfront. And it's part of the
this charge from features on support. It's part of the model. Yeah. Well, first you pay that
cost upfront. And then you can charge for features on support. Then the next problem is that
it's hard to get steady income. So if you're charging for features, once you develop the feature
that feature is finished, and you need to find the customer willing to pay for the next feature.
If you are charging for support, that's better, right? But you need to get enough customers that
are add up to the containers that are supporting this software. Because customers are
unlikely to want to pay for the full cost of developers, all the developers needed to support
and keep maintaining the software. And finally, it's one of the first things that get cut.
So if the customers for any reason are in a less good financial situation,
it's very easy for them to say, oh, yeah, we have this support contract for this free software piece.
Well, yeah, it's free software. Let's just not keep paying this support contract anymore.
So yeah, that's like this works, but it's not easy. So of course, this is like a lot of people
have realized that it's not easy. And a lot of people have tried to do business around free software
and they found that it was a lot of work. So instead of doing that, they have come up with another
model, which is called open core. So I haven't let you alone for a long time. So let's now do a show
of hands. Who knows what is open core? All right. So most of you, but not everybody, I'm surprised.
I thought it would be more. Anyway, so open core in brief is publishing some pieces of software
as open source, while keeping some other pieces as close source and charging licensing cost for that
other piece. There is a spectrum of open core. Not all open core software is the same. I heard
someone say shit. And yeah, I mean, open core is not open source. There is a spectrum. Some,
some open core is kind of like weight, right, that you're like hooking your customers into
the open source piece and then reeling them into the enterprise version. But other open core
is a lot nicer, where you could say, well, the open source version is kind of like the free
for all weighting area and airport where the enterprise version is the VIP lounge where you have
amenities and it's nicer, right. And yeah, and there's a lot of things in between. But the point
is that the closed source version is not open source. And the company is paying for the open source
development with the licensing fees that it's getting from the known open source. But.
So I thought it would be interesting to look at the projects that are part of the CNCF
landscape for those of you that are not in the Kubernetes space. The CNCF is a foundation cloud
native computing foundation is a foundation inside the Linux foundation. And it has this like
category of projects and you can be like incubating and and sandbox and graduated. So these ones
are like the incubating and graduating graduated project of the CNCF landscape. And so I went through
all of them to find out which ones were open core and which ones weren't. It took me a long time
to do this. The whole train ride from Munich to Brussels. Anyway, so I found out that this ones are
the ones that are open core. At least I could find that they were open core. It's not easy to find
this information. They it's not like they say, hey, we are open core very big. You have to like
dig in. Anyway, I thought it would be more, but still quite a number of them are open core.
And then this ones were donated by companies that were using them for something. It could be that
they did it like as part of their infrastructure or they did it together with some other
customer and so they did some project and they created this thing and then they donated it
to the CNCF. And these are like a bunch of very different companies. It includes companies like
Google and Red Hat, but it also includes like Spotify or Lyft or Alibaba. So one. And then the others,
the remaining ones are the ones that were developed by the community. So I think this shows a little
bit of the who pays the up from cost, right? Like even the blue ones, the ones that were donated
by companies, the up from post was paid by companies. So it's hard for the community to develop
things. And I know there might be errors here. I did my best, but it's not super easy to find like
all the information. Anyway, this was kind of anic data. And now for a different kind of anic data,
there's a hashic or terraformed snafu. So show of hands who knows what this is about.
Okay, not that many. Less than who knew about open core. All right. So on August 2023,
hashic or announced that they were moving all of their projects to this business source license.
For those that don't know, hashic or you used to have a bunch of open source projects,
like terraformed and vault and a bunch of others. And at least to me, hashic or was an example
of a successful open source company. They were doing open source and they were successful.
Until they paid this. They switched to this bustle licenses that is not open source, right?
It was a license that if you were an individual using terraformed, you were fine. But if you
were building products on top of terraformed, you had to pay them. And of course, they were going
after the big fish or we don't know. But we expect that they were going after the big fish,
but in their going after the big fish, they also went after the small fish as well, right? So
they were affecting everyone that was using their product. And this was done after, oh sorry,
this was done after 10 years of having terraformed be open source. So a lot of things had been built
on top of terraformed. A lot of companies were building products on top of terraformed.
So what happened was that this company said, well, no, we are not going to pay to this bustle
license. And so they got together and they created a fork that they first called it OpenTF,
then they called it Open Tofu. Then they created this open fork. Not only is it open source,
but it's also open governance. So it's really a community-based project that is not controlled
by one company, but like many companies are contributing, many people from different places are
contributing. And what I find the most interesting from this story is that when they started
several companies committed to donating the time of their employees to this project, right?
Like they committed to five years of five employees or three years of three employees. And so on.
So they, they were willing to spend a lot of money because like five years of five employees,
it's a lot of money. They were willing to spend a lot of money on keeping this project open source.
They were not willing to pay Hashikorp for this. But so that's one interesting point.
And then the other is they had not done this before, right? So when this minutes of the project
going away appeared, then they were, yes, we are contributing our employees, but not before when
it was owned by Hashikorp. So I don't know, I think all of this is kind of interesting.
Okay, so we talked about the traditional, the open core, and now I'll just cover a few other
options. There's a bunch of them. So one option is to turn to donations. So there's a bunch of ways
you can ask for donations. One option is the GitHub sponsor thing. So if you are on GitHub,
you can just say that you want to receive donations. And then if, as a dependency, so someone
that is using your project goes to GitHub, they can check all the dependencies that are open to the
donations. And they can say, oh, well, okay, so I have these 10 dependencies that are open to the
nations, I will donate one URL per month to each or whatever amount, right? So that's one thing.
And GitHub claims that they have distributed $40 million using this. So that's good.
Then another option to ask for donations is through open collective, which is a platform that has
different hosts that have collectives. It's hard to get all the terminology right, but yeah.
So the open source collective, which is one of the hosts, has 2692 collectives. So a lot of collectives.
And then the open collective Europe, which has open source and other things, not just open source
projects, has like 400 more collectives. So all in all, it's a lot of collectives. What are these
collectives? They are projects, right? Different projects. Like for example, oh, yes, the video
system is there. And you can say, okay, we want to develop this feature and you can participate
in the crowdfunding campaign to get enough money to develop that feature. Or you can say, well,
subscribe to us. And then I'd like five euros per month. And then, like, if enough people subscribe,
then that adds up to someone's salary, right? And it's great, like seeing the list of projects
that are available and seeing the projects that have received donations, that's great, it's like,
I think, no, yeah. It shows that a lot of people are actually donating and helping this projects
be successful and helping employ developers like this projects when they reach enough money,
they can employ people to work on this. And that's great. But also, it requires you to be
asking for donations and constantly saying, hey, we have this page, please donate. And we have
this campaign, please donate. So, like, it feels a little bit like begging, but it's working,
at least for some projects. Another option is to go the route of government funding.
So, NLNet is one of the organizations, not the only one. So, one of the organizations that
distributes money from the European Union's next generation internet program. So, that's like a
big pot of money. And you have to go through a lot of bureaucracy to get that money. So, NLNet
and the other organizations that do the same facilitate this. They do most of the paperwork and they
select projects that are going to receive the money. And then they give them the money and
they take care of most of the bureaucracy. According to the page, the last time I saw it, like
1,500 projects, 1,500 plus projects have received money through this way. And these are
some of our large projects and well-known and some are not well-known projects and small projects
that have proposed to do something that was deemed useful for the world. And so, they received
this grant. The grants are usually not very big, but they can help a project that is struggling.
They can help a project to get something done and get more features. In general, it's about
developing new features or even new projects. It's not about maintaining existing software.
Another government funded way of getting money is the summer intake fund, which is part of the
summer intake agency. It's from the Sherman government, but actually they are helping maintain
the digital infrastructure around the world. So, it's not just for German projects or German
developers, but rather for the projects that make up the digital infrastructure of the world.
So, they are set on making this situation that we are talking about better. And in the case of the
summer intake fund, they're actually paying for maintenance. So, not for new features, but for
keeping the projects well maintained. And in general, they are paying to larger
projects. Yes, okay, that three was over something. All right. So, I was saying, in general, they pay
larger projects. Okay. And finally, the last alternative that I want to mention is the open source
pledge. This is something that started a couple of years ago and I find this initiative very interesting.
So, the pledge is basically saying, we as a company, like, comment to the 19 2000 dollars per
developer per year, two open source. And the companies can choose who they donate to and how they
donate to. And the only thing that they need to do is donate at least 2000 dollars per developer
per year per year. Some companies choose a bunch of projects that they depend on and they donate
a little bit to each project. And some other companies, I've worked like the project of the month
and they donate like a big amount of money to a project each month, depending which one was the
project selected that month. But yeah, in the end, it has to add up to 2000 dollars per developer
working at the company per year. The goal of the open source pledge is to establish a new social
norm in the tech industry of company Spain, open source containers so that burnout and related
security issues can become a thing of the past. So, in the abstract of my talk, it talked about
acid time for an open source tax. And this is sort of like an open source tax, except it's voluntary
and the company is the site who they donate to. So, it's not really how a tax would work because
if it's a tax, everyone pays the tax and someone decides where the money goes. Well, this is kind of
like you decide your own tax. All right, and finally, I feel like probably the most common way
of making money out of free software is to be employed by a company that does something else
but pays for open source developers. And I know a lot of people that are in this situation that
they are working for another company for a company that is a for-profit company, but that some
of their time is allocated to working on open source. It could be 20%, 30%, 50%, but to the company,
it's a win-win situation because they are paying for the maintenance of this software that could be
like a dependency or tool. Of course, I'm not talking about like the main core business of the company,
the company should pay the developers working on its main core business, right? But like
a dependency or a tool that the company is using and they give the developer the time to work
on this tool and at the same time, they are getting the expertise of this person that can help them
with whatever it is that the company does. So this is also a very common model of making money
if you are a free software developer. All right, so we've seen a lot of different ways of making money.
Is this enough? Is this enough? Not really, not really, it's not enough. It's not enough.
All right, why is it not enough? No, no, you, I'm not asking you to answer. So it's not enough.
It's not enough for many reasons. One of the reasons is like it's really complicated, right?
Like you need to set up a collective and ask for money or you need to like run the grant application
and when it runs south, like you need to correct the new grant application, which is kind of like academia.
And it's, it's still complicated. But also, it's not steady, right? Like it's, it's really hard to
make this. Let's say, okay, when you have a job, you have a job and you work on it and you get steady
income. But all of these that we have been describing, it's, it's really hard to make it steady.
But that's not the only reason it's not enough. And I want to propose here, uh, perhaps a controversial thing.
Which is that this, everything that I described is about paying senior developers that are already
maintaining core pieces of infrastructure. And of course, we should pay that people, those people, right? Like,
for sure, I'm not saying we shouldn't. I'm saying that's not enough. Because if you only pay senior
developers that are already maintaining core pieces of infrastructure, you're not giving space for
people that cannot afford to work on open source in their nights and weekends, right? Being able to do
a second show for free during your nights and weekends is a privilege. And it's a privilege
that a lot of people don't have. In particular, women in the world, still today, are disproportionately
in care, in, in charge of care taking responsibilities. So that's like, for many women, that's their
second show, right? And thus, when you only pay senior developers, you're not making space for
all of these people. So I know this is controversial, but I just wanted to plant the seed there
of this idea. But now, I want to imagine a better world. And I want to imagine a world where we
have teams of people that are paid to work on open source of work. Some are senior engineers
and some are junior engineers that are coming up to speed and helping the senior engineers
helping them with, like, bug reports or documentation or whatever tasks the senior engineers don't
feel like doing. And so that eventually they can take over, they can create their own
projects and be maintainers and so on. But also, like, all of them are paid a steady salary if they
want to, right? This is the utopia that I like all of you to think about and think that this is
possible, right? And you can say, well, but that's too much of a utopia and like, no, that's not really
possible. But like, think back to, like, when in 1984's Dalman created a new project
and the situation where we are today that we should say, like, 97% of software depends on open source,
right? Well, today, we would already be in utopia, like, if you were back in 1984. So it's good
to have a goal. And I think that's the goal that we should have that everybody that works in open
source should be compensated if they want to, right? And I think they're still a great place for
volunteer work. I'm not saying, oh, no, there shouldn't be volunteers. No, volunteers are super necessary.
But if someone wants to do it as their full-time show, they should be able to do it. And that's the
that's the utopia that I want to to plant. So some ideas to make that possible. I'm first
on foot and then some ideas. First, remember that open source is already making the world better
today that people working in open source are adding a lot of value today. And so people working
in open source should be able to do it as their full-time show if they want to, right? Because we
are adding a lot of value. It's not that we are begging for scraps. It's that we are asking for
people to be fairly compensated for all of the value that is being added. All right. And now,
some practically, yes, perhaps not so utopic. First is about companies giving back. I think the
open source pledge is a great idea. This thing about it being sort of attacks, but with total freedom
of who you are donating to. So if you work at a company that uses open source and hasn't signed
the pledge, I invite you to talk to the management of your company and ask them to consider signing
the pledge. And donating this $2,000 per developer per year. And if they say no, well, maybe
donate a little bit less, right? $2,000 per developer per year may be too much. If you are
in a country where that's a lot of money or if the company is not making that much money,
whatever, but something. It's good to start with something. You will not get the batch of like we
are in the pledge, but you can still post a blog about the donations that the company is doing for
open source. And that's still good. And if possible, I would advocate for donating a steady
amount every month, rather than big lumps of money to different projects. I getting steady income
is more important even if it's less. Now, the next one is a little bit controversial, and it's
about foundations employing developers. And it depends on the foundations, some foundations are
already doing it. And it might not be controversial, but other foundations are not doing it. And so
it might be controversial. But I want to invite all of you if you are part of a group that is not
employing developers. And it's receiving donations, right? Like if you are in a foundation that
receives donations and it's not employing developers, start to explore this subject and start to think
about how could we make it work? How can we employ people and pay them for their job without
discouraging volunteers? Because that's the problem, right? Like if you pay someone like are all the
other volunteers going to say, oh, I'm not going to do it anymore because he's paid and I'm not paid.
So yeah, I'm out. Okay, we don't want that. So we need to start thinking about this and start thinking
how we can make it work. I don't have the answer, but if we stop from having the conversation
because we don't have the answer, then we are never going to reach the answer, right? So please start
this conversation at whatever organization you are in. And yeah, finally I have this other idea,
kind of crazy, or maybe not so crazy, but there's the open source pledge. So I'm proposing the open source
employment pledge, which is, well, if you are not willing to demand money, maybe you are willing
to donate a time of your employees. So every 20 developers in your company, 50% of one person's
time goes to them developing open source. And that 50% is like completely free of company influence,
right? It's not like, oh, you work on this project, but we tell you what to do. Now, it's 50% of
their time for maintaining the project, however they see fit. And so, and if the company is not willing
to pay money, but they are willing to do this, that's an option. I have not created the website.
You are all, like, whoever here feels the initiative to create the website, you can go and create
the website. You have my blessing. I'm finally, I'm a big advocate for teams. So I feel like,
if you are a solo maintainer and you are feeling a lot of pressure from keeping up with your
project and you can't do it anymore, it's time to show up with other people and like help each other,
right? When you need to take some time off, someone else can take over and when that someone
else needs to take some time off, you can take over. So I want to invite you, if you are a
solo maintainer, to try to find other people in your space and form a team. I'm a big believer in
teams. All right. And with that, I'm done with this talk. Thank you very much.
Thank you. I think we have, like, two, maybe three minutes for questions.
So if there are some questions.
So good morning, everybody. And thanks for this marvelous talk. I think for us,
there needs this kind of talk some more than many others. So, thank you for your presentation.
And I don't have to be brief, since I've plenty of notes about this. So first of all,
voluntary text is there is not such a voluntary text. We need some unvoluntary text,
particularly for big companies, since the positive externalities are so high. And this is a critical
infrastructure, I keep it on time. It's a critical, such a for humanity, okay. We cannot
flee for money, like road maintenance do not, do not back, okay, for money, okay. It's like
road maintenance. So we need something more effective. And I think it's high time, not for reasonable
proposals, but for unreasonable concrete proposals, like the part of Texas. So this is
like irreseeable, defective company should believe or for this kind of stuff, but I think
you want to go in the direction. So this is the first point, second point. One second, one point,
at least one point. To me, your talk resonates so much with feminist theory, for instance,
the difference between productive work and liberty work. And we need as developers to organize
sorry, do you have a question? One second, one second. If it's more of a statement than a
question, stop with your own talk. Any actual questions, please? No, no, sorry. All right,
sorry, we can keep discussing, somewhere else, where should we go to keep discussing?
Thank you, Mark, a great talk. Carry on the conversation after it.