 Hey everyone, this is Jono Bacon and thank you for joining me for my session I'm thrilled to be here and thank you of course to the Linux Foundation for putting all of this on I hope you're all safe and well wherever you may be in the world So today we're gonna talk about doing open core well And I'm gonna share my screen and we're gonna get right into the actions bear with me. You lovely people all right Okay, so So Open core is a pretty let me go there. Oh hang on. There we go. Open core. It's a pretty complicated subject It's been a pretty controversial subject Across the open-source world And one of the reasons for that is because there's been a number of companies that have sprung up in recent years that are trying to balance this This balance between an open-source project that adds a lot of value that people can use and they can download and they can Contribute to with a commercial product that sits on top of it or sits near it And over the years we've seen various people expressing Some concerns about this, you know, for example Simon and Matt and various other people And I think a lot of this this this concern is quite reasonable And that's typically because kind of the balance in the culture of the participation in in an open core project project Is just it's not quite the same as a regular open-source open-source project. Okay Now I've struggled with this over the over the time because over the over the last 20 years that I've been involved in open source. We've seen many Many companies be successful We've seen the red hats and other folks like that and they've taken models that are very very different But we're seeing a whole range of different companies who've been very successful with open core And it all begs the question. Is this the right thing for open source more broadly? Like a good example of this is something like vault Which is a very popular open-source project and this is this has been facilitated by hashy corp And there's no denying their success and there's been a lot of people who've been incredibly passionate about About the the products that they build and the projects that they work on all these different elements So I don't really want to get into the question of whether open core is Um a good model or is the right model or is the best model to me The thing about open core is that it can if it's facilitated correctly I think I think it can work pretty well But I think one of the reasons why we've seen some of this Some of these challenges with open core and some of this feedback and some of these criticisms Is because culturally it's kind of unusual to to to many open source folks. Okay We are a big A big collection of cultures in the open source world You've got open source and apache and you've got free software and all of these different groups And it even subdivides into specific areas such as you know The ubuntu community and the debi and community and the fedora community all of these different all these different subgroupings So my general view has been I think open core can work Well, if it is executed effectively if i'm being completely honest with you I think one of the reasons why people struggle with it is because many companies don't execute it effectively So what I want to cover in this session is essentially my Roadmap of some of the things I think we should focus on when doing open core You've effectively decided that you're going to work on an open core project That's the way your business is going to be structured You're going to have an open source project and then a product that sits on top of it And and and you're going to use the open core model to generate revenue as well as building Technology in the in the open source project as well Now a lot of people I think certainly when I talk to companies and I'm working with companies around open core They think it's a technology problem. They're like, how do I configure my github repo correctly? And how do I get the right people involved and and how do I incentivize people and how do I How do I build the tech in a certain way? And I actually don't think it's a technology problem I think it's a culture problem and it's about bridging two different cultures. You've got the open source project over here Which is all about providing a level play in field open Code review and issue tracking and discussion and all these different elements and then you've got The that the company over here, which is all about generating an effective business and generating revenue So when we break open core down, there's kind of two primary components to this Okay, we've got the project and if you think about most open source projects It is all about and as it should be about a level playing field an open source project really succeeds when you've got a diverse range of people participating in terms of gender in terms of Sex in terms of race and there's all of these different elements as well as ideas and background and perspectives and approaches Now you've also got the product side of things and typically with most companies. They get to make the decisions around the products Okay, so I think where we see these cultural challenges is actually in this middle ground is in this This kind of connective tissue between the project and the product So I think when you look at the vault and the hashi corp and another example will be git lab who I think have done an amazing job With their open core business is they've really perfected that middle ground. They've nailed it They've got it down and they've built a good cultural connection between the project and the product The businesses that I think get it wrong and the projects that get it wrong There's kind of a division starts forming between these two different sides So everything I'm going to cover in this session is all about Understanding and refining that central middle ground. Okay So I want to cover six principles I'm going to try and get through these as quickly as possible in this session because I want to leave some time Uh for some for some q&a at the end, okay All right, so let's get into the first one the first principle really is Does the market and industry want your project and products, right? It might sound a little obvious, but There needs to be a need And uh, and I think this breaks down into a number of different areas One is that open source really isn't a panacea I've worked with a lot of companies in my career Where they've got a product and they think all we need to do is create an open source project and we can bring people in It's the perfect it's the perfect situation, right? We we gain excitement We get people involved as part of the open source project and then it's going to generate a ton of leads and a ton of revenue And in many cases that doesn't happen So open source is not going to solve all of your problems We need to first of all break it down into does your project actually solve a pain point? Does it add some kind of value? Does it do something that adds value in the world? Just being open source itself is not enough just being free software itself is not enough, okay so Does can you create a project that in itself completely standalone can add value to the world? Now the next question in my mind is going to be Is there a realistic project project product market fit in there? Does the product that you create add something valuable on top of that project? So a good example of that will be matamos matamos is an open source Chat platform similar to slack And you can go and use the open source version Completely by itself and get a load of value out of it a lot of people do that and they've got a lovely community wrapped around it But then they've got an enterprise product that sits on top of it that helps with You know corporate integration all these different elements. So there's a logical There's a logical value on both sides of that equation But the next question is going to be a people can actually pay for the product Now sometimes amazing how many businesses actually leave this question to kind of some of the time and they'll cover that later on But this is really important. Okay, because Are they going to pay for it and how much are they going to pay are important questions? And then we also need to be clear on what participation looks like especially with competitors If you're building an open source an open core project You're going to have to be comfortable with your competitors potentially participating and contributing to that project Just look at any typical open source project. Look at linux lots of people Contributing and participating in linux from radically competing companies. Okay So the second area here is going to be who are your target audience? Right? Who do you want to bring into this? And again, this might sound like a bit of a baseline element here But I think it's really important because there are many different audiences out there. There's users of the software There's customers who buy the product. There's what I call the inner developers These are the people who contribute to the core open source project itself And then you've got outer developers. These are the people who will build These are the people who will build Technology that sits on top of it such as plugins or apps that sit on top of a platform You've got contributors in different forms people who write docs people who do translations You've got commercial partners who will maybe go and do affiliate marketing and And run partner programs. These are very different audiences with very different needs Okay, so we need to be clear and prioritize who who our audience should be because To be completely honest with you you're never going to be able to Satisfy everybody all of the time. So we need to prioritize and focus on the right pieces With most of the companies I work with on the open source project side They care most about inner developers and users And the product side they care about customers So we need to make sure we design the journey for both of those sides because they're very different What a customer needs will be very very different to what an inner developer in a project is going to need The way I would recommend you do this is to use this model that I've been kind of developing over the course of my career I call it the community participation framework Where the best experiences in the world are journeys You know if you go to disney world if you go to a good restaurant if you buy a video game The first steps in that journey are very carefully orchestrated to make sure that you can have the best possible experience We need to do the same thing with our communities So I you know in a nutshell and I cover this in my other talks and in my book people powered You define your audience, which is the little person there on the left You on ramp them to to generate something of value Which is really critical and then you nurture them from being initial casual participants to regulars And then onto core and the little lumps in there are the incentives that you drop in to move them forward So if you want to build a great open core project You need to build an intentional journey for your open source contributors as well as your customers And they should be separate if you make it the same journey. That's where you're going to start getting into hot water All right, so let's get on to the third one now This is this is a big one. Do you have an open accessible project infrastructure now? This is often where a lot of companies who I've worked with in open core This is where they often start right, but there's a reason why this is number three of my six areas that I want you to focus on and the reason for this is that Um, we need to figure out the cultural pieces first as I mentioned earlier on this is this is a culture challenge It is not a a technology challenge Now this number three here is the technology piece of things But if we don't have a clear have clarity on our audiences and what they want and how we engage with them And the standards of conduct and expectations if we don't have those clear then all of the technology decisions in the world are not going to Fix the lack of trust and the and the cultural challenges that you're going to face between these two different parts of the of the fence Okay, so when I think about the open infrastructure pieces, this is all about defaulting to open. Okay Um, use an open source license now. I'm not going to get into whether it should be a permissive license or a copy left license I will leave that as an exercise for all of you to go and enjoy that debate Um, but have some kind of open source license You can't have an open source project if you don't have an open source license So open core requires the the the the open source license You absolutely need to make sure that you have open code issues and documentation. I kind of see this as four priorities here. Okay The most critical priority is going to be open code You just cannot have an open source project if you don't have open peer reviewed code The second is open issue tracking. This is where people file bugs and defects and other bits and pieces Um, the third is going to be conversation You need to make sure that people can discuss the project and what should go into it in the architecture And then the fourth is road mapping not all projects have completely open road mapping. I'm okay with that I'd love open road mapping if you can do it, but it's not a core requirement But if you want to build a real open core Community you absolutely need to have open code issues and communication and the documentation piece kind of fits into that too So, um, we make sure that we've got that peer reviewed workflow And what's important about that is that when your engineers in your company Submit a pull request it needs to be reviewed out in the open Even if the only people reviewing it in the early stages of your project or other engineers in your company That's fine. We have to adhere to the openness if you don't do that You're not going to earn the respect of it being a real open source project. Okay, so And that's one of the reasons why the the on ramps are so critical because you can bake that peer review process Into the onboarding experience for example of your inner open source developers Now the open communication I think is really important And this can sometimes be difficult for companies who are less familiar with open source Who want to go down an open core direction? Because it's culturally normal to go into a meeting room and have a conversation with a small set of people But it's important that we don't do that. We need to make sure that we are Having conversations out in the open where possible now There are exceptions to that rule for example if you're discussing security defects Or you're discussing something that only relates to the the commercial product you can have that privately That's fine. But for the open source project, we need to operate out in the open So the open communication channels and meetings are essential And as a general rule just try to avoid code dumps again This is a cultural difference between some companies and some projects What companies will think I dumped this massive chunk of open source code in github They're gonna love it Well, not really because it's actually it's an incredible amount of work to understand that code And and break it down and and make it maintainable You know, I will point you to star office as a historical lesson for that particular that particular piece All right, so let's get on to number four now I think this is This is really important Possibly one of the most important elements of this is what is the relationship Between the community and the company. This is where it is at when it comes to open core Remember what I talked about with the project and the product You've got that that connective tissue in between if you don't have a good relationship You're gonna really struggle and this is not something you can just do once this is an ongoing thing We build trust as an ongoing day-to-day basis We are judged on the on the content of our actions not just the words that we say, okay So I've got a lot to cover in this so first of all If you want to build an open core business and project You need to understand those cultural norms of open source Because that is going to be the baseline if you don't understand how an open source project works And you're not willing to commit to that and the norms of that then you're going to struggle with the open core model And I just recommend that you don't do it. I've actually worked with four or five companies now Where I've come in and they've asked they've been interested in open core model And I've come in to kind of help them build out the strategy And then I've actually recommended that for them not to do it because I've not been confident enough that they can Actually a understand those principles and be commit to those principles And if you're not willing to commit to them, it's going to be a disaster So we set expectations around what that participation looks like and then we have to Equalize that community participation as much as we can That's what I covered earlier on around making sure for example that the the the development work is done out in the open Even if it's the just engineers from the company Now a critical element of this is going to be providing training and incentives for your staff You know, it's easy for us in the open source world and for people who've been around open source for a long time to get kind of snooty about About about how you kind of You know, well, they should know how to do this. It's really easy. It's not rocket science to understand open source It's actually really weird for a lot of people in businesses. So you need to train them You need to give them incentives around the right kind of participation There's a lot of engineers out there who've never worked with open source and we need to make sure that they feel comfortable in doing So um, and then you recognize and reward participation within the community itself Okay, so this is really important. You would never ever want to funnel all of your engagement through a community manager This is one of the biggest anti patterns. I've seen in my line of work Which is building communities is a company will think I need to build a community around open source I'll hire a community manager and then the entire company funnels everything through that one person Open source people don't want that. They want to talk to your community. Your staff members directly. Okay So that's that's really important and then never ever ever ever spam Users or sell their information or anything like that that completely breaks down the trust All right, so I'm going to get into a couple more I want to be mindful of time and hopefully leave a couple of minutes for questions I know I'm getting through a lot of content But I wanted to make sure that this was absolutely worth your you know 25 minutes or whatever So this one is about building really strong dependable trust and relationships now Again, what I think businesses that do open core. Well, it's all about they they figured out a way of facilitating that trust and doing it effectively, okay GitLab I think are one of the most wonderful examples of this right GitLab contributors to the project generally have a pretty good relationship with the GitLab company Because the GitLab company has gone out of its way to be as open as possible If you want an example of this go and read their company handbook. It's completely out in the open. It's pretty remarkable. Okay so You've got to be intentional about diverse high quality community experiences You've got to remember the model that I showed earlier on about the the on ramping and the casual and the regular and the core If you don't if you're not intentional about shaping that journey Then you're going to essentially boil everything down to the lowest common denominator Then it's really important that you build that relationship with your key contributors Don't just see them as consumers of your community Help them to come in and shape ask for their input tell ask them what is going wrong. How can we improve? How can we refine what we're doing? You want to make sure you incentivize the right kind of mentoring? Your more seasoned members of your community have them mentor the newer folks Have your staff members take time to go and provide mentoring and support the community. You need to make time in your staff's Just day to day work to actually invest their their time in the community They're not just going to be able to write code consistently all of the time And then you you are going to get criticism at some point with with open core. It's it's completely normal Frankly anything to do with open source. You're going to get criticism because there's a lot of Very good very decent, but often very vocal people out there in the world and they keep us honest Okay, so I'm sure I'm going to get criticism for delivering this presentation and that's fine because that's how we get better That's how we improve so we need to Be be reasonable and measured and be a listener when it comes to that kind of criticism. Okay All right, so I'm going to get into the final one here Which is number six and this is about open accessible and inclusive leadership I am going to be having a few minutes for questions If you've got questions you want to get in then Feel free to pop them into the old chat channel and I'll get to them as quickly as I can So This one I think is is is again It touches on the cultural elements, you know, some of you may have been coming to this session and think Oh, he's going to tell us all of these specific technical things I should do like what I should put my readme.md and what I should put my contributing md and how my How my peer review code process should be working and you know, how many slack channels I should have We can get into that level of detail, right? There's I have a separate presentation Which I do which kind of is packed with all of those kind of detailed technical recommendations, but it's like an hour long Okay To me the most important thing again is about culture and the thing about leadership is that psychologically We mimic our leaders Okay, we all do it and this is one of the reasons why if you've got great leadership at the top And they they they're they're inclusive and they're engaging and they're collaborative and they're open to criticism and feedback Then you get you in many cases get that kind of behavior in the in the community in the organization They wrap not everybody but in many cases that happens, but if you've got bad divisive Uh, you know bigoted leadership, then you're going to get some of those behavioral patterns as well. Okay, so Um, this this one's really important clear governance for the project I think is absolutely essential you absolutely want to make sure that Uh, especially if it's a larger project and you want lots of different organizations to be involved You need to have objective leadership. Now a good example of this is the linux foundation, right? They have leadership Um, which is out there in these different projects and that provides an opportunity for Um for different companies to come in and feel like it's an actual level playing field. Okay Um, you also want to base that leadership on actual participation and not just you know people who are A big deal or a big shot you want to make sure that people come in and it's uh, you know, they've got real merit, right? Especially for example in technical steering committees You want to limit and ideally avoid any kind of specific privileges for any commercial entities If they're going to come into your community, they've got to earn their way in They've got to earn a place where they can come and actively participate You've got to really define very clear policy when it comes to that that bridge that connective tissue between the product and the project So this is especially important for the company. You got to make it very clear how your engineers How your participants operate in the community? So it fits in line with the open culture Which is the open bit in open core and then always being open and transparent in what you do And this is a final one If you if you want to if you need a legal entity for your open project Go to an existing foundation. Don't set up a new one a new dedicated foundation. It's incredibly expensive It's incredibly complicated and it takes forever. Just go to an existing foundation Whether it's the linux foundation Apache or something else. Okay, that's the place to do it All right, so we've got just a couple of minutes left One final point like when I mentioned open core and twitter elsewhere people start fighting And we're all learning, you know when I first got involved in open source in the late 90s We hadn't got any of this stuff figured out and we've learned over the course of the last 10 or 15 years Because we've shared interesting insights and ideas. Okay So I think we need to explore all kinds of models with open source and how to do them well Um an open core is one of them. So I just encourage us all to have a view of of being have been Open and transparent in terms of how we have these conversations Um, and then I'd certainly love to hear your feedback Let me know on twitter in the chat and comments and elsewhere And I'm going to wrap it up and get to some questions. All right. Hang on. Let me stop sharing my screen Let me go to Hang on bear with me Do do do All right, let me go to the questions now. We've only got a couple of minutes I'm going to blast through these as quickly as possible Eduardo silver any advice for how to avoid friction on features in open source versus the product I think the general view that I would take here is that the project the open source project Should be the features that are going to be broadly and generally available to everybody And you want to make sure that the product is going to really I think commercial integration and optimization is the best way to focus on the product But it depends largely on what kind of what kind of technology you're building What I think is very important is that you set the expectations Of what happens if someone creates an open source equivalent to the The commercial feature and to me you should never squash code Let people have that code available elsewhere But sometimes you may have to have a policy that says we won't include this because it competes with the commercial product You need to draw that line yourself in terms of what you feel comfortable with that Lucas Galvini Or galva galvanini once I have a small community. What point should I invest more? What point should I invest more time in I would at the beginning absolutely focus on the on ramp Create that and identify your audiences create the on ramp And and certainly in the first few Stages of someone joining the community make sure that people have got access to good quality mentoring I can't go into detail about this because we don't have enough time I don't want to pitch anything too hard, but definitely go and get my book people powered It walks through how to go through that step by step Nithya, so nithya ruff who is an amazing person Some of the criticism about open core is around advocating for license restrictions or change to allow business models Can you comment on this? Um, is it about using open source open OSI curated licenses only or not allowing license changes? I think you need to use an open source license. Um, I get why we've got these licenses that are propagating In terms of restriction what people can do. It's not open source. Use an open source license is my personal take on this Jono, this is Gordon half. What is your take on clas? I think clas are fine I mean, I think it's part and parcel of running a large scale open source project I just think you need to make sure that The process is clear people understand their rights understand what they're signing. I think it's totally fine Liz writes. What are your favorite good bad? Examples of open core not pure open source projects working well in foundations Um Not oh, I see open core. I mean, I gave some examples earlier on. I think I think vault hashy corp Git lab. I think great examples. I think matthew most is a great example um in terms of bad examples I don't know actually. I mean, I don't really I'd rather spread the world I'd rather spread sugar around the world and vinegar. Um, so let's just focus on the good stuff Um, and then I think I've got like 20 seconds to answer a steve walley question Any advice on keeping customers and community separate? Um, I don't think you should keep them separate I think the customer should be welcomed and be part of your community But I think the cultural norms of both sides needs to be very clear. All right. I'm out of time everybody Thank you so much. If you want to learn more go to johnobacon.com Peace out. Thank you everybody