Ep. #17, Open Source Economics

Edith Harbaugh: A lot of the fun of creation is the creation, and the hard work is all the maintenance and the support and the documentation after.

Paul Biggar: Developers don't want to make companies.

Sean Byrnes: I think that a lot of developers don't know how.

Nadia Eghbal: Open source infrastructure needs a developer evangelism team. Or it needs a community manager or something.

Paul: Or a sales team.

Edith: It's bad enough to get a snotty bug report from a customer that's paying you, but when it's from somebody who doesn't even give you anything.

Sean: The problem I have with calling it free labor is that I find it a little bit condescending to the intelligence of software developers.

Nadia: In the end, money is actually really closely tied to open source and we're just not talking about it. Everybody gets paid for open source.

Paul: Hi, I'm Paul Biggar, founder of CircleCI.

Edith: I'm Edith Harbaugh, CEO and co-founder at LaunchDarkly.

Paul: And you're listening to To Be Continuous, a podcast about continuous delivery and software development.

Edith: You can get in touch with us anytime at our Twitter handle, @continuouscast.

Paul: The show is brought to you by Heavybit. To learn more, visit heavybit.com. And while you're there, check out their library, home to great educational talks from other developer company founders and industry leaders.

In this episode of To Be Continuous, Nadia Eghbal and Sean Byrnes join us to discuss the economics of open source.

Why Open Source

Edith: So Nadia, what do you like best about open source?

Nadia: I like that open source is where I feel I spend time with a lot of creative people. It's sort of like creative talent at its best, and it feeds directly back into the rest of startups and technology and everything else that I love, but it seems like everything starts with open source, which makes it really magical.

Edith: So Sean, what do you like best about open source?

Sean: It's the community. I enjoy learning from other people. I enjoy being able to find people I would never connect with that I have interests in common with, and the community that helps, because I consider open source to extend beyond just writing lines of code to sharing ideas and sharing concepts and sharing solutions to problems. While I might not always use those same solutions, I'm always inspired for new ways to solve other problems.

Paul: So that's super interesting, because nobody said that they like how it supports their Silicon Valley startup through sharecropping, or nobody said, "I like how I get paid to work."

Edith: Well, Paul, that comes later in the episode, but this would be a great time for our guests to introduce themselves.

Nadia: I'm Nadia Eghbal. I've been writing recently and thinking a lot about how to support open source infrastructure. Originally I have a background in nonprofits and impact investing and working with foundations. But most recently I was a founder of a startup and then I went into venture capital and has sort of seen the system from all different sides, and would love to marry together all those different interests and topics, which seems to happen in open source.

Sean: Hey, I'm Sean Byrnes. I've been writing software most of my life. I've also been a founder of companies and an investor.

I would not consider myself an expert on open source, and I don't want to claim that pedestal, but I am the maintainer of some open source libraries which seem to be pretty popular, and I have contributed to others. And I think that I've been lucky enough to know a lot of open source developers in my life, which is by no means a majority of them, but enough that I feel part of the community at least.

Everybody Gets Paid for Open Source

Paul: So one of the topics that we were discussing just before the show started is this idea of how open source developers get paid, or if open source developers should get paid. Nadia, it sounds like you've been talking about this for a while, or thinking about this for a while. Can you kick us off?

Nadia: Yeah, I actually have a new thought on this topic from Mikeal Rogers, who runs Node.js Foundation. And he said recently, I think on the last post I had written, that everybody gets paid for open source. And I think that's a really great way to start thinking about it versus saying that nobody gets paid.

Because in the end we're contributing time to open source, right? And in the end somebody is paying you to have the time to work on open source, whether it's your employer and then you can work on open source full time at your job, or you're full-time employed and that gives you the bandwidth to be able to work on open source on the weekends or whatever.

So when we think about paying people to work on open source, I think people sort of bristle at the idea because they think that money is not involved in open source at all.

And what I really liked about Mikeal's point is that in the end, money is actually really closely tied to open source and we're just not talking about it.

Sean: It's interesting because my point of view is that it's actually more nuanced. I agree with you a hundred percent, but I think that it's very nuanced in that a lot of people do get paid for open source. It's not even that we aspire to wanting them to get paid, right? Because there's lots of kinds of open source.

It's funny because on Medium Nadia and I had an exchange and I kind of quantified it into the four categories of open source the way I see them, which is by no means the universal standard, but at least how I see the world. There are places where open source is part of your corporate product.

It's part of a whole. Like, LaunchDarkly, Edith's company, has open source SDKs. It's not because they're doing anything, granted, it reduces their sales friction if their customers can see the code before they integrate it into their app, right?

So that's one kind of open source. A second is what I call corporate open source, where there's an open source project, but there's a company that sells services and products and stuff around it, right?

So Confluent does that for Kafka and Databricks does that for Spark, and MySQL was, I think, one of the first companies to really make a good model out of it. Red Hat, you could argue, had mixed success. But that's another kind, where there's a company whose corporate goal and sales is towards this project.

There's the third kind, which I call kind of like corporate marketing, which is you take a project out of a company and you roll it out like LinkedIn did with Kafka, where they're actually the companies maintaining it, they just make it available. So Google with Angular and Facebook with React. And again, there I think that it's, you could argue why companies do this, some of them do it for recruiting, some of them do it for marketing, some of them do it because they're very nice people.

But there I think that the fourth category is where it's a little bit weirder, where it's what I call the community, where somebody started a project. Maybe it's an individual, maybe a few people to solve a problem.

And a lot of the most important open source projects today started that way. Even Linux started that way, right?

And it grew and it got bigger and eventually then it became unclear, because other people were using that project to build other companies and build other products and make more money. And I think in that fourth category is where I think it's less, 'cause in the first three categories it's usually pretty clear who's getting paid to do what and where the money's coming from.

But in the fourth category it gets very muddied very quickly. Because if I start something, and the metaphor I like to use is the open source library that I wrote was something called Likely.js, which is a recommender system for Node.js, where you can like Amazon product recommendations.

And I know that there are people in the world that are using that as part of companies. And those companies are obviously making money because they're using it to recommend products, right? And so the question is, so in that world, do they owe me anything for creating that, which is underlying their products?

And then in turn, what do I owe to the projects that I built Likely on top of? And then where does the flow of economics in that world go?

Paul: So I have an interesting view on that. Years ago I got involved in this project called PHC, which was a compiler for PHP. And there was a couple of guys who had started this and I joined a year later, and when they started it they made it GPL.

When I joined, I argued we should change it from being GPL to BSD. Because if someone comes along and uses that technology to build something that's cool, I would rather that happen than that not happen.

And it might be that if it was GPL that it wouldn't happen. And so that essentially, related to Likely.js, you decided by the license whether or not you were going to make it publicly available, or if you didn't want people to build business on it, you could have made it GPL or AGPL or something along those lines and you could have restricted it in any way that you wanted, and you chose not to. And there's something implicit in that that communicates to people who are building their companies on it, et cetera, as to what your intent was.

Sean: No, that's true. Although there's a nuance in there, which is that even the GPL suffers from this, what Richard Stallman still complains about today, which is you could still use Likely.js on a server to produce a service without...

Paul: AGPL would work around that.

Sean: Sure. And there's other licenses that I could choose. But the majority of licenses out there today... But even then, let me argue the counterside, not because I agree with it, just because, hey, let's argue, because then it's more interesting.

What's up? As an individual developer, I don't have the time or resources to go pursue people. I'm not gonna go sue somebody, really? No, come on, it's not gonna happen.

So I think you're right, only in the act of releasing it as open source on GitHub, I was making a decision that it is possible for people to use this in ways that I don't intend. They could have used it on Silk Road to recommend drugs for all I know, seriously, right? Or to make money on it in ways that I am not going to benefit from. And I made that decision knowing full well the impact of that.

And I would actually argue most developers do that. The question is whether or not there's like remorse later on when it turns out, wait, I really wish I hadn't made that decision and then can go back in time.

Paul: Well, I think this is a common thing, that people create a thing and then they say, well, if this is popular, I could sort of keep it, or I could... there's value here that I could keep to myself, or I could keep the value to myself or try to profit from it in some way. But they make what is essentially a marketing decision.

I'm just gonna release this, I'm gonna see what happens to it, I'm gonna see if it spreads, and then if it spreads, I can then make a decision as to how possibly I can make money out of this or I can get value out of this. But at that point, obviously the cat is out of the bag in terms of people actually using the software.

Nadia: Yeah. I think you should start from the principle, like you said, of it's really great when you give something away and then people can use it for whatever they want, whether it's for a hobby project, whether it's for illegal drugs or whatever, businesses, whatever. That's kind of one of the coolest things about open source, is that you can use it for whatever you want, and that's kind of what you signed up for, right? If you didn't want to do that, then don't license it that way.

