Open Source as a Business
CC Attribution 4.0 International:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Krenn, Philipp
How do you build a lasting and successful company that also stays true to its open source roots? This talk takes a look at why open source is important to business and three essential elements of this path. * Strategy: How can you monetize your open source product? Is it support, an open core approach, cloud services, or a combination of the three? And which ones are the features you can even commercialize without alienating your community? * Struggle: "You received a 100 million dollars in venture capital and yet you have so many open issues?!" Once money is involved the dynamics often change. How can you manage expectations and still build on a flourishing open source community? * Success: How do you balance open source and commercial success? How do you align engineering and sales decisions? This talk takes the perspective of Elastic, the company behind the open source products Elasticsearch, Kibana, Beats, and Logstash, which makes its money with support, the commercial extensions, and cloud offerings. But we are also taking a look at how others are approaching this challenge, what worked, and what failed.
 Hi, everyone. Since the title and everything was English, I will switch to English. I hope that's fine for everybody. I guess we'll manage. So I'm Philip. I want to talk a bit about open source and how to make money out of that or how to survive on it or however you can see that. So it can be a strategy. Sometimes it's a struggle. Some people even reach success, but that's another discussion. So we'll see where this goes. So when we say open source, since we're at an open source conference, I assume everybody is kind of familiar with what it means. The main thing is software that can be freely used, modified and shared. That's the open source.org definition. That's kind of like what most people accept that what is open source or what is not open source. If you're coming more from the Free Software Foundation, it's about the four freedoms. Use, study, share and improve code. So we'll just assume we all kind of know what is open source. I don't want to make the finer distinctions between the different licenses, but it's just about software or open source software in general. So I assume that everybody is using open source, right? Good. Everybody or almost everybody is open issues. Yes, yes. Who is contributing back? Okay, that's fewer already. That's kind of what you commonly see. I like this comic where when you ask like, who wants well maintained open source software, everybody raises their hand. Who wants to contribute back? Like people kind of lower their hand. And then you say like, who wants to actually maintain a project? Everybody is gone. That's sometimes what you see. Especially not here, like this conference is a bit of an outline in that regard, but there's a lot of other more commercial events. This is what you have. Like everybody uses open source software and everybody wants well maintained open source software, but the ones giving back or investing into it is kind of like a much smaller subset. So how can you keep that feasible? And the other thing is most of us probably want to be paid for doing their work. And there's this nice quote from the founder of Puppet who said like 98.5, however he came up with that number, percent of the code that they put into Puppet was put there by somebody who was paid to work on the project. So only a small fraction was actually buy volunteers. And even though a lot of the code is open source or pretty much everything is open source nowadays, they still paid a lot of people. So where do you get the money from? Because open source software is probably better than commercial software in every regard except for one thing and that is making money, which is a bit unfortunate. And generally open source is not a business model. Like I don't want to give that impression that you have to be a commercial entity and make money out of open source software. That's totally not the case. But in many cases, it's what people want to do for the sustainability of their projects. And for example, for the company I work for, our CEO always says like open source is a distribution model. And it's kind of a force multiplier. It's kind of like to get it out to people. Otherwise distribution of the software would be much harder if it wasn't open source. So it's kind of a precondition to get started. But it doesn't solve the problem of how to keep the company sustainable in the long run. And that's what we kind of want to look into now. Anybody knows this logo? Probably not. Anybody heard of Datomic? It's like this in the closure ecosystem, data stored, it was a pen only. It has some very fancy features. It is a great project. But what they didn't have is they didn't have an open source version. And we can probably argue why they kind of stagnated and never really breached out into the wider ecosystem. Probably multiple reasons. But one of them I think is that they didn't have an open source version. So yes, they do have a very weird licensing model. If you want to start, you can use their software and you get updates for one year. If you want to get any further updates after one year, you will need to pave them. Otherwise you're not allowed to get any updates anymore. And then you have commercial licenses. And I think one of the reasons why we're kind of stuck or are still stuck in kind of a niche is because they didn't have this broad open source base to build on. So where do I come in? I work for the company Elastic Search, LogStage, Kivana, Beast, those are all our products. And this is not only about our story of how we want to make money, but a bit of a broader talk of what are generally your options, how to make money, and also some of the more recent developments of what has been happening. So these are some of the open source products that we produce. And if you're using any of these sites behind the search box, there is our software doing the search. But none of them are paying us at the moment, I think. So why do we have a wide distribution because of that and lots of users? This doesn't give us any money back to keep working on the products. So the question is always, where is the money and how can you make money? By the way, does anybody make money out of open source software here? Three, four. Okay, we'll get back to you in the end. I'm curious what you do to make money. Because there are multiple approaches for better or worse. We don't probably agree on everything, but yeah, there are options. So what's the way do you want to spend your time? Because we have like 60 minutes or 55 now, and I probably have material for 90 minutes or more, and then we don't even have a discussion. So I could focus a bit more on the strategy of how can you even make money? The struggle is what are the current problems or what are the different parties involved in striving for that? And then we can just round it up in success at the end. Who would be more interested in the strategies and all the ways to make money in open source software? Who is more interested in the struggle part? You didn't help me much here. Okay, we'll start and we'll see where we can take this. Okay, strategy. So how can you make money out of open source software? Yeah? Just shout. So are these different business models like you can set some open core business model or you can also support? Yes, support is a good one. I have support on the one I want to start with. I'll just call it services and I'll, so the responses were support and other stuff. The one thing I want to focus on for the first thing, there are basically three big things how you can make money. And the first one I would kind of like put together out the services. It could be support, it can be consulting, training, you can offer some certification. It's anything that you do around the software to provide services. Popular examples for those. What are the big companies earning money with that? Reddit. Yes. Reddit for example, I have two examples here. The first one is Canonical. What are they doing? Yeah, that's the company behind Ubuntu and then obviously Reddit, which I don't know, is now IBM or Harvard to quantify that now. But they have been making money out of open source software for a long time. And they had this amazing graph where they showed that for 64 consecutive quarters, they had revenue growth on an open source business model. And it's just been going on and on and on and on and on. And now you could just say, well, this is easy. We'll just do what they have been doing and we'll just have the same growth for years to come and we'll be fine. Unfortunately it's not that easy. Support and services sometimes work, but they don't necessarily work. One thing that is interesting is the support problem. What happens if your product is too easy to use and nobody wants to pay for support because you don't need it? And then you have this unfortunate situation where you might want to have a product that is not too easy to use so somebody pays you for support. And it's kind of like a force field. You don't want to end up in the middle of that to survive. You need to make it a bit harder to use or your documentation worse. You don't want to end up in that place. The other big problem with support is generally renewal rates. Companies paying you, for example, on an annual basis, they will look after one or two or three years, they will look at what cases did we have, what did support solve for us? And then they might say, well, the product is working well. Why should we be paying you? Unless it constantly breaks and we really need you, why are we not saving money on that support subscription anymore? Or support because you don't know the product that well initially, but after three years you probably know how it works for you. Yes? Some companies want really to pay for software because it's kind of part of their policy because they cannot run any software which has no support even if the software runs. The point or remark was that some companies need to have that as a policy. Yes. I always call it the mafia model like insurance. You basically buy some protection and then you can shout at somebody for being responsible for whatever breaks. Yes? Yeah. If you're a bank or an insurance company, you probably, it's mandatory. Anything you use in production or like in some use cases, you will have to have support otherwise you're not doing that. Yes, why Reddit and others are still on the market. Yes. But maybe you don't want to go into that area. And also that is kind of like a limited segment. And you probably have to, you don't get the money for free. Like you have to, like enterprise software is not that much fun sometimes. So there is a reason why there is so much money in there. So maybe it works, but it doesn't work for everything and it doesn't work for every product. For example, if you're a video player, you don't really have a business model in there. Like you won't be able to survive on that. So some kind of tools and platforms or data stores or whatever will be able to survive there very well. Others will have a much harder time. Yeah? I think support is the second problem. Second problem is that you probably have to support old versions. The point or question was about supporting old versions. Yes. I think that's a bit like how desperate are you? Yes. So for our company, we have support policy of around 18 months or so. And then it's out of support. And we might help you, but it's pretty much best effort. And we will say like, you have to upgrade. Otherwise it's really broken and we cannot easily reproduce it. Support has its limits. So this is what I would say, when your best customer comes and says, I want to use ES2 or whatever, whatever. If you have a customer insisting on using very old versions, they will have to pay a lot. Yes. You just need to increase their pain as well. And then you just said you must make it more expensive just to get them sooner let out. Yes. I guess that the model there is you need to shift the pain from yourself supporting old versions to making it so expensive that you shift the pain to them. So that they move on at some point. I think that's kind of like the model where you need to push them. But yeah, that sales will see that very differently. That's more the engineering perspective. And the final problem kind of is what if you have somebody who doesn't provide the open source tooling, but just the services around it. So it could be support, but it could also be training. For example, if your business model is we do the training and certification around our products, nobody can stop any competition to do the same. I think even some people with the booth around here are doing certifications and trainings for products which they probably didn't build themselves, which is totally legal. But this is just one more thing that makes that business model a bit more complicated because the company building the product will only ever be able to, I don't know, have 50 percent or so bill of allows because 50 percent they will invest into the and 50 percent at best or so they will be able to put into services. So they probably have to charge double the rate of their competitors because they can only spend half the time on the products. Yes, they have a better reputation and they know the product better. But oftentimes it's only about the price. And it's very easy to undercut you in price if you just use the product rather than building it. And that's kind of like a bit of an unfair competition as well. And some people even say that the business model that Redhead built was kind of like from the past when open source was a different thing and it was a different environment like you didn't use cloud services that much because nowadays you really need Redhead Enterprise support when you're running on a cloud provider that is doing all the support for you. So maybe it's shifting that that model doesn't always work like that. However, some companies are still trying to go back to that. For example, I think SUSE is now an independent company at least if I can trust crunch that SUSE is an independent company now again trying to build around services around SUSE and make that a sustainable business model. And I guess we'll see how that works out. So support and services and everything around it, that is one big tier of how you could make money out of open source software. The other one is that's already been mentioned as well is OpenCore that you have like a base version that is open source and then you have some added value products around that which are probably commercial or at least not open source. So this could also be dual licensed like if you want to ship that with your products, if you have some open source things, then you need to pay to ship those. MySQL might be a big one there. I mean, they had the dual licensing for a long time, but they keep adding more and more commercial features to MySQL now as well. That's probably the redhead mentality in the background as well. But while the core product is open source, more and more things especially around scaling and operability are getting commercial there. For Neo4j, the graph data store, they also have like an open source product. But for example, if you have anything that needs to go to more than one server, that will be in the commercial version. And that's just what they have. And the problem that you will generally have here is that others can basically use what you're building on and then just take kind of like the top tier where you try to commercialize. So what you have is if you have a product that is 90% open source and then you have 10% of the functionality you try to commercialize, some other entity can just try to compete with you on those 10%. And you will still have to do the other 90% to keep the whole thing going. And obviously you will again not be able to compete on prices on that. That's kind of the problem there. The other kind of force field you will, yeah, sure. So I can't imagine a company giving all the features that their commercial editions have, especially at the pace at which their core evolves. So is it really a threat that some competitor will come and put the 10% on top? So the question was, is it really a threat because somebody else might not be able to keep pace with that? Yeah, for us, for example, we have been doing elastic search for a long time. And then one thing that was driving a lot of sales were security features. We've made them or a lot of them free now, but they used to be only commercial features and we had a company in Germany which competed just on security features. So while we did the entire open source stuff, we were with them only competing on the top or 5% or so on features or less. And they obviously can undercut your price easily because you need to carry 95% of the open source work with you as well, whereas they only do the 5% or whatever. So it depends a bit on the specific situation, but it can be a problem that somebody competes with you on just the part that you're trying to commercialize. So it could happen. The next kind of problem where you have in mentality is if your company is not doing so well, you will try to push more and more and more to the commercial side. And it will not go well for your open source product in the long run. And that's a very fine line because on the one hand side, you don't want to die as a company because that doesn't help the product in the long run either. And you also don't want to kill the open source side because that's not what we want as open source fans. And the final problem is oftentimes the tooling that people provide is something that you probably don't need if you're using a cloud provider. So what is commonly what people have been trying to commercialize is scalability things or security things or any kind of automation around that. And normally your cloud providers take care of you. And they basically pick the open source parts, reproduce the commercial part that you try to commercialize and just bake that into their service. And suddenly you have a very strong competitor on the one part that you try to commercialize. So that's another problem with OpenCore where you run into that. And speaking of cloud services, cloud services are obviously a great way to make money yourself. Any examples anybody would know where the company doing the project is making money out of cloud services or services? Yeah, Kitap, for example, yeah. Yeah, Redis as well, yeah. The example that I have is WordPress. Because if you go to WordPress.org, you can download it and run it for yourself. If you go to WordPress.com, you get the hosted service. And that's run by them and that's how they make money. Or Sentry, which is like developer error analytics tool, which just captures like all the stack traces and errors that you have in your application. They have everything BSD licensed, I think except for their billing module, but everything is BSD licensed. But they also provide a cloud service and their approach is like, we can provide this relatively cheaply and it would be so much more hassle for you to run this yourself rather than pay us 10 euro a month that you will just buy our service. And since it's kind of niche and specialized, they don't really have any competitors trying to take their software. So they have that. And obviously you have the problem again that somebody else is trying to eat your lunch. Which might end up like this. Because obviously you have the bigger cloud providers. And if it's open source, they have the right to run whatever you're producing as open source as open source themselves. For example, if you are competing with Google Cloud, AWS, whatever, Azure, you will, if you run on their service, you will not just need to kind of like pay the same amount they pay for the hardware, but you always need to pay them a bit for the fee, like whatever their revenue stream there is or their margin. You need to pay that. And you also need to pay into building the open source stuff. Whereas if they just take your software and run it, they will always be able to undercut you on pricing. And that's kind of pain in the ass. But yeah, I have no idea how to pronounce his name, but one of the main people behind Hudson Jenkins and the company Cloudpiece, he says it's very hard if you have a pure open source model to defend that against cloud providers. Because they have the right to use your software. I mean, your open source did everybody can do whatever they want with it. It's just very hard to compete with the big cloud providers. Especially if it's just one click away from all the other services they have, rather than signing up with you and then giving you some money and integrating them with everything else. And some people also say it's probably not the idea of open source software that the big cloud providers make money out of your products. But you can argue about that. So these are kind of the three big things. You have services, you have an open core model, or you had cloud, those are the three main revenue streams probably. So here's a different question. What if I have a different licensing model where I allow somebody to choose my software if he makes less than one million, let's say one million dollars per year? That's fine, but that's not open source. So the question was if you limit it, if somebody makes less revenue than one million per year, they can use the software freely, otherwise they would need to pay you. Yes? That is not in the terms of open source because open source doesn't have any limitations on use case. So you could also not say, hey, this is open source, but you cannot use this in some war material because it's limiting the use case. Open source is just free. No strings, no strings is not exactly true, but it's like you cannot exclude by company, by revenue, by use case, those are all technically not open source anymore then. This is exactly what quite a few companies are trying to do, and we can discuss that as well, that you try to have some limitations, for example, what is very common that they say like you can use this yourself and everything is free, but you cannot provide it as a paid cloud service to others because if somebody makes money out of that cloud service, it should be the company doing that. You can do that and quite a few companies do that, but that's not open source according to the OSI definition, which leads to a full set of other problems, but yeah, that's what you have. Then there are a lot of smaller ways or more sidetracked ways how you could make money. One of them is partnerships. Does anybody know what is one of the most lucrative partnerships any software company has? Yes, the default search engine in the US for Firefox. I think in 2015 or so, the default search engine in the US in Firefox switched to Yahoo from Google, and Yahoo paid a lot of money for that. That's one of the main revenue models of the Mozilla Foundation. If I got the right numbers, they paid 375 million for five years, so that's some serious money to change hands for a partnership model, but obviously, you will not be able to replicate that for any kind of software. It's just a very small field. For them, it worked out pretty well. It's rather domain-specific, I would say, and very few companies will be able to live in that area. Another thing that might be working out well are donations. Anybody know somebody making a lot of money out of donations? Not exactly a software product, but yes, exactly. The Wikimedia Foundation. I got the 2016-17 report, and in that year, they made 90 million from 6 million people, because they have one of the most visited websites, and they can just add that banner to please support us, and then people might donate money, so that works for them. But for a lot of other people, it's probably not enough to actually survive. I'm always a bit careful. Scaling and planning is very hard, especially the planning part. If you want to hire 10 developers, and you know, I need to make that much money in donations, it's very hard to predict that the donations will really come in, and then you have hired people and you're not able to pay them. That's not a great place to be in, so I'm a bit skeptical if that is what you want to do. I found that a very nice quote that some people make a lot of money on Patreon or donations, but probably for everybody making a lot of money out of that, there are 10 or 100 others who make very little or no money out of that at all. So yes, there are some success stories, but I don't think it's super easy to replicate across the board for everybody either. You could do certified partners. So for example, I think Moodle has that because Moodle, the e-learning platform, that's normally very customized when you roll it out anywhere. And what they have is on their website, they have some section where it says, like, our official partners for customizations are these companies. And to be listed there, you pay them. And that's kind of like a very direct revenue stream because people who need to implement the Moodle platform need customization, and then they will probably pick one of the official partners on the website. Not again that needs a commercial ecosystem, and it kind of needs a product that needs customization. If you don't have a product that needs customization, that's not an option. And it's kind of like something that, yeah, where you have that. Somebody making money out of ads in a weird way, or not weird, but in an unexpected way. They're one of the sponsors here. Yeah? Hi. Hi. Hi. Hi, Professor. Hi. Yeah, my example was Adblock. Yeah, it's the same business model. It's the same business model. You participated in the Acceptable Ads program. Yes, the Acceptable Ads. Now I need to be careful what I'm saying. But yes, they're the Acceptable Ads. So for Adblock plus, or Adblock, if I remember correctly is, if you're a small company doing ads, you can be whitelisted and you just request it. Whereas if you're a large player, you need to pay for that. It's about the revenue that they make by monetizing the Adblock in usage. And there's just a threshold. And if you're above the threshold, then you pay a revenue threshold. So there is a revenue threshold. And if you breach that, you will need to pay. Yes, that's the model. We tend to be working fine. I think it's only acceptable ads. My question is always like, if business is not working out that well, what is acceptable? Yeah, the thing is that there is an Acceptable Ads committee, which is external to both companies, both to beta fish, which is doing Adblock and also external to IO. So and it is a committee which is made out of user rights groups and also people from the ads tech sphere. So together they decide on what the Acceptable Ads criteria are. So in this way, we ensure that there is an independent set of Acceptable Ads criteria which are out of the business model. Interesting. So the committee is out of the business model deciding of what is acceptable. Interesting. So I learned something as well. Another way to make money would be merchandise. SD, for example, has a swag store. But I can only imagine that they make enough money for some servers each year and not pay anybody full time on swag. So I think the revenue there is kind of limited. Another interesting thing is bounties or crowdfunding. So there are more and more websites which say like, hey, there is this bug. I want this bug fixed. I will pay you $100 if you fix this bug. And then somebody can implement that. And if you accept it as the one paying, the money will be transferred. Or you can ask for a specific feature and somebody can implement that. Yeah. So when you run it in production, the stable builds, you don't get them to build free. But you have to subscribe. So a paid binary model, there is a bit more like the reddit enterprise edition where the source code is free but well tested and certified binaries, they would cost something. I mean, that's not an uncommon model that you would do that. No, I think the swag store is just something on the side because they seem to have one of the more popular, better known swag stores. But I don't think that it's anybody's main source of revenue as a swag store. I don't think that would work to be honest. And it do go to some conferences to sell the swag actually at the conference, I think. And it's just open VSD sponsored stuff then. It's like a dedicated sponsor table. So for bug bounties and crowdfunding, one of the more successful ones, there was a game that was five or six years ago, which was called Cataclysm. They took in some and they actually delivered the game afterwards because with a lot of Kickstarter projects, their success rate is a bit questionable. I think that one here is at least the main developer is making enough money to work on that through Patreon. What project is that? Vue.js, the JavaScript framework. With any paid features, what I'm always a bit afraid of is division and maintainability because somebody says, like, I want this feature and it doesn't really fit into your product. And then you take the money one time, but you probably have to maintain that code for X years. And oftentimes the maintenance costs over long periods of time is much higher than the initial development. So it's kind of a very tricky deal that you get features that you never wanted to merge and then you suddenly have them and need to carry them forward. So I'm a bit careful there. Corporate sponsoring is another thing that might work well or depending on how big your algorithm is. Google Summer is one of the bigger programs where students just develop stuff for open source projects. And that has been going on for quite a while and has been, I think, pretty successful. I've been both a student and a mentor and an org admin and it always worked out very well for us. The problem is sometimes the incentives are a bit complicated if you have some company-sponsored programs. Okay. Heading over to this ruggle of what could be the struggles around open source software. So the first one is a bit the philosophy of, yeah, open source software. So one of the philosophical problems is everybody wants to do open source and call themselves open source. But really doing open source means you need to contribute upstream because otherwise you're mostly a consumer of open source and maybe you do a little bit on top of that. But you don't really keep the ecosystem going by just taking your stuff and staying within your bubble. So you need to go upstream to actually contribute. And I think for every kind of open source project you have like three different kinds of people in your ecosystem. You have contributors, those who actually give back. You have those who use your software. They might open an issue. They don't give you code back, but they're at least users. And you might be able to convert them into a paying customer or a cloud user or something at a later point in time. And then you have the consumers. The consumers are normally those taking your stuff, building their own products around it without giving anything back. And if you have done open source, you might have some of those as well. We definitely have some. I basically, they have products around it, but they're pretty much like a black hole. Like nothing is coming out of that again. They just take what we produce and disappear. So we always call those the vultures that just wait for some open source stuff they can take and then use. Amazon is kind of like a very interesting one because they try to get more and more into the open source ecosystem and say like we're doing so much. On the other hand, they have been using a lot of open source and giving back not that much, especially in the past. So for example, one of the interesting things is when they say like, oh, some projects are not that great. For example, Presto, which was open source by Facebook, but they suddenly then have a revenue generating product which is backed by that kind of thing. They just call it Athena and it's kind of like customized and bundled for their use case. But it is another open source project in the background. Or another thing that people don't find that great is if Azure says like, or if you ask an Azure user, are you using Redis and they say like Redis? No. What I'm using is Azure Redis cache. When it's kind of like, yeah, you have the name in there, but people think it's actually an Azure product now. And that happens quite a lot that people just know the cloud provider's specific thing and then think it's coming out of the cloud provider. And then you're cutting off the company doing something very much, which is not that great. Speaking of Redis, Redis has been doing some interesting stuff in the past year around licensing. So Redis Lab modules, not Redis itself, they were always AGPL licensed. So they always wanted like, if you make any changes to that, we want to see what you're doing so we might be able to incorporate that back into the product. And the ones that are out there are, yeah, those products, I think they added one or two more to have a Redis for time series or something like that. In the end, they tried to build every problem model around data stores on top of Redis. So they implement all kinds of stuff there. And what they did is they stripped out the AGPL and switched it over to another license, which was Apache 2, but modified with Commons Clause. So that was pretty much exactly a year ago. And that one was kind of tricky and also a bit misleading because when we say Apache 2 license, everybody pretty much knows what Apache 2 license means. And then you should really continue reading and say modified with Commons Clause because that's making all the difference. So what Commons Clause basically does is it disallows you from having any paid services around it. That could be cloud services, but depending on how you read it, it could even be like providing customizations around it. So anything you make money on top of their software would be disallowed by that license. That was the idea. Not Redis itself, that was always BSD licensed and state BSD licensed, but those Redis modules around it to add more value. And this actually was pretty confusing for multiple reasons. A, Commons Clause, people started to abbreviate that with CC. Is CC a very good abbreviation for Commons Clause? Probably not because when you read CC, you probably think Creative Commons, which is a totally different thing. So that caused confusion. The other thing is some people saw Apache 2 modified with Commons Clause, and then they would assume that this is the right URL for this, which looks deceptively similar, but this is the Java Commons library, which is Apache licensed and Apache product, which is something totally else again. So it was just like a very unfortunate naming, and it's just collisions of things you don't want to have. And what also didn't help was when one of the investors into Redis Labs, the company behind that, posted an article on TechCrunch about the open source wonks that open source doesn't have a place for them because, well, their investors, they wanted to make money. That didn't help the situation either. So stuff got a bit heated, and it didn't really progress the right way. So that is kind of their argument, why are we doing that? Because, well, a lot of people are making a lot of money out of that, and we kind of want to participate in that. That's kind of like the other side of, well, if somebody makes money out of our software, we should be in that equation as well. So like I said, Redis itself always was BSD. They just communicated it so badly that they had to write two blog posts within a couple of days to make sure that Redis itself is still BSD licensed and just the modus were affected. And in the end, the common schools was very kind of deceptive, so they kind of changed that in March of this year, and they have their own license now. So it's called the Redis source available license, which basically means it has some limitations. You can see the source code, but you cannot run it as a cloud service, for example. And to have a 3T model, that is something that a lot of companies now try to do. So you have some open source core product that you can use with whatever open source license you use. You have something that is free to use, probably source available so you can see the source code, but you're not allowed to provide that as a cloud service, for example. And then you might have some commercial features on top of that. And you need to pay to use those again. So that's one model here. What did MongoDB do? They stripped out encryption between the nodes, which was then implemented by some open source tools. They stripped out encryption. No, maybe. I don't know that story, but I'm talking about licensing here, not encryption. So what MongoDB does, or the initial license that MongoDB always had was the server was the AGPL license, and the clients, bless you, to avoid any confusion, was always a patchy license. So the libraries, the Java driver, whatever you were using, that was a patchy license so you didn't have any issues. But the server was always AGPL. And that was okay for most people. But they did change that a year ago, or almost a year ago, to their own license, which they called the server-side public license, or SSPL, which kind of tried to be like the AGPL, but reaching a bit further. So what they did is they exchanged one clause in the AGPL, which is the 13th clause. So if you're offering their program as a service, then additional rules apply. And basically what they require, if you offer MongoDB as a service, you don't only have to open source the code that you run there, but also the entire tooling around it. And some people said, well, this is kind of like within the spirit of open source. It's kind of like going further because it's not just their code anymore, but also the tooling around it, but it's fair game. And others said, well, this clause was basically there to avoid anybody else being able to run that as a cloud service because you cannot open source all that tooling. Or also it required specific licenses. And some people claimed you couldn't even run that on Linux service anymore because that would not be compatible with that license. It's definitely more than the reciprocity you have in copy left licenses. So you have the permissive licenses. You can do a lot of stuff and you don't have to kind of like reimplement the same permissions on your side. Copy left kind of has this, you use my library, then you need to apply my license like in the GPL or AGPL. And the SSPL is kind of trying to go further. Use my code and then everything that touches it around it on your side as well, all the orchestration and everything, that would need to be open sourced as well. So that was the general idea of the SSPL. And Pekona, they're like provider and they have their own kind of small fork and they provide services around data stores. They run an interesting poll and they ask like, with that license, does that change impact you and will you replace MongoDB with something else? And they said like, it looks like 49% of the people said like, the change does not affect me. 49% of the people said we would migrate away. And 2% of the people would say like, well, we will have to buy an enterprise license now. Which is an interesting number because this is probably not representative, but you might lose 50% of your users with a change like that. In the end, I don't think that actually happened because MongoDB made that change and technically with the SSPL, MongoDB is not open sourced at all anymore. But they're still just as popular as before and nobody really seems to care much, which I find slightly surprising, but that's what happened to them. What was unfortunate around their entire change was the first thing was timing because they said like, we're changing the license of our server today. And that basically means the next patch level release that is coming out, we'll have that new license. That is pretty sucky because if you run that as a company, you probably need to run that through your legal department. And they may take weeks or even months to actually approve of a new software license that nobody has seen before. And until then, you cannot upgrade even to the next patch level release. You might just be cut off, whatever security fixes might be out there. So that's kind of like, I think the proper way to do something like that is say like, okay, we will change the license, here's the new license, the next minor or major version will apply that license. And you can then figure out what is your way forward and not like, we will change the license today because that kind of traps users a bit and was not that nice. The other thing that kind of happened before but still after is that people tried to clone MongoDB and just use the wire protocol and the APIs but have their own backend implementation of independent of that. Does anybody know this one? The logo. Obviously, no Azure fans. Yeah, exactly. That's Cosmos DB. Cosmos DB is kind of like their Azure's multi-model data store that does all kinds of things but it also has a MongoDB compatible API. Foundation DB which was bought up by Apple and has recently been open source. They also have something and Amazon recently released DocumentDB which was using the API of the last open source version that MongoDB brought out and they never jumped to the SPL licensed versions there or we kind of work around that in the long run. MongoDB also tried to make SSPL a proper OSI license and you can follow the flame wars on the mailing list where it's going back and forth but in the end they said they were withdrawing that because it's not going anywhere and there is no chance to make that work in the long run. But they're not the ones like other companies have very similar models. For example, Confluent, the company behind Kafka. They have a clause that says you can use their free tier excluding anything running as a service, platform as a service, infrastructure as a service, whatever. If you run it as a service, you cannot use some of their software. They have this three tiered model as well. They have Apache Kafka. This is Apache licensed. Then they have a free tier that has this cloud limitation. You cannot run these features as a cloud provider. Then they have commercial features. These three tiered approaches come on across companies now what many are doing. Other things, what is the struggle? The first one is follow the money. One is the conflict of interests. You always have the engineering view which is more like we want to do open source and we want to open source and share our features. The other one is the sales side which always says like, no, nothing should be open source. I want to sell everything. That's always an internal struggle within companies. One thing where this was interesting was that the main company behind Cassandra for a long time was Datastax. Cassandra is an Apache project. At some point, they clashed because Datastax wanted to do stuff that the Apache foundation didn't approve of. They had this kind of IP divorce where Datastax product tried to separate away from Cassandra. They also started saying like, our implementation even though it has totally the same basis and is very similar is much faster than the other one. It's kind of like one of these weird things. They kind of got together a bit more again and they're cooperating more. But what happens sometimes if two are fighting is that some third party enters the market. Has anybody heard of Skillr? SkillrDB? That's kind of like Cassandra API but re-implemented rather than Java. They're using C++ and they claim 10 times faster and whatever. So that's kind of like there are three players basically for one API now. You have Apache Cassandra, Datastax and Skillr and all try to capture the same market or the same API. You should in theory be able to switch between them. Another problem is sometimes is venture capital is like a nice accelerator to produce features more quickly. But obviously you will have to deal with the venture capital in the long run and you will need to make the money. One thing I think or one project that is like a great open source project is CouchDB. And they used to be super popular. I think like 10 years or so, CouchDB was more or less the no sequel Datastore that everybody was using. But I have the feeling that they were kind of overtaken by a lot of other players and probably there are multiple things to that and you could argue that multiple ways. But one thing is I think that they didn't have the venture capital to accelerate their development. And for example, the founder of CouchDB, Damian Katz, he founded another company called CouchBase and they took on a good amount of venture capital and they are not a pure open source product. They have some open source but only some. But as a company, they are doing well. CouchDB kind of like their popularity has decreased a lot over the years. It's a great open source product but it kind of lost the popularity probably because it didn't have the money to be or have all the features the others have. Another thing that you might run into as a problem sometimes is you have a product that is too limited to be useful and sometimes you kill the company because you have too much open source stuff and you cannot monetize enough stuff. What happened to this company? Or does anybody remember RethinkDB? It was like a document store. It was a bit like MongoDB and developers loved it and it was very popular and everybody said great stuff about it but they never managed to find a sustainable business model and they died as a company. I think the Linux Foundation bought the remaining intellectual property and source code but the product has been pretty much dead for one and a half or two years now because nothing came out of it. The other thing is InfluxDB for them, anything that is scaling like anything that needs more than a single node is commercial now. They had features as open source features that allowed scaling but they removed that to find a sustainable business model. On the other hand, that obviously limits their usefulness because as soon as you have more than one server, you need to pay them and for a lot of projects that's not really going to expand their footprint for that. The final thing where I'm always wondering how long they will still be around is this one because they have taken on a lot of venture capital over the time and who is using Docker? Who is paying Docker? Yeah, that's the fascinating thing. I know they have Docker and some companies and especially enterprises are paying them but the relationship between who is using Docker and who is paying Docker, Inc. is such a small fraction. I don't think this will be workable in the long run. We'll see. They have found a market gap where they are targeting Windows platforms where currently no one else does. They have found a market gap and I think that's exactly the point, a gap and they took on way too much money to be a gap company. I don't think you will ever be able to recover the hundreds of millions they took in with a gap. But we'll see in the long run. Other companies are trying to play tricks. They are open source but they trick people a bit. Does anybody know what the tricks of these open source companies are? Yeah. The main thing for SQLite is that that's all they take. This company is not in the center. Yeah, that is true. SQLite is very popular. Are there any forks of SQLite? No. Does anybody know why not? The code is open source but the tests are not. So they do have tests but that is basically what is protecting them. So they have the brand and the code but nobody can fork the code because their tests are not open source. And who would want to fork a project and start changing stuff without the tests they have? And Juke has the same model. You can't see the code but you don't have the tests so nobody can fork them. Which is, it has all the four freedoms but it's maybe not exactly in the spirit of open source but it has like, yeah, things like that in there. Okay. To wrap up kind of like success in open source, the first thing I think I always need to mention is business is optional. To be a successful open source project doesn't mean you need to make money because there are many great open source projects which don't have a main commercial entity behind them and they're doing great. Probably this one is one of the most widely known ones. Like yeah, there are a lot of companies or there are companies around it to make money but there is not one entity controlling it or pushing the development. It's a community project that is working well and it doesn't have a direct commercial entity behind it there. Sometimes people decide that they don't want to form a company. For example, Envoy, the service mesh thingy, Matt Klein at Lyft who started that, he said like he didn't want to start a company because it's probably like you're throwing in five years of your life or 10 years of your life to start a company that's probably going to fail and you need to work a lot and probably in ways you don't want that. He wants to have more of a foundation and multiple companies contributing to that without getting very rich or without the chance to have his own company. He would just rather do development work in a project rather than starting his own company out of that. But that's a very clear decision there. The other thing is that business is always complicated that you have in there. I really like this point from a former Docker engineering lead is that if you do some open source as a closed source company, like everything will think that Microsoft is bringing out this open source. People are like this is amazing work. They're doing open source. If you do some small thing as not open source, if you're an open source company, people are always enraged at how could you not make something open source. It's kind of like the perception is very complicated there. Some people even argue that it's maybe time to update the open source model a bit. That is pretty much what MongoDB tried to kind of like make the server side public license an acceptable OSI license. They themselves claim that they closed this ASP loophole, that the cloud providers just benefit off of them. Others say like, no, this is kind of what makes open source that there are no limitations to anybody. That's kind of like a delicate balance there. Does anybody know this logo? Yes, CockroachDB. They also have, they recently adopted the business license BSL, which comes from MariaDB, if I remember correctly. What they have is that license is kind of tunable or it has parameters that you can tune. Something they have is, so they limit that you can use the code, but you cannot offer commercial services around it. That's one of the tweaks they have. The other tweak they have is all the code that they released today is under their own tweak of the BSL license. But after two years, all the code after two years goes to Apache. So it changes license after two years. However, that kind of puts them in a very interesting position that within two years they always need to figure out another feature that they can monetize in the future to sustain as a business. That's a very interesting pressure field they will have in the future. Another interesting thing is what do you protect as an open source company? Does anybody know what Chef recently did? So Chef changed their license and that's actually interesting. All the code they have is now Apache 2 licensed and you can use that. But what you cannot do is you cannot use the Chef marks and the binaries are also commercial. So while you get the code, for the binaries you will need to pay. And to provide the binaries, you will need to use your own trademark. So for them, they don't want to protect their code, but they basically protect their trademark and then the binaries. And that's their business model. But all the code is now open source. Whereas for example, we as a company, we don't protect elastic search as a term that much. As long as you use it kind of like in the right way, you're allowed to do that. We would rather protect our code. Whereas Chef says like, we're the only ones who are allowed to use Chef. They try to protect the trademark and build on the trademark. Whereas we try to build kind of like more on the code and not so much on the term. Because we would rather have more people use elastic search and have like a bigger community rather than having the code out there and people having their own naming schemes for that. But that's interesting. So strategy-wise, we're also doing kind of something very similar. So we have an open source license. We have a free license, which is source available. We have commercial features. Those are also source available. You can all find everything on GitHub. But to use them in production, you will need to have a commercial license. Unless you do something illegal and comment out the checks where we check the license, which a lot of users in China are actually doing. Because we have some telemetry which you can opt into and we get the telemetry from those Chinese customers. But they probably would never pay us in the first place anyway. And no company in Europe or the US probably would do that to kind of circumvent the license. So we're not afraid of losing money there. What is kind of important for us is that all the code is open. So we have a patchy two license code on something we call the elastic license. But all the code is on GitHub. So even the commercial features, you can see what are the issues we are opening. What is the code? How does it work behind the scenes? You could even do a pull request for commercial features because you can't see everything. And we kind of combined all that code. We have one folder basically that contains the commercial code and everything else is a patchy two license there. And the way we think about this is what incentives or perceptions or behaviors is one of those four licenses going to drive with. Open users who normally mostly care about free paying customers, open source only uses. Open source only uses would be something like Wikipedia because out of principle they will only use open source stuff. Competitors that might be some cloud providers even though we have partnerships with a lot of them as well. Our own salespeople and our own developers. So what does the specific license change and kind of approach change for our developers as well? And then you need to kind of like keep all of those in balance. And that's kind of like the edge we try to walk on. We do have training and consulting as well, but nobody can survive on that. And we try to keep that pretty small. What we do try to make more money out of our cloud services. So if you want to get hosting, we try to be the best company for that and nobody else. You can also run that yourself. And what we have as well is a swag store, but that's not a major revenue source. That's more for fun. So we have our own shop and you can get stickers and everything even though I have stickers over there. So today you get the stickers for free. This is not a major revenue source, but this is something we've added as well. So we tried to get money from everywhere there. So questions, disagreements. Yeah. Wait, we have a microphone. Is this, was that the right one? Do I have to turn it on? Try now. Thank you. Wait. I have questions about Docker. Is it on? No. No, it's not on. I... No? No. Yeah, I tried like this. Okay. And questions on Docker. The question is really they built this whole ecosystem and in the end probably they will sell the whole company to some other big company. So are they really in the need to make money? Is Docker... So the main question is does Docker need to make money or are they just looking to be bought by some bigger entity? Yeah. On the other hand, yeah, maybe Microsoft wants to buy them, but I'm not sure like what would you even get out of Docker Inc at the moment because that the... From the technical level, I think all the relevant parts are in Moby nowadays. So the technological part has moved out of Docker Inc already. What are you really buying in with Docker? The brand name? I don't think you buy much there anymore. Or maybe I'm overly pessimistic, but... Yeah, let's make it a bit hard and yeah, maybe Microsoft is buying their future. So... Yeah, I know. Docker Inc, I think a year ago, so Docker Inc had, I think, got new management and tried new approaches, but still I haven't seen much in terms of sales or commercial products from Docker Inc. And they took on a ton of money. And some companies are pretty pushy around sales, which nobody likes, but I'm not even sure that Docker Inc has much to sell for the average company. Yeah, some and more enterprisey, but I'm... Yeah, at least I don't see them in any way to make money out of me. Your buying can list of outdated containers ordered by Populet. Yeah. I mean, what would be kind of the main losses right now, I think, is... The Docker technology moved mostly to Moby. I think the main loss would be Docker Hub. And that's kind of the relevant thing, but you're still not making much money out of that. So, yeah, while we would feel Docker Hub, I don't think otherwise we would miss Docker that much. I don't know. I'm happy I'm not with Docker. Are you sure that Moby is working? Like, it is a machine that you can compile and run? No. I think it's just a dog. So, Moby is just a dog? I don't know. I haven't, to be honest, I haven't looked into it. I just thought that all the... There are different issues there, but they're not close and it's just... It looks not like a working project. Interesting. It's kind of placeholder, I think, the reaction to something, just my opinion. But wait, isn't Docker wrapping part of Moby or is it really two separate code bases? I don't know. Okay. Maybe it's just... Yeah, well... And it was also probably not that well done because the initial announcement was super confusing for most people. So, yeah. Yeah, I think for the business model, I think it's similar to WhatsApp in the end. They basically had the opportunity to create a business model. So like WhatsApp, they tried to sell the opportunity for a business model, maybe. But I mean, WhatsApp had millions of users. You bought something there that communicate every day. But for Docker, I think there, with WhatsApp, you have more of this network effect. My friends need to be on the same network that I can use that. With Docker containers, okay, yeah, somebody needs to create the right kind of containers, but I could also switch to Rocket or whatever, another base technology at some point, maybe. But maybe, I don't know. Time is up. Time is up. Thank you. Thank you.
 Hi, everyone.  Since the title and everything was English, I will switch to English.  I hope that's fine for everybody.  I guess we'll manage.  So I'm Philip.  I want to talk a bit about open source and how to make money out of that or how to survive  on it or however you can see that.  So it can be a strategy.  Sometimes it's a struggle.  Some people even reach success, but that's another discussion.  So we'll see where this goes.  So when we say open source, since we're at an open source conference, I assume everybody  is kind of familiar with what it means.  The main thing is software that can be freely used, modified and shared.  That's the open source.org definition.  That's kind of like what most people accept that what is open source or what is not open  source.  If you're coming more from the Free Software Foundation, it's about the four freedoms.  Use, study, share and improve code.  So we'll just assume we all kind of know what is open source.  I don't want to make the finer distinctions between the different licenses, but it's just  about software or open source software in general.  So I assume that everybody is using open source, right?  Good.  Everybody or almost everybody is open issues.  Yes, yes.  Who is contributing back?  Okay, that's fewer already.  That's kind of what you commonly see.  I like this comic where when you ask like, who wants well maintained open source software,  everybody raises their hand.  Who wants to contribute back?  Like people kind of lower their hand.  And then you say like, who wants to actually maintain a project?  Everybody is gone.  That's sometimes what you see.  Especially not here, like this conference is a bit of an outline in that regard, but  there's a lot of other more commercial events.  This is what you have.  Like everybody uses open source software and everybody wants well maintained open source  software, but the ones giving back or investing into it is kind of like a much smaller subset.  So how can you keep that feasible?  And the other thing is most of us probably want to be paid for doing their work.  And there's this nice quote from the founder of Puppet who said like 98.5, however he came  up with that number, percent of the code that they put into Puppet was put there by somebody  who was paid to work on the project.  So only a small fraction was actually buy volunteers.  And even though a lot of the code is open source or pretty much everything is open source  nowadays, they still paid a lot of people.  So where do you get the money from?  Because open source software is probably better than commercial software in every regard except  for one thing and that is making money, which is a bit unfortunate.  And generally open source is not a business model.  Like I don't want to give that impression that you have to be a commercial entity and  make money out of open source software.  That's totally not the case.  But in many cases, it's what people want to do for the sustainability of their projects.  And for example, for the company I work for, our CEO always says like open source is a  distribution model.  And it's kind of a force multiplier.  It's kind of like to get it out to people.  Otherwise distribution of the software would be much harder if it wasn't open source.  So it's kind of a precondition to get started.  But it doesn't solve the problem of how to keep the company sustainable in the long run.  And that's what we kind of want to look into now.  Anybody knows this logo?  Probably not.  Anybody heard of Datomic?  It's like this in the closure ecosystem, data stored, it was a pen only.  It has some very fancy features.  It is a great project.  But what they didn't have is they didn't have an open source version.  And we can probably argue why they kind of stagnated and never really breached out into  the wider ecosystem.  Probably multiple reasons.  But one of them I think is that they didn't have an open source version.  So yes, they do have a very weird licensing model.  If you want to start, you can use their software and you get updates for one year.  If you want to get any further updates after one year, you will need to pave them.  Otherwise you're not allowed to get any updates anymore.  And then you have commercial licenses.  And I think one of the reasons why we're kind of stuck or are still stuck in kind of a niche  is because they didn't have this broad open source base to build on.  So where do I come in?  I work for the company Elastic Search, LogStage, Kivana, Beast, those are all our products.  And this is not only about our story of how we want to make money, but a bit of a broader  talk of what are generally your options, how to make money, and also some of the more recent  developments of what has been happening.  So these are some of the open source products that we produce.  And if you're using any of these sites behind the search box, there is our software doing  the search.  But none of them are paying us at the moment, I think.  So why do we have a wide distribution because of that and lots of users?  This doesn't give us any money back to keep working on the products.  So the question is always, where is the money and how can you make money?  By the way, does anybody make money out of open source software here?  Three, four.  Okay, we'll get back to you in the end.  I'm curious what you do to make money.  Because there are multiple approaches for better or worse.  We don't probably agree on everything, but yeah, there are options.  So what's the way do you want to spend your time?  Because we have like 60 minutes or 55 now, and I probably have material for 90 minutes  or more, and then we don't even have a discussion.  So I could focus a bit more on the strategy of how can you even make money?  The struggle is what are the current problems or what are the different parties involved  in striving for that?  And then we can just round it up in success at the end.  Who would be more interested in the strategies and all the ways to make money in open source  software?  Who is more interested in the struggle part?  You didn't help me much here.  Okay, we'll start and we'll see where we can take this.  Okay, strategy.  So how can you make money out of open source software?  Yeah?  Just shout.  So are these different business models like you can set some open core business model  or you can also support?  Yes, support is a good one.  I have support on the one I want to start with.  I'll just call it services and I'll, so the responses were support and other stuff.  The one thing I want to focus on for the first thing, there are basically three big things  how you can make money.  And the first one I would kind of like put together out the services.  It could be support, it can be consulting, training, you can offer some certification.  It's anything that you do around the software to provide services.  Popular examples for those.  What are the big companies earning money with that?  Reddit.  Yes.  Reddit for example, I have two examples here.  The first one is Canonical.  What are they doing?  Yeah, that's the company behind Ubuntu and then obviously Reddit, which I don't know,  is now IBM or Harvard to quantify that now.  But they have been making money out of open source software for a long time.  And they had this amazing graph where they showed that for 64 consecutive quarters, they  had revenue growth on an open source business model.  And it's just been going on and on and on and on and on.  And now you could just say, well, this is easy.  We'll just do what they have been doing and we'll just have the same growth for years  to come and we'll be fine.  Unfortunately it's not that easy.  Support and services sometimes work, but they don't necessarily work.  One thing that is interesting is the support problem.  What happens if your product is too easy to use and nobody wants to pay for support because  you don't need it?  And then you have this unfortunate situation where you might want to have a product that  is not too easy to use so somebody pays you for support.  And it's kind of like a force field.  You don't want to end up in the middle of that to survive.  You need to make it a bit harder to use or your documentation worse.  You don't want to end up in that place.  The other big problem with support is generally renewal rates.  Companies paying you, for example, on an annual basis, they will look after one or two or  three years, they will look at what cases did we have, what did support solve for us?  And then they might say, well, the product is working well.  Why should we be paying you?  Unless it constantly breaks and we really need you, why are we not saving money on that  support subscription anymore?  Or support because you don't know the product that well initially, but after three years  you probably know how it works for you.  Yes?  Some companies want really to pay for software because it's kind of part of their policy  because they cannot run any software which has no support even if the software runs.  The point or remark was that some companies need to have that as a policy.  Yes.  I always call it the mafia model like insurance.  You basically buy some protection and then you can shout at somebody for being responsible  for whatever breaks.  Yes?  Yeah.  If you're a bank or an insurance company, you probably, it's mandatory.  Anything you use in production or like in some use cases, you will have to have support  otherwise you're not doing that.  Yes, why Reddit and others are still on the market.  Yes.  But maybe you don't want to go into that area.  And also that is kind of like a limited segment.  And you probably have to, you don't get the money for free.  Like you have to, like enterprise software is not that much fun sometimes.  So there is a reason why there is so much money in there.  So maybe it works, but it doesn't work for everything and it doesn't work for every product.  For example, if you're a video player, you don't really have a business model in there.  Like you won't be able to survive on that.  So some kind of tools and platforms or data stores or whatever will be able to survive  there very well.  Others will have a much harder time.  Yeah?  I think support is the second problem.  Second problem is that you probably have to support old versions.  The point or question was about supporting old versions.  Yes.  I think that's a bit like how desperate are you?  Yes.  So for our company, we have support policy of around 18 months or so.  And then it's out of support.  And we might help you, but it's pretty much best effort.  And we will say like, you have to upgrade.  Otherwise it's really broken and we cannot easily reproduce it.  Support has its limits.  So this is what I would say, when your best customer comes and says, I want to use ES2  or whatever, whatever.  If you have a customer insisting on using very old versions, they will have to pay a  lot.  Yes.  You just need to increase their pain as well.  And then you just said you must make it more expensive just to get them sooner let out.  Yes.  I guess that the model there is you need to shift the pain from yourself supporting old  versions to making it so expensive that you shift the pain to them.  So that they move on at some point.  I think that's kind of like the model where you need to push them.  But yeah, that sales will see that very differently.  That's more the engineering perspective.  And the final problem kind of is what if you have somebody who doesn't provide the open  source tooling, but just the services around it.  So it could be support, but it could also be training.  For example, if your business model is we do the training and certification around our  products, nobody can stop any competition to do the same.  I think even some people with the booth around here are doing certifications and trainings  for products which they probably didn't build themselves, which is totally legal.  But this is just one more thing that makes that business model a bit more complicated  because the company building the product will only ever be able to, I don't know, have 50  percent or so bill of allows because 50 percent they will invest into the and 50 percent at  best or so they will be able to put into services.  So they probably have to charge double the rate of their competitors because they can  only spend half the time on the products.  Yes, they have a better reputation and they know the product better.  But oftentimes it's only about the price.  And it's very easy to undercut you in price if you just use the product rather than building  it.  And that's kind of like a bit of an unfair competition as well.  And some people even say that the business model that Redhead built was kind of like  from the past when open source was a different thing and it was a different environment like  you didn't use cloud services that much because nowadays you really need Redhead Enterprise  support when you're running on a cloud provider that is doing all the support for you.  So maybe it's shifting that that model doesn't always work like that.  However, some companies are still trying to go back to that.  For example, I think SUSE is now an independent company at least if I can trust crunch that  SUSE is an independent company now again trying to build around services around SUSE and make  that a sustainable business model.  And I guess we'll see how that works out.  So support and services and everything around it, that is one big tier of how you could  make money out of open source software.  The other one is that's already been mentioned as well is OpenCore that you have like a base  version that is open source and then you have some added value products around that which  are probably commercial or at least not open source.  So this could also be dual licensed like if you want to ship that with your products,  if you have some open source things, then you need to pay to ship those.  MySQL might be a big one there.  I mean, they had the dual licensing for a long time, but they keep adding more and more  commercial features to MySQL now as well.  That's probably the redhead mentality in the background as well.  But while the core product is open source, more and more things especially around scaling  and operability are getting commercial there.  For Neo4j, the graph data store, they also have like an open source product.  But for example, if you have anything that needs to go to more than one server, that  will be in the commercial version.  And that's just what they have.  And the problem that you will generally have here is that others can basically use what  you're building on and then just take kind of like the top tier where you try to commercialize.  So what you have is if you have a product that is 90% open source and then you have  10% of the functionality you try to commercialize, some other entity can just try to compete  with you on those 10%.  And you will still have to do the other 90% to keep the whole thing going.  And obviously you will again not be able to compete on prices on that.  That's kind of the problem there.  The other kind of force field you will, yeah, sure.  So I can't imagine a company giving all the features that their commercial editions have,  especially at the pace at which their core evolves.  So is it really a threat that some competitor will come and put the 10% on top?  So the question was, is it really a threat because somebody else might not be able to  keep pace with that?  Yeah, for us, for example, we have been doing elastic search for a long time.  And then one thing that was driving a lot of sales were security features.  We've made them or a lot of them free now, but they used to be only commercial features  and we had a company in Germany which competed just on security features.  So while we did the entire open source stuff, we were with them only competing on the top  or 5% or so on features or less.  And they obviously can undercut your price easily because you need to carry 95% of the  open source work with you as well, whereas they only do the 5% or whatever.  So it depends a bit on the specific situation, but it can be a problem that somebody competes  with you on just the part that you're trying to commercialize.  So it could happen.  The next kind of problem where you have in mentality is if your company is not doing  so well, you will try to push more and more and more to the commercial side.  And it will not go well for your open source product in the long run.  And that's a very fine line because on the one hand side, you don't want to die as a  company because that doesn't help the product in the long run either.  And you also don't want to kill the open source side because that's not what we want as open  source fans.  And the final problem is oftentimes the tooling that people provide is something that you  probably don't need if you're using a cloud provider.  So what is commonly what people have been trying to commercialize is scalability things  or security things or any kind of automation around that.  And normally your cloud providers take care of you.  And they basically pick the open source parts, reproduce the commercial part that you try  to commercialize and just bake that into their service.  And suddenly you have a very strong competitor on the one part that you try to commercialize.  So that's another problem with OpenCore where you run into that.  And speaking of cloud services, cloud services are obviously a great way to make money yourself.  Any examples anybody would know where the company doing the project is making money out  of cloud services or services?  Yeah, Kitap, for example, yeah.  Yeah, Redis as well, yeah.  The example that I have is WordPress.  Because if you go to WordPress.org, you can download it and run it for yourself.  If you go to WordPress.com, you get the hosted service.  And that's run by them and that's how they make money.  Or Sentry, which is like developer error analytics tool, which just captures like all the stack  traces and errors that you have in your application.  They have everything BSD licensed, I think except for their billing module, but everything  is BSD licensed.  But they also provide a cloud service and their approach is like, we can provide this relatively  cheaply and it would be so much more hassle for you to run this yourself rather than pay  us 10 euro a month that you will just buy our service.  And since it's kind of niche and specialized, they don't really have any competitors trying  to take their software.  So they have that.  And obviously you have the problem again that somebody else is trying to eat your lunch.  Which might end up like this.  Because obviously you have the bigger cloud providers.  And if it's open source, they have the right to run whatever you're producing as open source  as open source themselves.  For example, if you are competing with Google Cloud, AWS, whatever, Azure, you will, if  you run on their service, you will not just need to kind of like pay the same amount they  pay for the hardware, but you always need to pay them a bit for the fee, like whatever  their revenue stream there is or their margin.  You need to pay that.  And you also need to pay into building the open source stuff.  Whereas if they just take your software and run it, they will always be able to undercut  you on pricing.  And that's kind of pain in the ass.  But yeah, I have no idea how to pronounce his name, but one of the main people behind  Hudson Jenkins and the company Cloudpiece, he says it's very hard if you have a pure  open source model to defend that against cloud providers.  Because they have the right to use your software.  I mean, your open source did everybody can do whatever they want with it.  It's just very hard to compete with the big cloud providers.  Especially if it's just one click away from all the other services they have, rather than  signing up with you and then giving you some money and integrating them with everything  else.  And some people also say it's probably not the idea of open source software that the  big cloud providers make money out of your products.  But you can argue about that.  So these are kind of the three big things.  You have services, you have an open core model, or you had cloud, those are the three main  revenue streams probably.  So here's a different question.  What if I have a different licensing model where I allow somebody to choose my software  if he makes less than one million, let's say one million dollars per year?  That's fine, but that's not open source.  So the question was if you limit it, if somebody makes less revenue than one million per year,  they can use the software freely, otherwise they would need to pay you.  Yes?  That is not in the terms of open source because open source doesn't have any limitations on  use case.  So you could also not say, hey, this is open source, but you cannot use this in some war  material because it's limiting the use case.  Open source is just free.  No strings, no strings is not exactly true, but it's like you cannot exclude by company,  by revenue, by use case, those are all technically not open source anymore then.  This is exactly what quite a few companies are trying to do, and we can discuss that  as well, that you try to have some limitations, for example, what is very common that they  say like you can use this yourself and everything is free, but you cannot provide it as a paid  cloud service to others because if somebody makes money out of that cloud service, it  should be the company doing that.  You can do that and quite a few companies do that, but that's not open source according  to the OSI definition, which leads to a full set of other problems, but yeah, that's what  you have.  Then there are a lot of smaller ways or more sidetracked ways how you could make money.  One of them is partnerships.  Does anybody know what is one of the most lucrative partnerships any software company  has?  Yes, the default search engine in the US for Firefox.  I think in 2015 or so, the default search engine in the US in Firefox switched to Yahoo  from Google, and Yahoo paid a lot of money for that.  That's one of the main revenue models of the Mozilla Foundation.  If I got the right numbers, they paid 375 million for five years, so that's some serious  money to change hands for a partnership model, but obviously, you will not be able to replicate  that for any kind of software.  It's just a very small field.  For them, it worked out pretty well.  It's rather domain-specific, I would say, and very few companies will be able to live  in that area.  Another thing that might be working out well are donations.  Anybody know somebody making a lot of money out of donations?  Not exactly a software product, but yes, exactly.  The Wikimedia Foundation.  I got the 2016-17 report, and in that year, they made 90 million from 6 million people,  because they have one of the most visited websites, and they can just add that banner  to please support us, and then people might donate money, so that works for them.  But for a lot of other people, it's probably not enough to actually survive.  I'm always a bit careful.  Scaling and planning is very hard, especially the planning part.  If you want to hire 10 developers, and you know, I need to make that much money in donations,  it's very hard to predict that the donations will really come in, and then you have hired  people and you're not able to pay them.  That's not a great place to be in, so I'm a bit skeptical if that is what you want to  do.  I found that a very nice quote that some people make a lot of money on Patreon or donations,  but probably for everybody making a lot of money out of that, there are 10 or 100 others  who make very little or no money out of that at all.  So yes, there are some success stories, but I don't think it's super easy to replicate  across the board for everybody either.  You could do certified partners.  So for example, I think Moodle has that because Moodle, the e-learning platform, that's normally  very customized when you roll it out anywhere.  And what they have is on their website, they have some section where it says, like, our  official partners for customizations are these companies.  And to be listed there, you pay them.  And that's kind of like a very direct revenue stream because people who need to implement  the Moodle platform need customization, and then they will probably pick one of the official  partners on the website.  Not again that needs a commercial ecosystem, and it kind of needs a product that needs  customization.  If you don't have a product that needs customization, that's not an option.  And it's kind of like something that, yeah, where you have that.  Somebody making money out of ads in a weird way, or not weird, but in an unexpected way.  They're one of the sponsors here.  Yeah?  Hi.  Hi.  Hi.  Hi, Professor.  Hi.  Yeah, my example was Adblock.  Yeah, it's the same business model.  It's the same business model.  You participated in the Acceptable Ads program.  Yes, the Acceptable Ads.  Now I need to be careful what I'm saying.  But yes, they're the Acceptable Ads.  So for Adblock plus, or Adblock, if I remember correctly is, if you're a small company doing  ads, you can be whitelisted and you just request it.  Whereas if you're a large player, you need to pay for that.  It's about the revenue that they make by monetizing the Adblock in usage.  And there's just a threshold.  And if you're above the threshold, then you pay a revenue threshold.  So there is a revenue threshold.  And if you breach that, you will need to pay.  Yes, that's the model.  We tend to be working fine.  I think it's only acceptable ads.  My question is always like, if business is not working out that well, what is acceptable?  Yeah, the thing is that there is an Acceptable Ads committee, which is external to both companies,  both to beta fish, which is doing Adblock and also external to IO.  So and it is a committee which is made out of user rights groups and also people from  the ads tech sphere.  So together they decide on what the Acceptable Ads criteria are.  So in this way, we ensure that there is an independent set of Acceptable Ads criteria  which are out of the business model.  Interesting.  So the committee is out of the business model deciding of what is acceptable.  Interesting.  So I learned something as well.  Another way to make money would be merchandise.  SD, for example, has a swag store.  But I can only imagine that they make enough money for some servers each year and not pay  anybody full time on swag.  So I think the revenue there is kind of limited.  Another interesting thing is bounties or crowdfunding.  So there are more and more websites which say like, hey, there is this bug.  I want this bug fixed.  I will pay you $100 if you fix this bug.  And then somebody can implement that.  And if you accept it as the one paying, the money will be transferred.  Or you can ask for a specific feature and somebody can implement that.  Yeah.  So when you run it in production, the stable builds, you don't get them to build free.  But you have to subscribe.  So a paid binary model, there is a bit more like the reddit enterprise edition where the  source code is free but well tested and certified binaries, they would cost something.  I mean, that's not an uncommon model that you would do that.  No, I think the swag store is just something on the side because they seem to have one  of the more popular, better known swag stores.  But I don't think that it's anybody's main source of revenue as a swag store.  I don't think that would work to be honest.  And it do go to some conferences to sell the swag actually at the conference, I think.  And it's just open VSD sponsored stuff then.  It's like a dedicated sponsor table.  So for bug bounties and crowdfunding, one of the more successful ones, there was a game  that was five or six years ago, which was called Cataclysm.  They took in some and they actually delivered the game afterwards because with a lot of  Kickstarter projects, their success rate is a bit questionable.  I think that one here is at least the main developer is making enough money to work on  that through Patreon.  What project is that?  Vue.js, the JavaScript framework.  With any paid features, what I'm always a bit afraid of is division and maintainability  because somebody says, like, I want this feature and it doesn't really fit into your product.  And then you take the money one time, but you probably have to maintain that code for  X years.  And oftentimes the maintenance costs over long periods of time is much higher than the  initial development.  So it's kind of a very tricky deal that you get features that you never wanted to merge  and then you suddenly have them and need to carry them forward.  So I'm a bit careful there.  Corporate sponsoring is another thing that might work well or depending on how big your  algorithm is.  Google Summer is one of the bigger programs where students just develop stuff for open  source projects.  And that has been going on for quite a while and has been, I think, pretty successful.  I've been both a student and a mentor and an org admin and it always worked out very  well for us.  The problem is sometimes the incentives are a bit complicated if you have some company-sponsored  programs.  Okay.  Heading over to this ruggle of what could be the struggles around open source software.  So the first one is a bit the philosophy of, yeah, open source software.  So one of the philosophical problems is everybody wants to do open source and call themselves  open source.  But really doing open source means you need to contribute upstream because otherwise you're  mostly a consumer of open source and maybe you do a little bit on top of that.  But you don't really keep the ecosystem going by just taking your stuff and staying within  your bubble.  So you need to go upstream to actually contribute.  And I think for every kind of open source project you have like three different kinds  of people in your ecosystem.  You have contributors, those who actually give back.  You have those who use your software.  They might open an issue.  They don't give you code back, but they're at least users.  And you might be able to convert them into a paying customer or a cloud user or something  at a later point in time.  And then you have the consumers.  The consumers are normally those taking your stuff, building their own products around  it without giving anything back.  And if you have done open source, you might have some of those as well.  We definitely have some.  I basically, they have products around it, but they're pretty much like a black hole.  Like nothing is coming out of that again.  They just take what we produce and disappear.  So we always call those the vultures that just wait for some open source stuff they  can take and then use.  Amazon is kind of like a very interesting one because they try to get more and more  into the open source ecosystem and say like we're doing so much.  On the other hand, they have been using a lot of open source and giving back not that  much, especially in the past.  So for example, one of the interesting things is when they say like, oh, some projects are  not that great.  For example, Presto, which was open source by Facebook, but they suddenly then have a  revenue generating product which is backed by that kind of thing.  They just call it Athena and it's kind of like customized and bundled for their use  case.  But it is another open source project in the background.  Or another thing that people don't find that great is if Azure says like, or if you ask  an Azure user, are you using Redis and they say like Redis?  No.  What I'm using is Azure Redis cache.  When it's kind of like, yeah, you have the name in there, but people think it's actually  an Azure product now.  And that happens quite a lot that people just know the cloud provider's specific thing  and then think it's coming out of the cloud provider.  And then you're cutting off the company doing something very much, which is not that great.  Speaking of Redis, Redis has been doing some interesting stuff in the past year around  licensing.  So Redis Lab modules, not Redis itself, they were always AGPL licensed.  So they always wanted like, if you make any changes to that, we want to see what you're  doing so we might be able to incorporate that back into the product.  And the ones that are out there are, yeah, those products, I think they added one or  two more to have a Redis for time series or something like that.  In the end, they tried to build every problem model around data stores on top of Redis.  So they implement all kinds of stuff there.  And what they did is they stripped out the AGPL and switched it over to another license,  which was Apache 2, but modified with Commons Clause.  So that was pretty much exactly a year ago.  And that one was kind of tricky and also a bit misleading because when we say Apache  2 license, everybody pretty much knows what Apache 2 license means.  And then you should really continue reading and say modified with Commons Clause because  that's making all the difference.  So what Commons Clause basically does is it disallows you from having any paid services  around it.  That could be cloud services, but depending on how you read it, it could even be like  providing customizations around it.  So anything you make money on top of their software would be disallowed by that license.  That was the idea.  Not Redis itself, that was always BSD licensed and state BSD licensed, but those Redis modules  around it to add more value.  And this actually was pretty confusing for multiple reasons.  A, Commons Clause, people started to abbreviate that with CC.  Is CC a very good abbreviation for Commons Clause?  Probably not because when you read CC, you probably think Creative Commons, which is  a totally different thing.  So that caused confusion.  The other thing is some people saw Apache 2 modified with Commons Clause, and then they  would assume that this is the right URL for this, which looks deceptively similar, but  this is the Java Commons library, which is Apache licensed and Apache product, which  is something totally else again.  So it was just like a very unfortunate naming, and it's just collisions of things you don't  want to have.  And what also didn't help was when one of the investors into Redis Labs, the company  behind that, posted an article on TechCrunch about the open source wonks that open source  doesn't have a place for them because, well, their investors, they wanted to make money.  That didn't help the situation either.  So stuff got a bit heated, and it didn't really progress the right way.  So that is kind of their argument, why are we doing that?  Because, well, a lot of people are making a lot of money out of that, and we kind of  want to participate in that.  That's kind of like the other side of, well, if somebody makes money out of our software,  we should be in that equation as well.  So like I said, Redis itself always was BSD.  They just communicated it so badly that they had to write two blog posts within a couple  of days to make sure that Redis itself is still BSD licensed and just the modus were  affected.  And in the end, the common schools was very kind of deceptive, so they kind of changed  that in March of this year, and they have their own license now.  So it's called the Redis source available license, which basically means it has some  limitations.  You can see the source code, but you cannot run it as a cloud service, for example.  And to have a 3T model, that is something that a lot of companies now try to do.  So you have some open source core product that you can use with whatever open source  license you use.  You have something that is free to use, probably source available so you can see the source  code, but you're not allowed to provide that as a cloud service, for example.  And then you might have some commercial features on top of that.  And you need to pay to use those again.  So that's one model here.  What did MongoDB do?  They stripped out encryption between the nodes, which was then implemented by some open source  tools.  They stripped out encryption.  No, maybe.  I don't know that story, but I'm talking about licensing here, not encryption.  So what MongoDB does, or the initial license that MongoDB always had was the server was  the AGPL license, and the clients, bless you, to avoid any confusion, was always a patchy  license.  So the libraries, the Java driver, whatever you were using, that was a patchy license so  you didn't have any issues.  But the server was always AGPL.  And that was okay for most people.  But they did change that a year ago, or almost a year ago, to their own license, which they  called the server-side public license, or SSPL, which kind of tried to be like the AGPL,  but reaching a bit further.  So what they did is they exchanged one clause in the AGPL, which is the 13th clause.  So if you're offering their program as a service, then additional rules apply.  And basically what they require, if you offer MongoDB as a service, you don't only have  to open source the code that you run there, but also the entire tooling around it.  And some people said, well, this is kind of like within the spirit of open source.  It's kind of like going further because it's not just their code anymore, but also the  tooling around it, but it's fair game.  And others said, well, this clause was basically there to avoid anybody else being able to  run that as a cloud service because you cannot open source all that tooling.  Or also it required specific licenses.  And some people claimed you couldn't even run that on Linux service anymore because  that would not be compatible with that license.  It's definitely more than the reciprocity you have in copy left licenses.  So you have the permissive licenses.  You can do a lot of stuff and you don't have to kind of like reimplement the same permissions  on your side.  Copy left kind of has this, you use my library, then you need to apply my license like in  the GPL or AGPL.  And the SSPL is kind of trying to go further.  Use my code and then everything that touches it around it on your side as well, all the  orchestration and everything, that would need to be open sourced as well.  So that was the general idea of the SSPL.  And Pekona, they're like provider and they have their own kind of small fork and they  provide services around data stores.  They run an interesting poll and they ask like, with that license, does that change  impact you and will you replace MongoDB with something else?  And they said like, it looks like 49% of the people said like, the change does not affect  me.  49% of the people said we would migrate away.  And 2% of the people would say like, well, we will have to buy an enterprise license  now.  Which is an interesting number because this is probably not representative, but you might  lose 50% of your users with a change like that.  In the end, I don't think that actually happened because MongoDB made that change and technically  with the SSPL, MongoDB is not open sourced at all anymore.  But they're still just as popular as before and nobody really seems to care much, which  I find slightly surprising, but that's what happened to them.  What was unfortunate around their entire change was the first thing was timing because they  said like, we're changing the license of our server today.  And that basically means the next patch level release that is coming out, we'll have that  new license.  That is pretty sucky because if you run that as a company, you probably need to run that  through your legal department.  And they may take weeks or even months to actually approve of a new software license  that nobody has seen before.  And until then, you cannot upgrade even to the next patch level release.  You might just be cut off, whatever security fixes might be out there.  So that's kind of like, I think the proper way to do something like that is say like,  okay, we will change the license, here's the new license, the next minor or major version  will apply that license.  And you can then figure out what is your way forward and not like, we will change the license  today because that kind of traps users a bit and was not that nice.  The other thing that kind of happened before but still after is that people tried to clone  MongoDB and just use the wire protocol and the APIs but have their own backend implementation  of independent of that.  Does anybody know this one?  The logo.  Obviously, no Azure fans.  Yeah, exactly.  That's Cosmos DB.  Cosmos DB is kind of like their Azure's multi-model data store that does all kinds of things  but it also has a MongoDB compatible API.  Foundation DB which was bought up by Apple and has recently been open source.  They also have something and Amazon recently released DocumentDB which was using the API  of the last open source version that MongoDB brought out and they never jumped to the SPL  licensed versions there or we kind of work around that in the long run.  MongoDB also tried to make SSPL a proper OSI license and you can follow the flame wars  on the mailing list where it's going back and forth but in the end they said they were  withdrawing that because it's not going anywhere and there is no chance to make that work in  the long run.  But they're not the ones like other companies have very similar models.  For example, Confluent, the company behind Kafka.  They have a clause that says you can use their free tier excluding anything running as a  service, platform as a service, infrastructure as a service, whatever.  If you run it as a service, you cannot use some of their software.  They have this three tiered model as well.  They have Apache Kafka.  This is Apache licensed.  Then they have a free tier that has this cloud limitation.  You cannot run these features as a cloud provider.  Then they have commercial features.  These three tiered approaches come on across companies now what many are doing.  Other things, what is the struggle?  The first one is follow the money.  One is the conflict of interests.  You always have the engineering view which is more like we want to do open source and  we want to open source and share our features.  The other one is the sales side which always says like, no, nothing should be open source.  I want to sell everything.  That's always an internal struggle within companies.  One thing where this was interesting was that the main company behind Cassandra for a long  time was Datastax.  Cassandra is an Apache project.  At some point, they clashed because Datastax wanted to do stuff that the Apache foundation  didn't approve of.  They had this kind of IP divorce where Datastax product tried to separate away from Cassandra.  They also started saying like, our implementation even though it has totally the same basis  and is very similar is much faster than the other one.  It's kind of like one of these weird things.  They kind of got together a bit more again and they're cooperating more.  But what happens sometimes if two are fighting is that some third party enters the market.  Has anybody heard of Skillr?  SkillrDB?  That's kind of like Cassandra API but re-implemented rather than Java.  They're using C++ and they claim 10 times faster and whatever.  So that's kind of like there are three players basically for one API now.  You have Apache Cassandra, Datastax and Skillr and all try to capture the same market or  the same API.  You should in theory be able to switch between them.  Another problem is sometimes is venture capital is like a nice accelerator to produce features  more quickly.  But obviously you will have to deal with the venture capital in the long run and you will  need to make the money.  One thing I think or one project that is like a great open source project is CouchDB.  And they used to be super popular.  I think like 10 years or so, CouchDB was more or less the no sequel Datastore that everybody  was using.  But I have the feeling that they were kind of overtaken by a lot of other players and  probably there are multiple things to that and you could argue that multiple ways.  But one thing is I think that they didn't have the venture capital to accelerate their development.  And for example, the founder of CouchDB, Damian Katz, he founded another company called CouchBase  and they took on a good amount of venture capital and they are not a pure open source  product.  They have some open source but only some.  But as a company, they are doing well.  CouchDB kind of like their popularity has decreased a lot over the years.  It's a great open source product but it kind of lost the popularity probably because it  didn't have the money to be or have all the features the others have.  Another thing that you might run into as a problem sometimes is you have a product that  is too limited to be useful and sometimes you kill the company because you have too much  open source stuff and you cannot monetize enough stuff.  What happened to this company?  Or does anybody remember RethinkDB?  It was like a document store.  It was a bit like MongoDB and developers loved it and it was very popular and everybody  said great stuff about it but they never managed to find a sustainable business model and they  died as a company.  I think the Linux Foundation bought the remaining intellectual property and source code but  the product has been pretty much dead for one and a half or two years now because nothing  came out of it.  The other thing is InfluxDB for them, anything that is scaling like anything that needs  more than a single node is commercial now.  They had features as open source features that allowed scaling but they removed that  to find a sustainable business model.  On the other hand, that obviously limits their usefulness because as soon as you have  more than one server, you need to pay them and for a lot of projects that's not really  going to expand their footprint for that.  The final thing where I'm always wondering how long they will still be around is this  one because they have taken on a lot of venture capital over the time and who is using Docker?  Who is paying Docker?  Yeah, that's the fascinating thing.  I know they have Docker and some companies and especially enterprises are paying them  but the relationship between who is using Docker and who is paying Docker, Inc. is such  a small fraction.  I don't think this will be workable in the long run.  We'll see.  They have found a market gap where they are targeting Windows platforms where currently  no one else does.  They have found a market gap and I think that's exactly the point, a gap and they took on way  too much money to be a gap company.  I don't think you will ever be able to recover the hundreds of millions they took in with  a gap.  But we'll see in the long run.  Other companies are trying to play tricks.  They are open source but they trick people a bit.  Does anybody know what the tricks of these open source companies are?  Yeah.  The main thing for SQLite is that that's all they take.  This company is not in the center.  Yeah, that is true.  SQLite is very popular.  Are there any forks of SQLite?  No.  Does anybody know why not?  The code is open source but the tests are not.  So they do have tests but that is basically what is protecting them.  So they have the brand and the code but nobody can fork the code because their tests are  not open source.  And who would want to fork a project and start changing stuff without the tests they  have?  And Juke has the same model.  You can't see the code but you don't have the tests so nobody can fork them.  Which is, it has all the four freedoms but it's maybe not exactly in the spirit of open  source but it has like, yeah, things like that in there.  Okay.  To wrap up kind of like success in open source, the first thing I think I always need to mention  is business is optional.  To be a successful open source project doesn't mean you need to make money because there  are many great open source projects which don't have a main commercial entity behind  them and they're doing great.  Probably this one is one of the most widely known ones.  Like yeah, there are a lot of companies or there are companies around it to make money  but there is not one entity controlling it or pushing the development.  It's a community project that is working well and it doesn't have a direct commercial entity  behind it there.  Sometimes people decide that they don't want to form a company.  For example, Envoy, the service mesh thingy, Matt Klein at Lyft who started that, he said  like he didn't want to start a company because it's probably like you're throwing in five  years of your life or 10 years of your life to start a company that's probably going to  fail and you need to work a lot and probably in ways you don't want that.  He wants to have more of a foundation and multiple companies contributing to that without  getting very rich or without the chance to have his own company.  He would just rather do development work in a project rather than starting his own company  out of that.  But that's a very clear decision there.  The other thing is that business is always complicated that you have in there.  I really like this point from a former Docker engineering lead is that if you do some open  source as a closed source company, like everything will think that Microsoft is bringing out this  open source.  People are like this is amazing work.  They're doing open source.  If you do some small thing as not open source, if you're an open source company, people are  always enraged at how could you not make something open source.  It's kind of like the perception is very complicated there.  Some people even argue that it's maybe time to update the open source model a bit.  That is pretty much what MongoDB tried to kind of like make the server side public license  an acceptable OSI license.  They themselves claim that they closed this ASP loophole, that the cloud providers just  benefit off of them.  Others say like, no, this is kind of what makes open source that there are no limitations  to anybody.  That's kind of like a delicate balance there.  Does anybody know this logo?  Yes, CockroachDB.  They also have, they recently adopted the business license BSL, which comes from MariaDB, if  I remember correctly.  What they have is that license is kind of tunable or it has parameters that you can  tune.  Something they have is, so they limit that you can use the code, but you cannot offer  commercial services around it.  That's one of the tweaks they have.  The other tweak they have is all the code that they released today is under their own  tweak of the BSL license.  But after two years, all the code after two years goes to Apache.  So it changes license after two years.  However, that kind of puts them in a very interesting position that within two years  they always need to figure out another feature that they can monetize in the future to sustain  as a business.  That's a very interesting pressure field they will have in the future.  Another interesting thing is what do you protect as an open source company?  Does anybody know what Chef recently did?  So Chef changed their license and that's actually interesting.  All the code they have is now Apache 2 licensed and you can use that.  But what you cannot do is you cannot use the Chef marks and the binaries are also commercial.  So while you get the code, for the binaries you will need to pay.  And to provide the binaries, you will need to use your own trademark.  So for them, they don't want to protect their code, but they basically protect their trademark  and then the binaries.  And that's their business model.  But all the code is now open source.  Whereas for example, we as a company, we don't protect elastic search as a term that much.  As long as you use it kind of like in the right way, you're allowed to do that.  We would rather protect our code.  Whereas Chef says like, we're the only ones who are allowed to use Chef.  They try to protect the trademark and build on the trademark.  Whereas we try to build kind of like more on the code and not so much on the term.  Because we would rather have more people use elastic search and have like a bigger community  rather than having the code out there and people having their own naming schemes for  that.  But that's interesting.  So strategy-wise, we're also doing kind of something very similar.  So we have an open source license.  We have a free license, which is source available.  We have commercial features.  Those are also source available.  You can all find everything on GitHub.  But to use them in production, you will need to have a commercial license.  Unless you do something illegal and comment out the checks where we check the license,  which a lot of users in China are actually doing.  Because we have some telemetry which you can opt into and we get the telemetry from those  Chinese customers.  But they probably would never pay us in the first place anyway.  And no company in Europe or the US probably would do that to kind of circumvent the license.  So we're not afraid of losing money there.  What is kind of important for us is that all the code is open.  So we have a patchy two license code on something we call the elastic license.  But all the code is on GitHub.  So even the commercial features, you can see what are the issues we are opening.  What is the code?  How does it work behind the scenes?  You could even do a pull request for commercial features because you can't see everything.  And we kind of combined all that code.  We have one folder basically that contains the commercial code and everything else is  a patchy two license there.  And the way we think about this is what incentives or perceptions or behaviors is one of those  four licenses going to drive with.  Open users who normally mostly care about free paying customers, open source only uses.  Open source only uses would be something like Wikipedia because out of principle they will  only use open source stuff.  Competitors that might be some cloud providers even though we have partnerships with a lot  of them as well.  Our own salespeople and our own developers.  So what does the specific license change and kind of approach change for our developers  as well?  And then you need to kind of like keep all of those in balance.  And that's kind of like the edge we try to walk on.  We do have training and consulting as well, but nobody can survive on that.  And we try to keep that pretty small.  What we do try to make more money out of our cloud services.  So if you want to get hosting, we try to be the best company for that and nobody else.  You can also run that yourself.  And what we have as well is a swag store, but that's not a major revenue source.  That's more for fun.  So we have our own shop and you can get stickers and everything even though I have stickers  over there.  So today you get the stickers for free.  This is not a major revenue source, but this is something we've added as well.  So we tried to get money from everywhere there.  So questions, disagreements.  Yeah.  Wait, we have a microphone.  Is this, was that the right one?  Do I have to turn it on?  Try now.  Thank you.  Wait.  I have questions about Docker.  Is it on?  No.  No, it's not on.  I...  No?  No.  Yeah, I tried like this.  Okay.  And questions on Docker.  The question is really they built this whole ecosystem and in the end probably they will  sell the whole company to some other big company.  So are they really in the need to make money?  Is Docker...  So the main question is does Docker need to make money or are they just looking to be  bought by some bigger entity?  Yeah.  On the other hand, yeah, maybe Microsoft wants to buy them, but I'm not sure like what  would you even get out of Docker Inc at the moment because that the...  From the technical level, I think all the relevant parts are in Moby nowadays.  So the technological part has moved out of Docker Inc already.  What are you really buying in with Docker?  The brand name?  I don't think you buy much there anymore.  Or maybe I'm overly pessimistic, but...  Yeah, let's make it a bit hard and yeah, maybe Microsoft is buying their future.  So...  Yeah, I know.  Docker Inc, I think a year ago, so Docker Inc had, I think, got new management and tried  new approaches, but still I haven't seen much in terms of sales or commercial products  from Docker Inc.  And they took on a ton of money.  And some companies are pretty pushy around sales, which nobody likes, but I'm not even  sure that Docker Inc has much to sell for the average company.  Yeah, some and more enterprisey, but I'm...  Yeah, at least I don't see them in any way to make money out of me.  Your buying can list of outdated containers ordered by Populet.  Yeah.  I mean, what would be kind of the main losses right now, I think, is...  The Docker technology moved mostly to Moby.  I think the main loss would be Docker Hub.  And that's kind of the relevant thing, but you're still not making much money out of  that.  So, yeah, while we would feel Docker Hub, I don't think otherwise we would miss Docker  that much.  I don't know.  I'm happy I'm not with Docker.  Are you sure that Moby is working?  Like, it is a machine that you can compile and run?  No.  I think it's just a dog.  So, Moby is just a dog?  I don't know.  I haven't, to be honest, I haven't looked into it.  I just thought that all the...  There are different issues there, but they're not close and it's just...  It looks not like a working project.  Interesting.  It's kind of placeholder, I think, the reaction to something, just my opinion.  But wait, isn't Docker wrapping part of Moby or is it really two separate code bases?  I don't know.  Okay.  Maybe it's just...  Yeah, well...  And it was also probably not that well done because the initial announcement was super  confusing for most people.  So, yeah.  Yeah, I think for the business model, I think it's similar to WhatsApp in the end.  They basically had the opportunity to create a business model.  So like WhatsApp, they tried to sell the opportunity for a business model, maybe.  But I mean, WhatsApp had millions of users.  You bought something there that communicate every day.  But for Docker, I think there, with WhatsApp, you have more of this network effect.  My friends need to be on the same network that I can use that.  With Docker containers, okay, yeah, somebody needs to create the right kind of containers,  but I could also switch to Rocket or whatever, another base technology at some point, maybe.  But maybe, I don't know.  Time is up.  Time is up.  Thank you.  Thank you.
