Evolving from Side Project to Successful Business with Egil Østhus, CEO and Co-founder of Unleash

(Intro Narrator at 00:00:00) Today, we're talking to Egil, CEO and co-founder of Unleash, about how he turned his open source side project into a successful business. You're listening to Joel Beasley, Modern CTO.

(Joel Beasley at 00:00:17) I was curious, though, because one thing caught my attention. So feature management connected to PII, personal identifiable information. How are they connected? Because I don't see it.

(Egil (Aigle) at 00:00:30) That's a perfect question. You know, maybe we can start by defining feature management and what is this problem really, because feature management is tooling for software developers. So basically, what it means is, you know, software developers, they want to push code to production, right? And that's important for so many reasons. And when you want to do that, you probably want to do that for one of multiple use cases. So a very typical use case, I'm a developer, I'm working on my new feature, right? And I just want to see if it works, right? But I don't want to make it available for everybody else, right? So the best way to really see that it works is to kind of get it out there in production. And why is that important? Because that's the only real thing, right? If I'm testing it on my machine, it's always going to be kind of a very simple setup compared to the advanced setup you have in production. If I'm doing that in a test environment, it's still not the same as the real thing. So if I can get it in production, that's the perfect thing. But how can I put it in production if it's not ready, if it's not tested, right? That's not something you want to do. And that's basically what feature management is doing. So using a tool such as Unleash, you would, as a developer, release that new part of the feature into production, but it wouldn't release it to all of your users. And what it means is I can then start to do very fantastic and quite amazing things. So I can start saying, this new feature, just make it available for me, right? And if it works, I can even say, okay, let's make it available for myself and Joel. That's even better because then the two of us could test it, but nobody else. So if there is a mistake there, if there is anything going wrong, nobody else will notice because it's not there, but we can see it then. And then we start touching on this PII or the personal identifiable information there. Because if I'm going to target that towards the two of us, I need to know who we are, right? So it means that that piece of information is, it needs to be part of the equation, right? It needs to be part of that problem solving. So what happens is that some vendors in the space, they start sending that information back. And why do you want to do that? This, of course, is for ease of use, because if I'm starting to use this in large scale, I can, you know, use that set of data to kind of configure this rollout. And what does that mean? It basically means that this information is sent back to a server, and then you have the entire PII conversation going.

(Joel Beasley at 00:03:09) There's the connection, right?

(Egil (Aigle) at 00:03:11) Yeah.

(Joel Beasley at 00:03:11) Thank you for helping me with that. I told Josh when he was doing the notes, I said, are you sure this is correct? But it makes complete sense because as you roll these features out, depending on the type of feature, depends on the type of information you might want to segment users across your systems to roll them out to first.

(Egil (Aigle) at 00:03:28) Yeah, exactly.

(Joel Beasley at 00:03:29) Yeah. Yeah. That's super interesting. So when you are, you know, building this feature management software, because that's what you do, correct? That's your main product?

(Egil (Aigle) at 00:03:38) Yep. Yeah, that's our product. Correct.

(Joel Beasley at 00:03:40) And that's an open source product?

(Egil (Aigle) at 00:03:43) It is.

(Joel Beasley at 00:03:44) So I'm curious to know about one last thing about the PII. Where does it start and stop? So when I think about PII, obviously date of birth, Social Security numbers, you know, that information comes up first to your mind, right? But let's say my Google search history or my Netflix watch history, where is the line drawn?

(Egil (Aigle) at 00:04:10) It's a fantastic question, and I will not try to come across as an expert on all the details of PII. But basically, you know, what happens there is as soon as you start having more and more information available about individuals, as you say, based on your Netflix, based on your Google, based on whatever, you can start cross-correlating all of those pieces of information to really start identifying individual users or a very detailed set of users. So I think it's a very interesting topic that is going around in the world at the moment. With all the GDPR, it started a couple of years back, and it's, you know, also looking at with all of that tension in the world, having access to detailed information about behaviors, about users, about individuals is really, really valuable, but also something that we need to be very careful about and mindful on how we deal with that. For us in Unleash, being born out of Europe within GDPR and everything, of course, that was already a sign for taking care of that. And now we are in a very good position to really have the product that is designed data privacy first.

(Joel Beasley at 00:05:24) And how did it get started? So it's an open source project. It's top in the world right now for its open source category. How did it get started?