I don't know, I wouldn't frame... At least the problems that I'm seeing or that I'm interested in is not really about seller's remorse, I guess, of, oh, I made this thing and now it's really popular and how can I make money off of it. But I think it's more really about investing back into the infrastructure that we're all using and that requires some sort of maintenance and upkeep.

And that's why I like the term infrastructure, and I'm trying to use it in that sense of things that don't have a business model or a business attached to it. You literally could not charge for Python. That's not gonna happen. Or the packaging associated with it or whatever, but still, millions of people are using it, touch billions of people.

And you literally have one person working on a library or a project. It seems like it's in everyone's best interest to make sure that it works properly.

Edith: Well, I think Nadia made a really good point that a lot of the fun of creation is the creation, and the hard work is all the maintenance and the support and the documentation after.

So Sean, you basically got the fun.

Sean: Oh, totally.

Edith: And then you're...

Sean: Well, if you even think back to the original "The Cathedral and the Bazaar" essay from years ago, that was one of the fundamental topics of... Eric was inheriting, I think it was called pop mail, from somebody else. He had gotten tired of maintaining it, and so he wanted somebody to take it over, and he found Eric and Eric took it over.

I think, yes, as engineers, we like creating, and we like creating things in our free time, and we don't like maintaining them as much, and maintenance feels more like work. And so I agree with Nadia's point that if everybody is driving economic value from it, somebody has to be willing to step forward to support it.

I think the problem is that... it's funny that you have a background in nonprofits, because I also have worked for nonprofits, and I see the similar lament in nonprofit companies, no, nonprofit organizations, where the person who starts it usually really wants to solve this problem. They're usually very good at that. They're not good at the fundraising.

And in this case, in nonprofits, it's like raising grant money or getting donations. But they have a good mission and they have a good organization to go do it. And they have this lament, which is, why can they not get more support to solve the problem they see in the way that they want to solve it?

And I see the same around maintainers of open source projects. And I think the challenge is going to be that I wonder if it is even possible for the general economy to support them to do what they want to do the way they want to do it, or if they're going to have to start doing it the way the general...

Paul: Right, because they have other options. They can start a consulting company, or I think you called it a category two company or something like that, to build around it and support it themselves that way, and then their job isn't what they wanted their job to be, which is making cool software. Their job is doing maintenance contracts for a big soulless enterprise.

Edith: Wait, you say that like it's... soulless enterprises...

Paul: I'm a big fan of soulless enterprises, but I'm just looking to sort of put the...

Sean: They have a lot of money.

Paul: And if any soulless enterprise would like to buy CircleCI, they should contact me for enterprise prices.

Sean: Just mention the code OSS for 10% more on your contract.

Edith: And by the way, thank you for wearing your LaunchDarkly t-shirt today, Paul.

Paul: Always.

Is It Free Labor

So Nadia and Sean had this conversation on Twitter a week ago, which led to them being on the show. And one of the tweets that got involved was from Jacobian, who's one of the senior Python kind of people. And what he said is, "OSS developers deserve to be paid. SV, Silicon Valley, has made massive profits by exploiting free labor. This needs to end."

And I think that there is this feeling in open source, or at least by a lot of people who end up on the maintenance side of things, that there is a sort of a sharecropping going on here and that something needs to happen about that.

Edith: I think Nadia actually put this extremely well in the essay. I wish I had written that essay. It was brilliant. But just what's really fed this is the explosion of GitHub and that it's really easy now to start an open source project.

Nadia: Yeah, I feel like right now is just a time when we're so used to thinking of open source in a certain way, and things have kind of gone along as they have for so long, that we haven't necessarily noticed or taken a step back that the past five years look completely different from the past thirty years. And stuff is just not the same anymore.

I think it should be framed as a really good thing, because it means that open source kind of won in a way. Companies want things to be open source. They want to learn how to open source their own projects. They want to understand the whole thing.

Everybody is defaulting to open source, and that's a really positive thing. And the question is more of not like, oh, we're exploiting people and that really sucks, but how can we help support that underlying layer that has helped make everything so great? It obviously needs some sort of reinvestment back into it.

Edith: Yeah, one of the most fascinating thing about "The Cathedral and the Bazaar," which was written thirty years ago, is that they referred to Linus Torvalds as this charming guy. Like, wow, he's this charming, personable guy who persuaded people through sheer force of will to work on his project.

To go back to Sean's example about a nonprofit, and then everybody in the studio right now is like, whoa, that's not... not at all. By anybody's perception of it now. And I don't know whether that's just the grind down of having to keep maintaining a project or...

Sean: Well, first I'd like to thank... I don't know if his name is actually Jacobian, but whatever it is, thank him for his service and work on Python. Because I think no matter what we agree on here, we can all agree that the people doing this are doing a service for the general community.

The problem I have with calling it free labor is that, A, I think it's misleading. And secondly, I find it a little bit condescending to the intelligence of software developers that they're just being taken advantage of. Like they're somehow... they have no choice.

There actually is legitimate free labor being abused in the world. People who have no choice, they have economic limitations, they have no options. I think the reality in software development is that no matter where you work in the world, software developers are a highly paid profession, people who can make money doing this, maybe more in Silicon Valley than elsewhere, but people can make money doing it.

And it is a challenging profession in that these people are smart and they understand the impacts of what they do. I think the question largely is... I really do think it comes down to the fact that there are people who have done work that is now being used in other ways, and what is the rationale and the economic equality that they deserve for that, right?

So you think about... sorry, I just want to go back. There's equivalencies previously in history, right? It's not like this is the first time in history that technology's been used in different ways, right?

You looked at the ways that the telephone changed the economy and electricity changed things. These things fundamentally alter the way we function, and they can be used in ways we didn't intend.

And I think that you think to the original... all the original programming languages all came out of academic research. And then it was always going to be... university research has always been available to the general public. So it was always, as Nadia said, back then it was obvious.

Now we have companies like... Go is developed by Google. Right? So what does that mean? Does that mean that the world changed?

Like, Java was developed by Sun Microsystems. It worked out really well, but Java's never really been open source.

Paul: So to take his point a little more, well, I don't necessarily agree with Jacobian's point here, but I think the feeling that he's trying to say is that there's tons of these startups who are making millions and millions of dollars, and they're building it on the "free," and I'm making quotation marks, which you can't see.

Sean: But they were great actually, right? A good flourish and nice wrist snap.

Paul: Companies are making millions of dollars on putting together, wrapping together open source libraries and open source technologies that are produced by people to whom they gave no money, and to whom they are sending bug reports, and who are then shouldering the maintenance burden, all for free relative to the companies that are using them.

Edith: I think a lot of open source was based on, I call it the take a penny, leave a penny model. Right, where like tipping, "Oh, I'll use this project, but I'm contributing back."

Paul: I think it was actually the take a penny, take a penny.

Edith: It was originally, I'd say, this very idealistic thing where it was coming out of universities. Like, oh, you're working on this part of the stack, I'll work on this other part of the stack, and we're all getting paid by research grants, so it doesn't really matter. And what's changed now is that it used to be that using open source was a very subversive thing. Like, it was sticking it to the man.

Paul: Now the man is exploiting open source.

Edith: Well, so open source has won the battle where you no longer have... I remember when I started out, you have to fight to use open source.

Sean: I have a funny story about that, which I forgot to tell at the beginning.

Edith: But let me finish. But now it's the reverse. Now all of a sudden it's like the big companies, in Paul's words, the soulless corporations, who are filing the snotty bug reports. And it's bad enough to get a snotty bug report from a customer that's paying you. But when it's from somebody who doesn't even give you anything, there's some legendary GitHub threads that you can read where basically somebody's like, "You don't understand who's the customer here."

Sean: No, well, I'm not gonna tell my funny story now because I would lose the moment, but I will say that again, it comes back to me, a feeling that there's this problem that exists where the mindset is, I want to get paid for doing things the way that I want to do them. And I think that that's the challenge that I run into with this, which is they could ignore those bug reports, right? You could say, listen, I don't care what you think.

Literally, a lot of these projects, most open source, I don't know statistics, most open source projects have a single maintainer and almost always a single contributor. If you're very lucky, you get a full from... So there's almost always one person that's doing it.

That person has the ability to do whatever they want. Even the most popular ones, right? Even though they probably wouldn't do this, they could, in theory, do whatever they wanted.

Edith: That's the whole idea of a benevolent dictator.

Sean: The benevolent dictator for life, exactly. So, but my point is they want to get paid for operating this in the way that they want to operate this, and doing this in the way. And maybe that's not the right model. Maybe there's a point where these things turn over.

What happens today often, I see, not for Python, that's obviously not going to go away, but for libraries, somebody will build one and they'll maintain it for a while, and they'll get sick of it, and a few will pop up. So Likely, when I wrote it, was the very first and only recommendation engine for Node. Now there are a dozen, right?

