 Thank you for coming to the session. And we have been immersed in the cloud native worlds the entire week. So I thought maybe you can start this session by going to a different world, world that is quite different from Amsterdam or any other tech hub. And here is the capital of Falsett, a capital of Prorat, a town called Falsett in rural Spain, which is, it looks like a little town, but it's the epicenter of one of the most prestigious wine regions in Spain. And here, the life has a different rhythm, life has different habits. And most importantly here, the vineyard grows on water at the mercy of the elements to be transformed by people into something else. And these different outcomes that you can have can be either some grapes that you can sell in the supermarket for a few euros, or a bottle of wine that could be sold for a few thousand euros. And the difference between these two is that one is better than the other because both require intentional work, whether it is for you to set up a supply chain that can guarantee that your grapes will arrive fresh to the supermarket and beautiful because consumers really like their grapes to look pretty, or whether you have centuries of tradition that have enabled you to make a bottle of wine that is worth so much. I am Jorge Le Fiesta. I am the author of the Union Foundation Introduction to Backstage course. I am now a backstage Kirova org member. I am head of developer relations at body.io. And I'm a certified sommelier. That's why I talk about wine all the time. I want to talk about wine not only because I like it, but because I think that open source is a lot like grapes. You can do a lot with it. You can use it for free, or use it to close deals for millions of dollars. And the problem that, well, going back to this slide is that we have been doing this since the 90s. The commercialization of open source began very early on since it started existing. And there's a lot of literature you can see on that. But what I want to focus on in this session is what happens with the open source project that you are trying to commercialize or trying to make business with is very different. And it's something that is not normal people. It's mainly using a paradigm that was not applied before in this context, or it's just solving problems that don't even have a name yet. And when you have these kind of projects, you can see a potential in them, maybe because you are the author, maybe because you have a very niche need or niche perspective that this could help the market. But the problem is that at this point, the value that this new open source software provides is the same as its risk, unknown. We don't know if this will stop existing. We don't know if the approach is going to work out in the long run. So making business in these circumstances is difficult. So thankfully, I'm here to provide you a guide with three easy steps to get money out of your open source initiative or to get funding for your open source base initiative. First, try it out. Second, get involved in the community. And third, sell it. However, it might not be as easy as the people try to market it, but that is remain to be done. How many of you have heard of backstage? Okay, that's impressive. It's pretty much everyone. And it's great. It's been three years, but it still is a very rapid evolution. However, in 2020, what was backstage? If I had asked this question, nobody would have raised their hands and we wouldn't be even having this talk at all in the first place because backstage was trying to solve problems that they didn't have a name yet back then that we didn't know how to call. Some people didn't even realize they had these problems. The thing is that at that stage, even though it was unknown, somebody had to buy it. In fact, quite a few dozen people have invested millions of dollars to make the project succeed and to adopt it in a way that makes it work for them. So how do you make this for your own project? Or how do you make this for new open source software that you find? Because we already see that there's a lot of incubating projects in the CNCF community projects, which is the stage where backstage started at some point. And now it's still not a graduated project, but it still has a massive crowd and people trying to adopt and are interested in getting insights on how it works. So in this talk, I will explain a bit of the approach that I used before. Before I was working on a consultancy called Frontside. That is, they are the ex-consultancy and we started using backstage very early on because my former boss that I discovered it and he was really into it because he liked difficult things, I guess. Because the people in our team just did not like it. So we had to convince the entire team, which is a lot of engineers, like super senior, so it was not an easy task. But then one of the things that helped me, helped the organization move on all into backstage was getting the market insights that this was gonna be a big thing and that this could be a big business for the company. So that's what I'm gonna, the experience that I want to try to share today. So before we get to first step, I want to go a little bit before and go to step zero, which is writing down what are the problems that you are trying to solve? Why are you even trying to do this open source project in the first place? And this is important. It may seem obvious in the beginning, but it's great to have it just in a paper and just fold it and keep it in your pocket because it's gonna be a bumpy ride. And you want to make sure that you have a NorthTars that you can follow, even if you get lost in the weeds of trying to adopt the open source technology or as you are developing your open source project. So once you have that done, you can finally go to the first place, which is the first step, which is trying it out, except it is not the first step. The first step is gonna be making some due diligence on the project, whether it is yours or whether it's somebody else's, you really need to make sure that the licenses are gonna work out for you. If you have plans of commercialization, you have to make sure that the license is gonna be compatible and you have to make sure as well that if you are gonna pitch it as a project for your team, you have to make sure that the licenses are okay for you, for compliance and everything. This is the first step. Then you have to check the authors to make sure that they are gonna, at least stay on the project long enough to get it to a point in which you can take the role if needed, that they are just able to produce great software. They have some trajectory, they have done open-source before. And then one of the most important things probably is, how will this project survive? Because nothing is free, especially not in this economy. So we have to make sure that this project will thrive. And that means that there is a business model behind this project. Even though it's open-source, we are not in a naive 90s scene when open-source is just, oh yeah, this is some cool script that I wrote. I'm gonna share it. This is not how it works anymore. So you have to make sure that the business model of this open-source project is compatible with what you want to do with it. Or you have to be very intentional about the own business model that you want to operate in this space. So that leads to something. The paper that I recommend a lot for checking what is the business model of the project is this by DuPak and her team. Because this lists a set of archetypes of open-source business models. And it's not that they just sat down and they had some beers and some wine, some sodas and stuff like, how do people make money off of open-source? No, they went and systematically selected 120 companies over the past two decades that have made money out of open-source. They took out dozens of traits and characteristics, mapped them in a data set, then extracted clusters and then labeled them with different categories. So it's like a very, it's a truly data-driven way of knowing what are the business models behind open-source that are being used successfully over the past decades. And these are six of them. The seventh I didn't include because it's traditional open-source, which means no business model, just release a cool script. But these are the six main ways of making money off of open-source. I'll just go super quickly over them just so we get a point of reference. There's the open-source platform. This is by the authors, it's not my opinions. And they have a long reason and they can look into the paper. But there's, for example, open-source platform that they say of Kubernetes, an example, which is a symbiotic evolution subsidized by other products. Because for instance, it was created by Google, then it was open-source. And then there's another dynamic in which these companies make money off of Kubernetes. And we can see that it's being quite successful. And it evolves by helping each other. Then there's the funding base like Apache, there's infrastructure ones like Cypress or Gatsby. Then it's OpenCore that we all know. Then there's proprietary-like that when consultants create kind of product-sized ways of product, like they create product bundles out of open-source and they just sell it to their clients through different channels. And then there's open innovation, which at that point I thought might be the one that was working with Backstage because there is a core contributed by the company. And it's expected for the community to extend it and eventually they will start delegating ownership so they can keep running it but without having to invest all this money to run the show alone, let's say. And even in the architecture of Backstage, you can say it's like a plugin-based architecture. So it does give you this advantage of using the open innovation model. So once you have that figured it out, it's time to finally try it out. When you try it out, you will discover very important things like what comes out of the box and what is the gap from what is in the box to solving your problem. Because I remember that David, the founder of rodi.io, he explained that when he downloaded Backstage, after seeing these 45 videos, he was so spectacular, everything that was a hello world in a UI. So that didn't really talk about what was the potential of the thing. And that's very important in early stage projects. You have to be patient and you have to be aware that the onboarding is gonna be rough. There's gonna be difficult problems. There's gonna be scarce documentation. Things are just not gonna work perfectly out of the box. So these are things that you will have to contribute as well. So be mindful of that and don't get just frustrated and leave when you try this software. But it's very important that you do have some sense of how much work do I have to put in into this project to make it solve my problems that people are willing to pay for. Because if the gap is too wide, maybe this is not the right direction. The next step, which is actually two again if you have been looking at the numbers, is getting involved in the community as soon as possible. And I say that this is just as important the first step because it is. And it could be even more important if it wasn't because you have to use the software. But it is important and you can make it at the same time. Because as I said, you are gonna need help to set this up. So it's a great way to get started in the community is doing that. And I think it's the most important thing when exploring open source software and trying commercialization and exploring novel solutions because you will be reducing risk. If in the project there's a change expected on an API that you're interested in, whether they're gonna deprecate it or are breaking changes. Or even if they're gonna change licenses, you want to be the first person to know before they make these changes because it's transparent work. So you will see the initials, you will see the RSEs. So you can adjust your plans and know what's coming. So it's a great way of reducing risk to participate in the community. Then you have also the way of learning from others because you are gonna talk to them, share their experiences. And you are also going to gather success stories which are very important for you to be able to pitch your idea to people saying, hey, this has worked for others. So it can work for us as well or it can work for you. Here are some ideas that you can use to maximize your engagement. Write a newsletter based on the code based activity. This is great for reasons. First, you are gonna learn, you're gonna be the first person to learn what's going on. And secondly, the community is gonna appreciate a lot this work because then they don't have to do it themselves. So it's a great win for everybody. All know their ideas, organizing online events because it will allow you to gather adopters which is a rarity because it's a new project. There's few people using it. And I suggest using the on conference format because at this stage there's not gonna be speakers that they can talk about this new thing that just came out. So it's best to gather the people using it and see what is in their mind and see what are they thinking about? How are they solving? What are the use cases? What are they investing on this? It's a great way of getting a sense of what's going on outside your organization. And helping out others is another very important aspect of the community engagement because you eventually will want to, for example, recruit people. And what better way to recruit people that already know this niche technology that just emerged and doing it from the community. So it's good to have a good reputation and be a good person in there. And of course, contributing back to the framework is just essential. I didn't even mention it because it's just, like obvious, you just have to do it because as you try to use it, you'll realize that, oh, we need this, so you just have to go through it yourself. Now sell it, here's the seller part, except we're gonna scale it down to something more humble and say right a pitch. Because that's the first thing of selling, right? You have to have your arguments of why people should buy this. So let's see. The good thing is that throughout this process you already have a lot that you normally would need for a pitch. You have the viability because you have to check the license, you have to check the business goals, you know how you can operate, where you can operate, where not. You know what the company that made this is expecting. You have your ballot proof because you initially decided to do this for a reason. And most importantly, you have refined this ballot proof by talking to other people in the community. You have learned a vocabulary that is being used to talk about the pain points and how others are addressing these problems. Because before maybe you had a way of calling things, but it's great to know how other people are talking about these problems, but it didn't have a name. You also have the expected efforts that's gonna help you a lot because you know how many resources or people or time or money you're gonna need. And you have very importantly success stories when you can say, hey, this company is like us and they are having a lot of success, so we should do it too. Or hey, this customer, you can sell it to a customer by saying this is working for these people in this industry. You know pitfalls, so you can show the stakeholders that you know what you're talking about. And you also have a lot of market insight because you know who is paying, who's investing money on making this so early. That means that they really need it. Otherwise they wouldn't be adopting something that is not very stable. It's because they are really like touching a nerve there. So once you have this, there's something absolutely essential of any pitch that is missing from these bullets. Does somebody have any idea? Well, it's something absolutely needed, money. Do you don't write a pitch just to tell, oh, this is a nice story, it's not a tale. You are trying to convince people to give you money whether that is in teammates that you will need for your project or hiring people or a hard sale or an upscale or an up sale on an existing contract. You are trying to convince people to give you money. And that's something also that is super important in the pitch. So you have to include it and make it proportional to the things that you're exposing to them. And I cannot really tell you how to calculate this money because of course it depends on your circumstances. Maybe you don't need money. You need people for your team or maybe you need to convince your boss to let you use all your time to this project. So that's something that you have to figure out but it's the most important thing. So now you are really ready, right? You have gathered your insights. You are part of the community. You know what you're doing. You have convinced your boss even. But while you were doing all of this, 54 million dollars were dumped by VCs in the same problem space that this new open-serve project was operating in. So this is absolutely going to change the things that you are doing because it is going to change the industry. It's gonna give a name to the problem before it was, there was no name. Now there's things. For example, in the case of backstage, now there's, you can embed it in the platform, in the near narrative that now when you walk around the aisles, everything is a platform. While if you were in Detroit, nothing was a platform. But now everything is a platform. You can, does that also gonna change the way you talk about this? There's gonna be a lot of money spent on PR in this problem space. Some of it will go to say that the open source that is free is insecure, unstable, hard to use. So then you have to be ready to tackle these claims if needed. But in short, you really need to be able to manage change because this is a very fluid environment just that the new open source project is changing all the time. The industry is also changing all the time because of course, you are not the only person interested in this software or this kind of solution. So for dealing with change, these are the four things that I think work best. First is shop for alternatives. You cannot just turn a blind eye. I say, oh no, this new vendor do not exist. I'm gonna keep to my own work. Now you have to be able to say, okay, maybe there's a vendor that works for me. So even if that means ditching the work that you did before, but sometimes it just happens, happens in academia all the time, for example. And you'll be critical of what you need. Then you need to be able to tackle claims as I explained before, because maybe you pitched this beautiful thing to your VC and he will like, oh, I read this article in this magazine and it was a sponsored article trying to throw dirt in the open source project. So you can be, and it's usually not very informed, so you can easily see what is right and what is not right from the thing that your VC read. You also have very importantly have, you will have to update the narrative because as I explained, the names will change, there will be a context given to your solution and now this is gonna be in the people's mind and you can hook them more easily if you're using the words that they are using at the moment. And very importantly as well, you can explore partnerships. Just the fact that there's alternatives doesn't mean that everybody's your enemy. You can just form partnerships to sell or do cross marketing or do whatever it is needed because it's a problem space that is big. So there's always gonna be room for collaboration even if there's a competition among the people that have shown up in the space. So that's a wrap. And unfortunately this journey doesn't end up in the vineyard, but with the profit that you make out of open source. You can book yourself some holidays in product and enjoy one of the most magical ones of space. Thank you.