(Egil (Aigle) at 00:05:32) It's a very interesting story. So I founded this company together with my brother. So I always believed I wanted to, and my dream was to be a developer. And I quite soon after majoring in computer science realized that there are so much smarter developers around, and I'm not one of them. But Ivar, my co-founder and brother, he is. And he has always been working in very forward-leaning tech organizations. And he was back in 2014 when this project was started, he was working already in a DevOps culture. So the DevOps handbook was already implemented. Everything was automated. They could push code to production whenever. And he was super frustrated because even though, you know, it was all organized in order to get this piece of code shipped to production, he found himself and the team not doing so. And why was that? Well, there are so many excuses or reasons for not pushing to production. It's not ready. It's not tested enough. It's not complete. It's not feature complete. It's too simple. We need to make it more robust before we put it in front of customers. Again, it's the same use cases we just kind of started to explore there. And another interesting part is the company where he worked was very technology agnostic, meaning they believed that developers wanted to take the best tooling of choice to solve the problems they needed to solve. And it was not like a management decision to do only Java or .NET or whatever. And because of that, you can imagine the tech stack was just all over the place, which is also a challenging thing. So at the time when he was starting to search into what tooling was available, there were a few tooling available, but they were very focused towards either Golang or Ruby or .NET. And, you know, if you really want to deliver a great software experience, you need to have a very good, sane behavior and experience across all of those microservices that are coming into play. So he felt that if you want to have this type of tooling, you need to make sure it behaves exactly the same way across all types of programming languages, and that's not the case if you're using a specific one for Python and a different one for Golang. And, you know, developers, engineers, if they don't find a tool, they just make it, and that's what happened.

(Joel Beasley at 00:08:00) Yeah. I love it. That's my background. I don't know if you read up on my history.

(Egil (Aigle) at 00:08:06) Okay. Yeah.

(Joel Beasley at 00:08:06) So I love talking about programming and open source projects, and I had a number of questions too here about, you know, your experience in open source and what you're seeing. But from a business standpoint about Unleash, right, being a large open source project, there's other competitors out there, right?

(Egil (Aigle) at 00:08:25) Sure.

(Joel Beasley at 00:08:26) LaunchDarkly has a ton of cash, commercialization. I don't think that they're open source, though, right?

(Egil (Aigle) at 00:08:32) No. Yeah.

(Joel Beasley at 00:08:32) So what is the advantage that you have against this 800-pound gorilla that is LaunchDarkly?

(Egil (Aigle) at 00:08:39) Yeah. It's a great question, and it's a great space to be in because there's so much happening. And it's true, we are up against, like, a very big gorilla out there. So why is open source the edge there? I would say open source is the only thing that makes sense for software tooling, like for software developers. And why is that? Well, first and foremost, it's very easy for them to get started, right? You know, software developers, they don't want to go to sales calls. They don't want to kind of go to the salesy meetings. They just want to go and get stuff done, right? So they want to test it. They want to start using it. And open source is available freely, obviously. You can just download it, start to use it, and then really start playing with the tool. And I would also say that what we see is the open source community, it's a very, let's call it a very well-informed product manager, which means when we are looking for the next feature to develop, there is already a conversation going between our team and the community saying, this is what is important to us or this is what is really not so important for us. And, I mean, the best stories we have is developers starting to develop a new feature and starting to get feedback from our users when they start publishing the code to GitHub, right? So already before it's shipped, they're getting feedback from real users. And, you know, feedback is the best way of learning, right? That's how human beings learn. We test, we get feedback, and then we adapt to that. And I would also say, you know, it's about trust. Open source is the ultimate level of trust or transparency. I mean, when we are claiming how we are dealing with PII or how we say we are dealing with security practices, I mean, there is nowhere to hide because I know that you, as a developer, can go and inspect my code. And if you call my bluff, you are going away. And I need to be very true to how we communicate. And it is a competitive edge. And it is also an inspector for it. I mean, if you found a very nice open source project that just gets started, and if it really works, you want to tell your pals, and that's what you do. And then it starts to have this bottom-up growth, and that's what we see happening.

(Joel Beasley at 00:10:56) For you starting this as an open source project, did you ever imagine it would become a commercial endeavor, or was it just a fun project?

(Egil (Aigle) at 00:11:06) Yeah. No, it started as a, let's say, fun project. It was started to kind of solve the problem in the team for making them more kind of easy to go to production, all of those reasons. And, you know, what happened was there was never any commercial ambitions. There was never a business plan behind it. It was this cool thing that we do, and the team showed it off on the sprint demos, and they started to talk about it at meetups and parties. And it started to grow. And, you know, developers move between employers, and they bring the tooling with them, and it starts to spread organically. So it was first in 2019 where there started to be a really strong market pull. It started to be kind of coming from the community. Is there any commercial offering here? Is there any type of support? Because it's really a great product. But is there anything more? Because, you know, we need an SLA or some kind of support agreement or whatever in place in order to really start using it at this big scale.

(Joel Beasley at 00:12:10) Yeah. I do want to jump in here, okay? Because you hit a good part of the story. Tell me a small story about the moment you and your brother realized that this thing's actually something.