I haven't maintained it in a few years because, frankly, there's better options available. And so that becomes the circle of life, where the community is maybe not contributing to the original project, but creating new ones that pop up around it to replace it and augment it, and it becomes this kind of free-flowing, free-form entity and community.

The Journalism Parallel

Paul: So I find it very similar to the things that journalists are lamenting about. So journalists are talking about, like, the...

Edith: We used to get paid.

Paul: We used to get paid. We used to get paid a lot. We were the arbiters of what content was, and then all these people came along and they started making content for free. And that content isn't the right content, or whatever complaint it is.

But a new technology, the internet, allowed anyone to write, and lots of people wrote for free, and it devalued what they were doing. And then the people who wrote for free found business models, whether it was like being able to get a job from writing, or YouTube royalties, or whatever the thing is.

And there's this really strong parallel, that the people who are maintaining the big projects are like, well, we want to get paid for this, how come no one's paying us? And the people who are maintaining the small projects, and who are building it for free and are getting jobs out of it or getting consulting out of it or whatever, are like, fuck it. I'm making billions of these. I do it because I like to write, and I don't care about your problems of maintaining Python.

Edith: So I tweeted this and I'd like to expand on it, which was, I think a lot of these free projects crowd out paid products. I mean that in a very economic sense, that if there's four free libraries sitting around for recommendations, it's really hard to get paid for one.

Nadia: I think that makes perfect sense for projects on the level of the one that you're talking about, Sean. And especially for JavaScript libraries, and there's a lot of overlap.

Sean: No shade being thrown at JavaScript.

Nadia: No shade, no, truly no shade on this side of the table.

Sean: I feel it. It's high shade.

Nadia: But I'm just saying that there are plenty of, and I think that's sort of where all the fun and the creativity is happening, is like, oh yeah, I made this project and I'm gonna put it out there, and someone else might make another one, and that's cool, and you can choose whatever you want. And that really mirrors sort of the information revolution in a lot of ways, with content and journalism and other things, like music even, where you could just give it away, and now paid products can't compete. I think that's actually okay in a pretty natural and expected development, and we shouldn't fight what's happening.

But then there's still plenty of examples of projects like Python and its packaging, or Ruby and its packaging, or whatever, that aren't being supported at all, and it seemed like you can't use a small project to explain why we shouldn't support a big project because those big projects...

Paul: I think OpenSSL is a really good example. So OpenSSL had one maintainer, and it had some security issues with it that were basically... and everyone in the world was relying on it, and then everyone got screwed.

Sean: I actually don't agree. I think that if you think about how many languages exist today, how many options you have to choose between, I think that it is true that Python, you're not gonna have three versions of Python that people are maintaining.

But there's so many languages, if the Python maintainers are like, listen, we don't wanna do this anymore, and they walked away from it, it's not like the world would end, right? The existing Python may not get better. It can't get better.

Paul: I'm going to disagree on this. So if you look at all the companies and all the projects and everything that are being built on Python, the world would end. If Python went away, I mean, someone would come in and have to support it.

Sean: Exactly.

Nadia: Then why don't we just do it? That's, I guess, the part. Why do we wait for a disaster to happen?

Even with OpenSSL, for example, they were asking for years for donations, openly soliciting, trying to get people to pay towards, and it was only when there was this huge bug that suddenly everyone was like, oh my gosh.

Selling Risk Reduction

Paul: So I have a strong opinion about this. Basically, they're asking the wrong questions. If you're going around saying we want donations or whatever...

Nadia: Like, basically trying to kickstart.

Paul: Companies actually really can't give donations. Donations are really fucking hard to give. What they should be looking at is companies and their risk profiles.

So you have a company that is built on top of Python, and they've no support contract, and the whole thing could fall under them at any minute, they're definitely going to want to donate or give or buy or something that reduces their liability in some way, reduces their risk factor. And the idea of going around and saying, oh, we need money, please give us money, I think is ludicrous.

And the idea that I've drawn up for this is basically someone should go out with literally a sales team, go to every Silicon Valley startup, every venture capitalist startup, every venture capitalist, everyone who makes revenue in the software business, and say, give us point one percent of your revenue, or one percent of your revenue, or somewhere in that range, and we'll make sure that it goes to the libraries that you rely on to de-risk those things going away, the bugs not being done, all that sort of thing.

And the idea that people would just throw their hands in the air and say, "Why won't anyone donate to us?" It should be a very proactive approach of going out to each of these companies saying, give us money, here's an LOI, here's my checkboard, bring out the checkbook.

Nadia: Actually, with OpenSSL, it was actually a very interesting setup, and I talked to Steve Marquess, who was at OpenSSL, just to understand that structure. And it was actually, they realized exactly what you realized, which was even though people keep saying OpenSSL never got more than like 2,000 donations a year, that wasn't how they were actually paying their bills. They were doing consulting contracts. And they brought in no more than I think a million a year, but it was more than $2,000.

So there's Steve Henson, who is contributing to, or he was the one paid maintainer for a while at OpenSSL, and now they have a bunch of other people. And then Steve Marquess came in for this reason to say, hey, I'll write a little bit of code here and there, but really what I think you need is a little bit of a business mindset. And so he managed and continues to manage all of the contracts, all of the business services.

None of the developers want to talk to clients, but he'll be kind of like that interface. Even email, he says, don't ever email Steve Henson, just email me. I'll forward it to him if he needs it. And so I think that actually speaks to what open source needs more of, a business mindset.

Paul: I'm proposing something that's ever so slightly different to that, that rather than a single company, or sorry, rather than each company like OpenSSL having a business person who goes around and who tries and raise money or who sells the developers' time for things, you have a single company.

Edith: So you have the united way of open source?

Paul: You have the united way of open source.

Nadia: But then Paul, then you still have the issue, how does this united way decide where the money goes?

Paul: You can look at people's Gemfiles to determine where the money goes.

Nadia: I'm totally on board with this. This is kind of what I'm slowly trying to move towards.

Sean: I think companies are more likely, when they get scared like that, to hire a shadow maintainer than they are to donate to the open source project. You see this all the time.

Companies that rely on big projects like HBase and Cassandra, they actively go out there and try to... They basically have shadow maintainers on their team whose job it is to be the expert on the source code, to update it.

Paul: Companies typically use more than just HBase. They're using hundreds and possibly thousands of the other things.

Sean: We're talking about a class of projects which are the huge projects, like the programming languages, the big projects, because the small ones, we've already talked about those. We can go back and talk about them again, but those are a different story for the project.

Paul: Do we think that the small projects don't deserve funding?

Sean: I think that it's much harder to make a case for them because they live and die so quickly. I think it's really hard.

Nadia: I would liken them to art, which is how a lot of people think about code. And when it's sort of on that level, I think of it as art and creative expression. When I think about the big projects, I think about them like highways or roads or infrastructure.

Edith: Or cathedrals.

Nadia: Or cathedrals.

Paul: This is interesting. No one thinks that the smaller things deserve some sort of support?

Sean: I think that if you were willing to maintain one long term, maybe. The problem is they're just less complicated. So then you run into the barrier, like if it was really easy to recreate Python, maybe we would.

JavaScript libraries are one thing. I like to think about stuff I do as a little more complicated than that. But that's just my personal opinion.

There's definitely a grading of the complexity of something. For example, in most places there is n number of implementations of a bit vector. It is really not hard to write a bit vector. If you really didn't like the ones out there, you could write it yourself.

But a programming language is on the other side of the spectrum, where it's really complicated. If you've ever done one, it's crazy hard to do. And on the spectrum there, the smaller ones probably deserve, but the replacement cost is so low that you can just churn them through.

On the higher end, where the replacement cost is higher, this is where I think that if a company really was scared about their reliance on it, they're less likely to support the open source project where they have no control over what the money goes towards. If I give to OpenSSL, I personally believe that they would do something positive with it, but a corporation cannot make that bet. So I want somebody on my team who knows OpenSSL code that can improve it or change it in the ways that I need it. And I see that as my investment in my production.

Paul: So I'm gonna suggest that we're thinking about this a little bit wrongly, because the way that we're talking about big projects, big projects are infrastructure, small projects are art or whatever.

Sean: I disagree with that too.

Paul: It applies kind of a morality to the value of particular open source projects, and the value of what they do, and really the value applies to individual companies. A company derives a certain value from a certain library, and it doesn't matter whether it's a big library or a small library or a big project.

That company should be putting money into its risks, and if its risks include a very small library that has one maintainer but that is a key part of their drug recommendation engine, it's gonna be up to that company to make sure that the money goes to the right places.

