 Thank you for coming here, for today's talk. I know day two, great keynotes, and a huge place. Getting lost is easy here. So I'll just skip the title one. Like they say in Chicago, we are glad you are here. We are also glad that we could come here to share our stories. But more than our stories, we also want to keep this interactive, and so we'll try to get through what we want to present as soon as possible and listen to more questions or comments from the audience. Whether it is a story that I want to tell about this picture, but yeah, this science are everywhere. I don't think anybody would have seen this. If you have seen this, raise your hand. OK, this one person that has seen this. So they took a similar path that I have taken. What we are really going to talk today is the conundrum that we have about should we open source or not open source from three different perspectives, from a founder of a project to an engineering manager or somebody who's maintaining the project to a product management person. So before that, a quick show of hands. How many of you are maintainers of open source projects here? It's good to see some hands there. How many of you are looking at creating a product out of that project or making money out of that project? That's a lot more, right? So cool. We'll see if the journey that we had to convert a project to a product, what we learned in that process, and if that will help you or you have some things that you can share that we can take away from here as well. Before we get into those learnings, something happened around five or six years ago. And thanks to these people, of course, they did the Kubernetes thing. But they also changed what it means to be an open source company, right? I have not met most of them, but I've been watching them from India, getting inspired from their work. And when I started my startup back in 2017, a lot of things that I got inspired was learning from them remotely. So we're all in search for building unicorns, at least like if you have an idea and you want to go to investors. Investors will only find you if you have a potential of becoming an unicorn. And one sign of becoming an unicorn is either climbing up this ladder of sponsorship from startup sponsor to silver, gold, platinum, or getting acquired by one of them. But what these people did is it's not about building a product that gets acquired. It's about building a community. And that community builds the product and delivers that product to the end users. So that was an interesting change in the perspective of what open source means. It's not just about the code anymore. It's about the community that you built, right? So with that change definition, so unicorn is not about the money, but it's also about building a strong community around your project. We'll just do a brief introduction and then get into the learnings. Hey, hey everyone. Thanks for coming to our talk, Code, Chaos, and Cash. So in this talk, we want to talk about our personal experiences of how we have looked at building communities, business around those projects, and we want to share some of our opinions. And I want to throw in a quick disclaimer that these are our personal opinions and not of our employers. Yeah, that was very important for this talk because I don't know, it might be a little debatable. So I'm Anusha. I'm a technical product manager at Nirmata. So Nirmata is the company behind Kivarno. So if you all don't know Kivarno, it's a Kubernetes policy engine. Prior to this, I worked at VMware. So there I've worked on projects like cluster API and providers for cluster API. I want to give a quick introduction of Kivarno because in today's talk, I'm going to be sharing my learnings as a product manager over the past year at Nirmata. So Kivarno was donated to CNCF in 2020, but that is not the origin story of Kivarno. So obviously Kivarno predates me. That's why I have this information. I got this information from the founder of Kivarno himself, Jim Bugwadia. So the story goes like this. So Nirmata had a Kubernetes management platform and like all platform vendors, everybody was trying to build up a managed Kubernetes platform that had cluster management, app management, observability stack, and even security was one of them. So back then, an alternative to Kivarno was OPA, open policy agent. And if you're new to OPA, so you need to be able to learn a new language called Rego and write Kubernetes policies using that language. So the team wanted a simpler option to write policies. They didn't want to write it using Rego. And that is where they started with a small rule engine and Kivarno that we know today was just part of a backend service powering the platform. And the idea to donate to CNCF to make it open source was really a go-to market strategy for Nirmata. They just wanted to evaluate whether whatever they're building was right and testing it out in the open is a very good idea. So that is where Nirmata donated Kivarno to CNCF in 2020 as a sandbox project. So the graph that you see over here, during 2020 you see a lot of additions and deletions in commit history. That is where we donated. And then we are now an incubating project. Oops, sorry. We are now an incubating project and well on our way towards graduation. So throughout this talk I'll be sharing Kivarno's journey, Nirmata's journey and monetizing some of the aspects of Kivarno, how we prioritize different features across the enterprise solutions and the open source project. Over to Kiran. Thanks, Anusha. So I have at the opposite journey. I came from a startup, but now I am at VMware. I'm trying to build a sustainable open source project like how do you work on a strategy that funds the projects? But I'll also be sharing a little bit about my past journey with open source projects. One of them is OpenEBS. Like they say, if everything works well in the production, it's not that fun. When things break or when things are slow, it gets exciting. That's exactly the journey that I had with OpenEBS. We didn't have anything but an idea and then we decided we will do that in the open source because that was a fad at that time. Docker was just coming out. Like everything was open source. And I think investors also like the idea that open source is a differentiating factor. So let's do it in the open source. The graph looks very similar to any other open source project. You'll have a lot of churn in the beginning. And especially just around the time of meeting to CNCF, there's a lot of additional checks. So you'll do an additional churn of cleaning up the repositories and all that. We are still in the sandbox stage. There's a lot of stories about that to tell. I'll share that a little later. But one other project that we founded as part of my previous startup was Litmus, which was a spin-off from, it's a tool that we built to test OpenEBS and that itself became another project. And now that project has gone into incubation stage and it's on its way to getting graduated. Going back to this picture, the reason why many people probably don't see this is this picture was taken when I was roaming around the city and landed at an entrance to McCormick Place that was shut and it's not maintained. That's something similar that we experienced when we were working on open source projects. We have our ups and downs. We initially get to a place where you hit a wall. You don't know what to do next and you somehow figure it out. That's why we are here. That's why I'm glad that we are here. And Chicago is a great representation of this like pattern, right? Like it's very beautiful. Like I think right now we are here at the conference where we can take like beautiful walks, enjoy the city, but it's not always going to be like that. It will all hit like, it's popular for its wins, right? So what happened with OpenEBS was we started with an idea. We didn't know how to do open source. So we ended up listening to a lot of people on how to do it right. And the core functionality that we built in OpenEBS starts to change the moment we put it in OpenEBS and we just accepted a lot of feedback. And with every feedback we had to like fork and like do a lot of like iterations on that one. And that takes up a lot of time. And while we were like spending time on that, we also had like couple of like investors like usually fund you for like one or two years and you need to show something at the end of it. So we got into like these phases of like raising money for the next project, getting acquired by some other company, all of these things like hit us, right? So the learnings that we share are basically based on that like turbulence that we had. But also one of the good thing that we did was to keep us on track, to keep us on track from an open source, we donated it to CNCF. Doing it in the open source was one thing but keeping it in CNCF helped us to get regular checkpoints and somebody else other than our investors are the founders telling us what's right, what's wrong. And CNCF has this good way of like labeling the projects from Sandbox to incubating to graduated. One thing that I learned in this journey is you can go through these stages but you have to transform yourself along the way. What you do when you're in a Sandbox stage is not exactly the same that you do when you're in a project, right? And from going from project to product, you literally have to transform your like thinking about like the project, you probably need a new team also at that time, right? If that was like little complicated, I'm a huge fan of Game of Thrones. So this literally explains like our journey as an open source project founders. We start with like everything is possible. We can climb all the towers and all that but then we do fall at some point. And then we realize, okay, now we are in a project mode. We have like a lot of things to take care and we need like a lot of support from different people to get it up and running. And then maybe we just become like a saint or like, you know, our all-knowing person at that point. So then we get into like the product phase, right? So the product phase or how you define the success is a little bit interesting, so I'll come to that one. So just to give a snapshot of this one, right? Like, so this is like the trend that we see in CNCF right now. So this whole like trend also started getting published very recently but there's like a huge rise in the number of Sandbox projects that came in. We opened EBS and Litmus where I think like the 11th or 12th projects but now we have around 175 projects in the category but only around 24 of them are in the graduated state, right? So what does success mean? So graduation like CNCF definitely has a criteria of production usage and all that but I would like to call something as like an happiness generator, right? So you do an open source project but you also check what brings you happiness. Is it like the wealth that you generate with the other people or is it like the careers that you have created for other people, right? So I'm more on the side of the community and like, you know, growing the community and a lot of individuals that come with that and even if your company doesn't make any money you have actually generated wealth for like a lot of other people like that. Don't even know how to get started with projects, right? So that gives me a lot of joy. All right, so we know that projects go from sandbox to incubating to graduation or like an idea, project and product. So we'll split our learnings into these three categories, right? So anytime we start with an idea it's absolutely the best, right? Like you, that will solve all the problems, right? If that is the case we wouldn't have had this kind of a chart and you know, this had to come up, right? There's, you have to interwork with like all these other ideas and the moment like we have a lot of these projects we need a foundation that will help make sure like, you know, everything works properly and all that, right? So what I learned with the idea and Open EBS I don't know many of you know here. It was a storage engine. It was started as a single storage engine but by the time we went into CNCF and incubation at least the sandbox it had three engines not just a single engine and by the time we are like, you know today it has like eight engines that's basically, we fell in love with the problem but the way we accepted the feedback instead of like trying to iterate on the same idea we ended up like creating multiple engines and that's actually come to bite us right now, right? So there's more to talk about get married to the problem. So I think like rushing it, rushing in with a project to an extent that it, you know it now becomes like something that you cannot retract is something that we should avoid, right? Spend a lot of time in terms of learning about the community that is having the problem. Also like these are the lessons that we took away from our research when we were doing this open source, right? All the things that are on the left hand side are things that seem very obvious like things that we should like do, right? But what we learned is code, the code is a new marketing, right? You know we don't market like you shouldn't rush into like marketing like with a blog or like you know future looking statements about a project when you don't really have the code. The other thing that we noticed is even before our startup got into a stage where we could seek investment the major companies have tools that will analyze your open source projects and already rank in terms of, hey, is this a viable thing that we should like invest or look into it or not? So you have to be careful like I didn't know about this back then but when we tried to go for funding we realized hey, people ran the scan on our code when it was in the initial phases and then the initial impressions are really hard to like change. So that's one important, it's a double S word it gets contributors but it also pushes like based on the initial impressions it kind of like takes that away. The second mistake that we did was about forking the projects when we decided like hey, that community is not going the way we want and eventually what we realized especially like OpenEBS has one engine that's similar to Longhorn and we both started off like together. We were talking to each other but the way the data is connected to the devices and like another parts connect to the volumes there was like a disagreement in terms of like how we do it and then we decided okay let's fork this, right? That was a bad mistake like we shouldn't have done that, right? So spend more time engaging with the community gathering the feedback, it's okay like you know they will not accept it right away but if it works I think it will succeed, right? I'm not going to all of them but yeah. So definitely like a lot of ifs and buts but is it really easy decision to open source or not? From a contributor perspective, from like validation perspective, getting feedback perspective, yes it's all good but then there's also this thing about licenses and we've seen a recent history of like a lot of changes happening to the licenses that pieces of the community or like pushes the community away and all that, right? So I was chatting this to Dems like after coming here and I was like constantly in the flux of like changing the slides. So what he suggested was like more like a layered approach. Maybe you don't have to like start off like fully open source. Start in a layered approach, right? Like start with maybe like just joining the community talking about like a prototype or a demo that you have and if people are interested then start giving out like some kind of documentation or like the APIs to connect with the product and then eventually decide like how to really open source it, right? That was like a great advice I wish I had when I started these companies, right? So the second or the third thing, open source is for feedback. Second one is like how do you do open source? The third one, there's going to be differences. As you're on board, you just cannot do alone and you're going to like have co-founders and co-maintenors that come on board. It's very important to make sure like there's some principles that are set and that you agree on it. Like disagree and commit doesn't work at least with the core team, right? Like they end up like going into different directions and that was also one reason why we had like many engines there, right? So at least like these are the four things that we should definitely agree upon, right? Yeah, I think like I can't see the slide here but the great advice from Joe Guetta there as well. Again, like these are things I wish I had before. Coming back to the, once we decided we will do the project, right? Like we had a very small team and we automated like a series of stuff with the tools that were available. And one thing that we didn't realize is like how those tools are also backed by open source companies and those tools also changed their licenses and we ended up like instead of building our own core logic, migrating from one tool to the other, right? So this is also one place where I feel like CNCF helps, right? The thing that we should do from the start, especially if you're like building a startup is you're going to build what you measure, right? Almost like telemetry comes as like an afterthought. You don't know, like you don't base your decisions on anecdotal like inputs. There's going to be a lot of feedback that is going to come in. Use some kind of a telemetry to research like, hey, what engine, for example, in opening years, we later learned that out of all the 250k downloads that were happening, it is just one or two engines that were actually like the 90% of the downloads that were coming through, right? And that kind of makes it easy to kind of make the decisions. We put that in at a very late stage. They're like, again, like we look at stars as a way to like recognize the health of the project or like, you know, it's a thriving project, but I would say like, you know, you should put that at the end. It's a vanity metric compared to like the real metrics which are about the usage. Letting go is another like really, really important thing. The longer we hold on to things because we are going to think that we will hurt somebody, we are eventually anyway going to hurt if we don't have like a sustainable model built around like that particular project. So it's better to like let it go as soon as we decide, hey, this is not going to be the direction that we take. Again, like the lessons from the seven engines to like, we are now going to come down to only two engines in open EBS that are like really getting used. Thanks, Kiran. So, okay, so we saw like whether to open source or to just keep it in a source or, you know, follow a layered approach, but say, let's say you have decided to open source your project, but that's not the end of the story, right? That's just the beginning. You need to be able to build sustainable projects and not just that, you also want to monetize from these projects. Maybe monetize is the wrong word. You want to be able to build business around it. So what is the key to all of this? And the key is community. So how do you build the community traction organically? So it's definitely not a one-time marketing event. It has to be over time, you engage the community, you work with the community and you grow your community organically. There's a few ways to do this. I can quote examples from Kivir Noveran, suppose say typically all the open source projects have Slack channels. So you might have a Slack channel in the CNCF workspace or in the Kubernetes workspace. So make sure the maintainers or the people who are working on the project are always, you know, checking these channels, answering questions, because this really helps new user to use your project if they have any questions, get them answered and you know, that just builds trust over time. And also evangelize at events and conferences. So you can use conferences such as these KubeCon or even your local meetups, wherein you talk about your project, raise awareness about the project, get new users to try out your project that way you'll get quick feedback on whatever you're building and then nurture and grow new contributors. I think this is one of the key aspects of building sustainable projects because as a open source project, there'll be hardly say two to three maintainers or even if it's backed by a company or like a startup, there are like very few engineers working on the project. And as and when your project grows, the community grows, it's really hard for these two to four people to do all the heavy lifting and maintain the project and not just maintain, you have to also keep adding new features, make it more usable and so on. So that is where community plays a key role and it's very important to nurture new contributors, be welcoming to them and for this, you may need to write good documentation, maybe good test pipelines so that any new contribution does not break your project and also use opportunities like LFX mentorship. So that is something I've seen Kivano gain a lot from because most of the star features of Kivano are from LFX mentorship projects. So it's kind of a win-win for both mentors and the mentee, so make use of opportunities like that and do not get, okay, strategize the OSS project roadmap. So it's probably a good idea to treat your OSS project also as a product but used by the community. Like of course, nobody is going to pay for it, it's free, but it's going to help you in the long term. So treat it as a product and make sure it has a roadmap of its own. So typically I've seen projects use something like GitHub milestones wherein you define at least for the next two to three releases, what are the new features that are going to come up, what direction your project is heading in. So this gives an idea to the users, what they need to expect, they're going to be new features that they want to try out and so on. So be very transparent on what the roadmap is going to be and do not get pressurized to favor commercial versions or community versions. So almost all of the projects, there might be a few exceptions, almost all of the projects have enterprise offerings and your customer request might be very different from your OSS user request. So do not get pressurized just to prioritize whatever your customers are asking for because they are not the ones who are going to validate the newer features for you, the open source users are. So always make sure you strike a balance, I know it's hard, but we have to do it. One other aspect is maybe it's all good in theory, right? You can say, okay, I need to write better documentation but who has the time for it? Or I need to write better code, I need to do code reviews, who's going to pay for doing all of that? At the end of the day, it all comes down to a developer or a maintainer's time and you need to pay, somebody has to pay the bills. So, and nurturing new contributors, I want to be a mentor but, okay, give me something to be a mentor, right? I need some incentive to do all of these things. So that is where I think, what do I go to next? So that is where I want to talk about enterprise back to us. So like I mentioned, if not all, most of the open source projects are backed by companies today. It might be a single vendor or multiple vendors. So in case of example, Kivano, there are maintainers across companies but it is heavily backed by Nirmata because Nirmata's solutions revolve around Kivano. It is our core offering. And there are also huge projects like Kubernetes or even cluster API for that matter where multiple companies have vested interests in these projects. So they have built teams, even business units around these projects so that they can contribute to it. They can maintain it because they have the product suite depending on this core project. So, and what to expect from the community. So this I can speak from a, you know, product manager from a startup. We do understand that the open source project is completely free to use. We do not charge anybody for that. And we do gain, we do get value from it because we get insights as to how the product itself should be structured, what features to put into the product. All the insights come from the community, which is great. And communities, open source projects are a great place to test out new feature ideas because it's okay if you release something in beta and say something goes wrong. It's fine, you can release a patch and there is not really strict SLAs that you have to maintain. As opposed to a commercial offering where everything is, you know, completely SLA based and if there's any, there's no room for error basically. And I think while it is okay for everybody to consume your project, I think one ask, typically from the communities, if you're using any open source project, say something like Kivarnu for example, and say you are from a large organization. For example, all of these projects have an adopters list. The adopters list talks about, say if you're using my project, list your company as an adopter, right? So this really helps the enterprises backing it because you don't really have to buy the enterprise license. You don't have to buy the enterprise versions of these projects, but it really helps if you list yourself as an adopter. For example, like recently LinkedIn announced itself as an adopter of Kivarnu and it really helps us because we are okay if they don't buy a product. Just saying that LinkedIn is an adopter of Kivarnu, it helps us with several other say customer pitches wherein we can say, hey, as someone as big a giant as LinkedIn is using our project, it means they have tested for scalability, they've tested for performance. So that kind of gives us value. So it's very important. So today if you're using any open source project, make sure your company is listed in their adopters list because that really helps the companies. And don't open source for the sake of it. So by this, I mean that just because having an open source project or having the CNC of TAG is cool, just don't wait for the sake of it. Only after you have evaluated, if you really want to open source, decide on the license beforehand, what kind of license you want to maintain. So you don't really have to donate the CNC of to be open source, right? You can be open source under your own company's org. So that way you have a little bit more flexibility on what you can change and what you can not change. And also be transparent about the different prioritizations that you're making. Just because the code is open source, you don't, it doesn't mean you strategize everything within the enterprise and just, you know, just turn out features which nobody has clue on as to why you're doing certain things. So yeah, I think being transparent is the key. Oh, we have about five minutes left. So I'm going to power through. And then balancing OSS and enterprise. So this is about feature prioritization. So obviously your product prioritization is going to be different from the project prioritization because the users are different. So your product users are mostly say, some other enterprises wherein they're okay if they don't have the bleeding edge features. They're fine if they get some feature to releases down the line, but stability is more important. So maybe you'll have to prioritize differently for your customers, as opposed to an open source project where you want to try the next cool thing. Maybe you want to integrate AI in your projects. You're free to do that. So prioritizing is, you know, maintaining the distinction in the prioritization is very important. And then, I can't read this side. Yeah, again, having a clear roadmap. So your product roadmap is completely different from your project roadmap because your product roadmap is heavily influenced by your customers, what your company's vision is. But your project roadmap is mostly governed by your open source users. Of course, it can be influenced by your product because at the end of the day, the company needs to make money, but not completely influenced. Support users versus customers. So don't neglect your open source users. So if they ask you any questions on Slack, be sure to respond to them. Don't be of the mindset that, hey, I'm going to prioritize my customer more. Okay, you may have SLAs, but if you just put in this effort to answer your or support your open source users, you never know, right? They can be a customer tomorrow. This is all form of, you know, building that trust with your OSS users that someday they might become an enterprise customer as well. And then I want to talk about, quickly about shifting focus. So again, coming back to project versus product, both of them can evolve differently. For example, Kivano is a Kubernetes native policy engine, but looking at the open source request, the constant ask was, how can we use it beyond Kubernetes? So that is where we prioritized making it as a general purpose policy engine, as opposed to a product wherein people were more interested in policy and governance part of it. That is where we evolved our product from a policy management to policy management and governance. So it is completely different how both Kivano and our enterprise solution has evolved and also expanding use cases versus pivoting, right? Expanding use cases in terms of, maybe you start with a small use case and I think it's really important to start with a small use case and not be all over the place, especially you have very few people working on it, that really gives you to focus on one thing alone and just be the best at that thing. And also pivoting strategies. So as a startup or as a new project, it is very common that everything is going to be chaotic. What you think is right today might prove to be false tomorrow. So you might have to pivot your product strategy or even your project strategy. But it is important to have everybody's buy-in, whether it is the community or even your internal alignment. Like Kiran was mentioning about having eight storage engines, right? But for open source project, maybe it's okay to quickly deprecate, but having eight support model for eight project engines in an enterprise solution is really hard because in a startup there are hardly 50 people and if you are supporting eight different things and eight different customer requests comes in, it becomes really hard to prioritize and even move along. And last thing is make your enterprise products enticing. So you clearly need to differentiate the product differences between your project and your product. And that does not mean you start building features now only in the product and don't contribute to upstream, right? What I've seen work at Nirmata is make all the major contributions upstream. The core features has to come from Kivarno and everything say enterprise does maybe provide good SLA support and even built abstractions on top of the open source project. And be comfortable that users are not your customers. The open source users, they're not going to pay you and it is open for a reason. You decided to make it open source. You decided on the license. So you really need to be comfortable with the fact that your open source users are not going to pay you and depending on the license, there might be some other company building on top of your project, right? And that is the key to, you know, you have to make peace with it. Yeah, do you want to? I think we'll just pause here to take any questions that are there. One thing, it's okay to not do a 24 bar seven support when you're like doing an open source project. When you become a product, you will have like enough funding and like, you know, people to do that. It's important to like set that expectation early on. The one of the mistakes that we do, we become very responsive in the initial stages. Community expects that kind of response throughout and it's not possible to do that. So just having a documentation saying like, this is when we support is good. Good. Thank you everyone. We can take questions at this point. So if you have any feedback, please drop in this one. I think I can take that. So the question was, you are building an enterprise product out of an open source project and you want a new feature and where do you decide what goes where, right? So I think most of the times the enterprise product, if the core offering is the project itself, it is going to follow the open source project in terms of the core capabilities itself. Now it depends on what kind of feature, right? If that feature makes a difference to the open source project, if that makes a difference to the open source users, then I would definitely recommend to, you know, make that decision in the, make that contribution to the open source project itself because again, you get the benefit of the community, right? But if it is like a very niche use case of a one high paying customer and you cannot let go of that customer, then just build it in your product. Yeah.