(Egil (Aigle) at 00:12:24) Yeah. There are so many moments in that history, but maybe I would say there are two moments. The first moment is when we decided to actually start pursuing this commercially. So this is myself and my brother, you know, hanging out. We were out for a burger and a beer and kind of just, you know, casual, having some relaxed time together. And he started to talk to me about this organic call he started to receive. And he started to talk about this project, and this is before I joined the project. And at the time, I was setting up a 400 or so developer-sized organization, very legacy technology, you know, dealing with large customer requirements, contract requirements, a lot of kind of this business side of software development. And when he told me the capabilities of the tooling, I immediately saw that this is really something that can really help my day. This can save my day. Because I wanted to be like this team, always moving to production, but I had a very legacy technology stack I was working with. So it's good business, but it's been around for ten, fifteen, twenty years. So it hasn't really every of the nicest whistles available there. And also the contracts and the type of customer. This is a payroll and accounting type of software. So a lot of compliance, a lot of, you need to make sure it's really properly done. You do not mess up with payrolls, right? You don't mess up with accounting. So you don't just release software. So for us to do, like, a daily, weekly, monthly release was really unheard of. And we know that that's how we want to build software. And having Ivar tell the story of how can we really get this done and really decoupling these two problems and tackling that, that was kind of an eye-opener for me. This is real. This is really having a lot of value. And I think the second moment, this is about a year after we started to pursue this. We started just talking to a lot of customers and signing customers and doing this as a side gig. So the first year, we just did this weekends and nights. And, you know, when you start looking at the number of customers there, we had Lenovo on board, and we started to have also some well-recognized insurance companies and then huge global brands on the customer list there. It was sort of we just need to really do this, like really, really do it. This is not good enough to just be weekends and nights anymore because this is just getting too serious. And that was also a moment for saying, okay, this is it. This is happening.

(Joel Beasley at 00:15:10) Oh, man. And then it became your full-time job?

(Egil (Aigle) at 00:15:16) It is. Yeah.

(Joel Beasley at 00:15:16) How are you growing currently? Where are you at on your journey?

(Egil (Aigle) at 00:15:18) We are growing quite fast. So we are 27 people at the moment. So still a small team, but, you know, looking to hire more and more talents. And our customers, quite soon into 250 paying customers there. So it's getting from a small project into more of a real business, and the future is just bright for that.

(Joel Beasley at 00:15:41) Did you raise capital or just bootstrap it?

(Egil (Aigle) at 00:15:43) Yeah, we did. Yeah. We had a good seed round back in 2020, and we actually closed the Series A just before everything went dark in February last year.

(Joel Beasley at 00:15:55) Lucky you.

(Egil (Aigle) at 00:15:57) Yeah. Lucky me. Lucky us.

(Joel Beasley at 00:16:00) So when you guys think about the competitors, I'm a business person, but I'm just curious. It's important too. I think there's a lot of the audience, you know?

(Joel Beasley at 00:16:11) I love the David and Goliath story. Right? And so I'm trying to figure out, without putting words in your mouth, how do you see your strategy as far as against your competitors? Or are you just completely Jeff Bezos, Amazon-style focused on the customers, and you just put up blinders to your competitors?

(Egil (Aigle) at 00:16:33) Yeah. I would say we are more towards the Amazon type of side of things. I would say we have deep respect for our competitors. There is a lot of talent there.

(Egil (Aigle) at 00:16:42) They are working hard to deliver a lot of good value to their customers. But also we are seeing some of their decisions, at least to our philosophy, is fundamentally wrong. So I think we are very focused on solving the real problem for the customer and not catching up with our competitors. Right? There are so many—I mean, the easiest thing we can do is to go to the plan list or kind of the feature list and just start copying features. Right?

(Egil (Aigle) at 00:17:10) End up in a feature game. Of course, it's always going to be a feature game in sales, and we want to throw the stick towards us and say, oh, they don't have that feature or this feature. But if you really have an engaging conversation with the customer, really understand the problem you are solving for the customer, really are clear on where you fit in to solve that problem or support the customer with that problem, that goes so much longer. Right?

(Egil (Aigle) at 00:17:37) Because you don't buy a product because of 10 features. You buy a product because you want to get something done or you need to solve a problem, a challenge. Right? That's the key thing here. And also, I think we want to challenge a bit the status quo every here and there.

(Egil (Aigle) at 00:17:54) Because, you know, one of the very interesting marketing campaigns we did when we started was basically saying we ship software on Fridays. I'm not sure how familiar you are with software development. Usually, that is sort of unheard of because, you know, something goes wrong, and then you end up spending all of your weekend fixing those issues. And for us, it sort of is a kind of a truth, and it's sort of established—this is how you do software development. But should it be like that?

(Egil (Aigle) at 00:18:23) Is that really what it should be like? And if you really start thinking about it, you should just put it out there. If it works, it works. If not, just very dynamically turn it off and fix it and nurture it and improve. That's what we should be doing.

(Egil (Aigle) at 00:18:36) So why should we not release on Fridays? You should. You should absolutely release on Fridays. And if you do, you also have the process and tooling in place to really have a good quality product, and that's what you should be aiming for.

(Joel Beasley at 00:18:47) Yeah. And I love it personally because I was writing software before this concept was widely publicized, and it was something developers did and talked about. I'm sure one company somewhere was doing some homemade version of it. Right?

(Joel Beasley at 00:19:01) That's actually exactly what we would do. We would do a homemade version of it. And then when tools came out, the tooling was way better way to handle it. But I love what you said about the ease of use of getting it into production because I'm a very outcome-driven person. I like things now. I'm always working on my patience.