And so the way of determining who gets money that I've been thinking of is literally looking at Gemfiles or looking at POM files or whatever it is in your particular language. You can follow that dependency tree to see who actually is involved, what projects are involved in making your library, how much they're being used, and determined that way who should get support, or even whether there's someone down that path who is willing to support what you have.

Nadia: I actually totally agree. I think when I think of big versus small projects, maybe that's not the right term, but just the idea of something that has critical dependencies, or someone or something really, really needs this to work for their own purposes, then somebody should be supporting it.

And also just as a simple heuristic, if maintainer is asking for more support, they might need more support. And support doesn't always look like money, but maybe it's like, I don't have the time to work on this, I'm really stressed out, whatever. It requires some sort of closer attention. If a maintainer is really happy (Sean, you're happy with your project) and you're not asking for any support, then we don't need to support it.

What Money Does to Open Source

Paul: So the thing that this inevitably gets to is what happens when money gets introduced to open source. I wouldn't at all argue that open source doesn't deserve money and needs to keep doing it as art, but definitely...

Sean: Let's all agree the four of us deserve a lot of money.

Paul: But I think there's definitely an argument to be made, and I think that you've both made this, that people get involved in open source for intrinsic value, and it's not for the money largely. And so when you start to introduce money to it, and you start to prioritize, and maybe people want project management and that sort of thing, and roadmaps and deadlines and that sort of thing, is money going to damage what we believe as open source, and how can we avoid that?

Sean: Or is the answer that really you have to help projects transition between... I laid out my four categories, whether or not you agree with them, but maybe if a project becomes really critical and has an individual maintainer, there has to be an infrastructure to support them transitioning to a different model, right? We don't sit around worrying about what's gonna happen to Spark, because Databricks is there. We don't worry about what's gonna happen to Kafka, because Confluent is there.

Paul: And they have the product managers and that sort of thing, who talk to the customers, who determine the order of things and the priorities and the roadmaps.

Sean: And maybe the answer is that you have to help these projects transition. I worry that even if you followed back the gem paths or the packages, it's still not clear to me if you know exactly who to support and how.

And yes, they want support. That makes total sense. But again, I worry about, going back to the thing I've mentioned a few times, do they want support to do their project the way they want to do it? Or do they want support to do the project in the way that the companies wanna use it, in the way that they wanna go?

Because it's not like they'll get money to just keep doing it. The money comes with expectations that you will do what I want.

Paul: The money is for de-risking largely. And so there has to be some sort of maintenance guarantee or turnaround time or understanding that bugs are gonna get fixed in order for that to happen.

Nadia: So one point I quickly wanted to make, in regard to what happens when we introduce money into open source. What I had said in the beginning of this was that everybody gets paid for open source already. And I think that's a nice framework to have because...

Edith: You can't take that to the grocery store on Fridays.

Nadia: Well, what I'm trying to... So for example, Heroku is employing the core Ruby maintainers right now, right? And so they have a full-time job and they're allowed to work on Ruby, and that works right now because Heroku is supporting them. Who knows if Heroku will support them later. Ruby is older than Heroku.

But in the end, there's some sort of arrangement working there. We're not thinking about what's going on with Ruby, is it okay for that language, because Heroku is paying somebody to work on it. So money is already there and already being used. We just aren't quite thinking of it as directly, I guess.

Edith: Well, it goes back to a lot of these open sources coming out of the government. Who was really paying for this? Tax dollars.

Nadia: The internet started because the government was funding it.

Edith: Yeah, so all those people who were getting a PhD were in effect funding this infrastructure.

Nadia: Right. So money's already there.

Edith: Well, so you could say it was on the back of somebody getting paid 20K a year as a grad student. No, I'm serious. That's why UC Berkeley student gets paid, which is pathetically low.

Paul: But money that's in open source now is not being directed towards a particular goal or a particular agenda. It's being worked on on the side or something along those lines. Although I agree, everyone is getting paid. But they're not getting paid to do a thing, largely.

And so when companies start to support that, then people change from doing a thing because they like it, or because they're using it for work and they feel other people could use it, to actually needing to support this for some other company's agenda. And that's a different goal, it's a different feeling. It's different from what I want to do in open source.

Edith: Well, Nadia, you've talked to the most. I know you've done so many interviews. Is there any common thread about people wanting to get paid or not wanting to get paid? What are you hearing the most?

Nadia: Well, I think it's part of actually what Sean was saying around, do they want to get paid to do the same thing they've always been doing? Life obviously just doesn't work that way, as nice as it would be. And so I think community and funding are actually really closely tied. And I've tried to be careful to call it sustaining open source infrastructure more than just funding, even though it kind of gets simplified to funding sometimes.

Because it's not really about money. It's sort of just about money enabling people to do what they already want to do.

And so when I think about introducing more money, let's say, to open source, it's really around how do you help enable a healthy, thriving community to exist? How do you help maintainers manage their time better? And yeah, I think it's a very delicate question and it has to be implemented by somebody who, I guess, understands... We're not trying to change open source, right?

It shouldn't be a centralized thing. You can't have, say, an institution that is producing all of the open source infrastructure and it just comes from this one place. That would be awful. You have to work with... each of these little ecosystems is completely different.

Each of them takes pride in being very different from the other ones. And so figuring out how to coordinate all that is actually probably the hardest part.

Sean: Although let's agree, if there was an institute for open source, you have to fill out forms in triplicate at the front desk in order to get in to review the source in the...

Who Decides What's Fair

I'd say, so what is the tension here? Because originally, I feel like a lot of this arrived out of... It was very organic, right? A lot of projects being created and it was almost Darwinian in that something survived and then it died and something replaced it.

And now we're kind of not willing to let it be that simple anymore. We're not willing to let the Python maintainers walk away because Python's too important. We're not willing to let it be Darwinistic anymore. We have to find some way.

Paul: I don't think that's it. I think we are willing to let anyone walk away who wants to walk away. I think that people are looking at money that is arriving in other parts of the ecosystem and saying it isn't fair that that is going there. It is "where is mine," but I feel "where is mine" is a very kind of pejorative angle on it.

Edith: I don't mean it at all that way. I just meant it more like I worked so hard on this with this idealistic view that I was giving back to the community, what Sean said, that everybody... and then I see all these people who are taking the code, not contributing back and, by the way, being real jerks when they have a support request. I think it's, again, that's hard, but who decides what's fair then?

Sean: I agree with you, because it was funny, I remember when Red Hat went public and all of a sudden the founders of Red Hat were filthy rich, and I remember being like, what the hell happened to Linus? And then I read an article where they did give him a bunch of shares of Red Hat and he used to buy a fancy... And I still was like, wait a second. He got a fancy car and they got... that's not fair.

Edith: It's like the whole Kickstarter thing with Oculus VR. So a lot of people had kickstarted Oculus VR and they felt like they were part owners and then they sold to Facebook for, what was it, like six hundred?

Sean: Three billion, I think.

Edith: Because it wasn't equity based.

So I feel like we've been kind of stuttering our way towards open source, perhaps needing money, that there's an issue of what projects survive versus wither.

And capitalism actually has a pretty well-defined model for this. If a company can't find sufficient customers to pay them for their goods, they go out of business.

And I think when I hear what Sean and Nadia and Paul are saying about who decides how much funding to give to somebody, we talk about a centralized institute of open source, I'm like, well, wait a second. But I'm curious to hear other people's thoughts around this.

Paul: Well, I think there's a bit of a patronage (patronage? I don't know how you pronounce that in America) model around it at the moment, that you could imagine that Python or something like that is the Sistine Chapel, and there's a Medici somewhere who's funding its development for basically altruistic or perhaps personal status reasons or something along those lines.

And in fact there's people who've been doing things with Gittip and Patreon and that sort of thing who are looking at that as a kind of a patronage model, which I think is a terrible way of funding these things relative to the more capitalist alternative, personally.

Edith: Well, it's interesting because they're kind of doing... Well, so there's two models. There's the after the hat, which we already talked about, after the fact, where you kind of go around saying, hey, we built this. And the second is, I'm fascinated that now people are trying to kickstart software.

Nadia: Yeah, it's actually a bunch of... I know like Django, RVM, there have been a bunch of crowdfunding campaigns around funding development, but it's hard, right? Because developers already don't want to spend time marketing themselves. Everyone agrees that, even outside of coding, Kickstarter campaigns are a lot of work.

And you can only really do it once, maybe twice, until people are kind of tired of you. And I don't think I've seen one that's gone much more than 50K or so.

Ruby Together

Paul: So I received a cold email a while back from Ruby maintainers. And I'm not sure who exactly was involved in it, but they were looking to get funding to sponsor the kind of Ruby ecosystem, RVM, and the servers that go behind RubyGems and that sort of thing.

Nadia: They did it.

Paul: They made it? So how much can you...

