DOP 292: No Project Is Truly Open Source
32:52 Share

Morally, I think that a license should never be changed of anything to be less permissive. That's my rule. You want to change, make it more permissive, not less. You made business because it was permissive, now you don't like it? Well, you are allowed to do that, and I am allowed never to use you again. This is DevOps Paradox, episode number 292. No project is truly open source.

Welcome to DevOps Paradox. This is a podcast about random stuff in which we, Darren and Victor, pretend we know what we're talking about. Most of the time, we mask our ignorance by putting the word DevOps everywhere we can and mix it with random buzzwords like Kubernetes, serverless, CICD, team productivity, islands of happiness, and other fancy expressions that make us sound like we know what we're doing.

Occasionally, we invite guests who do know something, but we do not do that often since they might make us look incompetent. The truth is out there, and there is no way we are going to find it. P.S. It's Darren reading this text and feeling embarrassed that Victor made me do it.

Here are your hosts, Darren Pope and Victor Farsen. Back on August 19th, 2024, Victor put out a video on the DevOps Toolkit channel talking about open source. And if you haven't watched it, I'll have a link to it down in the episode description. Victor, do you even remember that far back? That's been a couple months, but do you remember the gist of it real quick? I know the gist of it. Now, if you ask me about the details, that's long gone.

I don't know what they said, but I know what they think about it. So I guess that's good enough. Can you give us a 20, 30 second gist of what that video is about? Because we're going to find that a lot of things have happened since you first did that video.

Quite a few things. One is that open source, I think in vast majority of cases, is a go-to-market mechanism. It's not that companies pour hundreds of thousands of millions into open source because they are nice. It's a way how companies penetrate market. It's a go-to-market strategy.

That's important to be understood. That's not necessarily bad, just to be clear. Everybody benefits from open source. But that part is important to understand that there is no open source without finances. There are no finances without business.

When you understand all that, then news that we tend to receive fairly often now about changes of licenses or changes of some processes and so on and so forth in open source feel different or are understood different when we understand that open source is not done by contributors. That's the important part. Unless it is a very, very, very small project.

Okay, that's the 60-second gist. Thank you for going a little over for us. Since August 19th of 2024, there has been yet another big open source thing to hit the fan. Let's put it politely. WordPress has done some very interesting things, just sort of like in a, they're doing a rug pull, but it's interesting that it's actually the open source project doing the rug pull this time instead of the companies doing the rug pull.

Yeah, but it's open source, right? Open source projects tend to be controlled by companies. So when we say open source is doing this and that, is it really contributors or dedicated maintainers which happen to work for a company? I was trying to build up a little bit, but I don't want the lawyers coming after us. So we're going to keep it nice. You can go look up on the internet about everything that's happened with WordPress and WP Engine. That's all we're going to talk about. But the key part to this is...

This, I think, is going to keep continuing on. We'll talk more about that in a few episodes. But if people think that open source is free, free as in beer, that can still be true. And as you said, in a very small project. Free for using open source. Yeah, it's free. It's not free to develop. That's the important part. Well, that's the question I have now. Since we now live in this world of AI and we've seen rumblings that

some of the large hyperscalers are saying that most of their code, or not most, a good majority of their code is being written completely by AI now. I don't believe it, but let's assume that's true. Couldn't we just have AI agents write all the new open source? First of all, I haven't seen any evidence or indication that AI is writing something significantly new, right? It's getting, getting, not there yet, but getting pretty good to

do what has been done many times before, right? Because that's what it does, right? It knows the source code of a significant number of projects and it can do again what has been done before, right? Which is not the same, right? I sincerely doubt that let's say that you're building an open source project that is going to be based on some kind of plugin mechanism and you want to design it in a better way than projects before you.

I sincerely doubt that AI is going to do that. Figure out new, better way to do something. Now, you can easily do things or help us do things that have been done many times before, but hey, that's the easy part. So going back to the title of your video, The Dark Side of Open Source. I had to look it up there. The Dark Side of Open Source. Let's talk about some of the points that you talked about in that video. Because I want to pull a few strings.