(Joel Beasley at 00:19:24) Right? And when I was writing code and developing, I would think to myself all the time, exactly what you said, where we would sit there and debug and debug and debug in a staging environment. And then once that was good, and staging had some variant of production data in it, and once that was good, we'd go over to production, and then there's inevitably issues there that you debug, debug, debug.

(Joel Beasley at 00:19:47) And so I thought to myself, why not just skip that step? Like, let's—

(Egil (Aigle) at 00:19:51) I know. And that's what you should be doing. Why do you have staging there? I mean, just think about the expenses of keeping that staging environment up and running. I mean, it costs a fortune.

(Egil (Aigle) at 00:20:01) Right? And as you perfectly well pointed out there, you are trying to simulate the data from production. But even—I'm not sure how you do that. Some do. But you shouldn't, at least to be compliant with GDPR, you cannot do a copy of that data. So you either need to mask it or you need to have some test data, and then it starts to grow as a problem, and then you're spending a lot of money.

(Egil (Aigle) at 00:20:22) So why do we really want to have this? You should just skip it and just go directly to production.

(Joel Beasley at 00:20:27) Yeah. You can roll databases back. Like, you can—

(Egil (Aigle) at 00:20:29) I know.

(Joel Beasley at 00:20:29) Put systems and processes into place. And it's one of those fun things where once you see it, you can't unsee it. Once you see how you can have a workflow with feature flagging—is that what you're calling it? Feature management or feature flagging?

(Egil (Aigle) at 00:20:42) Feature flagging and feature toggles. There's so many different names on the same type of tooling.

(Joel Beasley at 00:20:48) It's which author or which conference you're listening to. But once you see that happen in practice, you can't go back. So if people are listening and you are not doing this in your software development production pipeline, this is something you should do. Open a book on it. Take a look at it.

(Joel Beasley at 00:21:05) There's a great open source tool I know about called Unleash. What is your domain? Unleash.io?

(Egil (Aigle) at 00:21:12) getunleash.io.

(Joel Beasley at 00:21:14) getunleash. I like it. I like it. For you, from your perspective of when you started playing around in the open source world to today, what have you noticed?

(Joel Beasley at 00:21:25) What's changed about that?

(Egil (Aigle) at 00:21:28) Oh, good question. What has changed? In the industry?

(Joel Beasley at 00:21:31) Yeah. Like, your experience. You want me to lead with an example?

(Egil (Aigle) at 00:21:36) Please.

(Joel Beasley at 00:21:36) When I started in open source, there were many people who were business people who said open source—they didn't like it. You're giving up your intellectual property. It's not going to last. It's just not going to last. If you go back to the '90s and early 2000s, people beat up on open source quite a bit.

(Joel Beasley at 00:21:56) Well, it's clearly a part of the ecosystem, and it's established. I personally don't know how it could go away. It's just become a thing that we do as people. So that was one of the big changes that I see.

(Egil (Aigle) at 00:22:07) Yeah. Yeah. Yeah. No, definitely. I think there is a few key takeaways in the open source space. So open source, I think, has matured a lot. People, as you say, are starting to get used to it. I think the biggest one of the biggest topics is sort of this notion of open source is just free.

(Egil (Aigle) at 00:22:27) It's free. But also, we need to admit there is a lot of open source contributors that are spending a lot of their spare time. And then it's also something for large corporations to really start thinking about. Because they've been taking benefit from these strong developers spending their nights and weekends and just taking that product without—it's sort of—there are some—and I think also it starts to be more understood that open source is free, but it also comes at a cost. Right? Because it needs to be maintained, and everybody wins from having a strong commercial entity behind the open source. And I think another part of open source—I spend a lot of time also looking outside of the software industry. I mean, you know, it's a quite turbulent world we are living in right now.

(Egil (Aigle) at 00:23:16) Right? The global trade is really going back to more regional trade. It's going back to very individual countries for themselves. And there seems to be more and more lack of trust between nations and people. And open source is all about trust.

(Egil (Aigle) at 00:23:32) Right? It's the fundamental trust and transparency way of delivering software. And if we continue on this path of distrusting each other, I cannot see any other way than software needs to go open source. Because, you know, you don't want to take software from somebody you don't really trust anymore, particularly when you start diving into all of those security and privacy issues we talked about. And I see that open source is very focused in the developer space today. I would be very surprised if it doesn't start taking a bigger chunk also in other kind of verticals of software for sure over the next couple of, I don't know, years or two.

(Joel Beasley at 00:24:13) Do you see any drawbacks to open source? Any cons?

(Egil (Aigle) at 00:24:17) You know, every piece of software is as good as the weakest link, as always. I mean, the biggest drawback with open source is if you build a business and there is a lot of compliance and responsibility and legal parts on top of that software, the problem—the possible problem with open source is that if you're starting to be dependent on open source libraries that go out of being maintained anymore. Right? Because if you don't have any commitment behind it, if it's sort of a project, sort of a hobby something, you are so dependent on that individual or those individual contributors that really want to put in their time and really maintain that product. So the maintainability is a big possible issue or challenge, I would say.