2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_0_47.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_48_167.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_168_347.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_348_419.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_420_551.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_552_1415.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_1416_1571.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_1572_1907.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_1908_2015.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_2016_2291.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_2292_2423.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_2424_3203.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_3204_3275.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_3276_3335.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_3336_4715.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_4716_7223.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_7224_7355.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_7356_7751.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_7752_8135.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_8136_10019.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_10020_11495.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_11496_11831.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_11832_12179.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_12180_20087.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_20088_21167.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_21168_21695.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_21696_22079.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_22080_22319.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_22320_27527.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_27528_28343.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_28344_28475.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_28476_29639.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_29640_34943.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_34944_37547.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_37548_40319.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_40320_42539.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_42540_42911.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_42912_43271.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_43272_44483.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_44484_44663.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_44664_46607.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_46608_46775.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_46776_49595.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_49596_51047.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_51048_62435.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_62436_62987.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_62988_63959.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_63960_65087.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_65088_66275.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_66276_67955.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_67956_71255.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_71256_73199.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_73200_74795.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_74796_76271.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_76272_76427.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_76428_77807.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_77808_78059.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_78060_78971.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_78972_79871.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_79872_80963.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_80964_81695.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_81696_83135.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_83136_83435.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_83436_83903.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_83904_88955.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_88956_89147.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_89148_89195.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_89196_90803.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_90804_91043.png 2019_-_Open_Source_as_a_Business_-R5A-rW72Oo_91044_91052.png