You can't have completely free open source without somebody working on it, right? You're not going to have open source software unless somebody has actually written the software. Yes. So free as in investment, not free as in usage, right? Correct. An investment. So even if somebody was just doing it on their spare time on the weekends, that's still an investment they gave of their time. They could have been playing with their kids, watching football,

But there is a difference between somebody's investment given up for free and someone's investment with some expectation of return. So let's say that you have a relatively small Opusos project, let's say Node.js library, right? Something that effectively a person can do over a few weekends.

I think it's reasonable to expect that that person just did it because that's a nice person and is giving it away for free forever. I have no interest in it. This is my hobby. There was investment, but there is no expectation behind that investment except maybe some personal glory, right? And you have a different situation, let's say bigger project, project of a size that requires dedicated maintainers in plural.

Now, when we have dedicated maintainers, then that investment comes from somewhere because those people will need salaries and they're going to, I'm going to use a silly term, borrow money to be able to finance themselves living while doing that. And that means that somebody gave money and that somebody expects something in return. Not necessarily in terms of, hey, this is going to stop being free.

I think that no open source project should ever change the license, just to be 100% clear. But hey, maybe this will lead to a certain adoption and maybe we can build some enterprise features or enterprise layers or maybe that same thing as a service. There are many different ways how that can be monetized while still keeping it open source. It's always investment in time, but sometimes that time is financed by borrowed money.

And sometimes it's not. And usually the size of the project dictates whether it's one or the other. Let's go with the size of the project. If I am borrowing money to try to build my small little project in hopes that I might be able to sell some contracts, is that a good or a bad use of borrowing money? I mean, I'm assuming that we're talking about money that is really not real money, but

I'm going to do this over weekends, or maybe I'm going to do that work four days a week instead of five, things like that, right? So it's time investment rather than money, assuming that I understood your scenario well. My scenario was actually money. I'm going to go to the bank. I'm going to get a bridge loan to make sure I don't have to go work in an office for anybody else. I'm going to work on it for six months, and I hope...

at the end, and I'm using the word hope very specifically, I hope at the end of six months that I'm going to be able to sell it to somebody. It's tough. It's tough with open source because there is a tremendous competition, right? Now, of course, you can find a niche

And that would be amazing, right? Something that only you thought of that is not going to have some amazing number of users, but enough, right? To either make you famous or somehow earn you money, right? But more often than not, if you start an open source project with the idea that that open source project will succeed, excluding tiny ones,

You're competing with other projects that are financed, well financed. I'm talking about VC money, seven digits amounts. And then how will you compete? You need to have some really brilliant ideas, something really different to succeed in that way, either without borrowing money or borrowing from a bank. Because borrowing from a bank is not going to give you $1 million. And let's say that you can borrow $50K, $100K. That's not going to last you a year.

This isn't the late 90s anymore, where money was just being thrown at any possible idea like a sock puppet. Oh, that's a different thing, right? Money is thrown, but first of all, not by banks, but by VCs. And also, mostly, there are two circumstances, generally speaking, how you can get money from VCs. One is that

You have an idea that is very much related to the current hype that everybody wants to jump in. Or you have the ability to demonstrate how this will become profitable in a decent amount of time. Because most projects take years, sometimes decades, to actually start turning more than the investment in them.

And in the first category, you need to jump into some hype, right? And then the money keeps flowing. And that hype today, for example, that's AI, right? If you want to get VC money, either demonstrate how that project is going to return money fairly quickly, or you're in one of the hypes. I'm going to throw this out there because I think this could be a hype.

Laravel, one of the PHP frameworks recently raised a series A at $57 million. I don't know on what valuation. Let's think about it for a second. A PHP framework. It could have been a Go framework. It could have been a Ruby framework. It could have been whatever. $57 million. What would you expect as the VC giving them that money? How much money would you expect coming back out of that?

57 million investment. I mean, we're talking about 5x, 10x. So you're talking a half a billion dollars, if not more? Yes. Do you see a PHP framework bringing in that much money? What's going to happen? How is that even going to be monetized? You're going to sell support contracts? I mean, I'm not either. But that's the thing is...