(Joel Beasley at 00:25:05) Gotta get those GitHub bounties. Right?

(Egil (Aigle) at 00:25:08) I know. Or go with an open source product where there's a business behind it.

(Joel Beasley at 00:25:12) Yes. Yeah. Which is what I love. I don't know exactly which episodes I've mentioned it in, but I've mentioned it in several episodes that I love the open source model with professional services behind it. Because every time I've ever used and loved an open source product that was solving a problem in higher-level business context, I want to—I don't want to maintain it.

(Joel Beasley at 00:25:35) I want to use it, but I don't want to maintain it. I don't want to host it. And I just wanted to download it and play with it and see if I could configure it and if it would do a proof of concept. And then once I say it's good to go, I'm like, well, I wish there's a version of this that had professional services because it's so much easier.

(Egil (Aigle) at 00:25:53) I know. I know. And I think that's also a perfect business model, even if it's professional services or pure hosting or an open core business model. There's so many ways of tackling that. And I think you're absolutely right.

(Egil (Aigle) at 00:26:04) Open source is a great way to get to a new tool, and you can play with it. You can start using it. You can really see if it really fits your needs because that's also a big thing, right? You want to make sure it really is doing what you need it to do. Or if it doesn't, why should we spend more time paying or working through procurement and all of that stuff?

(Egil (Aigle) at 00:26:24) So I think that's absolutely a very correct observation.

(Joel Beasley at 00:26:29) Now I'm not writing code on a daily basis anymore. I haven't for the past three years or so because I focus mainly on the podcast. But—

(Egil (Aigle) at 00:26:38) Of course.

(Joel Beasley at 00:26:39) Obviously, everyone's watching ChatGPT and Copilot from GitHub. Have you seen—because you're in open source on a daily basis—have you seen yet a ChatGPT-type bot contributing to any open source projects?

(Egil (Aigle) at 00:26:57) Not that I'm aware of, but I wouldn't be surprised if it's already happened.

(Joel Beasley at 00:27:01) I know. Isn't that—I was thinking we need to create a ChatGPT bot that goes and solves the bounties and just deposits the money into our accounts.

(Egil (Aigle) at 00:27:11) Yeah. Maybe that's the thing. It's a cash machine for you.

(Joel Beasley at 00:27:16) Yeah. Well, I have talked to people that build tools that use these types of technologies to identify—it's very segmented. I'll talk to a security company that's using it to do something very specific with scanning for vulnerabilities, but in a more intelligent way. And then I'll talk to a fraud company that's using it in different ways. And so you see these isolated uses of it.

(Joel Beasley at 00:27:37) But what I think surprised me the most about ChatGPT is the fact that it's got this ability where you can communicate with it in casual language.

(Egil (Aigle) at 00:27:49) Yeah. That's absolutely amazing. I would be surprised if we don't—if we probably will see quite soon, if not available—casual language to interact with source code.

(Joel Beasley at 00:28:02) I love it. It's definitely the direction we're heading. I do have one small little path I want to just run down for a second.

(Egil (Aigle) at 00:28:11) Sure.

(Joel Beasley at 00:28:11) I was thinking the other day about, after watching these ChatGPT videos, you can teach it. You can ask it for an answer to a problem in programming or otherwise. You can have it write stories, and then you can talk back and forth with it and have it make adjustments to the stories, and it understands the context. And then I was thinking about how humans work, and I was listening to Marc Andreessen of Andreessen Horowitz and Elon Musk. They were going back and forth on Twitter talking about how basically—we're Neanderthals thinking that this ChatGPT thing is intelligence right now or something to that effect.

(Joel Beasley at 00:28:51) But that's what I saw from Twitter in my casual evening hours scrolling through. And what I thought to myself is, well, isn't that what a human is? Like, isn't that what intelligence is? If I have this conversation with you and we start solving a problem and we go back and forth and then we come to a conclusion and we would leave and we would both go talk to our spouses and say, yeah, I had a really intelligent conversation today.

(Egil (Aigle) at 00:29:13) I know.

(Joel Beasley at 00:29:14) How is it not? And then humans will say, no, but, you know, our soul that allows us to be different and this living fact. And so I was just curious if you've thought at all about any of this communication-is-consciousness type deal.

(Egil (Aigle) at 00:29:29) Yeah. No. What can I say? It's an interesting question because we start diving into what is really a human being and what is intelligence and where is the start and stop of humankind. I definitely follow you.

(Egil (Aigle) at 00:29:41) It's sort of this conversation and also how we learn, how we interact. It's through this kind of communication there. I think the question for me is more of, what does it take to really get from a casual learning test, fail, improve type of conversation into really thinking like crazy outside of the box type of things? I'm sure we can make algorithms for making that happen as well. I have no clue how to do that, but it's definitely a next step of really inventing something truly amazing that really nobody thought about before.

(Egil (Aigle) at 00:30:18) And you know, what is this soul? The soul—isn't that also just a conversation between yourself and yourself?

