 Hi. Hi, everyone. Thanks for coming, hearing me talk. Today, I'm going to be talking a little bit about my journey, really, and what I've learned from interviewing a number of successful open source creators and maintainers. I'm going to give you the five lessons that I have learned from interviewing successful commercial open source founders for the podcast that I started. My lesson 0.5, if you're British, don't start a podcast. It's really embarrassing when you tell people that you've got one and the imposter syndrome is very strong. So yeah, who am I? I'm old enough that this was my first computer. It had a three megahertz processor and was amazing. I studied AI here in Birmingham University at the depths of one of the AI winters. There were zero AI jobs when I graduated, which is a sign of the times, I guess. This was my gateway drug into open source software. Back at university, we had dialogue modems and there was a Slackware CD on the front of a magazine. We couldn't believe that we could put it on our local desktop machines at home and write code without having to go into a university lab and sit in front of a Sunos terminal. This was the first job that I had out of university. I was working for the BBC. That was what their homepage looked like in 1997. Yeah, so quite a long time ago. Right now, I'm co-founder and CEO of Flagsmiths, so we are a commercial open source feature flagging, rote config and AB testing service. We're sort of bootstrapped, just about profitable now. Very proud of that. I'll talk a little bit about that later on. You can check out our code. You can run the entire platform on your desktop, the couple of containers, github.com. Why am I talking here right now? My career as a software engineer was basically completely full of consuming open source software. Occasionally, my colleagues and I would raise bugs with open source projects and maybe add some documentation, but it was kind of 99.9% consumption and 0.1% production. I thought it's time to change that. I've been running a software agency for 20 years and we sort of thought that we have the resources to do it at a small private company, 12 people in London. We thought let's change that. Let's start an open source project. But I soon realised that I didn't know what I was doing. I've got a lot of experience writing commercial software, but I had no understanding of how open source projects worked. I'd only consumed them. I hadn't produced them. I didn't know what was okay and what wasn't okay. I didn't know if it was acceptable socially or ethically to do things or not to do things. I just kind of assumed we'll write some code and we'll put it on github and that'll be that. Surely that's the end of it or that's the beginning and everything will just start happening naturally. We did that and nothing happened. I thought let's start a podcast which is now a source of personal embarrassment. Although I am proud of the content that we've generated from it. I thought it would be good to reach out to successful founders of open source businesses and projects and find out what their stories were. How did they start? How did they build their projects and their communities? Maybe they'll tell me. But at the time we were a pretty bad website, a pretty simple open source feature flagging tool. We didn't have a podcast. We didn't have any traffic. We didn't have any followers. We had 30 stars on github. Surely no one's going to speak to me. So that was lesson one that I learnt was that the community is amazing. One of my colleagues, Matt, he's American. He just emailed a bunch of really successful people and said, will you come on our podcast? I was sort of sitting there thinking no one's going to come on our podcast. But they did. He emailed Heather Meeker. She's been instrumental in open source licensing. We emailed her. She said, sure, I'll come on your podcast. We emailed this guy. Probably most of you recognise David Heinemann Hansen. He started Ruby on Rails. He emailed him and said, sure, I'll come on your podcast. And then we emailed Michael Dahan, who for some reason there in his crunch-based picture looks like the fifth member of the Smiths. He started Ansible and he was like, yeah, I'll come on your podcast. He was actually the first guy I interviewed. Before I talked to people, I make a point of cloning their most successful github repository and looking at the first few commits of that repository to try and get an idea from the code of how things started. And Michael's easily got the best first commit of any of the projects that I looked at. Unfortunately, a lot of them you feel like people have done three months of work and then pushed a whole load of code. But Michael's first commit is amazing for Ansible. The first commit message is just Genesis. It's two files. It's a README file and a Python file, which I think if you can see on the right is 4k. And so 51,000 commits later. Yeah, it's quite a bit different, but that was a big source of inspiration to me because I thought, wow, you know, this guy just put 4k of Python up online and built a very successful project and business out of it. So that was my first lesson one that the community is really amazing. And I think the only people that turned me down were people who were working in not-for-profit organisations and the idea of the podcast was about commercial open source. So, yeah, so lesson two was scratch your itch. So we've been running a software agency in London and we had enterprise clients and we just couldn't ship software with them. It was really painful. I don't know, you guys maybe some people might feel the same experience where you get to the end of a sprint and we can't deploy our software that we've written because there's a bug somewhere else that breaks the build or prevents things from going live and then you wait another week. The same thing happens, then suddenly you're like two months later, nothing's been released, everyone's freaking out. Everyone knows that the next release is going to break a load of stuff because there's two months of code in it and you're going to be working the weekend trying to put fires out. So we as an agency were like, well, look, there must be a postgres of feature flags, right? Like they're a fairly well understood paradigm in software engineering. This was five years ago. There must be a postgres of feature flags, but we couldn't find one. So we thought, OK, look, this is our opportunity. Let's start building one and we'll open source it and we'll see where we go. How hard can feature flags be, right? They're just booleans. So we'll give it three months, shortly be done in three months. And five years later we're still working on it. It turns out it opens up more interesting and complex problems and solutions. And now there's actually, there's Unleash. There's a bunch of language dependent projects, but five years ago we were like, OK, let's just do that. We sourced it and we didn't really know where it would take us. And it turned out that it's now a business that stands by itself and is starting to hire folk. So I've got some little clips from some of the folk that I've interviewed over the last couple of years for the podcast. And reiterating the lessons that I've learnt. So here's a clip of Mitchell Hashimoto, who is a co-founder of HashiCorp, invented vagrant and terraform and a bunch of other really transformative technology. So how many little things about the genesis about the, you know, what gave you the, was there anything that influenced or kind of sparked that idea in your head? Sure, yeah, it's quite simple actually. I worked as a junior engineer at the time, one of my first programming jobs, with a consultancy that we worked on, you know, different projects every couple months and you might want to hop on and help a co-worker with a different project. And one of the things I was frustrated with in my work was that my dependencies would get completely overlapping and not dependencies like programming language dependencies, but like my Apache version or my Ruby version or whatever, like global dependencies would get messed up. And I was thinking, I really like a way to, you know, metaphorically what I was thinking was, if you think about a Windows computer or something, metaphorically I wanted to like double click the customer and just like get their environment, right? And I think the, you know, virtual desktops and stuff were a thing even then, but I think the other constraint on me as a university student was I had no money. And so I needed to do this in a way where I wasn't taking an hourly fee or I wasn't, you know, having multiple laptops or something like that. And so that, you know, engineering is all about constraints and within the constraints that I had, I had to figure out a way to do this free and local basically and that at the time the only free hypervisor that was cross-platform with virtual mock, so I took that one. I was a Ruby programmer so I used Ruby and I started just sort of hacking things together to see if I could make this thing work. What made you open source that project? Sure, I mean I think the, there's a couple things. One is that open source is really, I don't think I would, you know, be nearly where I am as a programmer or an engineer without open source because I originally was self-taught. I did eventually go to university for computer science, but I started programming when I was 12 and, you know, my parents didn't want to spend money on these programming books because they're expensive. It's not like a book that's like a novel that's, you know, maybe like $10 or something. Like a programming education book with like $50 is like, my parents are like, no, definitely not. So I found zip files and source code online that sort of, you know, without get or anything. I just found like people uploading cars or zips and I figured that out and I would just read source code and that's how I kind of learned how to do stuff. And yeah, so it wasn't really a choice in that sense for me because open sources was core to how I thought about things. And then the other side, which I think is equally very important, especially sort of the context of our conversation, is that I had absolutely zero intention of ever starting a business, ever making any money at all around vagrant or, you know, yeah, vagrant. I mean, I'd never crossed my mind. And so like the complexities of building a business around open source were a non issue because I was not going to build a business around open source at the time. So, yeah, so that was lesson two. So lesson three, this is probably the sort of toughest problem that we had because we knew, you know, we knew how to engineer software. We knew a little bit about sort of marketing and talking to community and, you know, speaking to customers and things like that. But we had no idea about the licence to choose. We knew what we wanted or we knew what we wanted to defend against, I guess. But we really didn't know, you know, what the best licence was to achieve those goals. And I don't know about you, but I can't. I'm just physically incapable of reading legal documents. As soon as you get, you know, your first sentence that runs on about 15 times, my brain stops. So, yeah, there's a choose a licence.com is really helpful for me where it just boiled down the different licences and, you know, really, you know, fundamentally pragmatically what they mean for you. Your project, your liabilities and your business. And this is one of the things that has been interesting about the podcast is that there's a whole really, really, really wide variety of opinions and approaches and positions on which licence to choose. And interestingly, everyone felt like, I think most of the people I spoke to felt like they were on the right licence for them. But there were a whole variety of different licences that were being used. We chose BSD3, but I spoke to David Cramer, who's founded Sentry, and he had some really interesting things to say because they've had quite a few problems with people abusing their code and abusing their licence. So talk about the gigs. It's interesting. People mentioned elastic, but there's kind of like the example of one pretty much, right? And you're right, like it's not like they got extinguished out of existence by any stretch, is it? So I don't quite know why so much focus is put on that. I don't know, maybe just because it's Amazon and they're this huge, you know, gorilla and blah, blah, blah, blah. So talk about the, or what was the impetus for changing the licence in that case, if you weren't worried about AWS? So, you know, I mentioned I'm like this big focus person. I hate when I have to spend energy on like nobody wants to be frustrated all the time, right? Like you want to be able to spend your energy in a way that's productive and useful. And one of the ways I became frustrated over time was we would see startups, almost always startups, come in basically like copy paste Sentry, like pieces of it and things like that. And I'd be like, well, it's legal because the licence says like literally even our documentation, they would just be like, well, we copy pasted this entire page, but it's open source. It's legal. And the point where I actually had to go like we would have people take our SDKs, which are free open source still today, and they would just fork the thing and not attribute us in the licence. And I have to go be like, hey, you realize this is illegal, like I can take down your entire project, and then they would go fix it kind of thing. But I was so tired of having conversations with that about that, especially with our server code. And then at some point there was also a company of pretty like a larger than us company that was trying to distribute Sentry. And I'm like, why would we help you do these kinds of things? Like you don't contribute back. You're not helping us build a business which funds everything, right? Funds not only development of Sentry, but it keeps, you know, everybody paying for everything that they have for concerns in life like that works for us that develop Sentry, right? And so those things were just really annoying. They weren't a threat to the business, but they were annoying in the sense of like they from an ethical point in our like moral high ground were like, we don't like this and we don't want to spend energy on this. So we changed the BSL license and it effectively has squashed all those concerns. Now I will say day one of us converting to this license, somebody's like, I'm going to fork Sentry and it's going to still be free and then I'm going to build a new Sentry. And it's like, no, you're not, but like good luck to you kind of thing. And I think that was a good move because it's at least we don't have to think about it anymore. If somebody does this, we're just going to straight up goes like submit a cease and desist. And again, these are not like individuals that are like nice people just making mistakes. We wouldn't like go after them, but it's like a company that has, you know, $50 million from venture capitalists just, you know, not playing fair. They weren't taking the whole thing and just putting a new like badge on it. They were taking sort of components of it and then sort of encapsulating their stuff around that. Yeah. So, you know, it's always hard to say what has been used and what hasn't because we can only see what's publicized. No, but the source, of course. So most people do not have an open source product. So I could not tell you who has and who hasn't used our server code. And if they do whatever open sources for learning as well as everything else. But when it was things like using our SDKs again, which is fine, but they're not contributing back. They're just forking it or using our documentation, which is just straight up what the hell like annoying. Why would you? Again, it was just this frustrating thing that we'd see it and it's like, can you? Why are you doing this? And like to where I'd have to have conversations with their lawyers? I'm like, I'm not a lawyer, but I'm going to explain what's going to happen if you don't address the situation. Okay. So lesson four. This is probably my favorite. So yes, small teams can be a superpower. So as I mentioned earlier, we kind of bootstrap flag Smith using engineering resource from the software agency that I was running. But they were really, really limited. Quite often everyone in the company would be busy and no one would be working on flag Smith. And that was fine. That was how we paid the bills. Sometimes we'd literally be getting a few hours a week of time to spend working on flag Smith. Some of us worked on it. We kind of got into it and it was lovely and being able to write code without a customer telling you how they want it to be. Or, you know, making decisions for you. But we had very, very limited resources to build the initial versions of the platform. And initially, you know, we were intimidated. There are these huge closed source companies, you know, the biggest one in the market, in our market space. They've raised $330 million. And it's like, you know, they've got, you know, a huge team of engineers. And, you know, there's no way we can compete with that. But we sort of realised as we started picking up pace that a combination of small teams building on open source frameworks and an elastic infrastructure can be a superpower. And, you know, WhatsApp had 32 engineers at the time that they got acquired. And with 32 engineers, they were supporting 450 million users. We're not quite at that scale, but we're serving billions of flags a month on our SaaS platform now. And we have three engineers. So we realised that, you know, this constraint can actually, in a way, it can work to your advantage. And I spoke with Jason, he's the co-founder and CEO of TypeSense. They've got an interesting product. They're a search product, like an in-memory search database. And, yeah, they're a very, very small bootstrap team as well. And he had similar opinions. I think it really helps with your product direction, is what I'm saying. Is that scarcity of resource is really powerful? Yeah, and I think that's a very good point in that right now, I would say us being a two-person team is actually a big competitive advantage that we have in that if we need to build a feature, we, as the folks that are also implementing it, can directly talk to the user that's going to be using it, get feedback in real time. And implement it and, you know, be done with it. There are no other dependencies between us and shipping a feature into the product. And that is super, like that's like a superpower, I would say. You know, we don't do elaborate roadmap planning and we don't do, like we intuitively know, just based on users asking us, we kind of know that, okay, in the next three months, here's what we're going to be working on. So we have that in our mind and that, you know, there's no elaborate meetings for roadmap alignment and, you know, all of the things that, again, not bad things, but things you have to do once you have a large team that need to get everyone aligned on working on similar goals. I think being small right now is, helps us focus on one thing at a time because we literally have no choice. I mean, sometimes let's say we get something that is taking too long, we do switch to something else and quickly see if we can fix that and then come back to something. But being able to also do something like that where, you know, like, for example, we had a feature planned in a plan for actually February geosurge. That's something that people have been asking for. We had planned for it in geosurge, but then after working on it realize there's this performance implication to adding this feature. So it's going to take a while for us to figure out what the issue is. And so we paused that and we said, okay, let's punt on that. There are other these other pressing things that have come through in the meantime. So we started working on it. So I think having that flexibility to move things around and not being committed to things one way or the other and being able to respond to user feedback in real time. I think is and also, like you said, reducing the communication overhead that typically larger teams start inheriting. I think that all of that does not exist in a small team. And that's something that's been a, you know, such a nice time saver at this point in time. Of course, you can't. I don't think you can ever be. Well, let's see, you can never be a two person team forever. But at this time, at this stage, I'm definitely enjoying all of the benefits that come with the small team. Yeah, so they're just, they're two guys working together. And again, yeah, they're building a product that's going up against a really, really heavily funded commercial competitor. Okay, yeah, so this was another thing. This is lesson five. So getting to the commercial in commercial open source can take a long time. So this was one of the things that was consistent across pretty much every single person that I spoke to. There was years that went by from the inception of the product project to really it becoming a business entity that could stand on its own two feet. When we started Flagsmith, we didn't do it because we wanted to build a huge business that could buy us all on Ireland. We just wanted it to exist, and it didn't exist, so we started to build it. But that was five years ago, and after about a year and a half or so, we realised that people wanted to pay us. So we had this really sort of crickily designed website, sorry Neil, that we'd spent a few hours on. I was in the pub after work having a drink one day with the team and started to get a message from the website chat from this huge American healthcare company wanting us to give them a quote for an enterprise licence. I didn't really know what to do at that point, and it took us a while to figure out who the people were that were contacting us and trying to give us money. How we charged them, what we charged them for, what the business model was, and why they wanted to pay us was the big thing that it took us time to figure out. But we were happy with that. We weren't in a rush. We didn't have investors who were breathing down our necks. We were just building it at our own pace. I spoke with Gabriel who co-founded Rocket Chat, which is an open source competitor to Slack and Discord. It was a hyper-hot market. Slack created this market and it very rapidly became a very valuable company. I was kind of surprised because I would have thought, well, if there's going to be any sort of project that can grow quickly, it would be something like Rocket Chat. No, it took us a while to figure it out. We didn't monetize almost anything for the first year and a half, almost two years. We tried to create the obvious routes like, okay, should we sell support? Yeah, we can sell support, like have a support contract for a few companies, but that doesn't necessarily scale. Then we started playing out with, should we sell a SaaS version of our product, which also started to get subtraction. But immediately understood that we are competing then too much directly with Slack or others that offer like this free version and so on. So it wasn't really a game changer. It was only when we created the license for the enterprise and it started to remember what the guys among the viewers were talking about. Well, I'm telling like auditing tools, reporting tools, scalability package. So we started to create our microservice APIs and put those things on the enterprise and offer those on the enterprise package is when we started to see the traction. But that was already 2019 by that point. Oh wow, okay. Because we only got the funding on 2017. From 2015 when it had the first comment until it started to get traction, I was bootstrapping and trying to fund everything out of my pockets and my friends and family pockets. And by the end of 2016 is when I talked to the guys in the A, they made an investment in training like the third of the year of 2017. And then I started building a company. He passed away. So I think I missed a lot of his. I don't think I know that I didn't get his influence and his knowledge about how to move things faster and playing faster with finding a business model that work and playing with the monetization correctly. So by the time we figure out monetization was already like 2019. And then when we have selling on-prem license for people who are looking for high degrees of customization, but also like we've been talking to the Irish for security. And then start having customers like the Navy, the Air Force, like Credit Suisse, Deutsche Bank. Start to have a lot of different large corporations which are willing to spend six figures, seven figures on securing and privacy and customization. So yeah, so that was like four years between the inception of the project and then starting to get traction commercially. OK, so it's an off by one error here. I said five lessons, but you know, off by one error has happened. So there's my final lesson, which is, you know, in my opinion, and a lot of the people that I spoke to, I reiterated this sort of open source software and the cloud in particular combination of those two things are eating the world. So I've been working in software engineering for 27 years. And over that time, more and more software and tooling and frameworks and infrastructure tooling has become open. So back in the day before I started my agency, I was working for a digital agency in London. We were working on the Woolworth's website. And in production, the Woolworth's website was charged $50,000 per CPU per year for a Java application server called ATG Dynamo. And that was normal. That was what they needed to use at the time to power that website. And funnily enough, I'd forgotten the name of the application server. I remembered it when I was writing this talk, ATG Dynamo, for those of you who are old enough to remember that. It was a bit of a toy end of the original .com boom. And ironically, does anyone know who owns ATG now? It got bought by Oracle, which I thought was quite poetic. But if you tell people now that they need to pay you $50,000 per CPU per year to run an application server, to build an e-commerce portal, they just wouldn't believe you. And this kind of idea was reiterated when I spoke to Mike Driscoll. His spanner and CEO are real data. They work with a lot of big data. And he had this to say. Probably the way I think often about open source is when we think about folks who study industry and the maturation of industries, and folks like Clay Christensen and Jeffrey Moore, business authors have written about this, you have periods of innovation and periods of commoditisation. Traditionally, during periods of innovation, companies with what was proprietary and what was their unique edge was something that no one else could do or very few folks could do, and they would charge a lot of money for that proprietary database or that proprietary web server. I think if we look at my view of the history of open source, it's essentially a commoditisation wave that started at the lowest level operating systems and then slowly makes its way up the stack from operating systems to programming languages to databases. And so I guess I would say in general you're probably correct that as technologies mature, they tend towards becoming more open source. Probably the other axis here is not what the technologies are but how they're delivered. And so the new axis of innovation is the movement from the desktop environment to or the server environment to I would call it cloud services. And so I think that's where there's so much innovation that you can almost feel like databases are so commoditised. You really have the emergence of someone like Snowflake, which is a commercial database provider, and their axis of innovation is on, they've innovated on delivery of the software as a pure cloud service. And so I think those are, if anyone wanted to run a database, fair to say that you don't need to pay anyone to run a database on your own local server, but when you add the layer of running it at scale elastically in the cloud, then that I think is challenging. And so I think those are just kind of orthogonal axes of innovation and one is mature and the other is not. Right, yeah, so that's it. The six lessons that I've learned. And yeah, if anyone has any questions, I'll be happy to answer them. Thank you. Yeah, it's funny actually. So I was talking to my friend Chris here about that last night. This is the first open source conference I've been to, right? I've been to South by South West from places like that. And one of the things, one of the, I think one of the reasons that I wanted to speak to people about the podcast and one of the big things that I kind of wasn't sure about. And at the start of the talk I said about, you know, I wanted to know what is okay and what isn't okay. And I kind of wasn't sure if it was okay. And one of the things I've noticed coming to this conference this week is that I still think there's a lot of differences of opinion. And I don't think any of these positions is right or wrong in any way. You know, what does it mean to be open source anymore? I mean, you can run our platform, you can download it from GitHub, you can have it running in Docker in a couple of minutes on your laptop. And you can use it in your applications. And that's all free and it's, you know, it's BSD3 licensed. And we have this really hard time trying to figure out what features should be closed, right? And it's like, should any of them be closed? Would we be able to sustain the project and the business and the employees by opening them all? And I guess we're afraid of doing that, right? Because we want to carry on as a team and as a project. And to do that, we need a commercial element. So, yeah, I mean, I think it depends on what you're building, right? Like we're building a full application and SDKs in 14 different languages. And it's like quite a lot of moving parts and things going on. But yeah, we're built on Django and we don't pay Django anything. And I still don't know if that's quite right, you know? One of the things that I didn't learn from the podcast was whether it was or not, right? Like, and everyone has different opinions, different opinions on that. Like Rails, I mean, you know, they... 37 signals, Basecamp, David Hine and my Hansen. You know, he hasn't made any money directly out of Rails, right? But he's made a very successful business on building applications on top of it. I think that, you know, the idea of like it being a bit imposter syndrome-y, you know, is still there, yeah. I still don't feel comfortable entirely. I don't think I ever will really. It's a great talk. Thank you. I'm curious how important is it for you to have a community and in particular a contributory community around the open source project given your other aims that you have? And is it a, if you do, sorry Tupada, is it a blessing or a curse? So, one of the lessons that didn't make it was, and again, this was pretty much everyone I spoke to, if you've got a commercial business like Century or Terraform, almost all of the core code is written by people that are paid to write it, right? There is a community that exists and they make contributions, but almost throughout everyone that I spoke to, people generally aren't contributing to, I don't know, the core of Influx DB's database engine, right? They might contribute on, and not that this isn't any less valuable documentation or support or triaging issues or things like that. We have contributors, but it's mainly small things around the edges, right? We have a Discord server that people ask us questions in and people we have a discussion board on GitHub and things like that. But I don't think we've really reached the, for us anyway, we haven't really reached that size where we're like, you know, it doesn't really feel like a community yet, right? Like it's not, you know, people getting together and sharing ideas about what it could be. Sorry, what was the second question? If you have contributions, is that helpful or not? Yeah, I mean, you know, like we love people contributing. The other thing I didn't mention was there was a project that I interviewed and they had a 10,000 line PR out of nowhere, which was the entire platform translated into Spanish. But it had taken them like two months and then they had this big problem of merging that back in. So, I mean, that I think that does happen from time to time. But yeah, I mean, we as their contributors are slowly increasing, but it's generally around the periphery around raising bugs and things of that nature. Thank you. Thanks very much. Thanks for coming and listening. Thank you.