I'm glad for them. I'm glad they could raise the money, but boy, I don't know how they're going to make it work. Support contracts are almost never the way how to earn the money that is expected if you take VC money, simply because they don't scale. Imagine, how are you going to earn? Okay, let's be generous and say not half a billion, but 200 million. Or let's say 100 million a year.

That's a reasonable expectation a couple of years later after that amount of money that was there. Half a mil a year through support is close to impossible. Now, when people say, sorry, did I say half a mil? 100 mil. That's close to impossible. And you will probably turn 100 mil in support...

You will have to have like a couple of hundred people, right? Because there is a limit to how much you can charge and how many hours you can bill. Support is not a good idea. Support is actually a very good idea if you want to start your own business, right? I'm not talking about no VC money, no 10x return on the investment. Then support could be, or consulting in some form can be a great thing.

Not when you accept VC money. It doesn't pay off. It's probably good when you're in between phase, yes. Many startups start with support contracts and so on and so forth, but eventually that needs to change. Well, I'm thinking about what would be the product out of a framework. Maybe there's some enterprise features for a framework, but riddle me this. How many enterprises are actually using PHP as their core development language?

Probably a lot. I'm not that familiar with PHP, but I would go on a limb and say that it's probably. I wouldn't be surprised that in enterprises, it would be like third or fourth or fifth most common language. Far behind, not the top three, that I'm sure, right? But it's relatively big. But I'm not familiar enough with Laravel to know, right? Well, again, going back to your number, let's say it was even 100 million a year.

You're not going to get that from somebody hacking on PHP on the weekends. No. That is not your core target audience to sell to. And again, I haven't looked at see how they're going to do it, but I'm just theorizing right now that I don't know any other way to do it except to go after the enterprise. And on top of that, the tools for developers themselves, and in this context, when I say developer, I don't mean you write code, but I mean end user developers or

however you would call it, right? People working on PHP applications in this case, they are probably the worst buyers. It's very, very hard to sell to developers. It's easier to sell probably to 100 times smaller number of people in the same organization working on something else. Security, infrastructure, anything else. Selling to developers, even though they're the most numerous in companies, is very, very hard on top of everything else.

Developer tooling is hard to pay for, especially since, can we say probably since Eclipse? Eclipse was probably one of the very first tools that everybody just sort of said, I don't have to pay for my IDE anymore. I mean, it doesn't mean it was good, but it was free. There are some success stories. JetBrains was a success story at the time, I hope. And I haven't looked at their financials, so I cannot be certain, right?

Docker is probably another success story that targets developers as well. But those are more outliers than rules. Let's go back to the WordPress story, high level, because I haven't read it that close. But from what I have understood is Matt, who came up with WordPress, went after a company, WP Engine, because they weren't giving back enough to the project.

I'm not going to tell the story more than that because I'm just making things up beyond that point. But that's the core as I understand it. But that's not a unique story. There's lots of open source developers that I have heard of that get ticked off when a company takes the software that they have created and doesn't pay for it, even though they have permissively licensed it with MIT or Apache or even a GPL. But that's their right, right? Which is who's right.

Not to pay for it. Correct. If it's permissively licensed, it is completely legit. And so I would have to fault, I'm air quoting fault, the open source developer that has produced the software that if you were expecting money in return, you should have been selling it from the first place and not open sourcing it. There is a company...

behind WordPress, what is it, WordPress.com, right? Well, automatic, yes. Automatic, exactly. And they're not earning trivial amount of money. They are getting competition that is potentially investing less than them, but they're not earning trivial money. So it's not kind of open source against corporation. It's realistically corporation against corporation or company against company in this situation, right? Where one company...

maybe not officially, but in practice controls that open source and at the same time is the major contributor. And that's a tough one because that company is putting blood and sweat into that open source project. And it's very depressing and challenging when somebody just comes in and says, you know what, I can earn money from this project as well without investing much in it. That's one side of the story. But the other side of the story is also that