(Joel Beasley at 00:30:24) Yeah. That's one way to describe it. Absolutely. Yeah. I like that.

(Joel Beasley at 00:30:28) That was deep, man. Yeah. I'm glad I went down that path. Sometimes those are hard conversations to have because they get very high level and very ambiguous really quickly. But—

(Joel Beasley at 00:30:39) I just felt like it. I was like, maybe this guy's got something. We gotta write that down, Josh. That's a good quote. If you had a magic wand and you could wave it and change anything about open source, what would it be?

(Egil (Aigle) at 00:30:55) Oh, what would that be? I think the one thing that really feels a bit, I would say, unfair is the huge number of open source developers contributing to highly used projects by so many companies without getting anything paid. So I think that business side of things, I'm not sure if that's a magic wand or whatever, but that feels unfair. I think that the open source community is all about sharing and giving and contributing and giving back to society. At the same time, it needs to be kind of equally or balanced.

(Egil (Aigle) at 00:31:26) Right? It's sort of you give and you take, or you give and you receive. So I think if it counts for a magic wand, I would say I can perfectly well imagine so many open source developers sort of having this a bit unfair type of feeling. I'm spending so many hours writing this project. There's so many that use it. There's so many that depend on it, and they're not really getting their fair share back.

(Egil (Aigle) at 00:31:50) There's so many, so that is depend on it, and they're not really getting their fair share back.

(Joel Beasley at 00:31:55) Well, I'll push back. Well, first of all, I'm not gonna disagree with your magic wand. Right? But I'll push back with a couple different perspectives. The first perspective is that they're writing it for their own use too. Right? I don't usually contribute to open source projects that I'm not using. Right? So you are getting some benefit. I get where you're coming from though, because there's not direct compensation. I would argue that there is compensation in the form of experience. Right now, I'm becoming more knowledgeable here that can improve my job prospects or other companies that are dependent upon it. So I do think there's a couple benefits, but I 100% agree that it would be really cool if they could just get direct paychecks. Right? But if you're a developer and you're contributing to open source and you feel that way right now, that should not be a signal that the system's unfair. That should be a signal that there's something that you don't know about how to convert what you're doing into money.

(Egil (Aigle) at 00:32:58) No, I think that's spot on, and I think also that's what you see happening in the open source community. I think there is a tremendous number of companies being built, and there is more and more money being pushed towards open source projects to really make it from, you know, this gig into more kind of a growing up company. And I think that there are going to be a significant increase in monetization around open source as we move forward. I have no doubt about that. So I think you're right. It sort of maybe feels a bit unfair, but it also kind of, they're seeing that there is a great opportunity in this space to really build some fantastic businesses.

(Joel Beasley at 00:33:38) Yeah. Like, I loved bounties coming about selfishly. Right? Because there would be a problem I needed solved in a system, and I would rather have someone who hangs out in that project all day come by and collect a little bit of cash and solve the problem than me try to become an expert in authentication or whatever the system might be that I'm working with. Yep. Yeah. So I like that. I also did a little bit of research last year, and I was incredibly surprised about the largest contributors to open source. It's all the big tech companies. They're the largest contributors to open source. I was talking with somebody on Stack Overflow, which is always a mistake because there's gonna be yelling. And somebody made some comment about how they don't, you know, contribute anything, and they keep all their source code private, and, you know, they were being negative about the bigger companies. And it was actually specifically Microsoft that they were calling out. So me being a nerd, I go over to Google, and I type in, "How much does Microsoft contribute to open source?" They were in the top three. I don't know which one they were. But as far as the report goes, they were in the top three for sure. And when you saw the dollar or the, they did a dollar amount or an hour or lines of code amount, it was huge. It makes complete sense why they bought GitHub.

(Egil (Aigle) at 00:34:57) No. It makes a ton of sense. And also, you know, it's a very fascinating part of the open source business because, coming back a bit, a bit back to some of the benefits of using open source. It's also when you are using an open source project, there is also a lot of benefit for you as a company because you know that if there is a bug, if there's an issue, if there's some improvements you need in a tooling, if it really is super, super important for you, and either a project or the company cannot or will not or are not able to prioritize at this moment, you can actually go in there and patch it yourself. Right? And give it back to the community, and it fixes for you, and it's sort of giving back. And I think also, more and more large organizations, and like you mentioned, there are tech companies, but also company, big corporations outside of the tech companies see this as a big benefit. And as you say, also, there is a huge way to attract talents, of course, to really get strong developers because you have this amazing open source stack.

(Joel Beasley at 00:35:59) And while I have you here, because you're a feature management guru expert, I'll say it. Right? You don't have to agree. But—

(Egil (Aigle) at 00:36:08) Well—

(Joel Beasley at 00:36:08) I'm always curious when I have, you know, you're in it all day, every day. Right? Do you see that people misinterpret or misuse these features in any way?