Nadia: Yeah, it's called Ruby Together, if we're referring to the same thing. I think it's actually a really great model as we talk about sort of how do you direct more money without it turning into this weird capitalist business. And I think it's actually really important to decouple infrastructure from business models for that reason, because you're not selling things and you want to sort of... It's more of saying, we need this to be good so that all the other business stuff on top of it is good.

And so yeah, Andre created this thing called Ruby Together. I think it's structured as a 501(c)(6), so a trade organization. And he got a bunch of recurring donations from companies and from individual developers to sponsor work on what he calls Ruby infrastructure. And so I think they mostly do Bundler, RubyGems, and RubyGems.org.

And part of it was because of some of these things that we've talked about where, for example, there were a couple of companies that were funding or basically employing the maintainers of different core Ruby projects. And once they lost that support because it just didn't contribute to the company's bottom line or whatever, no one was maintaining these projects for a really long time.

And so I think RubyGems went a year without anybody committing to it, which is crazy. And they had issues where somebody hacked into RubyGems. I think it was a couple of years ago.

Paul: I remember that.

Nadia: Yeah, and so nobody could take care of it because it's a volunteer system, right? And so nobody is responsible and everybody has full-time jobs.

Paul: I remember in that particular case someone was away or something. So there was like twelve or twenty-four hours before anyone actually looked at it.

Nadia: People had to take vacation days from their job to work on it, which is incredibly nice of them to do for everybody else, right? So it's stuff like that that I think they want to help prevent.

Paul: So how much did they raise? Who did they raise from?

Nadia: So they're very transparent on the website about all this. I think, I haven't checked recently, I wanna say they have maybe sixteen thousand a month recurring. And they're trying to grow that. So I think they just started.

Paul: That is ludicrously small.

Nadia: Yeah, it's really, really small, which is kind of crazy.

Paul: The important thing here is that it's recurring.

Nadia: It's recurring. That's very important.

Edith: But still that's barely one full-time person at San Francisco rates.

Nadia: Yeah, and it's a shame, right? And more people should be donating to it.

Edith: I just think the whole donation thing is fundamentally broken.

Sean: Well, altruism, unfortunately, if you worked in nonprofits, you know altruism is this great thing that is a very short well.

Paul: Well, so this isn't altruism by any means. This is companies who possibly went down when RubyGems went down saying, like, fuck it, we can't do that anymore. We lost X amount of money and I'm willing to donate 5,000 or whatever.

Sean: I think if it was clear if I donated my five thousand dollars that wouldn't happen again, it would be different. I have trouble believing corporations see the math being that simple.

Nadia: But they should, because, yeah, if someone were dedicated full-time to RubyGems, for example, if something went down, they would get it back up. And that didn't happen because nobody was working full-time on it.

Sean: Well, so if you're a corporation, do you try to support the RubyGems product or do you find ways to isolate your service and your product away from the other thing?

Paul: You do both. But fundamentally, if you're based on RubyGems or on the Ruby ecosystem and, let's say you're making a million dollars a year, right? Is it something that you're not gonna donate $5,000 a year to? Of course you're gonna donate five thousand dollars a year to it because, just fundamentally, someone wants to de-risk your site going down or your deployment process going down.

If you're unable to deploy for two days because RubyGems is down, right, you're in a really shit position and there's CEOs who are coming into the VP of engineering or developers or whatever size you are and yelling, why the fuck is the site down? Why haven't we been able to get this promotion out? Why haven't we been able to get this bug fixed? Whatever that is. And five thousand dollars is a trivial amount to make that happen.

And I'm making this on a one million dollar a year revenue thing. If you're a Salesforce and you're making, I don't know, a billion a year or ten billion a year or whatever Salesforce makes, donating a million a year, two million a year, ten million a year, it's small fry.

Edith: Well, to follow the money, Salesforce is actually Heroku.

Sean: Right, right. No, no, but that's exactly the point. I feel like a lot of these larger companies feel like they do that. You think about Googles and Facebooks and they do invest a lot in open source and employing these people in the middle of the year.

Paul: They're doing it for different reasons.

Sean: Cloudera, at one point, I feel like, employed, this is me exaggerating, the maintainers of most of the major Apache projects at one point. These companies feel like they are... I think it's gonna be hard set for them to be like, I'm gonna support your project, versus I'm gonna write my own language, Go, and I'm gonna start writing everything in Go.

Paul: Well, so I don't believe that it's supporting your project. I think the tie that you need to make is de-risk. I am being helped de-risk my business by putting money into making sure that these things don't happen.

Sean: And if you were paying for a service contract, I would believe that corporations would see it that way, but they're not, that's not what these...

Paul: There isn't a service contract available.

Sean: No, I know, but that's my point is, I think that that's why I don't see the line being that straight.

Edith: I'm pro-donation. I'm just saying it doesn't map, as you said before, it doesn't map into value delivered for the corporations.

Paul: There can be a more direct map than is being drawn now, though I agree it's not a service level agreement.

The Fair Source License

Sean: I have a question for all of you. So there's a new license that just came out recently called a Fair Source License. Have you seen this? Yeah, so it's interesting because basically it tries... is not an open source license, but it's not a closed source license.

Essentially it says that, here, you can look at my source code, you can use it, but there's a limit on the number of users you can have before you start paying me. So it's not like you just take it, do whatever you want with it. Most open source contracts are like, go do with it what you will, but Fair Source is like you essentially can try it out until a certain point, which means it's hard paying me.

Edith: It's more like a shareware.

Sean: It's like shareware. It's a little bit unclear about how you enforce the limits. There's lots of questions, but I'm curious, is the solution in the licensing? Is the problem that the licenses now are too open? If Ruby came with a license that, listen, by the time you're making ten million dollars a year on a Ruby program, you have to give us five thousand dollars, would that solve the problem?

Paul: Because there's a question of what is a Ruby program. So for example, if you're a... Let's say you're a big bank and you make more than ten million dollars a year and everything's in Java and there's a team that goes out and says, well, we're gonna be doing some Ruby stuff now. And maybe you think that in the future everything will be Ruby, but right now it's one small thing. Is the bank going to say, oh, this is great, let's give our money to Ruby, or is the bank going to say, Ruby is banned and you're not allowed to make anything Ruby?

Sean: Maybe. I don't know.

Nadia: I really like the Fair Source license. I like the people behind it. The lawyer who drafted it, Heather Meeker, she's worked on Mozilla and a bunch of other things. So she has a good mind for all that stuff.

I think it'll be great for maybe some of those projects we're talking about where, let's call them smaller projects, air quotes, of, yeah, you have something that you're working on and you want to charge fairly for it. I think it'll be a lot harder for stuff like Python, for example, to use.

Sean: But why? So why? Why would the same rules not apply? No, sorry.

Edith: Sean gives us the five whys of the Kanban.

Sean: Sorry, that was almost all five whys right there.

Nadia: I think there are a lot of answers to that. My answer to it is just in looking at the history of open source in the first place, right?

We worked for twenty, thirty years to get all this stuff open for a reason.

And it had these... I think when it started maybe it was kind of more of this political counterculture thing of we shouldn't charge for something that should be free or whatever. Or code should be free, everyone should be able to use it, no one owns this, whatever. But then you saw this incredible explosion of startups, in large part due to open source, which is something no one could have predicted, right?

It's like when you create a platform and you give people access to that platform, they start making things that you could have never even dreamed of. It's so great. And we should default to having those kinds of tools for anybody to pick up and do something incredible with. And I want to protect that.

Paul: It's one of those things that's obvious in retrospect and not ahead of time.

GitHub's Balancing Act

Edith: I think GitHub's relationship with open source is fascinating. You put in your article that they fueled the explosion, but they're closed source. And I'd say now...

Sean: They spend all day roll around in money.

Edith: And now there's a big petition from a bunch of open source people, like, why aren't you giving us all these tools? And the capitalist part of GitHub is like, well, we don't make any money off of these open source projects.

Nadia: Yeah, it's really hard because they ended up... they make money off of enterprise.

Paul: They make money off those open source projects.

Nadia: Oh, yeah, I mean, it's a freemium model.

Paul: They got huge because of all the open source. GitHub is the default. No one wants to use GitLab or whatever because of the network effects of open source. So to suggest that there's no value there, and I'm sure that someone with a better analytical sense than me could actually put a dollar value...

Sean: Just look at SourceForge before them. SourceForge made money off open source. Before GitHub even existed, there was open source, right?

Paul: Right, but all of GitHub's value is derived from the fact that open source is all hosted there.

Edith: So here's a question then for you. So you're the product manager for GitHub. You get a long list of requests for features from open source, which doesn't pay you anything. On the other hand, you have a list of requests from enterprise customers, and you're trying to put together your own map.