The first company controls that project, dictates or decides what goes in, what doesn't. There is rarely a project like that. And I might be completely wrong, so listeners, please let me know if I'm wrong. But most of the projects in situation like WordPress is right now are projects that are open source, but also tightly controlled by a company. There are both good and bad sides in both stories, right? How do you effectively contribute something

And I'm not talking about the core project, not necessarily plugins to WordPress. How do you contribute in a way that will move you forward with your business when those contributions are controlled and a company decides what goes in and what doesn't? When it's not truly open source, because no project is truly open source. But the projects that are closest to open source, and I think that this is the key point here that we need to start thinking about,

are projects that are in a foundation. And then we have foundation acting as arbiter, figuring out how the project can move forward and not a company. I'm not talking about WordPress now. I'm talking in general, right? There is a big difference between project owned by a company, even though it's open source, and project being in a foundation. Huge. And I feel that, especially when contributions are concerned, we are going to see...

More and more talks about that, that projects should go to foundation. I mean, I work a lot with CNCF, right? But let's change. Let's say Apache Foundation, right? Put WordPress to Apache Foundation. I think that that would be the first step, and then we talk about it. I agree. I think about another project that's not open source, but is public domain, and that's SQLite, or however you want to pronounce it. I heard today that's actually SQLite.com.

Like Meteorite, SQLite. Okay. I'll go with that. One of those. One of those. It's close enough. But we know what we're talking about. There are three people that work on that project. They do not accept. So it is source available. It is public domain. But they don't accept patches. They don't accept contributions. They do accept security findings, but they're not going to take code from you.

To me, that is, I heard this phrase as well recently too, benevolent dictator for life. The BDFL license, for lack of a better term. So being a benevolent dictator, you've got a person or a very small set of people that completely control sort of things like Linux as well. Does Linus allow everything in? I don't think so. Yeah, but Linus is probably the most important person

in Linux lifecycle development, whatever you want to call it. But Linux is in a foundation. If there is a conflict between Linus and somebody else, or other people in plural, there is a foundation who can resolve that conflict. Not necessarily always in the best way and so on and so forth, but there is a semi-neutral organization that can be an arbiter there. This is a parallel example. Let's say that

Like many different examples we've seen in the past, not the recent past. Let's say that Linus, as a person, decides to change the license of Linux. Do you think that's possible? I think anything is possible. Theoretically, yeah. But the point I'm trying to make is that Linus does not own Linux. Linux Foundation owns Linux.

Or Linux Co., or whatever would be his company, also does not own Linux. That's the point I'm trying to make. There is always an owner of a project, and that owner can be a foundation or a company. So is that something that I need as a consumer of an open source project? Is that something I really need to be looking at? Is who truly owns the software that I'm thinking about running?

It's not necessarily the only thing you should be looking at, but who owns the project is definitely one of the important things. Assuming that that's something that is critical for your company, right? Or whatever you're doing. There are projects that, hey, I'm using this library that indents my strings to the right side. I don't care whether something happened to it, I can rewrite it easily, right?

But things like Linux, I'm just naming the biggest one. Yeah, your future depends on it as a company. You should choose carefully. So what you're saying is I should not go out on the weekends, find all the open source products I want to use, or let's make it even worse, find all the different NPM modules I want to install into my JavaScript app and just start using them because they'll be there tomorrow, right?

Yeah, it depends. Okay, let me try to find a better example. Since you're talking about libraries, and I'm probably going to say something silly because I'm about to talk about Java, which I don't know anymore that well, but choosing whether to use Spring is an important decision that can have very costly repercussions later on. Choosing whether to use a library in Java that

does something with string formatting, for example, right? Or something like that. That's not an important one. You can make a mistake. That's fine. Well, you could make a mistake, but more than likely you're going to make the mistake by pulling a library from the Apache Foundation because there's not that many other libraries that do what you just said. Exactly. So let's go to the opposite side of this. As the open source developer, I do not want my software

into a foundation because I view a foundation. This is not Darren talking. This is the developer talking. I view a foundation as controlled by committee. They're going to tell me what to do and how it's going to happen. And if I don't like it, I'm going to take my toys and go home. First of all, that's not true. Foundation, a project where you're the only person working on it and that project lands in a foundation, it's not fair.