(Egil (Aigle) at 00:36:19) Absolutely. Absolutely. I think there are certain use cases where you probably don't need to go for full kind of full-fledged feature management. You can be more kind of static configurations. I think it's, as any tooling, you need to understand the purpose and the use case and why you are sort of leaning towards that particular tooling and just not use this tool for everything. Right? It's sort of, coming back to, developers should have access to the best tooling for whatever the purpose of the problem they're solving. And if you're a skilled developer, your toolbox is big. Right?

(Joel Beasley at 00:37:01) How do you do feature management well? What's the most important thing?

(Egil (Aigle) at 00:37:05) That's a good question, actually. It's, as most of these questions, it is, it depends. Right? It depends on the use case. I would say one thing that is really a good takeaway is really understand that feature management as a tooling has much a way of delivering software as it is a tool. And, I mean, if you wanna have the very old-fashioned release meeting type of governance around your software, you might not need a tool such as feature management, like Unleash or anybody else. So, I mean, a tool comes together with a proper process or engineering maturity or culture, whatever you wanna call it. I think that is a good or important part to really understand. It allows you to do amazing things, but also you need to be willing to do amazing things. Right?

(Joel Beasley at 00:38:01) Do you do consulting in the sense that, let's say, I'm a CTO, and I'm hearing about feature flagging. I've heard about it a bunch. Now I'm hearing about it on this podcast, and we don't do it. And my team, I want them to do it. But that's a culture shift, as you just mentioned. They wanna do best practices. They might be using a lot of best practices, but this is something new. It's a new motion. Do you have consulting services that they can bring in and see how to do it correctly?

(Egil (Aigle) at 00:38:27) No. So how we do this, we don't opt into professional services. We have decided to stay out of that space because, I would say, and maybe I can take a bit of a detour before I come back to your question. I would say if you have professional services and you are selling a product software tooling, you're probably not delivering a great software product. Because our focus is we need to make sure that we have a great user experience, very intuitive tooling, very easy to use, very easy to get started, and really, probably, really everything we do is focused around solving the challenges that you are solving, your needs, and not kind of just delivering another feature. And the professional services there is basically that is incentivized by me as a professional services provider selling hours. Right? I wanna sell more hours. And how can I sell more hours? I can sell more hours because it's complicated, because it's difficult, because it's, and so forth. So we are very focused on delivering the product. And if we were to go into more kind of transformational projects or kind of change management, that's a way different, that's a different type of business. Will we eventually grow into that? Maybe, maybe not. I'm not sure. But what I would say though, when we engage with our enterprise customers, we work very close with them from a customer success point of view, more in a sort of a trusted adviser role than professional services. So we would not go in there and do kind of the Capgemini or Accenture or kind of the Deloitte type of change management. We would do supported teams saying, "Okay. These are the best practices. These are sort of the how you should think and how you should work. This is how we can together kind of enable you to take this into the company, identify some quick wins, and really get that sort of bottom-up growth going for you." Because that's what we do. We are not kind of the professional services provider.

(Joel Beasley at 00:40:18) So if the team has the desire and the drive and the discipline, they can become a customer. Your customer success team can point them in the right direction, help them understand how to do this, but you're not gonna go fly out to their location and babysit them and convince them all.

(Egil (Aigle) at 00:40:33) No. We are not flying in the big, yeah, Accenture machine and just kind of rolling in heads and heads and heads to kind of do that. I mean, it's good for its purpose, but it's a different purpose than ours.

(Joel Beasley at 00:40:44) Yeah. I was just thinking to myself, getting to spend so much time and visiting different people I've gotten to meet on the podcast, I found that one of the hardest things across all organizations is a new behavior.

(Egil (Aigle) at 00:40:56) I know. And it's—

(Joel Beasley at 00:40:57) The easiest way to get a new behavior to happen is to have somebody who's influencing that behavior to happen. Yeah. And so I was thinking, I was like, "Well, there's clearly enough appetite in the market for people who just want, they know they want this." They're doing this, and they just wanna do it better, and they're coming to you. That's a great position to be in as far as the market. There's a lot of pressure there, and they're coming, you know, to you, which is amazing.

(Egil (Aigle) at 00:41:22) Yeah. Yeah. Yeah. It is. But I think it's also for us to be very important to stay focused on delivering the best possible products, and that's about focus. Right? We cannot, or if you start having too many focus points, you are losing focus. Right? And that's important for us to stay away from. But, you know, it's also for us to continue to be the aspirational company, and we see that happening. You know, live as you preach and do what you tell, and also to share that, giving that back to community, giving that back to our customers, and personal experiences or the company experience on how we are doing, delivering software efficiently, you know, because software development is about, it's a team effort. It's not about individual developers. It's about how developers work together as a team and contribute and collaborate in order to build that next amazing software.

(Joel Beasley at 00:42:13) We didn't talk about money yet as far as the business impact. So I don't have any studies, and I haven't looked into this. But I would imagine that if you get people into this feature flagging concept, there's a time, well, I just guarantee there's a time savings. Have you quantified this at all? Do you include any information about this in the process on your website?