Paul: Well, so yeah, I agree that there's certainly a temptation to say, fuck it, these guys are paying us money.

And I think this is one of the very difficult lines to straddle. When you have that group of customers, you have to be very careful to keep them happy and to keep them there. And you can't please everybody and you can't do everything and you can't acquiesce to demands and that sort of thing.

But if open source was to leave GitHub, there's an existential crisis for GitHub.

Nadia: Yep, totally. I think it's just a balance that they're trying to find right now.

Because this has been written about publicly too, in articles and stuff, just about internally right now on GitHub. There's sort of this tension between do we double down on enterprise, but if we do too much of that, then we forget our... There's just a little bit of turmoil, executives changing positions and stuff.

And I think they're just gonna have to try to figure it out, because they realize that, yeah, we might not directly make money. And this is kind of true of open source businesses too, right?

We might not directly make money off of that community, but without that community, the rest of it's kind of meaningless.

Sean: So I will say one benefit of GitHub, and I think the genius of GitHub actually, is that they've actually turned corporate software to look more like the open source projects. You go back before GitHub, right? Most closed source projects were managed much differently than open source, but today everybody's on GitHub.

We're all doing pull requests. We're basically using open source software methodologies for closed source, which actually is in the favor of open source because it makes it seem less different. It doesn't seem strange. It's not a different way of thinking.

Paul: And it's actually interesting that there's a lot of the closed source methodology that people want GitHub to allow that GitHub refuses to allow. So for tighter integration with Jira, or replacing the issues, or replacing pull requests with something that involves more code review, or that sort of thing, GitHub is saying, no, this is the way to do it. And so people, as you say, they end up much closer to open source than they would end up otherwise.

Edith: I would say that pull requests have helped fuel continuous delivery.

Paul: Continuous delivery! What a coincidence! What are the chances? Wow!

Sean: I would also argue open source is fuel continuous delivery.

Edith: Oh, well, all right. Let's hear this.

Sean: Yes. I have nothing to back that up. I would say that.

Edith: You're gonna argue.

Sean: I didn't say I was gonna argue that, I would say this.

Paul: So I think it's interesting, because people use continuous delivery when you want to deliver continuously. Open source fundamentally doesn't do that. For the most part, people release with almost Byzantine release models of, we'll release something with a version number every quarter, or whatever that thing is.

If you're using small projects, the small projects will tend to, you make a pull request, there's a new feature, goes in or whatever, and then you're like, oh, I'd like to release a new one. And so you make a pull request with a new number, that sort of thing.

And that is almost close to continuous delivery, except it's not actually continuous. There's no actual infrastructure, there's no automation. So yeah, I think open source isn't contributed to frequently enough to have continuous delivery, and are generally not continuously delivered.

Sean: Although it's really hard to... This is a topic from another side. It's hard to have continuously delivered downloadable software, right? Because once I downloaded it...

Paul: Every single version of the software gets tagged with a branch name or a SHA,

Sean: or there's nightly builds and stable builds on most of these projects.

Paul: Yeah, nightly and stable is continuous delivery. I would argue that they don't exist for most of these projects. I would argue they occasionally exist on the larger projects.

Sean: Well, when they start making money, maybe they will.

Edith: Look at that. Tied it all together. Wait, I thought you had an anecdote you were gonna share.

Lawyers Versus Linux

Sean: So this is completely off topic, but a long time ago, when I used to work at Verizon, this would have been fifteen... I don't know, long time ago.

Nadia: Did they have a hotline commercial?

Sean: Yes. So anyway, back when I used to work at Verizon, this is the phone company. I was a big proponent of open source at Verizon.

And this is back when Linux was like, oh, scary stuff, what is that? And the big tagline was, Linux is not ready for prime time. This was the big thing. Like, oh, you can't use it in production because Linux is not ready for prime time.

And here was Sean saying, Linux is ready for prime time. And I managed to succeed in creating this little bubble inside Verizon of, let's use open source. Let's get it through. And I actually was invited to speak at a Linux conference here.

The first time I've ever been to San Francisco, right? I lived in the Northeast, I'd never been to California. I flew all the way to San Francisco to speak at a Linux conference.

And they weren't even that big. This is maybe four rooms in one of the hotels around here.

And I got here and my talk was starting in an hour, and I got a phone call from my boss, saying that the lawyers at Verizon were afraid that they were gonna get sued, because this is back when people were suing you if you use Linux, because it was infringing on the patents of other companies.

Edith: That's crazy.

Sean: And I got prohibited from going on stage, because I flew all the way here, an hour before my talk, they're like, you can't go on stage, because if you go on stage, people will sue us, because they'll hear you talking about the fact that you live.

Paul: That is a phone call that you don't answer. An hour before any talk, you do not answer the phone from your boss.

Edith: This is why when Paul and I go on speeches, I try to get a hold of him and he's like...

Sean: I thought they were calling to wish me luck. I didn't think they were gonna be like, nope, sorry, nope, you can't go on. So let's all admit we've come farther than that, which is great.

Paul: So funny, a similar thing happened to me. One of my first internships was, I was working at Sony in London, Sony Computer Entertainment Europe, and my job was to port the EyeToy driver to PS2 Linux, which was the open source hobbyist version of Linux.

And I made the transition. Or I ported it, whatever, and we went to release it, and we did release it. And then the Monday after, I got an email from my boss saying, sorry, we had to pull it.

The lawyers didn't particularly like this, and it was an actual IP issue. It wasn't like an "eff, we're afraid of open source" issue, it was like someone else owned the library that had been ported, and there was some magic numbers in there, and so we were going to do something where there was two kernel modules instead. It never got done. But yeah, lawyers. Yeah, there we go.

Sean: So if we agree we're gonna get rid of all the lawyers, we're gonna pay all the open source people.

Edith: We've got regardress of this podcast. So you have moved to San Francisco.

Paul: We're gonna use the money that we used to pay the lawyers to pay the open source people.

Sean: What would we do with all that? There's too much money. We wouldn't have anything to do with it.

Is Open Source Venture Backable

Edith: So we haven't really touched on something that I actually was very curious about. You said in your article that you thought VCs were not willing to fund open source.

Nadia: I call it not venture backable. Well, specifically the infrastructure stuff I'm talking about, and I guess language is part of this problem. VCs backed plenty of open source businesses and plenty of infrastructure, especially stuff around DevOps and data infrastructure.

Obviously you guys are both venture backed, and so... or you guys. You can't see where my hands are going. But yeah, absolutely there's a place for venture and open source.

Paul: They backed NPM.

Nadia: That's right. Yep, they did.

But I think it was...

Paul: Is that not infrastructure?

Nadia: It is absolutely infrastructure. I think that it's in our best interest, especially looking at the history of open source, to keep it a public good, for better or worse terminology, in the sense that we're all benefiting and we're all using it, and so it should be something that is a tool that anybody can pick up and use.

Paul: This sounds like communism.

Nadia: I'm so sorry, I got distracted by the door and I said the word public good. I should have never said it, I take it back.

Sean: I agree. Venture backable is a right way to think about it, because the reality is most of these really valuable, I don't want to call them infrastructure, I'm gonna call them really valuable open source projects, are not gonna grow fast enough to have venture backed returns. Venture backed returns are very specific kind of business return.

Nadia: And some of them don't even have business models, period.

Sean: But even if they did, they just wouldn't grow fast. Python's been slow burning forever, right? This is not a fast growth business.

Ruby, the same thing. There's things that are so fundamental now that we use that just aren't fast growth, that are gonna produce venture backed returns, even if they had a business model associated with them. Ruby toil in obscurity for years until Rails came out. Let's be honest, these things are non-linear.

Paul: So this is funny, you talked in your tweets about people investing in programming languages, or, has anyone ever made money from programming languages? So my PhD was in compilers, and I remember being at a conference where I talked to one of the guys who made this, I wouldn't say important compiler, but it was a company that people had heard of, people in the compiler community had heard of.

And he said that eighty-five percent of compiler companies have one customer.

And the one customer was basically providing the services. They had a service contract with them. They were building it for that one customer who used it in one particular case.

Edith: That's not venture backable.

Paul: Not only is it not venture backable, but with compilers, and again, programming languages is the same sort of thing. You're competing with free, or you're competing with some other company who's providing it for some internal benefit that they have. The Googles of the world are contributing to GCC, Apple is contributing to LLVM.

If you come out with another C compiler, no one's going to make money off it. And so CircleCI is where I ended up, as the closest possible thing that could make money to being a compiler company.

Sean: That's great. I never heard the origin story before. That's awesome.

Edith: I'd like to say in full disclosure, Sean is actually an advisor and an investor in LaunchDarkly, so he obviously believes that we will have...

Sean: That's why Edith only says nice things about me.

Edith: He obviously believes that we will have exponential growth and pay for his kids' college education.