People from foundation are going to spend endless hours telling you what to do. They won't. There will be certain rules that you need to meet. Yes. People start telling you what to do when other companies start seeing interest in that project. So what you said, Arjen, is right, but that comes later. Spring, which I mentioned before in foundation, which I guess probably it is, I'm not sure.

Then, yeah, there are many companies that have vested interest in it, right? But you start a project, you donate it somewhere. It's not the foundation that's going to spend time with you telling you what to do. Nah, it comes later. Well, that's just what I'm thinking about is I don't even want the chance of me being told what to do. That's fair enough. It is fair enough. But that means I need to make that decision up front. If I was initially thinking, oh, I'll get it into a foundation, I'll get all this help. Let me tell you something. You might get some help.

but you're not going to get magic levels of help. Oh, no. Just to be clear, right? If you just started a project and you think there is a future for that project, for you as a person, it makes perfect sense sometimes not to put it in foundation. You want to own that stuff. I understand that perfectly. Foundation makes zero sense, excluding the fact that

Adoption of your project is probably going to be much higher in a foundation because marketing, this or that. But it doesn't make sense for you as the owner of the project to put it there. But for me as a user, as long as I have good alternatives, it doesn't make sense to choose something that is not in a foundation. That's the point. Foundation benefits end users more than owners. If anything, owners lose.

They lose, but then they gain because if it's in a foundation, I sort of think of it like music or books. If I'm in a foundation, now I've got potential distribution channel that I didn't have before. Oh, yeah. And also, as a rule of thumb, and this is not always the case, right? The amount of contributions and real help you're going to get is likely going to be much higher if you're in foundation.

Let's say that I'm in a company, whichever company I'm in right now, and beyond whatever we are doing and working on seriously, we have interest to, let's say, to contribute to Kubernetes. We have interest to do that, and we do that. Now, if Kubernetes wouldn't be in the foundation, then we would think twice before we would start pouring our investment into

putting money because even somebody being assigned to work on it, that's still money that costs. We would think twice about it because I, as a company, I'm not going to invest in a project that is not in a foundation because my investment is a tricky one. I can invest a million in man hours into your project and you can say afterwards, you know what, I'm going to change the license and you cannot use it anymore.

That would be a very silly decision from me as a company. That's why projects in foundation tend to have much higher rate of contributions because companies are more willing to go there. Is there any reason why an open source project should not end up in a foundation other than the

It's a small and I want to keep total control over it. No, also if it's big, there is, again, most of what I said is me as a user and also the rate of growth of that project and what's not. But me as the owner of that project, the main reason is that I don't want to give away ownership of it. That's the main reason. So you want to keep all your toys? Yeah, it's my project. And you see that all around.

The issues we're having with companies changing licenses is because they own it and they feel they get benefits from having an opposite project. They build the business and then maybe sometime later somebody is going to threaten that business and they can simply say, you know what? I don't like you. You cannot make business on top of this opposite project because I'm going to change the license. I strongly believe that

Legally, you can change anything you want, including the license. But morally, I think that a license should never be changed of anything to be less permissive. That's my rule. You want to change, make it more permissive, not less. You made business because it was permissive, now you don't like it? Well, you are allowed to do that and I am allowed never to use you again.

You gave us the title for this episode. No project is truly open source. And that's how we're going to think about this. So what do you think? Are you going to make choices based on the hottest trending thing in GitHub and just pick it up and use it if it's not in a foundation? Do you realize what risks are there? Does your legal department realize what risks are there? Head over to the Slack workspace, go over to episode number 292 and leave your comments there.

We hope this episode was helpful to you. If you want to discuss it or ask a question, please reach out to us. Our contact information and a link to the Slack workspace are at devopsparadox.com slash contact. If you subscribe through Apple Podcasts, be sure to leave us a review there that helps other people discover this podcast. Go sign up right now at devopsparadox.com to receive an email whenever we drop the latest episode.

Thank you for listening to DevOps Paradox.