(Egil (Aigle) at 00:42:35) We are seeing a lot of that, and I think the best study there to lean back to is the DORA report. I'm not sure if you are familiar with the, I guess you were familiar with the State of DevOps report that is published. I think that speaks for the industry. It's very much saying, what are the best behaviors? It does a fantastic job correlating engineering practices into business outcome. And so, of course, we are working with customers to look at what are the possible savings for individual use cases and case studies, and all of that is usually not something we are allowed to disclose, obviously. But it's huge time savers. It's efficiency for the individuals, developers for sure. We talked about the testing system, so as soon as we can start moving away from those, it's usually big dollars saved. So the potential there is just fantastic.

(Joel Beasley at 00:43:37) Do you have any, I'm a, I'm gonna push just a little bit more. Do you have any easy numbers? So if I'm a leader and I've got, you know, a team of X amount of engineers that I can expect if I start to explore feature flagging, that I can get a 10% efficiency, a 5%, a 99%? Like, how much would I be looking to gain?

(Egil (Aigle) at 00:44:00) It's a very complicated question because it's, there's so many variables in play there. I can think of one customer case we had. We had a customer, I'm not allowed to share, of course, the name, unfortunately, but it's a major customer in, based out of US East. One of their feedback was saying that, "Thanks to using Unleash, they were finally releasing in December, first ever in the company history." And that is months of savings of waiting for it, putting that into production. And you can just imagine the number of dollars that is attached to that event.

(Joel Beasley at 00:44:40) And these are results that you guarantee for every customer. I'm kidding. I'm kidding. I want to ask a couple leadership questions, and then we can wrap it up. Is that okay with you?

(Egil (Aigle) at 00:44:53) Absolutely.

(Joel Beasley at 00:44:54) Okay. This is a difficult thing you're doing. You're an entrepreneur. This is hard. Sure. How do you deal with the stress? I think I saw your wife back there earlier, and you see your relationship with family. How do you handle the stress of entrepreneurship?

(Egil (Aigle) at 00:45:11) That is a good question. I would say entrepreneurship is hard, but also coming from a large corporate, it's also easier, easier in a sense that it's more unclear. There is more unknowns in entrepreneurship. But also the size of the team and the problem in many senses is less complex and easier, if that makes sense. So I would say running a team of four or 500 developers, there is much more input from any direction to take care of. We are 27 people, much more manageable. But, of course, there is much more unknowns. So it's a different type of stress. And I think it sort of comes back to, where do you kind of, are getting excited? Where do you get your energy? Is it to kind of get stuff done and learn and grow? And I think that's, coming into this, we, the entire core team, is very much a growth mindset. We are here to learn stuff. We are here to understand and really figure out stuff, and it gives us the energy. So let's say it's actually now a bit less stressful than you would think, I guess.

(Joel Beasley at 00:46:22) And is this your, this is your first company? Because before, you were at this larger agency or—

(Egil (Aigle) at 00:46:26) Yeah.

(Joel Beasley at 00:46:27) Well, man, you're doing it. It's exciting. Last question here. Best piece of leadership advice that you ever received, but then, but then it stuck with you. So not just the coolest one you've ever heard, the one that stuck with you over time.

(Egil (Aigle) at 00:46:43) Yeah. Yeah. I think there is, there's two that comes to mind. The first one is sort of coming back to focus. I had a manager, and he observed me being a middle manager running around and trying to fix everything at the same time. Right? Because I was ambitious. I wanted to be ambitious on behalf of the team, and I wanted the team to really be in, like, great in all kind of areas. And he said to me, "Remember that you don't need to fix everything today." Right?

(Egil (Aigle) at 00:47:10) Focus on a few things, get it done, and move on. And that really stuck with me because it's so easy when you start having a lot of challenges, issues, whatever. As a typical leadership or manager situation, there is so much that comes on your plate, and most of them are issues, problems that you need to kind of solve or resolve and handle. And keep calm and remember what is the most important stuff and don't try to solve everything at the same time and kind of be a bit calm in that situation is super important. Then I would say the second one is basically remember that we are human beings.

(Egil (Aigle) at 00:47:47) Right? Listen. Listen to people. The more responsibility, the higher seniority you get, probably the less you should talk and more you should listen. Right?

(Egil (Aigle) at 00:47:59) Because if you can excel all of your peers, all of your team members, all of your direct reports to the next level by them trying, failing, supporting, coaching them, you're probably doing some amazing stuff. Right? And you don't need to talk too much about that. You can ask some very good questions and listen to what they're saying.

(Joel Beasley at 00:48:19) 100%. Yes. This is great. I'm so glad I got to meet you, man.

(Egil (Aigle) at 00:48:23) Yeah. Likewise. Yeah.

(Joel Beasley at 00:48:24) We made a podcast. How do you feel?

(Egil (Aigle) at 00:48:25) We do. Yay.

(Joel Beasley at 00:48:28) Woo. We did it. Thank you so much for listening. And if you found this episode useful, please share it with a friend or colleague who you think would get value from it. And if you have topics that you'd like to hear discussed on the podcast, either add me on LinkedIn or send me an email [email protected]. Every time I get an email or LinkedIn message, it absolutely makes my day and inspires me to keep going.