Sean: That'd be nice, 'cause it'd be expensive by then.

Paul: Education will be done by then. There won't be any universities.

Sean: That's true.

Paul: They will all have risen up to better soon.

Nadia: That sounds like communism.

Edith: Well, Paul is from Europe.

Paul: Our education is free.

Edith: I will say, I think there's a good distinction between a lifestyle and a VC-backed business. VCs want to get exponential returns because they're betting that of the ten companies they invest in, nine will probably fail and one will have to make up for all that return. So they're actually not looking for a steady 5% or 10% return a year.

Sean: Well, this is an interesting pathological case of open source. I don't think it happens very frequently, but let's take the example of NPM for a second, right? So you have Node comes out as a language and it's really interesting and has a lot of interesting things.

Paul: It's growing much faster than most other languages.

Sean: And growing really fast. And then you have NPM, which is a package manager for Node, which actually in some ways is more interesting and has more economic value than the language itself.

And so NPM can raise venture money. They can build a business around it. And this is an interesting, I don't think this happens very frequently, but this is an obvious case of economic disequilibrium, where NPM wouldn't have existed without Node, right?

And now actually NPM today actually does exist a little bit without Node. You can use it to manage packages that are not Node packages. But this company, if it sold for a billion dollars, right, what does it owe back to the Node community?

Paul: This goes back to your Red Hat.

Sean: Is it gonna be like, I'm gonna give you a bunch of shares and maybe you can buy a house or maybe a nice car while I go off and buy an island? Or how do you...

Paul: It's particularly funny since Node was built by Joyent, or with Joyent as their corporate sponsor, and before it was cast out into the whatever happened there. So who enjoys the economic goodness that came out from it? Is it the people who started it or is it Node or is it Joyent?

Edith: I mean, this actually has its roots in the 1600s where...

Nadia: Going way back.

Edith: Yeah, it was scientific discussions.

Sean: Source code back then was made on the frontier.

Edith: They had to use calfskin. No, the whole thing about the scientific community went through the same spasms of who really gets credit for a new discovery. What you said about NPM and Node, it's like, well, one wasn't possible, but the other amplified its effect. It's the same with discovery of calculus.

The famous quote was, I could do this because I stood on the shoulder of giants. We have the ability to build all these infrastructure companies now because we do have the foundation of languages, because we do have the foundation of compilers.

Paul: And it's giants on top of giants on top of giants at this point.

Edith: It's all turtles, dude.

Sean: Giants is about giants to giants or l-turtled.

Nadia: It's actually a great analogy. If we're gonna go back to the 1600s, I'll go back to the beginning.

Paul: It'll turn out there was a Medici at the end of it at some point.

Nadia: Yeah, that's right, you started this.

Open Source as a Highway System

But just comparing it to highways and cars in the United States, I actually wanted to write something about this as an allegory.

So we have an interstate highway system right now, right? You can take roads to go from one side of the country to the other. That happened in the fifties or sixties, it got started. But they've been trying to do it since I think the twenties.

Edith: It was actually communism was the reason why they did it.

Paul: I thought it was lobbying.

Edith: No, it was because they were afraid the Russians would invade and they needed it to get tanks quick.

Sean: I think it was aliens.

Paul: Not the other kind of communism. Not America's being communist to provide all these things. It's like fear of communism.

Nadia: That's part of it. There is also another part of it, which was that cars started in the late 1800s or whatever and they weren't really being... They were slowly kind of growing, right, but they hadn't hit a point of really being used by consumers everywhere. And suddenly after World War Two we had sort of mass production happening and everyone was like, all right, we want to be able to drive anywhere and do anything with these roads, but it was a really shitty system.

And so Eisenhower ended up championing it during his presidency, and the argument that he made for it, an interstate highway system, was really similar to, I guess, the need for better infrastructure with open source too, which was, if we can connect everything together, so much more prosperity can happen on top of this highway system. So it's not just consumers driving together or citizens driving around and seeing each other, but it's also trucking companies can drive across and transport goods from one place to another. Tons of people are gonna make money off of having a more efficient system.

Paul: Well, so to perhaps draw a failure in this analogy, there was a very convenient federal system that was already taxing all the people that could actually build this thing. And I don't think that...

Nadia: That's what I think.

Paul: So are you suggesting that this should exist in open source?

Nadia: It should. Yeah, sorry, just to clarify, I don't believe we should have this sort of unified, whatever, centralized system.

Paul: Federal government. The form's wrapped it up, actually.

Nadia: Yeah, just want to clarify this point. I just mean that that was kind of the point, right? There was somebody to kind of step in and help fund it. But we all agree that this should exist.

Paul: And when we talk about the other thing... I think though if you were to build this federal system, I think VCs would fund that.

Nadia: Yeah, to be super clear, I do not want a federal system of the... yeah.

Sean: But I think that's a really good allegory because it brings up the most important point. It took the only proven wealth redistribution mechanism we know, which is government, to do that, right? So the reality is we're probably not gonna have government step in open source. But we've never seen a privatized wealth redistribution at that scale work.

Paul: We do have governments in open source. We have governing bodies, there's the Apache stuff.

Edith: But they don't have taxation rights.

Paul: They could have...

Sean: I wasn't referring to government as governance. I was saying wealth redistribution was the idea of taxation and...

Paul: Those foundations and communities are receiving money from the member organizations.

Sean: I'm talking about the scale of all, if Apache was all of open source, I think that would be true. But we're talking about a larger undertaking here, right?

Nadia: It kind of goes back to that united way of open source.

Paul: There's a model here that could grow into a united way of, potentially...

Edith: I'd say one more thing, I love Nadia's analogy. There's a huge issue right now that all these bridges were built in the 1950s and '60s. And they're crumbling now. Because it's one of those things where...

Sean: Because we're supposed to have flying cars. Let me just throw that out there.

Nadia: Drones don't need roads anymore.

Edith: No, it's a issue, it's very much like open source. It's like this issue of deferred maintenance and it's somebody else's problem. And all of a sudden these bridges that were rated for fifty years, their fifty years are here.

Nadia: And the funny thing about physical infrastructure like bridges is it's one of the few issues that everybody, no matter how you politically affiliate, everybody agrees that we should have a better infrastructure system. So it's very non-threatening politically. But they still don't get done because it's not a sexy topic and no one wants to fund maintenance.

But even with open source infrastructure, we don't even all agree that this needs to happen. I think that's kinda the first step, is that, all right, we do need to figure out how to support it. What that looks like, we can talk about that, but...

Paul: If we can't agree why we need to support it, and I think that there is quite some disagreements over that, then we're never gonna agree on how.

Would Projects Want the Help

Sean: Is there the flip side? Is it true that all open source projects would welcome this kind of... I'm just thinking of the case of Hudson, right? So Hudson was an open source continuous build server that was ostensibly run by the community that Oracle tried to...

Paul: It's one of these old ones. It doesn't work very well. And it's not...

Sean: You should go to CircleCI, go to circleci.com, sign up. If you use the code Sean Byrnes, you actually have to pay 10% more, so don't use that one.

But the idea was Oracle was like the parent company and they were like, forget you, we're renaming it Jenkins and we're creating a new one, right? And so they actually resisted having, I don't know what you would call it, like...

Paul: Corporate overlord.

Sean: Corporate overlord. And so I wonder if even if this did exist, if it is a universal case that all projects would, the important ones, right, would accept this kind of help on terms that were not theirs. Would they, if we could even do it, if we could snap our fingers?

Nadia: Yeah, we absolutely should not do it on terms that are not theirs. I think the question is not do all projects need it, but do enough important ones need it that this is worth looking at.

Paul: What are the terms that people want?

Sean: Let me be more specific. Would they accept them on similar enough terms that you could have a generalizable solution, is more what I mean. I agree with you that we shouldn't dictate to them, but the problem is if they all want it slightly differently, there is no general solution then.

Nadia: Yeah. I think that's actually one of the hardest parts is that every ecosystem is different. Everyone has different needs and different histories. And so you can't just say, here's a million dollars, it's fixed now, right?

And I think that's kind of the fun part. I think of it as open source infrastructure needs a developer evangelism team. Or it needs a community manager or something, right?

Paul: Or a sales team.

Nadia: Or a sales team.

Edith: Or is this more and more like a corporation?

Sean: It needs HR and finance.

Nadia: I think of it more as stewards, and coming from a nonprofit background, I guess I think of it as stewards and advocacy, not sales and product and being the shit out of this.

Paul: Open source needs sales and product more than it needs anything else.

Sean: It's funny because we always project what we... I actually can see it from Nadia's perspective when we're in nonprofits, and I can see from your perspective working in for-profit. I think there's often a tendency, let's superimpose what's worked on open source, because clearly open source is not working.

