 Thank you. Okay, just for the record, Starz is in everything. It doesn't mean anything. And I'm not going to mention it in the presentation. And thank you for having me last. I'm going to talk about the open source side and the startup side, kind of two phases. There's going to be a lot about the product market fit. And actually, before we get started, I want to ask if anybody is in a startup? Good, good. And is it a pre-product market fit startup? Also good. It is an important concept because it's very different from what people know most of the time, because most people know what they know is post-product market fit. I'll talk more about it, and it's a common theme. And just a small disclosure, I'm not a business person. I'm a builder, so this is going to be my perspective. There's a lot more to it, a lot more details. But everything that I will mention is something I had to deal with when it comes to the project and the startup, even if I don't say it explicitly. I usually don't talk about myself, but here I kind of need to give a little bit of background, so I'll make an exception. I created the Docker Slim project, an open source project. Now it's a CNCF project. It helps you understand secure and debug container images. I build it for myself to solve my own problems. And then later on, I founded the company, Slim AI, and now with my new venture, I'm using the project, the promise of the project, and taking it to the next level in terms of automation using all of that current tech that everybody knows about, and I'm not going to name it. And I'll talk about the project phase and the startup phase one after another, but first, I want to mention a few important themes. First, you need persistence. But the open source and the startup don't give up. You can give up. If you give up, that's pretty much it. That's the main theme, and for example, with me, I'm not the smartest person. I'm not the most talented person. I'm a little stubborn, and I don't give up usually. That matters. Next, you need people who get open source and pre-product market fit startup when you get them started. It is critical. You need that with your partners, your investors, and your early employees. You need to talk to users. Same with your project and your company. Do it all the time. Really need to talk to people. Building an open source project prepares you for the startup more than you may realize. This is one of the other themes, and I didn't know about it, but it was an interesting learning for me. And one of the things that I didn't expect is doing the opposite of what you think you should be doing, or what you know, or what you're used to, or what's considered best practices. And this is related to pre-product market fit in this kind of unique world you need to go through first. Not something that a lot of people get to experience, but it's an important thing that you need to get right. So let's get back to the journey and the project itself. The journey started way before the project was created thanks to DevOps. Tons of definitions, but one is you build it, you run it. It's awesome, but it requires you as an application builder to know a lot more about the infrastructure, and you actually end up doing more. A lot of manual work. And I wanted to figure out if it's possible to automate that manual work. I've done a lot of different experiments. And then my first prototype was actually with AWS. And it was pretty successful. And then later on, I applied the same idea to containers, taking advantage of one of the Docker hackathons that Docker had. Got the first prize in Seattle. Got the second place in the climbing category. And the journey started there. And for me, I wanted to have an easy and an automated way to have production-ready containers. So I wanted to solve my own problems. And the problems I saw other people had around me. It was actually a lot of work for a one-day hackathon. I didn't get any sleep. And the project was still not functional by the deadline. So I was that close to giving up. I was thinking about not submitting. But eventually, I ended up submitting anyways, and I fixed the problems soon after just in time to record the demo. And maybe I got lucky. Maybe. But if you give up, then you're not going to be lucky. And there are a few lessons there. Giving up, not giving up, that is, is important. It's pretty much required. You need to keep going until the very end and pass that. And it's also pretty common not to have your project or your product happens with the startups all the time, not functioning until the very last moment. And you shouldn't feel like a failure. There are actually a lot of similarities between open source projects and pre-product market fit startups in that sense. They're not perfect. A lot of times it's till the very last second that you don't know whether or not it's going to work. Anyways, when you have an open source project, it doesn't become popular overnight. It was the case with Dr. Slim as well. Didn't get lots of stars. Didn't get lots of attention. Did get some interest, but it was a little bit. You have to work on it little by little. Day after day, it adds up over time, and then you get this amazing compounding effect. Again, you can give up. You've got to keep going. Something to keep in mind is that not every open source project is like Kubernetes. So if you try to measure yourself and your project to Kubernetes, you're going to feel like a failure and you're more likely to give up. You get to define what success is, and it's not necessarily the same scale. It's different for every project. When you grow in the project, it is important to make it easy to discover. I was lucky enough with the project. I ended up picking a name that people googled a lot. I asked a lot of early users, how did you find the project? And they said, well, I just typed Docker and I typed Slim. I don't know the project, but every project is different. So you've got to find your own way to be discoverable. You don't build a company around an open source project just because it's cool. You need to solve a big enough problem, and getting enough adoption for the project is one way to confirm it. There's a lot more to confirm it, but this is the first step. If you don't get that adoption, maybe you shouldn't start the company. Now, with open source project, almost any open source project, or most of them, adoption disability is tricky. You don't necessarily know who's using the product, and the HashiCorp founders talked a lot about that in their struggle. So don't feel like you're alone. Everybody has the same problem. For me, one of the things that helped was getting a custom release download location, and I was really surprised when I got the first 10,000 downloads. I didn't expect so many downloads and so many people using the project. It was early on, right now it's a lot more, but again, if I compare it to Kubernetes or another project, the numbers might be different, so you get to define what success is for your project. The GitHub issues could be a good indicator. Actually, that's one of my favorites. Unfortunately, it makes your project look like a failure, like it's broken, but it's really just a tiny fraction of the user base, so it's a good proxy. The number of contributions or contributors could be good, but only for a small fraction of projects, because most projects don't have a lot of contributors. A lot of successful projects don't. So it's a useless indicator most of the time, but it helps when you do have it. The most useful indicator is the direct user feedback. Users asking for more than what's provided is very important, because if your project solves every possible need the user has, why would they want to use a commercial product? They need to want more, so their needs need to go beyond the value of the project. That's important. For me, the project was a way to validate the concept of application intelligence and the application-centric approach to cloud-native infrastructure. I wanted to see if it was possible, and the answer was yes, and there was also adoption, so it made sense to move on to the next phase, and that's the startup phase of the journey. Startups with open-source can have competitive advantage in terms of adoption and market-mind share, and that's really important. It can be really useful if you use it right, but you also have more opportunities for things to go sideways. You need to pick the open-source model that works for you in your product. For Docker Slim, it was open-core. It never made sense to open-source the whole product. Going forward, for example, what Elastic did or Confluent did with their platform was strange to me, because then they rolled back the licenses and they should have known better there. But if you're using open-core, make sure that the core is useful on its own, and then it's truly open, not just a placeholder. You do need to figure out the story and the relationship between the project and the product. Positioning the product against the project is not going to benefit either, so that's a big no-no. You also need to have investors compatible with open-source. This is really important. They need to get open-source and its benefits. Do they consider it a liability? Or do they consider it a competitive advantage? Do they tolerate it just because they want to be a part of your startup? Or do they really get it and truly believe it? If you don't answer those questions, then it's going to be tricky going forward when things are not going to go smooth, and there will be times when things will not be smooth. And that's when you start getting those questions about the licenses, whether or not you should change the license or whether or not you open-source too much. And maybe sometimes those are good points, but I want to make another example using Docker and their open-source. If you look at Docker and what they open-source, before they got restructured, their business wasn't great. Now they're doing great. The level of open-source is the same and after, but before they were not successful. Now they are successful, so it wasn't about open-sourcing too much. It was about not executing and not focusing. And this is important, but the open-source project, but what you do there and the company, you need to focus. They had a bunch of mediocre products, and neither of them really took off. And then they focused on two that they already had and now they're successful. But you need to have investors who get it because they need to support you in this journey. Building a company from scratch is not something that many people get a chance to experience, but as an open-source project creator, you're actually one step ahead because you already created something from nothing, but limited resources, and you already created something that other people want. And that's one of the mantras you have, that companies, you've got to build something that people want and also willing to pay for, obviously. And you also convinced others to be a part of your project, so you're one step ahead. So if you want to learn more about startups, go create an open-source project. It will help a lot. Speaking of others, people are always the hardest part with the open-source side of things and the company side of things. When you're starting a company, you have to sell the vision a lot and when you're starting from scratch and you have nothing and no open-source, that's a tough sell. When you have an open-source project, it's much easier because you already have something and that actually helps you sell your startup. Pre-product market fit, especially with the first employees, you need missionaries. And the open-source project can help you find those missionaries. And ideally, the people also personally identify with the problem because it has a huge impact in terms of velocity and quality of work that happens and it's night and day. It's also critical to have people who get pre-product market fit. Again, it's this magic state stage in the company lifetime that's very different from what you know after. And it's very different and a lot of times it goes against the best practices. It's especially hard for your engineers. And being stage-appropriate in this pre-product market stage is this unique stage. It's key to operating a pre-product market fit startup. You need to have scaled-down and lightweight processes can operate like a big company. The same applies to decision-making process. The directly responsible individual model can be super effective where you pick a lead and they get to make a call. Design by committee, on the other hand, is not that great. It is an anti-pattern you want to avoid. I'll have more anti-patterns there but it's an easy trap to get into when you want to be inclusive and you want to make everybody happy. You also need to use stage-appropriate tools. For example, just because a big company uses Tool-X Kubernetes, for example, doesn't mean your startup needs to. And the same applies to your product architecture. The architecture your product needs to have in five years is not the product architecture you need to have now. You need to start with something simple. Engineers tend to build for the future, tend to future-proof what they're building but doing that when the future is not known is going to be a distraction and it's going to be counter-productive. Speaking of not knowing, you can predict a lot of things, a lot of unknowns and future-proof yourself. On the business side, for example, SVB was a great surprise for a lot of startups. Most startups were not prepared. Most startups that used SVB weren't prepared. But you deal with those when they come up and then you solve them. For us, a couple of other unexpected unknowns were the two wars, the war in Ukraine. We were just getting ready to expand our engineering presence in Ukraine and the war started. So we had a setback, same happened with Israel. Just when we were expanding our presence in Israel, the whole mess there started. And again, we were lucky on one hand because we were early on in our plans, but then on the other hand, unexpected setbacks that had impact on what we were doing. But probably the most important thing that you need to have is this direct line of learning when you're executing and operating a startup. It's a must for founders, but it also needs to be there for your builders as well. Having multiple layers of indirection that you see in bigger companies is felt in losing lots of context and it makes it easy to get off track and because of that, it takes longer to get to product-market fit. And the tricky thing there with product-market fit and early-stage startups is that you need to reach critical velocity in terms of your ability to iterate and your ability to learn. It's like back to the future. I hit 88 miles per hour. If you don't, even if you get close to it, you're not going to succeed. So it is important to move fast and iterate fast and you need to optimize for it. And a lot of times it means doing less and applying the 80-20 rule, getting 80% of the value, but 20% of the work. And I had to do that a lot where I had to ask the engineers to do less. Limited designs, simple capabilities and all of that. Nothing you do matters without users and actually talking to users is the most important thing to do. Again, with the project and with the startup. And that's one of the areas where you need to do things that don't scale and that's an example of things that are unique to pre-product-market fit and on one hand it's an example of doing things, an example of moving slow, but in reality it's more about quality and not scale. Because if you jump ahead and try to scale that learning with automated analytics that can handle 10,000, 100,000 users, that learning will be shallow and useless. You need to start with one person. You need to make them happy than two, than 10. You can't skip that. You can't scale first. Obviously talking to random people doesn't help so you need to make sure you target the right people and you need to actively disqualify users. It's a numbers game. You can't get stuck talking to the wrong users because there are a lot of them. There are a lot of users who are interested in mature and complete products but it doesn't mean that there are no users who are interested in something unique you have to offer. You need to discover them fast, as fast as possible and usually you want to target innovators and early adopters and they will use your product, an open source tool despite the gaps that you have in the product and the project because they care about the value. They want to take advantage of that. They want to be your design partners. If you have other adopters or laggers, they'll hesitate. When you ask them, do you want to be a design partner? They'll say, we want a more mature product. It doesn't mean that there's no value in your product. I'll mention a few anti-patterns. I mentioned one already. There are a couple of interesting PLG gotchas. Just because your open source base doesn't mean you automatically need to use PLG. You may want to have bottoms-up adoption, but you actually want to target your buyers using a more traditional way. Also trying to do PLG while you're trying to do enterprise sales is counterproductive because you have a limited capacity and you need to focus. If you're trying to do both, you're going to be bad at both. And have a PLG ready product that requires an investment. That's expensive. If you build that before you build enough value, you'll fail because without the core value, it's going to be useless. You need to have enough critical mass there. So the order matters. Building too much and building a lot more features where you use quantity as a substitute for value is one of the other anti-patterns. Not having enough features is not a problem. Not having PMF is. Company building and premature scaling is one of the other common traps. You need to nail it before you scale it. And then building for the future and building for scale. That's a common engineering gotcha. I'll skip that because I'm over time and I'll skip the other thing. So in terms of key learnings, one of the big ones for me was that creating an open source project is like a dry run for a startup. It's very similar, but it's going to be a lot more intense. And then the other learning was not giving up. And also having the right people on your journey with the open source and your project and your company. That's pretty much it.