All right, hi everyone. I'm Vlad. I'm going to talk about why and how companies should pay open
source maintainers. We'll get into that. So first of all, I'll just give you a little
tiny bit about myself. I work on software and philosophy, the contributes, and some
way to the public good. Right now mainly working on the open source budget on thanks Dev
and you're going to find out in due time what that is. I'm also doing a PhD at the University
of Edinburgh and the philosophy of the exploitation mainly, and we'll see how that sort of ties
into it. In case anyone's interested, I'm also a cat sitter. So, you know, come up to me. Let me know,
you know. All right. So here's a general, the general just of what I'm talking about. I just want to
talk about a couple of sort of ideas and also technologies that we might be able to use to make the
open source ecosystem more sustainable. However, these are just some ideas that I'm keen to discuss them
with you. I don't have all the answers, it's just that we have to really make more progress with
this stuff because it's important. So, you know, almost all companies, you know, measurements
vary, but almost all companies these open source software. Cat would occur that, you know,
that this great article a while back and he said that, you know, he approximated that open source
software creates around $850 billion dollars a value yearly. And, you know, if we didn't have
critical open source software, we can watch YouTube videos without, like, FFMPEG, you know,
you can use your phone to talk to your friends and family, you know, can get your medical records,
certainly can go to Mars, right? Never the less. A lot of software is kept going by unpaid
maintainers. Here we're seeing a tweet from FFMPEG saying, you know, our software is using these,
like, incredibly critical applications. And we just don't, you know, FFMPEG does get some grants,
but we just don't get paid by the corporations that get a huge amount of value from our software.
This becomes a problem when we look into things like security issues, right? So, if this opens
or software that we rely on so much as vulnerable, it can lead to really bad stuff when it's a
huge part of our global supply chain. And so we saw some close calls with FFMPEG, with log
for show, these are vulnerabilities, you know, just exit utos if you're not familiar, you know,
hugely important open source project, the maintainers kind of doing an enormous amount of work,
gets burned out and says, hey, can someone help me maintain this project? Someone shows up and says,
sure, I'll help you. But they're about guy and they, you know, introduce this awful exploit into this
thing that everyone uses. So that's scary. The reason this is a problem for suit for sustainability,
when it comes to ping maintainers is that, you know, maintainers need to pay rent. If you don't get paid,
it's very difficult to dedicate time to justify dedicating time to these projects that are often a lot
of work to maintain. And yeah, that puts, you know, it's not very nice for the maintainer and also
it puts a project they maintain at risk because, you know, there might not be someone to maintain it.
It might be improperly maintained and so on. All right, why don't maintainers get paid? Now,
basically, you know, money gets exchanged on the market, the market's exclusionary. So if you come and
stay in my hotel, I will say, hey, you can stay in my hotel. If you pay me, you know,
whatever the fee is, if you pay me a hundred dollars. Now, that means that I have to withhold
what I'm making or what I own until you pay me an appropriate amount of money. Of course,
I could just give you the hotel room, but then that wouldn't be a market transaction and it's
not usually how it happens. Opusers software is very much not like that. Some might say the
whole point of Opusers software is that it's not exclusionary that, you know, you have the right
to sort of redistribute and use and change in all the software, but also, you know, you know,
you're not supposed to stop anyone from having those freedoms, right? So in a sense, it goes
counter to the market. Problem is, you pay rent on the market. So, uh-oh.
Now, I want to talk a little bit about what Opusers actually is if it's not sort of part of the
market economy in that sense. You know, some people say it's a gift economy. I think, you know,
maybe, uh, but, you know, I don't think it's a gift economy right now. Okay, what is a gift economy?
So a gift economy, um, in a gift economy, what usually happens is goods get exchanged, um,
in sort of, well, I have a list here. It's sort of a directed and personalized way, right? So I give
you something that's sort of symbolic of my relationship to you. There's some kind of expectation
of reciprocity and that sort of maintains our relationship with our exchange. Um, that's not really
how things happen in Opusers, especially because, you know, when you create Opusers softer,
you're not giving it to a particular person. You're not saying, hey, I made this for you. Here's my gift
to you. Um, you know, it could be something like that in the future, but that's not really what's
happening right now, missing reciprocity. Um, and then the other thing is, you know, some people say,
well, you know, it's based on a steam. There's for sure a component of esteem and Opusers software,
but it's not really the case that it's a sort of exchange of esteem. Like, you know, I don't
give you the software, and then I get esteem and return, and that's it, right? There's many
reasons why people create Opusers software beyond esteem. Um, now you might say,
if you're Adam Smith, you might say, well, you know, what, well, why would anyone make Opusers
softer in, you know, in this case? You know, it's not from the benevolence of the butcher, the
brewer, the baker that we expected, the neighbor from the regard to their own interest. And,
you know, that's you obviously people are not irrational in that since people who make Opusers
software do get something out of it, obviously. Um, and so, you know, some people say, well,
you know, this is contradictory, right? Because if it's not an exchange, what are you getting out of it?
So, I guess what I'm saying is you might be getting something out of it. It is just not an
exchange. You know, you're not getting something from sort of a direct transaction in that sense.
And again, this is sort of an idea that I'm happy to sort of continue workshopping, but I think
open source production might be something like solidary meaningful work. Because you get,
there's a lot of goods that we get from work that we don't get from the transaction itself, right?
So, what I mean by solidary is, you know, it famously opensource developers like scratch
their own itch, and so, you know, you might be using a piece of software, and then you realize
that there's something missing, and you create a big, you know, you create that sort of feature or
whatever, because you would like it. But also, I think there's this component of, you know,
I wish we all had this thing. Here's something that I think is important. Wouldn't it be nice
if we all had it? And, you know, I would like if also other people worked in that way,
so that when there's something that I'm lacking, someone else can step up and help contribute that.
So, in this sense, I think it's solidary. And I also think it's meaningful, you know, this is a
long list, and I'm not going to get into it too much. But basically, there's all sorts of things
that we get from work aside from, you know, the money. We get autonomy, so the ability to create
something that's self-directed, and then we put ourselves into, you know, self-development developing
your skills, making some kind of social contribution where you feel like you're helping others
around you, you know, getting purpose, you know, something to sort of make you get out of that.
And then, of course, of course, the recognition. So, I guess the sort of point I'm trying to make here
is I think there's a lot of goods that people get from open-source production other than
sort of exchange, you know, goods that are exchanged. Now,
some might say, well, you know, cool, it's solidary meaningful work. Doesn't that sound nice,
but you're not going to get paid because that's, you know, not, you know, we don't pay people
based on how solidary meaningful their work is. Okay, you know, that there's a point there.
Thing is, obviously, there are good reasons, you know, you can't just say, well, all those open-source
people, you know, we should just sort of put them in companies and pay them if they want to get paid.
I think there's good reasons to produce software in the way that the open-source ecosystem produces it,
even if it means that sort of currently that is incompatible with the market.
You know, obviously, you get a much larger base of contributors. So, you know, there's only so many
people in a company. There's only so many people you can hire. And there's a high transaction
cost associated with that, you know, there's friction there, whereas when you have an international
base of contributors, transaction costs is very low. Anyone can help and often that means
that someone who's very specialized in the thing that's being built is the person that steps up to
do the work. And this doesn't happen. So, well, you know, it happens sometimes, but it's much more
difficult to transaction costs as much higher in companies. There's massive deduplication of work
for some things. Obviously, there are some things that we produce. There are specific to a
certain firm, a certain product. There's so much stuff that is, you know, used by a lot of different
companies. And so, if they all were to produce that separately, that would be extremely inefficient.
So, that's a good reason to do things in this way. And again, this is really tied to the
economics, right? It's difficult. It's more difficult to have this deduplication of work if you
have the high transaction costs of having to, you know, hire people and so on. And, you know,
so you're more, a more minor point, but in a lot of open source projects, the fact that
production is done in an open source way means a production is much more responsive to user needs,
because in open source production often, the people contributing are also users,
and so they really understand how the product works as opposed to, you know, a developer in a
company who might not be using the thing that they're making. So, they understand it from the user
perspective way less. You know, so this is not just me saying it. This is also Microsoft in 1998.
It's saying commercial quality can be achieved or exceeded by open source software projects, right?
So, this is sort of a thing that's acknowledged. Now, taking all of this into account,
nevertheless, maintainers are in getting paid. Why should companies specifically pay maintainers?
And I have sort of two main arguments. The first one was a moral argument, and this is more
sort of an invitation for you to think about that then anything else, right? You know, we can say
that open source software is a digital public, what does that mean? I won't get into the weeds too much,
but, you know, we have sort of free main things. If you work on curl or, you know, substitute,
you know, curl, I'm just saying like a really important open source package. If you make an
improvement to curl, everyone in the world benefits from it, right? To different degrees,
but everyone benefits. Crule is non-exclusionary in that I can't, you know, stop you from using
curl, I can't take curl away from you, you know, it's open source. And it's also non-rivalrous
in that if I use curl, there isn't less curl for use. For example, if I do a lot of fishing,
and I take a lot of fish out of the ocean, there's less fish for you, but if I use curl, I'm not
stopping anyone from using curl, right? So that's just generally what people may have public good.
However, some people benefit a lot more from curl than other people, or, you know,
equivalent open source projects. So companies that base their business model on curl get a
huge amount of value out of curl. Again, we're imagining. And, um, so Dina, we should also
take that into account that sort of benefit is not evenly distributed. So one kind of argument
that someone might make is to say, hey, do your CEO that's using my software? You know, all
these critical maintainers generate so much value for your company. And this is value that,
you know, you get the most value, or you get a sort of a really large share of the value
from this project. The people making it don't get that value because you're not able to
rent off of the development of that project. Wouldn't it be nice, right, for you to pay
something back to the people that enable you to sort of make use of this value? Now, I'm not saying
this as sort of this furrow moral argument because I think that's sort of philosophically really
difficult. But, I wonder how many people this speaks to, right? So my friend was about
says that emotions are suffused with intelligence and discernment and judgements about important
things. So often we get a hint about what things we should think about and what things are
important when it gets some information for the emotions that we feel. And so this is just an
invitation sort of to everyone to think, do you empathize with this situation that the mean
painters in? But of course, again, this isn't a furrow argument. So here's my second argument,
which is the business argument. What, you know, by business argument, I mean something like, hey,
look, you know, CEO or business owner, if you do something, either you will profit or you will
avoid loss, right? So it's sort of, it's sort of potential. It's wise to do this thing. Now,
we saw earlier, right, the benefits of open source production. And so the companies using that
open source author also benefit from the way that open source production is organized. So if your
company pays the maintainers that it depends on that software that you're relying on that
open source software, you're going to be able to benefit by enabling that larger base of contributors,
those more specialized contributors, that efficient production. And importantly, if you're
company relies on this, you're going to know that by paying the people who make the software,
you have more sustainability and security in the software stack that you rely on and are enabling
this more efficient model of production. And yeah, you know that you can keep relying on the
packages that you depend on. So it offers the company that's paying the maintainers stability as well.
There's also a little pleasant marketing bonus there if you're a company, which is,
you know, this sort of open source funding is something that we're still figuring out. If you
decide to pay maintainers and sort of lead this movement forward, there's a marketing bonus there
and in which, you know, if your customers are comparing you to a competitor, they might say,
well, these guys are forward with thinking, right? These guys are sort of leading open source
funding, so I trust them more, right, because they're fault leaders in this sector. Okay.
Those are my arguments for why. Okay, let's talk about how, because it's also not easy to
actually go and pay maintainers, right? And also who is getting paid? I'm not going to answer all
these questions. I'm just going to say a few things, right? For one thing, I'm talking specifically
about company funding, right? There's a big difference between aggregate fund, you know, I just made
up the word aggregate funding. So ecosystem, Andrew Nesbitt is doing amazing work. There's
sovereign tech fund, you know, I love this stuff. It's great. This is basically saying we're going
to take something like tax money and we're going to analyze the entire open source ecosystem
and then we're going to find out who globally needs to get funding. I love it, right? But what
I'm talking about is company funding. So companies that use open source software, paying
maintainers more or less directly. And so that's the first expression, thanks. So let's talk about
that a little bit. Open source pledge, you might have seen this, is sort of a cultural initiative
that I help maintain. It's funded by century, thank you, century. And sort of the ask is to say,
hey, look, if you want to be a member of the pledge, we asked that you paid $2,000 per developer
employed at your company per year to, you know, any open source projects or foundations.
You know, you can choose who you want to pay. However, you know, we recommend that you pay
sort of the pay for the maintenance of the projects that you depend on. Payments go directly to
maintainers so we don't handle any funds. You might have seen sort of the the marketing campaign
that we had and I know some people saw the billboards. It's kind of a little bit provocative
when it comes to companies that, you know, maybe don't pay the maintenance they depend on.
So far, we've raised almost $1.5 million or, you know, our members have paid maintainers
that amount over the last year. And, you know, there's pretty member companies and we're
so happy to keep getting new members, you know, here's a member of companies. So, you know,
you can check out the website. So, this is the general idea. This is where the cultural aspect of it,
right? This is where we're saying, hey, it should be normal based on, you know, some of the
arguments that I just said, it should be normal for companies to pay the maintenance they depend on,
right? Now, if I'm a company, the question then becomes, okay, cool, here's a million dollars.
Okay, what do you want me to do with it, right? Like, who do I pay? What do I do concretely, right?
And there's a question also of like, who should I give it to? Now,
you know, generally you want to say, well, you know, if you depend on some product, you depend on some
projects more than others, right? And so you would like to fund those. There are some criticality
metrics, so I've decided one thing here. In my, you know, so we can do more research here. In my
opinion, these criticality metrics are just sort of a proxy for how much the thing is being used,
right? So, let's focus on usage for now. However, I may be on a company,
depend on thousands of projects, how am I going to know which projects I depend on the most
in a scalable way? And with a minimum amount of effort, so I don't have people sort of, you know,
looking through my code every time I update something. Something that would be nice, it is,
if you had sort of, you know, the company has this code base and then the code base you could
give it to this service that sort of confidently reads your code and spits out some dependency
info about what your usage is. That's thanks Dev. So basically, just, you know, if you're not familiar
with thanks Dev, thanks Dev is the service where, you know, companies are really anyone can
sign in. You give us access to whatever repositories you want to give us access to. We sort of
analyze the code and then we say, hey, here's who you depend on the most and here's an easy way to,
depending on sort of the weighting of each project, directly pay those maintainers, right? So
you can pay the maintainers through the platform, right? Maintainers can also sort of sign up and say,
hey, I'm happy to be paid for thanks that and so on. Now, the question remains, how is this money
split up, right? Now, this is sort of what things Dev looks like right now more or less,
is like if you give a hundred dollars, you get split up like this. So if you sort of do the numbers,
the top row is directed dependency. So let's say the hundred dollars is your project. And then
the top row is things that you have in your package, you sort of whatever, right? And then the lower
things are sort of second level dependencies, which are dependencies of your dependencies and things
get split up like this. So, okay, cool. You might see a problem, which is, you know, if you use
left-pad and no postgres, obviously, no postgres is really important, and left-pad is like,
not so important. And so if you split that up into two, you're giving $50 a station that doesn't
seem like the best way to split things. So for the rest of the talk, I'm going to be sort of saying
something about that. We just saw with the previous talk, someone saying, hey, look, I'm giving
two with a couple of people bleak, and the ex-heck is tough. I'm paying maintainers, but I want to vote
on who should be getting paid and manually adjust and so on. You can do this in things that
today, right? So you can say, here are my dependencies, don't pay some projects, pay some projects
more and so on. So that's fine. The problem is we've heard from a lot of people that they just
want to say, look, here's, again, like $100,000, figure it out for me. I don't want to spend
time clicking around, right? So here's an idea. Instead of relying on what's on the package, what's
in the package, JSON and the other manifests, and sort of just waiting payments based on that,
we could do some kind of static analysis of the code days to get a bit more accurate information.
That's what is general principle. Here's one way to do that. It might not be the best way, but
again, let's see, is for one thing, it would be good to measure some kind of coupling metric
between each of the dependencies and my code, right? So if I use a dependency and it's not so
tightly coupled to my code, that means it's sort of more trivial to replace. If I use a dependency
and it's very tightly coupled, the replacement cost is very high, and so it stands to reason that
I probably should give that dependency a bit more money. Here's like a super basic demo of what
something like that might look like, right? So here's just some pretend code. If we look at where
I use no postgres, obviously I'm importing it, and then I'm calling some function from the package
and putting it into a binding and all the variables that end up depending on that DB variable,
we can say that have sort of been touched by postgres. So we can have some kind of metric like this
and say wherever something from postgres ends up making a difference to the code, what we can count
those statements, let's say, right? And in this sort of toy example, seven out of eight statements,
depend on postgres. Now left pad on the other hand, free out of eight statements,
depend on left pad. So it's, you know, in this simple example, less essential. So we can create a
score out of that. Now the other thing is it's not just that left pad is less critical to my
project specifically. Left pad is also way less complex than no postgres. So in general, if you
have to rewrite left pad from scratch, it would be fine. If you have to rewrite no postgres,
not so much, right? So we would ideally like to have some kind of metric of complexity for each package.
I'm not going to get in for that, right? Let's just imagine we have a metric to measure package
complexity, right? And then let's just say, well, whatever score we get, we need to make sure it's
between zero and one. So let's say we get all of the complexity scores for all the packages,
we take the highest one and then we divide by that highest one, right? Here's a table.
That's a lot of numbers. We're going to go through it, okay? First row, you have the coupling
between each of the two packages and my code base. We got sort of 87% for 87% whatever, right? So
that's sort of the number that corresponds to how tightly node postgres and left pad,
respectively correspond to my code base. The second row is how complex is node postgres, how
complex is left pad? We just may don't those numbers up, but imagine you have some kind of good metric.
What we can then do is we need to combine those two numbers in some way. We're just going to multiply
them whatever. And so that gives us one score that combines those two numbers. The thing is,
we'd like that score to be out of one, right? Sorry, not out of one, but to add up,
all course to add up to one so that we can sort of do it as a percentage. And so we have that
in the proportional score sort of by dividing by the sum. And then what you can end up with, for
example, is by this calculation that I made up, postgres would get $95 and left pad would get $5.
So that seems like a good result. So this sort of makes me believe that maybe this is something
that we should look into more, because static analysis could give us better information
about which dependency should get how much money, right? So this is sort of what you end up with,
as you get $5 to left pad and 95 to no postgres. That's sort of almost it. I'd love to hear what
you guys think. I think we might have time for like one or two questions, but I also don't like
sort of the rush dynamic of the questions. So please come up to me later if you want to talk about it.
Other than that, if you go to this handy link, I'll leave it up for a second. There's an issue
tracker that I made, because I know some people might have sort of similar questions, or maybe
we won one place to sort of consolidate like a longer discussion, because you know, your feedback is
valuable. So if you go there, there's just a link to this like codeberg issue tracker, so you can
make an issue, and then we can talk about it. Very importantly, I have one confession to make.
I made open source pledge, and thanks to have stickers, they're really beautiful. I made too many
stickers. Please help. The stickers are here. You take some for your friends. Take like five of them.
It's fine. Okay. Please. All right. That's it. Thank you so much.
Thank you. Thank you. Maybe, okay. Yes, hello.
Hi. Thanks a really incredible thought. I too concerns the first one of the seams that you're
solving social problems with the tank of coal solutions. Why do you just have to
developers at the company if they have 100,000 sent out a little loading thing, people click on a couple
of things and boom. You have a good idea. And the other one is $2,000 per developer is way too
five percent at Linus. That's the minimum and that's what I tell companies.
So I'll start with the first question. The first question I'm understanding correctly is why not
ask the people at the company who have more information about the dependencies, what they think,
because they have that domain knowledge instead of trying to find a technical solution that's
just going to approximate what people know about the importance of the dependent. Is that right?
It's also the game. Yes, that's right. Yes. The technology is going to be game. Right. So it's
mitigating people gaming the metrics. I think that's absolutely true. I think we need to do more for
that and I absolutely agree. I think the reason that it's good to have some kind of computational
solution is, again, I've heard from like a lot of companies that they're saying like, hey,
man, I just want you decide for me, but I do agree that maybe there needs to be a little bit of
pushback on that cultural change aspect to say, hey, guys, no, no, let's have a conversation.
So yeah, I take that point. And then the second point is you said $2,000 per developer is not enough.
Yep. Right. I think it's, you know, we're really trying to straddle a line
in between getting something that meaningfully brings change to maintainers and something that
companies are willing to do. As you scale that number up to a lot of employees, companies get more
and more reluctant. So we are thinking about, you know, whether that is the best number,
but I think that's sort of the compromise that we've reached for now, but it is not perfect. Yeah.
Andrew? So yeah. So we actually use, we actually use things step in the past and I'm not
using it anymore because it was too painful to to manually adjust all these things and because
Cinderella saw who's popped up at the top of all the dependency charts, every was the peak of
system. But here, we suggest something similar. We'd like a we need to produce a sponge anyway and
we'd like to produce like an open sponge because all of this is also missing things like
VLC, Firefox, Thunderbird and Layers 2, except on the B&E. So that was our big, our big problems
actually, we'd like to spend money, but it's too hard. And this only sort, let's have a, I like it.
Yeah. I don't even put that real on here. Yeah. So yeah, but I like it. Right. So how should I
best summarize your comment for the audience? Yeah. So so basically, there is a lot of limitations
to strategies like thanks Dev. And we need to work on how to to solve things that are not visible
in the manifest really. Yeah. Right. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. I
take, they take their comment. Yeah. Hello. Yeah. So yes. Oh Andrew. Yes. Finally. Yes. He, uh,
measure is financially incentivizing. They've had to make their code much more complex.
In, in fact, it is like, oh, most cheek, but it's actually products are very, like,
done. They're not necessarily going to do that. But we're already seeing people start to
realize. And he's at the algorithm is open source. It's very easy to reverse engineer how to do that.
We've got a great thing with open source, whether there's no barriers to entry. It doesn't cost
me to publish a new version with thing. If we start to financial incentivize the algorithm that
sends money automatically, we also need to consider the gamification and how we don't destroy everything
that is good in the free and open source. Well, the process. Yeah. So Andrew is saying,
hey, look, these metrics can be very easily game. They're not only can they be game. But they might
be incentivizing people to prioritize the wrong things. You know, if you use like whatever
measure of complex, you know, like left pad could just add like 15 trillion or four loops. And then
you could say, whoa, there's so many paths for the code man. It's crazy. So, um, yeah, I agree.
That's a problem. And I don't know. But yeah, thank you so much. I think we're out of time. I'm
I'm so sorry that this like it has to be so quick. I really would have loved to hear all of your
questions. But if you go again, you go back here. Um, please say hi. Okay. Thank you so much.