The problem is, I don't even know if that's a solution, right? Do we need something that's totally new, something that we have never seen before? Like communism.

A Million Dollars for Python

Paul: So let's suppose a million dollars arrive tomorrow for Python, right? Let's say a million dollars a year arrive tomorrow for the use of Python.

How would that be used? How would it be distributed? What are the conditions by which people get paid by this? Who gets paid by it? How does that work?

Edith: Do we pay out everybody who once contributed?

Nadia: That's hard too, because I think this has happened with grants in the past, or even right now for open source projects, where they'll give them a grant for three years, for example, but then it's like, well, what happens after those three years? And that's even a problem in nonprofits and philanthropy, right?

You don't want to just sort of get somebody hooked to this drip of capital and they just need the money over and over, and there has to be some sort of integration into sustainability and impact. And so I don't have any magical answers.

I think that the one commonality that I've seen across a lot of projects that need more support is that there isn't any sort of non-coding function that's really celebrated or encouraged.

Paul: Right, right, right. Yeah. There's no love for product management.

Nadia: Or even documentation to help people get started. So it's like, why aren't people contributing? Well, maybe because they can't figure out how to get started, right? And so investing into those kinds of things, maybe it's not always about direct payment or whatever, but it's like, how can we help build the ecosystem around the code so that it's then easier to kind of pick up and contribute to it?

Paul: So to ask it a different way, if the people who are looking for the money had their way, how would it be spent?

Nadia: It really depends on the people, which I think is part of the problem.

Paul: What have some people said? Or what's the biggest opinion, or the top two or something?

Nadia: The maintainers themselves have, I think, a pretty straightforward approach to it, which is, we want a salary for this. And I don't think they put as much thought maybe into how that actually works, and that's the part that I'm trying to sort out.

Paul: So the top five or ten people get a proper Silicon Valley wage out of it, or...

Nadia: Yeah. Or just even being able to pay rent and take care of their families, basic stuff.

Paul: And so they want to be able to work on it full time, and so work for, let's say, Python or something, versus working for Heroku on Python.

Nadia: Right. And so one thing that I think might help in the short term is matching up some of those maintainers with companies that are willing to hire them to work full-time on their projects, because that is happening right now already. And I think sometimes, when I've talked to developers who've tried to negotiate that for themselves with companies.

Edith: It's a really tough sell. So you're basically saying, hey, hire me to not work on anything that...

Nadia: Exactly. And it happens right now. It's already a practice.

Paul: I think when that happens, it happens because there's a company that already knows the value of doing this. And so they try to recruit that person rather, and often they'll negotiate a fifty-fifty, like with Guido at Google. Well, he's now at Dropbox, but originally when he went to Google, there was like a fifty-fifty time thing.

Edith: So I actually had a follow-up question for both of you. One was for Paul, and it's interesting because you come from a developer background. Why are you advocating for sales and marketing for open source?

Paul: Because people don't donate, so you need a sales team to go and get those donations. And I think that there's no doubt that if you showed up at a bunch of unicorns' doors and said, here's the risk factors that you face, here's the economic downside...

Edith: I've seen this in a movie and it was set with the mafia.

Sean: I'd actually rather go to the Fortune 500, because the unicorns are looking at the stock market being like, shit, shit, shit.

Paul: Maybe it's the Fortune 500s. But you turn up with people who have both money and risk on a certain problem, and you put a dollar value on that risk and you say, here's what you should do to mitigate that risk. And no one is saying, we'll put a horse's head in your bed.

But we're saying, you can donate or you can not donate, and here's the risk, here's the Heartbleed thing that happened, or here's what happens if all the credit cards in your system, which are being protected by this thing which is one maintainer only on Tuesdays... Then you can say, give us some money, and then you can direct the money to good places. And there's this questions as to how the good places need to go, but getting the money in, I think, is the first thing, and then you can have the conversation about how should we actually spend it.

Edith: I think this is fascinating because always the sell for developer tools is developers don't want sales or marketing, they just want to use it.

Paul: No, you're right. Developers don't want sales and marketing. What you need sales for is to make an enterprise sale. You need to find the champions within the organization, you need to find the people with the purse strings, and you need to make an economic case to them as to why they should spend it.

Edith: An offer they can't refuse.

Paul: And make an economic case as to why they should spend the money.

Edith: Man, your infrastructure is looking pretty rickety.

Sean: That's awesome.

Paul: And then you have to keep the process going.

Edith: So you gotta come around every week and keep...

Paul: Yeah, make sure that they're happy. Okay, well this stands exactly.

Sean: I'm pretty sure horse head was HTTP code 702 or something like that.

Paul: But that's fundamentally a sales process and it's not like a developer process. You can't just say, oh, this should happen, and expect a company to do it, or expect developers within an organization to try and make that happen.

There's a specific skill set to managing this process, to getting that money out of people, and to signing all the things, and that's called sales. That's what salespeople do.

Nadia: That I'm totally on board with.

Why Capitalism Doesn't Kick In

Sean: So why is it, this one last question, which is, if there is so much economic disequilibrium that exists, so much friction exists between these projects that people are working on and open source that are reliant in these large companies, why is it that capitalism doesn't kick in and companies do erupt? Even if it's not the maintainers, somebody else, like a side company, erupts to mitigate the risk the large companies feel.

So that jump up and fill that gap, because there is this potential, if there is this money, that the risk has economic value, capitalism would dictate that companies would erupt into this void, even if it's not the maintainers, so there's a couple of fill it.

Paul: A couple of ones that have. So for example, Ruby stopped maintaining, I don't know, version two point three, or maybe it was Rails stopped maintaining version two point three, and this German company came in and said, there's a bunch of companies who are stuck in Rails two point three. We are going to support Rails 2.3, we're gonna backport security fixes and all that sort of thing.

And they sold licenses for, I think it was ten thousand dollars a year or something along those lines. They got a ton of customers and they made a ton of money.

Edith: That's right. I think another thing is that the risk is so dispersed. So basically, my mafia jokes have said, what you're selling is insurance, but it's not insurance on any one given point of it. We're kinda back to the United States of infrastructure.

To have some...

Paul: Someone will fix your pothole.

Edith: Yeah. Well, but to have seventy different people come by your office to advocate for their little corners, not sustainable, there's not enough economy scale.

Sean: If people did know, if they knew exactly how much money was out there, would the void be filled by... Is it merely a communication problem? Would companies just erupt around these problems?

Edith: To me it goes back to uni-economic scale. So if you're hiring a salesperson to go and extract 20 bucks from like three million different companies, that's not enough to afford a salesperson.

Paul: And I think there's a related thing to this, that developers don't want to make companies and they don't want to sell. They like to write code and they like to write software, and often don't know how to take the value that they bring and attach a price tag to it and find the people who will pay that price tag.

Edith: Well, Sean, actually you're a developer and you started a company.

Sean: Well, I will say that I think that a lot of developers don't know how. I don't know that they do it because they don't want to. They just wouldn't even know how when put in that position.

Nadia: That's something I hear over and over and over again from developers, is like, I would really, really love if someone would pay me for this, and however you want to pay them. But I just don't even know where to start. I don't know where to go.

Paul: Even, I think, if they did know where to start, the work starts to look significantly different than the work that they actually want to do. So as you know, we've all started companies, we know what that's like.

You don't write code when you're starting a company. You talk to customers, you work on product, you hire people, you raise money, and very, very little of it actually looks like that.

Sean: You go to the Institute of Open Source, you fill out your triplicate forms.

Documentation and Final Words

Edith: I think we're close to time, and my last question for Nadia is tied in. You said something interesting about technical documentation.

Nadia: Yeah, I just thought of it as an example of, people might disagree around sales and marketing or get kind of freaked out by those terms, but even documentation I think of as something that's not literally writing code, but it's extremely important just to help people communicate with each other, right? And so it's kind of a technical and acknowledged function in open source, but that doesn't always get enough love.

Edith: I think it's also, I'll say it up front, technical documentation never gets much love.

Nadia: Never does, yeah. And yet, how do you get started with a new project? You read, right?

Paul: This is why people hire people to write documentation. Because developers like to write code, they don't like to write documentation, and they don't have particularly good skill sets at it. So you need people who have that skill set.

Sean: And next week we talk about continuous documentation.

Edith: Well, I'd like to give a huge thank you to our two guests. This was the first time we had two guests. So, any final words?

Sean: Go open source, support your favorite projects.

Nadia: Yeah, what he said.

Paul: Thanks for listening to this episode of To Be Continuous, brought to you by Heavybit and hosted by me, Paul Biggar of CircleCI, and Edith Harbaugh of LaunchDarkly.

Edith: To learn more about Heavybit, visit heavybit.com. While you're there, check out their library, home to great educational talks from other developer company founders and industry leaders.