 They asked me to do this session. I was thinking 30 people in a real intimate setting. There is no laptop. There's no slides. The point of this particular session is to actually share stories. So I'm hoping that people leverage the mics and ask real questions. And I promise to give you very intimate answers. There's a lot of people here, but I'm going to talk to you as if there's only 10 or 20 people here. The goal of this session is that throughout my career, I've had the fortunate situation to work in enterprise IT, pretty much every vertical you can imagine. But I also had the privilege of working at companies building the tools for those companies. And that bit of empathy, that bit of experience, has allowed me to join these open source companies like Puppet Labs, CoreOS, and I'm an advisor to many, such as Vercel, Docker, Upbound, and many of the boost that you'll see out there. And there's been a very common theme when I work with a lot of the founders. A lot of times, they have the inability to tell the story about their product. When we're building businesses around this stuff, I think people get confused between technology and product. A lot of open source companies are born from GitHub stars. You ever seen that? A team open sources a project, you wake up one morning and you have like eight GitHub stars. Two of them from your parents. And six of them are for people you don't know. And those six people are really important because they're like the first signal you get that you might have product market fit. And during the zero-inches rate phenomenon, you can raise money once you've got the 10 GitHub stars. And then you would actually do so much commitment to that open source project, the best technology in the world for that particular thing. And you're surprised that you can't actually build a business around it. No one's willing to pay for something that is actually free. And so when you show people the cool technology, it's like, yeah, we use it every day. And they pay you zero dollars. And then you introduce that pricing model and you find out just how valuable GitHub stars are. And so the difficult transition is going from hello world to hello revenue. And it's really hard because most executives at these companies have no executive experience. Being a GitHub maintainer doesn't qualify. You're literally sitting in a room full of people who can care less about the version of Kubernetes your controller works with. They can care less that you have revolutionized logging and you support more log ingest than the top competitor in the field. Literally doesn't matter. Most people are looking for an actual story that either saves them actual time or helps them finally do the thing that's been on the backlog forever. And you only get two minutes to tell that story for the most part. And so if you're in this room today and you're trying to figure out how to go from community to customers, you have to understand these differences. Your pitch deck doesn't matter in the real world when people have a choice. And so today I'm hoping people have the courage to use those microphones and share some of their stories and ask a question. And I promise to give you deep meaning. The first open source company that I joined, and I understood this, and remember, there's a distinction. Most people believe taking money from a VC is winning. It's worth it funny raising around. You feel super important like you've done something. But in the real world, we call that taking a loan. And you not only pay it back with interest, you pay it back with equity of your entire company forever. I do believe there's going to come a time where we stop celebrating people going to the bank and taking out loans. Your job is to build a real business. When I joined my first open source company, Puppet Labs, I was one of those customers not paying anything at all. I was working in a financial institution, and it was free. Now there's an important component about a free offering is that I don't need any approval to do that dry run. I can bring it in, I can do that POC, and I might go to your Slack channel back in the day with IRC and ask for help. And that's the test of your customer service, and it allows me to try out the product. And then something phenomenal happens, it goes to production. Now the next question is how hard is it to convert from that situation to someone that wants to pay? Step one, what the hell am I paying for? You've already given me everything for free. There's no roadmap that's published. And so I'm assuming that what everyone gets for free is the best that your team will ever offer. There is no roadmap, there is no vision setting, everything is in GitHub, so I believe there will be nothing to pay for. And then I actually joined Puppet Labs two and a half years later. I noticed our biggest competition was the open source community. We come out with Puppet Enterprise. Pretty cool offering, at least we thought. And what does most open source projects do as their first product? They build a GUI that does absolutely nothing, but allows you to log in with active directory. It's the same pattern every time. And then you go to their website, what does it say? Single pane of glass. Faster, cheaper, better, something, something DevOps. Now you're probably looking at your marketing person, and I was like, I thought we were the only ones. Everyone literally does the same thing. And then your customer is like, you're literally saying nothing to me. I'm already convinced that your product is helpful. You've already found market fit, it's in production. All I'm trying to figure out is what am I paying for? And so the delicate thing started to happen. The engineering team had to start building new products and services, and we had to have a decision. I don't know how far some of you are in your particular companies, but there's this thing that happens. You got this awesome new feature. The request may have come from the ticket tracker. You gotta make a decision, do we give it away for free? Or do we put it in the enterprise edition? Now there's a lot of engineers and I was super naive myself when I first started. I'm thinking everything should be free. How dare we charge anything for anything? And someone sat me down and was like, do you know how much money you make? I was like, yeah, I make a pretty good amount of money. Do you know where that money comes from? And I was like, VCs. But the truth is that's not sustainable. Eventually you need to build something that people are willing to pay for. So you have to actually put some of that to the side. You're building a business. And how do you convince the community to support you in a way that is sustainable? And I used to have to have those conversations all the time. We would have puppet confs and we would go there and people would complain, why is this valuable thing that saves us a lot of time cost money? I was like, because that's the only way they're gonna let me work on it. If you're willing to pay for it. And we did another mistake when we were at Puppet Labs. People used to install puppet, bar, lib, puppet. That's where everything went. Yum, install, puppet. And it was working. And then the enterprise edition came out and we chose to rename the command to PE-Puppet. So everything you did broke. So when you came to the website and you went to the documentation, how to give us money? First, uninstall everything that provided you value. And install the enterprise edition. And if you're like me, what'd you say? Nope, I got that particular path approved by Infosec. It was gonna take four months to get them to approve another executable on all the servers. It is like that. And so most open source projects introduced unnecessary friction when they're trying to convert customer or community into customers. These are very simple things. And the first thing that I learned at Puppet, when we started hiring people who didn't come from the community to be engineers, they had one fatal flaw. They'd never used the product before. Ever. And we started making decisions like a business with no context. And the bad thing about that, it got so bad we had to have what I now call empathy sessions. I had this idea that I started at Google called empathetic engineering, but it stems from those puppet days. We got the new engineers who didn't come from the community. This will eventually happen to your small startup. Currently you get to hire from a pool of people you know. You get to hire from those contributors that do awesome things and you invite them to join the company. But eventually you will run out of that. You're gonna hire developers you don't know. And they may not even understand your product. And we have to have them use the product before making decisions. Our customers are actually practitioners. Usually the people in this room are building infrastructure tools or products that would be used by practitioners. We're not selling to their manager. That would be the equivalent of having people have their parents go buy their school clothes without them being there. Mom I don't wear a goth. This isn't my style. And so you need people that have empathy. Now I'll share some more stories throughout the day but I'm gonna open up the mics. I'm hoping that we can get that same vibe when there's only 30 people in the room and you're here because you're actually trying to figure out how to have a successful business. Turn those community members into customers. And there's a way to do it authentically where they won't hate you. They'll appreciate it. If you're like me I don't mind paying for software that's helpful. But I need to understand what I'm paying for. So there are mics in these two aisles. Who's going to be the first to step up and ask a question. This tells me a lot. I'm gonna sit here for 50 minutes. I promise you I will. Oh. Here we go. So you were talking a bit about how a UI is often the first enterprise feature. Do you wanna talk a little bit about where you see that value being added specifically in ways that don't conflict with the community? I know that when we were starting Knative we sat down and had a discussion about what would happen if someone in the community came in and wanted to add some functionality that was going to compete with what we were planning to sell commercially and what was our philosophy gonna be ahead of time? Could you introduce yourself? I used to work with him at Google on the engineering side. So please introduce yourself. So I'm Evan Anderson. I, as Kelsey said, used to work at Google and was one of the people who started the Knative project. Big companies doing open source is a very interesting situation because typically they already have the ability to monetize day one and they're dealing with a different situation. When you open source something at a huge company like Google there's gonna often be a question. How do we make money on this? Another question that happens is what if our competitor takes this thing and monetizes it before we do? That is probably the most fearful thing that most companies have, especially in open source. Like first you're like open source all the things and someone says thanks for the software and they build the things that people wanna pay for while you do all the things that no one wants to pay for. Doesn't sound like a fair deal, does it? And typically this can go bad if you have no roadmap or no connection to what customers want. And so in particular in Knative when you think about a raw open source project and you get in a room without talking to anyone you say hey we're gonna build a web UI that does some weird obvious things that single pane of glass, metrics, dashboards all the common things you would expect from a product. The truth is nobody wanna use another dashboard. If I have Grafana set up over here I do not wanna log into your half-baked web UI and react with some temporary contractors that don't have any UX skills. To see what their metrics are. I just want to push them to the existing Grafana dashboard. There is no value in spending a year doing that. And so in that case what do you do? You just listen to them or you can just subscribe to those developers on Twitter. All this product is great except for, sometimes they even leave you issues on GitHub. I'm using HashiCorp Vault but man we got this enterprise HSN that costs seven million dollars. You know no one in the open source community got seven million dollar HSN at their house. That can be an enterprise feature. So when you think about your roadmap you're literally trying to say what can problems people solve on their own? And what problems can we uniquely solve given our expertise and people are willing to pay for? I think the willing to pay for part of the equation is super important. In the case of Knative it wasn't the software. Knative became Cloud Run. People willing to pay for an actual serverless platform that was fully managed end to end and if you didn't want to pay you can download Knative and install it yourself in your own Kubernetes cluster. The value was the thing you didn't have to do. You don't need to install it, you don't need to manage it yourself. And so it became super clear what the value was in that particular case. So I think the thing that I've tried to do my best is actually visit customers in their domain. I love conferences, but that isn't the place. I need to talk to the person that doesn't want to go to the conference. There's a person who actually keeps the lights on and they're not interested in any of the fashionable stuff. And so when you visit that customer and there's 80 people in the room, there's that legit person sitting in the corner is like, until it supports cobalt. You have no chance. That's the person that I need to hear from. And then you have this enterprise release notes. Now with cobalt support. And people are like, why the hell would you do that? Because they have money and you don't. We'll take this question and then we'll come here. Barton George from Dell. So sort of two questions or two areas that I'd love to get your thoughts or anybody else's on. You start about the money goes in, the money goes out, or I guess it comes in. But anyways, we talk about funding, we talk about monetization. And I'd be curious in hearing all the different ways of funding. So you've got your angels, you've got bootstrapping, you've got VCs. I know we used to talk about you over the VC, you also, they take a pound of flesh, but you get contacts, you get people who hopefully understand the industry. If you go with doctors and dentists, you're gonna get your money, but you're not gonna get, they're gonna take less of the business, but they're not gonna have the ability to help guide you and introduce you to people. So that's one part I'd be interested in hearing on the funding side. Let's start with that part. And I'll let you get the second piece. Six years ago, before I started advising startups and being on the cap table and enjoying and the payoff that comes from putting in the work, there was a VC firm, a pretty big one. They called me and said, hey, we would like you to become a VC. I'm like, for a why? I actually don't really think what you do is ethical. And they talked about the process and I thought about them very differently. I said, why would you want me to be a venture capitalist? Like because you have credibility. These days, everybody has money. Zero interest rates, SoftBank was making it rain like a startup strip club. And so people had no problem getting money, no idea, no product, no team, no incorporation paper. Just the hope that they would build something. And what the startups realized is that most founders that got wise and actually had momentum, some founders started asking the question, what can you actually do for me? I already have a popular open source project. We have part of Market Fit. I already have the VPs from some of the best companies asking how we can do business. I was just in their office the other day. What guidance do you have? And a lot of the VCs, at least the ones that I met, a lot of them made their success in the Netscape days. They don't know what to do in terms of all of this cloud native stuff. They've never used it before. They have no idea what the challenges of that particular target market is. And I don't know about you, but most developers I interact with, they're like, oh, look at this ad. I'm going to redo production because this ad is really great. It's not how it works. The heart now is most developers need to respect the messenger. If I respect the messenger, I'm willing to listen. And these days, a lot of times, those practitioners have a lot of decision-making power at these companies, right? The CIO approach by SAP and Oracle is not scaling anymore. Eventually you need people within your organization with the actual skill to do the work. So you hire that person and that person comes in and they have opinions and they want to make decisions and the good ones can back them up. How do they make decisions? So if you sell to the CIO, good luck, because I know how this works. The CIO, when you go to the exec briefing, guess who's on the right-hand side of that CIO now? It's the person who's going to actually do the work that's going to have to back up this decision, okay? So that is the new mode. And now if you're a VC, how do you do that authentically? I gave you money just putting that logo. We are back by. You ever go to a webpage and they have all of these logos like Product Hunt? You're like, that literally means nothing. Their product needs to work or doesn't work. Call for pricing, that's over. I would imagine most people in this room, if you find a solution, I need to download it right now. And you better have a getting started guide that works right now. And once I'm done with that getting started guide, there better be a video with someone I trust that knows what they're talking about. If you don't have those things, it doesn't matter who gave you funding at this point, you will lose. And we've seen this time and time that you're just losing. And so you can see from the last four or five years, look at the consolidation that's happened. All the incumbents who have all this money, all this pool, the best answer they've had in the past is just to acquire all of these startups and we hope that they don't kill them. So I think the game is very different now because there's a lot more competition in the software space. You ever go to that CNCF landscape page recently? My browser runs out of memory every time. There used to be like one logging solution, one thing here, one thing there. Now there's like 16,000 logging solutions because it doesn't take very long for people to compete in those spaces. So I really do think the game is very different. I do think BCs are still important in this equation, but I think founders now carry a lot more weight to be marketers as well. And if they can't tell the story, I'm off to a more authentic source because typically, if we're dealing with things that work, I gotta go with the people I trust, okay? So what was your second question? I'm just curious, now I've got a followup because that's a provocative statement. So can't the VC space be disrupted? Can't there be not your father's VC that comes in and says, we're doing it a bit of a different way, we're not from the Netscape days? And have you seen any of those? I mean, I think we have. I mean, if you look at a lot of the advisors now, a lot of them are more active, a lot of them have done recent things and they do lend some credibility. And I think some VC firms do a good job of saying, we have more services than just giving you money. Some of them are therapy for the founders, it turns out founders have a lot of struggles that they can't talk to other people about. And so you start to see some VCs. A lot of anger sometimes. What's that? A lot of anger with some of them too. Yeah, like I can't get money for this product, we spent three years building. That can drive a person crazy. And so I think startups are understanding also, I've seen VCs offering dev rail services, not just marketing, but someone who can come in and literally do all the things we talked about in terms of building those particular arm wraps to make a company successful. So I think the VC firms are understanding that they have to bring more to the table than just money. And I think founders that understand this are actually leaning towards those VCs who can compliment them in ways after the check gets cashed. Okay, so there is a future for the VCs. I mean, there's always a future in having more money than the next guy. Yeah. So speaking of money and getting money, I'd be curious in hearing all the different ways of monetization. So ways that I'm familiar with are, if you go with open core, and I think you were saying before you do, it comes with services. So at least, and some of my info might be dated, but with Red Hat, the software is free, but you can't buy it separate from the service. You've got ones where, so we've got modules that go on top of storage, five or free, one we charge for. And then you've got things like advertising models, like Google does. You've got subscription services. What other? I think there's one real model. Does it work? And if it works, your customer base will help you find the right price. Trust me, when we were at CoreOS, we were trying to figure out the price. You just make up stuff. I was the PM before I left CoreOS. You literally just make it up. We're gonna charge per core because that's what VMware does. And if the price is low enough, no one cares how you price it. But when you start getting over like $50,000, when you get above what one person who needs to use the software can improve on their own, then you get into a whole different discussion about what people are willing to pay. So pricing to me is just an exercise in what the market will actually tolerate. You see this, our product is $10,000 per person and you call and they give you a 99.99% discount and you're getting it for $1 per person. You understand? So I think the pricing model is subjective to what your group is willing to pay. Now the biggest problem I've seen in the startup world, number one, a lot of founders these days, especially the serial founders, they actually already have money. We've seen a lot of recent success stories like MailChimp, for example. They didn't raise pretty much any money, but just as a cushion towards the end. And it turned out they actually owned most of the equity as well. That's a whole different discussion. But not everyone needs money at this point to get started. That's why we see a lot of these smaller companies getting pretty far. A lot of these people used to work at large companies and they're leaving with millions of dollars in the bank. I think a lot of times they're just taking money for the perceived partnership, not because they literally need $100,000 to pay a few people for the next six months. It's a very different game because of how long people have been making money before they jump out to do these particular businesses. In particular, we're talking about open source projects. I'll give you a good example. I'm an advisor for the Acuity team. That's the team behind Argo CD. These folks worked that into it. I'm pretty sure they were paid pretty decently. That product had years to bake. They had an incredible feedback loop for a very long time. Product is pretty mature. It's used in lots of places. Think about when they exit into it. What do they need startup money for? They need a partnership at best. But they don't need to figure out how to bootstrap the initial product. They don't need to figure out how to find product market fit. They have those things. For them, they're just trying to figure out how to bet on the thing going forward and now they gotta start building the things that people are willing to pay for. So they're focused on the Delta. That's how calculated these moves are. People aren't starting from scratch in this open source thing that we're kind of focused on today. So that would be my answer there is that there's so many ways to do this. There's so many ways to monetize. And I wanna get into the open core versus various licensing things because those are reactions to the environment around them. If you're an executive at this company and you're watching a cloud provider sell more of your product than you can, you're gonna react in weird ways too in order to keep that business to survive. That's literally what you're trying to do. So whether it's the licensing thing, then you may have to try that and see if it works for you. All right, thanks for the question. I'm gonna swing over here now. Thanks. Hi, my name is Scott Crooks. I'm a senior SRA at Miro. The question relates around small to medium businesses contributing to open source and making a business case for it. So I'll give you a little bit of context around this. My team has a Slack channel for KubeCon so we can ping back and forth to each other. Vani, if you're in the room, by the way, just raise your hand. She actually asked it, guys, why don't we contribute more to open source? I'm having so much FOMO right now. And in my head, when I've heard of open source success stories that have come out of companies, usually it's because the company had a dire need for a given product and it didn't exist on the market. So what comes to mind, like LinkedIn, Kafka, for example, or with Google, Google Borg, which eventually became Kubernetes. So the question is, if you ask a given developer in an SRE, anybody in the technical rules, and you say, do you want to contribute to open source and make it part of your job? Of course they would say yes. But the question is, how can engineers go to the business and what kind of things can they talk about to say? You know, we want to contribute to the Kubernetes Gateway API and this is how it'll help us. Like what advice do you have for the engineering layer and how can they turn that into something that business can get behind and make it a part of their jobs? Thank you. That's a really great question. I'm gonna add a little bit more to it. So there's that one part around, we want to open source this. And the liability that comes with the brand putting their name on a project that they don't understand that is not core to their business, they can take a massive reputation hit if someone stops working on that project, right? If someone just says, hey, Netflix is a great example. Remember they used to drop open source projects every day, Ribbon, Spinnaker, remember that? And then what happens without a doubt is that those companies grow and they move on. And what happens to those repositories is no one at the core company is working on them anymore. And if you've been a maintainer of some of these complex projects, you know there's only a handful of people in the world that can work in the deep depths of those projects. And so while another organization will say, we want to just contribute the long-term requirements and responsibilities of those maintainers that I have to now review for the rest of my life, these patches coming from around the world and we don't even use the product. And the worst thing that happens in that scenario, I don't use it anymore. You can submit 100,000 line change. You're gonna get a very small response from me. Looks good to me. Merch. And this is how these open source projects get into very dangerous situations. No one's reviewing nothing. Usually there is no more vision. You can add all the features you want and then it gets so brittle that it's unusable by anyone. The stewardship is gone. These products actually require leadership. You actually need someone to say no. And so I've open sourced a project before called ConfD. I was working at a company, very small one, when I left Puppet Labs, right, configuration management. And what I learned from Puppet Labs was there's this golden pattern, file package service and containers that just came out. I was like, I don't think we need to write all of this configuration management code if the abstractions were to shrink. So I go to the small company right outside of Portland or inside of Portland and I noticed that they were trying to figure out Puppet for the first time. I said, hold on. I don't think we need all of those things. We can create a project as one does. And it was called ConfD and all it did was manage the config part because Puppet handled everything else. And I was very excited about open sourcing it. And you upload it and you make the repo public. And the GitHub stars start going up. This is when you literally turn on your GitHub notifications and you wake up and you're like, look, babe, I got 28 stars. She's like, I literally don't care. And now I'm at this company and we have actual things we're trying to do in production. And I'm this, actually I was a director slash VP of engineering. That wasn't my core job. And I understood that I had to be responsible. So I'm solving issues and adding features. I'm adding features we don't need. We actually built all we need it. ConfD needs one back in. That's CD. That's all we use. Maybe a file one for testing locally. And then the community showed up. And on Saturday, hey, I work at a big company that has tons of money that doesn't want to pay for software. I would like you to add console and AWS S3 and blah, blah, blah for free. And I looked at that issue like, yeah, I'm gonna do it. And I spent all of this time adding all of these backends. I said, no one day. It was to the Haschick Corp team. They were like, hey, we would like you to add support for Vault. And I said, no, because I was tired. So I can't support all these backends. We don't even use any of these. I don't even know what the quality is and I can't build a test harness. So I said, no, but there was something that good that came out of that because they made console template. And I remember when it landed on Hacker News and someone said, hey, you literally ripped off Kelsey's ConfD and Mitchell tried to explain himself and I jumped in and said, guys, this is what's supposed to happen in open source because I wasn't building the business. It was just a project that scratched my own itch. And someone started itching and asked me to scratch their back and I said, that's nasty and no. And so they built their own project based on the same ideas, but for me, it was a relief. I no longer had to say yes to everything. So I think as an engineer, the thing I learned is that open sourcing comes with a ton of responsibility that people do not understand. So you're at a company and you work on the platform engineering team and you go off long wolf and you open source this thing. Here's the thing, all of our names are on it. Any change that you merge in from the outside flows into production. I now have teammates on another team I've never met that doesn't have the same philosophy that we do. So you're signing the team up for a lot and then we know what happens, you leave. And then the project starts to rot and that company's name is on it. And then people go on Twitter. Company X sucks. They have all of this money. Look at their last earnings statement. They should be able to pay people to fix my bugs for free. That doesn't work. So my advice is that first, before you convince the business, make sure you as an individual engineer, understand and have empathy for the long game. And if you can convince yourself that it makes sense for the long game, then I think there's a few people, a guy named Ben Johnson, I remember he did the first RAF implementation or EDCD where we were at CoreOS and he creates these beautiful, beautiful open source projects and he's massive to read me. I don't want any contributions. I'm sharing. If you have bugs, good luck. I'll try my best and this is what you get. And I think that's healthy. So I would say this, as an engineer, make sure you understand that piece and reconcile what this means. And so when you go convince the business, remember these VPs and execs have a lot on their plate. And so you got to make sure that you understand. We understand the risk. We understand the brand reputation that can be caused if we forget to or neglect this project. And we understand the risks of merging patches. So here's our governance model. So just think holistically. And I think contributing to other open source is a great way for any company to control their own destiny. Like the best decision that Kubernetes made was the CRDs and the extension model. If there was something that you needed to exist, you had a way of doing it. And I think that is the right relationship you should have when you're building a business that you're gonna have to unfortunately have a plug-in system that gives your business a relief. When Kubernetes added our back, it was a beautiful thing because people wanted IAM integration at Google. Hey, Kubernetes is great. We're logging in with these random tokens in this API server. Wouldn't it be cool if I could use IAM? The nice thing is the engineering team was pretty smart. Instead of them hard coding Google Cloud IAM into the Kubernetes project, probably creating a bunch of friction throughout all the rest of the community, we decided that there needed to be core work around our back native to Kubernetes itself. That means Amazon and Azure and everyone else could also integrate IAM natively, but we had the fair surface so then we can actually build on top of that work. And then it allows everyone else to do everything that they need. So I think that's the right relationship you should have so you can say no, but give people the way out. Thanks for the question. We'll go here. Hey, Alex Zivier from Serbos. I'll leave the product side of things there. I feel somewhat personally attacked because we've done everything that you just mentioned. We've taken that loan from that VC. We're doing that whole enterprise playbook. You throw up a dashboard and those sort of things. I loved your K-native Cloud Run example of the value is in paying for the work you don't have to do. And in a world where the mantra as developer marketing does not exist, how do you like seeing businesses and open source projects talk about that value without just saying we save you time and money because no one believes that ever. I certainly don't. Are there any particular projects that you see that does really well or any particular approaches you specifically like? Could you tell people what your project is? Yeah, so Serbos is an open source or open core authorization service which allows you to define your authorization logic for your application as YAML policy rather than hard coding it across your entire code base. So I met you in Seattle not too long ago and sometimes I go to these events and maybe I'm speaking and I'll walk around the booths and I like to just learn what everyone is doing. And I think I walked up to your booth and say, tell me how this is better than open policy agent. And to my surprise, he was ready. Got the laptop out and said, I'll show you. And you proceeded to show me something that I thought was amazing. And I think I even tweeted, wow, this is actually good. I was thinking that, ah, something, something enterprise nonsense. But no, you understood who was asking the question and you were ready. And I think when it comes to this developer marketing thing, I need you to be ready. We've seen it. Next up is the sponsored keynotes from company X. And you're saying, oh, this is gonna be trash. And they get up and say, all right, these are the slides that marketing has approved. I'm going to say the words that legal has approved. Please pay us money for our software. And you're sitting there like, I am so inspired to tell you, no. The best thing you can do is show people how to do this. And I'll give you the example in the first time I learned as an engineer to show people. So I'm at the financial services company and we're using Puppet in production. And I spent the last two and a half years convincing InfoSec that Puppet was safe. And then getting it to production and using it for everything. I did it. I joined Puppet Labs as an engineer on the open source side of the house. So I'm a pierce at this point. And one of the sales rep, he looked like an incredible hawk and he came over and he was like, hey, I need you to talk to one of the customers. I'm like, ma'am, open source, we don't talk to no customers. Tickets, that's it. And he's like, no. And I walked over to his desk and I'm like, on the phone. So I pick up the phone and he's sitting next to me like, you better say good stuff. Cause he's trying to sell the product. And so I'm on the phone and I was like, listen, man. He was like, eh, we're not sure what to do. We don't think Puppet's the right fit for me. I was like, so what are you currently doing? And he was like, you know, we kind of built our own automation system. I was like, oh, you got a bunch of bash grips, huh? He was like, yeah, I was like, come on, man. How many bash grips you got? And it got real silent. I said, hey, let me, can we share a screen like we want to switch things? I said, all right. I said, all right. This is what you currently have, right? You got this bash grip and it does some stuff. So for loop in blood, do stuff to servers. He's like, yeah, that's exactly what we got pretty much. I was like, I know, I used to work there too. And then I said, I'm gonna show you the Puppet thing, right? I'm not gonna go through the website, but I'm gonna just show you the difference. So in your world, if you unplug the server, what happens for an error? But your script doesn't stop, does it? He's like, nah, we keep going. And then the QA team tells us, or back in the day, Nagios tells us that something's wrong. We miss the server. I'm like, how are you missing servers, bro? And so I said, all right. I'm gonna do the same thing, right? Same number of servers. But this time I'm gonna put the agent over there. I'm gonna log into the server. I'm gonna do something to a file. He's like, yeah, our developers do that all the time. I said, I know. And watch what happens. I'm gonna log out and we're gonna wait a couple of minutes and we're gonna log back in. And I was like, what do you think is in the file? And he's like, this must be a trick question. I was like, no, you saw me open Vim and put stuff in the file. This isn't hard. He's like, okay, the stuff that you put there using Vim. And I opened the file and it was back to the previous contents. He was like, wow, can't do that. And we're both fired up. And then I get off the call. And the sales rep over there, he's like, and he said it very loud, you know, the cubicle stuff, engineering sits here, sales sits over there with the little partitions. And he got up, he's like, that's how you talk to the customer. Because some people don't understand that is the paycheck source. And so as an engineer showing people how it works, like you did that day at the conference, I walked away in a few minutes. I understood there was a new player in the game. You gained my trust instantly by showing me something better than I saw before. And you know how many people I've told about that? I'm like, yo, I found something better than writing rego files. I'm just saying. So I think the most authentic way of doing this if you're a founder, you gotta be able to tell those stories. And you gotta be able to show it to people. So all those years when I was on the KubeCon stage, what was I doing? I was showing you. And there were people in the audience that saw that and they would go back to their desk and it was like, Kelsey said, you know what I mean, emails I got from people's managers was like, dude, please don't show anyone else anything because production keeps changing. But that's your goal. You gotta inspire people by showing them. Thanks. My name is Johan. I'm working for a small managed Kubernetes provider. Our customers are very paranoid about data protection. They don't come here. They kind of know what Kubernetes is, but they pronounce this Kubernetes because it has something to do with Linux, right? So my question is really why all of this hassle with the sort of open core commercial versus enterprise and so because it adds so much complexity. We're seeing that by doing managed services it can help people consume open source without going into all of these details. And why is that not more common? So there's one thing that, you know, when I used to work at startups sometimes you would go to the board meetings and your VCs. Remember, they're trying to get a big return on capital. That money needs to scale. Not 2X, not 10X, like a thousand X. You telling me that you're gonna fly around in a plane doing professional services, helping people, I can't get that kind of return. And so they say this derogatory thing, it's a lifestyle business. It's a very unfortunate term because real people actually need real help. Especially when open source projects are new there's not a lot of people in the world that have experience. And so when you do have people that have experience the number one thing most companies wanna pay for in the beginning is pro services. Because a lot of times these open source projects are not just a better way of doing the old thing they introduce new ideas that people don't even understand the concept. So the first thing I need from you is understanding what this is, however it relates to what we're currently doing and I need to get my implementation people on board. And so pro-serve is usually the thing that most startups aren't built to handle, right? You have a team of three or four engineers, you can't take one of them and have them fly around doing professional services. But I do like that there is an industry around this that will complement those projects. Funny enough, there are probably more pro-serve companies that make more money off of open source than the teams that build the projects. And you just laugh at them, right? They've raised $13 million on a billion dollar valuation. It's like, dude, we made 13 million last quarter on pro-serve. But the reason why this exists is mainly because they're looking for that huge multiple by selling product-led growth. They want self-service, they want people to be able to log in and service themselves. And honestly, that might be the right trade-off to have them do that. But to your point, I think most startups, if you're in this room, and I remember Hashtag Corp was one of the best examples I saw. When Hashtag Corp started to get real popular, like Terraform and things like that, I remember in your companies like Container Solutions, there's a lot of these companies that were like, we're experts, we know how to build new backends and plug-ins, we can come train your team and maybe even help you write that Terraform code to get you started. It was the perfect complement. And so when companies like that go and build these real relationships or there's actually a real communication track, you can talk to the core team and you also get that feedback loop. Hey, here's what we're seeing in the field. People really need this, this is what we're doing instead. And so I think that is probably why you see it. But a solution I believe is that these companies probably can't become pro-serve companies, they're there to build product, but they can benefit greatly by partnering with the service providers and maybe making them authorized service providers and giving them an inside track and getting that feedback loop in place so it's mutually beneficial for both organizations. Super quick follow-up to that. Can you say something about monetization through pure managed service versus the open core model? It's tough man, look, you go to AWS and they got everything. Because the thing is I'm not, if you're a platform engineer, you don't just manage the logging infrastructure. You manage the whole thing. You're not trying to make independent solution decisions and build a vendor relationship with 500 little companies. It's not scalable, it's hard to manage. And so we're in the Netflix era of technology and that's kind of what IBM used to do, right? Used to buy your backup solution from them, your email, sorry for the people who had used Lotus Notes. But companies have this affinity towards a vendor who can kind of give them everything under one umbrella, especially if they have a great track record for doing so. So if you open source your product and you only do one 100th of the puzzle, I have no desire to go build a net new relationship with you from a vendor standpoint, it's too much work. So I would probably like to do it under an umbrella. We have the cloud now. And so if I'm already using the cloud provider and I say, hey, I don't like your logging or metrics interface, I prefer Prometheus. We've seen what happened in the last five or six years. What happens now? The same logging service with the proprietary API now has a Prometheus API. Things have changed. So now you're like, hey, as much as I love you, I have what I need. It turns out I wasn't looking to download the software and build an SRE team around Prometheus. I just wanted to send some metrics to a place and then get some Grafana dashboards out of it. And so now I think it starts to realize where is the value. Now the best compliment I have, I've seen is, you may have something unique like MongoDB. Very unique offering. Whether you like it or not, it's a very unique offering in the marketplace. And they've done a good job of going into the cloud provider marketplace and offering something to value next to and they just compete with the various cloud providers. So it's definitely possible. But if you're just a component that can literally become an API on top of a bigger, more robust, reliable system, it's gonna be a hard time to compete. And the last thing I'll say here is that they ain't always about money for some of these organizations. Like, let's encrypt, for example. Early in my career, I used to pay like $400 for SSL certificate. Used to create this little CSR and email it and then they would email you back. Some certificates and you paid $400. Now let's encrypt did something that I never thought I would see. Typically we have open source software, you download it, read the documentation, run it yourself, but they kind of skip the step. You can now just use a fully managed service from an open source organization. That's a game changer. And so now I think the bar has risen for what we mean by open source. Maybe one day there'll be a managed Postgres offering from Postgres.org, right? And I think a lot of people who are open source practitioners and wanna support the community, instead of t-shirts and socks, maybe we just pay for the managed service. So I think there's an opportunity there and I think that's what you've been seeing for some of the newer companies that have been coming out lately. Great question, we'll go here. Hi Kelsey, thanks for sharing your thoughts and experience today. My name is Paul Jolly, I work on the Q Open Source Project. You mentioned that you've worked with Docker. Docker has experienced some challenges in moving from that free for all to paid pricing model. And that's manifested itself in a number of ways over the years. Most recently with the free team plan sunsets and then sunrise when they backed on that. This problem isn't exclusive to Docker. It seems a large part of the challenge to me is one of communication and getting the pricing story right. Upfront, early communication and then subsequent communication when the landscape changes, like your free tier is just getting too expensive to sustain which effectively then challenges the viability of the thing itself that everybody is benefiting from. What would your advice be to projects that have to make that zero to one transition at some point from like a free for all to a, we need to make the sustainable in the long term? Thanks. So I'm an advisor to Q. Q Lang is a modern take on thinking about configuration. You should go look it up. I'm also an advisor to Docker. So I need to be very careful because I did get them. I said it's not exclusive to them. It's not exclusive to them. But as an advisor, I was involved in that decision and what the pricing could be and why. And I remember a big component was the FAQ part. I spent a lot of time on the FAQ around that, right? So you look over the pricing, you look at the proposal, you look at the justification and there was this part of the FAQ. Maybe it was a little too short. So now you got to answer all kinds of questions, not just the ones that you're happy to answer but the uncomfortable ones that come from Hacker News and Twitter. We already know what they're going to be. And so you have to answer questions in five different ways because that's how people are going to read it. It's gonna feel like you're taking something away. But also you need to tell them what they're paying for. And so some of the people who convert it, in that blog post, they're like, there's gonna be a pricing increase. And no one wants a pricing increase. It's just no good way to make everyone happy from going from zero to paid. But there were some people, and I actually talked to some of them. And I said, why did you decide to pay? Some people said because I had no choice. I was like, why did you feel you had no choice? Because there's nothing better. It's all right, because I remember, if you're a platform engineer, what'd you say when that pricing came up? We're gonna write our own Docker desktop thing. I can learn React in three days. No, you can't. And so you're like, you know what, I give up. I think we should just pay that $15. There's only three of us. It's like $45? You were doing all of this for $45? That's wild. So I think some people started to come back to reality a little bit and say, you know what, the price is fair. The other thing that I think is important is who has to pay? Do you really wanna tax indie developers? Do you really wanna tax your community that gives you free marketing and part of the reason why you have such a brand that can command a price? Probably not. So in the FAQ, you have to call that out very explicitly and also remind them, thank you for helping us get here. But you also need to be transparent. It used to break my heart when people would be like, ha, ha, ha, Docker doesn't have a business model. And then you rely on it every day for your core job. That's insane. That lacks empathy because the software that you build, don't you want your company to pay you on time? Don't you want there to be a job to be there? We gotta start thinking about the people who work on this stuff and not just pretend that they'll be okay no matter what. There are real people and there's real consequences here. So I think sharing that real people's story with the people you're asking to pay, that's part of what are you paying for? And so when Docker desktop started adding things like plugins, OWAL, SSO integration, enterprise level features that if you looked at it and you said, you know what, that's fair. I don't have 500 developers here. I don't need Active Directory integration. Fair enough, those prices, I get, that's why you pay for them. So I think it's gonna just be really clear and the last thing I think that I tend to give in general advice is, you gotta have a roadmap. It feels like Netflix descriptions these days. Hey, after Stranger Things, I need to see something in a pipeline because if you ain't got none in a pipeline, I might cancel that subscription. And I think that's the battle that we're in now. So if you're gonna be having an open source project and you're gonna build a commercial layer, your communication needs to be flawless. You know who I think probably did it the best and I've seen in a long time was GitLab. GitLab, if you went to their GitHub repository, this is our roadmap. It was detailed. You can understand the business model and I think most people knew what they're paying for. So many people were so happy to pay for GitLab, you almost forgot that most of it is open source. They did just such a good job in transparency. When they moved from Azure to GCP, I remember they live tweeted the whole thing. They have a deep connection to their customer base. So I think that's something hard to achieve but you can do it if you're super deliberate. HashiCorp was another really good example. I love the HashiCorp model. I remember I was using Vault and they made Auto Unseal. So if you never use Vault before, it's a secret manager and the way it works is you typically have a set of master keys that when it comes up can decrypt the data but only when those keys are entered. So you can imagine if it were ever to restart in production that you would have to be at the console to make it come back. That's a nightmare for HA situations. So they added this enterprise level support called Auto Unseal. And what it would do is you can back it by like a key management service like in the cloud or some other thing that can store the key and then Auto Unseal it by having a particular train of trust and they made it an enterprise only feature. I was like, what the hell is this? Do you know how many batch scripts and GitHub repositories that are literally working around this open source limitation? And I think people like me, we felt it was unfair that we had all of these workarounds in place and we had issues open for years that there had to be a better way of solving this problem. And some people even had port requests to solve it natively. And then they put it in the enterprise edition. And I was like, damn, that's jacked up. And I went on Twitter and I said, if they ever move that to open source, I'll wear a Hashicorp t-shirt for a month. And nothing happened. That wasn't good enough. And they had this philosophy about what they choose to put into enterprise and what they choose the open source. And Mitchell made a promise to his community. He said periodically, we'll take enterprise features when it makes sense and we'll move them to open source. And then one day I got a call. I don't know if he's here, a guy named Nick Jackson. I was like, hey, we're doing something that I think you're gonna like. And I have forgotten about this by this point. And they were like, at Hashicorp, tomorrow we're going to announce that we're moving from enterprise to open source. I was like, oh, I booked a flight. And I flew and I had my Hashicorp t-shirt on underneath. But I said, I gotta see it first. And so they let me see it during the keynote. Arman came out, no rehearsal. I said, hey, hey, before you announce it, can I try it first? And I walked over to the laptop. I took a fresh install of vault. And the unsealed flag was right there in open source. No enterprise license required. I unzipped the hoodie and I had the Hashicorp t-shirt on. Only wore it for a day. But the thing that was dope about Hashicorp was the transparency. And when they fulfilled that promise and came back and gave the open source community stuff more, it felt like a different relationship. The enterprise is subsidizing. And then things flow back, that makes sense. I think that's the right cadence. The last thing I would add is, just have a clean plugin model so you don't have to worry about this thing. I remember when Nginx started to stop accepting changes that started conflicting with their enterprise software. Any Nginx users remember this? It was like this thing where you were like, I'm using Nginx in production for everything. And as HTTP started to become more prevalent, they were like, hey, we need some plugins and extensions. How about an API to Nginx? So we didn't have to try to reload the config file and restart Nginx all the time. An API would be dope. And people were doing pull requests, trying their best, and they were like, nope, that is an enterprise-only thing. An API? Everything has an API now, not open source Nginx. And so people got upset and they left. There was no transparency. There was no clear roadmap of how that feature was gonna find its way back. So people moved on, welcome Unvoy, took a while. But a new player showed up with an API by default. I'm not sure that was the best decision that they made to try to protect short-term gains in favor of losing the long-term race. So that would be my advice, at least some of the stories from the startup era. Thanks so much. I'm gonna do a quick time check. I appreciate how dialed up you guys are in because this is, if you're building a business, this empathy piece, the stories that I'm telling, you should have these stories too. You're gonna make some mistakes, your pricing's gonna be terrible, you're gonna get feedback from your customers, you'll aggregate that feedback, you'll listen and you'll come out with a better price. Even though people will get mad at you in the open-source community, you can fix it. You just have to be honest when you make that mistake. And so stay dialed in, share your stories, but remember the empathy piece. So we've seen a number of companies that have a strong single offering that is based on top of then being the guardians of an open-source project. They're then taken over or acquired by a larger enterprise, and then we can start to see the commitment to being the guardians of that open-source project dwindle, but of course there's a lot of effort around the enterprise part of that software. There's lots of thoughts around kind of avoiding pitfalls, who's done it right in that space, who's done it wrong and so forth. So you look, I have a lot of empathy because that comp D thing burnt me the hell out. People were literally asking me to work for free as if it was a requirement. And so I had to learn how to say no. A lot of times when we're dealing with faceless organizations, what we just believe is like this big giant company should keep supporting this thing for free forever. That is their duty forever. But we forget the whole part of open-source that makes it special. There's a fork button for a reason. The responsibility doesn't belong only to the current set of maintainers. And so what happens? We get a little lazy, right? Two years of free maintenance and bug fixes and timely release notes. We all say, well, that's not my problem. I'll just get the download and complain when something isn't working. And a lot of times I think we get confused. I've seen people open issues with no empathy. Hey, this issue has been open for three weeks. What the hell? I said, you get what you pay for. I can't afford to prioritize this issue. There's 900 other ones. Are you willing to help? Nope, not my problem. I guess you don't like your customers. You're not a customer. You could be a community member, but you're not a customer. You're paying nothing. That's the part that I think a lot of times the community forgets. There's a cost to doing this. There ain't nothing free. So when you look at an organization that takes over a project, I remember when VMware was sponsoring the Redis project. What does that have to do with VMware? It was just someone talk to the right person with the organization and they gave funding to this somewhat solo developer to keep Redis going for everybody else. VMware paid all of this money so that everybody can have steady stream of Redis features and bug fixes. Most of the time we don't think anything of it. We tend to think that VMware is getting more out of this deal than anyone else. And so I think that lack of empathy has created a very toxic relationship between these projects, the maintainers, and the people they temporarily work for. These maintainers, it's a job. They're free to leave that job and they're free to quit working on this thing. And so when I see a project drop off, it tells me something. Sometimes I'll reach out to the maintainers like, hey, everything good? It's like, dude, I'm burnt out. It turns out I did my performance review and they said we shouldn't be working on this open source project very much anymore. So to keep it going, I just been doing it when I'm off. My kids are like, dad, when are you gonna be finished? And so I decided to play with my kid. That's why these issues have dropped off because guess what? Most organizations do not have meetings at the top about all of these open source projects. There is no grand conspiracy. There's usually like two or three people that are going the extra, extra mile to keep these projects healthy. And the better job they do, the more people believe that it's in good hands and there's nothing to worry about. And only when they burn out do we turn our attention to the drop off and productivity. So I think for me, for me, how I like to participate, I remember Open Policy Agent came out and I was like, oh, if this would just support IAM in Google Cloud, I can send my logs to Bitquery from our serverless stack. It will be dope. And I decided to roll up my sleeves and that was my first contribution. It took a while, I studied the code, I wrote the unit test, updated the docs, and I issued the pull request and said, hey, I really would like this feature, so here's the code that makes it work. Any feedback will be appreciated because I approach that particular situation with empathy. They don't have time to add support for all of these things and I think we need more of that. So if we're gonna hold the corporations accountable, you as an individual have a bit of accountability as well. If you've gotten two or three good years from free software, probably got paid money at your job while using it. You gotta have a little bit more empathy when that productivity drops off and ask yourself, why haven't I contributed? And then I think that's the answer. So yes, it's easy to blame the faceless organization but this ain't what this is about because on one hand, we want the big corporation to do everything. On the other hand, we want it to be a democracy and everyone's vote counts but in this open source game, your vote come with keystrokes. We'll go here. Hey, Kelsey, Mitch Connors, Aviatrix. Earlier, you were talking about finding the real decision maker in the room as we kind of go about developer-driven sales. Do you have any tips on identifying who that person is? They're often not the first to talk, they're not the people to sign the paperwork. How do we find those real decision makers? Mitch, you are one of my favorite, favorite engineers of all time. Mitch works on Istio and he's that developer I talked about. We have a commercial thing around Istio and there's this open source thing that needs to happen and people like Mitch advocate for the community at all costs regardless of enterprise business interests. These developers step up and say, we can do the work. I know we had to do it twice. One for internal and one for external but I believe I can make up the difference and we should do the right thing anyway. That's what the people look like. Mitch Connors over there. So if you ever use Envoy or Istio, that's what they look like. How do you find the developer in the room? As an engineer, I became an executive at Google and they asked me to do these exec briefings and you go to these large, large companies and they usually introduce you to the CIO and all the big executives and say, hey, I have only one request. The people who actually use the keyboard must be there too. So we need a bigger room and I want to see those people or sometimes I go to the all hands and I'm looking around the room and the most skeptical person is who I actually need. So the CIO says, we're moving to the cloud in three days. There's a person somewhere back there like, are we not? Ain't even gonna happen. So I find this person, I'm like, oh, that's the person. And so at this point, I'm now talking to this person because I need to know. And you say, hey, does anyone have any questions? This person doesn't have any questions. So I find them at lunch and I say, hey, what do you do? Well, I'm actually the person who would have to do what they said. And I saw you shaking your head. Why'd you shake your head? Well, this is the 28th time we were moving to the cloud in three days. So I don't think it's gonna work. And then we get that whiteboard and I said, show me. It's like, well, we have this Sun Microsystem box with a 56K modem, but they think it's a modem. It's actually a phone line to the airline because we do reservations and they still use this as the interface to make reservations. And last I checked, there is no cloud service that runs Solaris with something to plug a phone line in with this phone number because they only support this phone number. And in the contract, if we change this phone number, we're done. I was like, oh, that never showed up on the diagrams. This is not digital transformation. This is literally, you need this box to stay in business. And then I try to give that person a voice. So now that I understand, the next time they asked me to come speak, I was like, let's just say you walk into your data center and there's this box with a phone cable in it. Some of you all think it's a 56K modem, but it's not. And I tell their story for them. And they all say, yeah, Kelsey, you're right. We should probably do something about that. And then you look at them again, they're like, I've been tamed this for three years. But Kelsey says it and all of a sudden he's a thought leader. And so for me, I'm on the hunt for this person. Like you go and you sit at the company lunch again. This is why I love going to the company's, they're building. A lot of people say, if you're a startup, I'm gonna go to the conference. You're dealing with the self-selected group of people. People who have time to actually go to the conference. Probably they have status and some of them don't literally care about anything that you're talking about. I need to go into their particular organization because a lot of times these are the forgotten people who don't get invited to the special meeting that only has 15 seats. No one's inviting that person. So I try to find that person and give that person a voice. And if you can get that person to be on board, then your feature looks like you ever use a product and you're like, wow, someone must use this. Exactly what I was thinking. And you know, I've been at Google for a while. I used to go to the product meetings or I would do these prototypes on the engineering side and say, what if it worked like this? I remember for Istio, I remember doing the first admission hook. You can install Istio by just injecting it. And I threw it on GitHub and you would tweet and say, Kelsey, why? I was like, well, no developer I know wants to add something to a YAML file. We can just add it on demand by using this particular hook. How do you come up with these things? I don't. They do. I just give them a voice. So that's my trick. If you haven't met that person yet, then you know you need to dig deeper. And I learned this trick on the sales side. There was a large customer I went on site with with the sales team. I just said, hey, sit there and let me do my thing. And all of these extra people showed up. And they were like, I've never met any of these people before. Who are they? And they were like, hey, I'm the guy keeping the lights on. I'm the girl that manages all the Oracle databases. You got to talk to me if you want to migrate this to something else. And I will get those people to show up. So when you show up, I always like to offer something. We're going to go do something hands-on. I'm going to show you how to actually think about this product. I'm going to show you how to go from writing Fortran to this new thing so you can leverage this new technology. That's always been my trick. And those people that were targeting, they tend to show up for me because they know what they're going to get in return. Thanks. Hi, I'm Ahmed. I work for Red Hat. I used to work in Knative and now I'm working on one of Red Hat's managed services. With the hype around microservices, everybody started saying microservices is the golden solution. Let's move everything to microservices. And probably most of you already have seen a lot of movement that say, oh, microservices suck a lot of time. We're not a million dollar business with this amount of, yeah, thing that is fitting microservices. And there are some solutions that are even moving back to consolidate these even nano services. Moving to the next hype, the cloud. Let's all move to SaaS, cloud, and so on. And recently, we've been seeing people who are saying, I'm actually not Google and I'm paying a lot of money in this X cloud while when I, or this X SaaS while when I invested in a bit of more not necessarily on-prem, but maybe not a SaaS offering, just some infrastructure, some JKE cluster or whatever and hired good people that actually made a lot of difference in my business and business continuity, at least for this type. I wanted to know your take on this if you also have seen this recently if you validate this approach. Yeah, thanks. Man, this is, I mean, you're naming things that are probably at the end of their hype cycles, right? Those two things are the hope within the hype cycles. When I zoom out and I look at the whole ecosystem, there's this false sense of winner take all. It's like the dumbest thing I've ever seen. You are not going to get all the customers. It's not happening. First of all, you can't support all the customers. So you're not gonna get them. Not all of them. You're gonna get your slice. Now you gotta decide, what slice do you want? So that way you can have a focus roadmap and you can say no to the slice that you don't want. I think a lot of these open source companies start by saying we just want all the customers. And then you get that customer that's like, we want active directory support. You're like, why do you want active directory support in my load balancer product? I don't know, we're enterprise. Until we see that, we're not paying. And so then you get distracted, right? And so sometimes you gotta figure out who you're trying to focus on. So I think when it comes to these hype cycles, that's just where we are. One of the biggest advantages I think companies have found in a long time is that if you can actually adopt a new technology faster than the other people, there's an advantage to be had. Remember when mobile apps came out? I literally changed my banking provider because they did not have a mobile app. Seriously, I was banking with the credit union. I lost my debit card and they said three to four weeks and you have to come into the branch to get a new one going. And for a while, that was fine. And there was a bigger bank. And they were like, you can just hit the app and say the card is gone and we will mail you a new one. I was like, what? Close account, transfer money. And then I also, I don't know if you're like me, but if you didn't have a mobile app for like flying airline, I ain't calling. I can't call for anything. I need to be able to do it in the app. So if you couldn't take advantage of that new tech, you got left behind. And there were some new businesses that came out that were mobile only. And they just started grabbing that particular market because that became the preference. Sometimes you don't have three years to get on board. So if you're now just talking about the cloud in 2023 as a hype thing, you're 11 years late on that one, right? We're now on-premise the new hype cycle. You know what we call, we call it edge, right? There's a new hype cycle. But I do think there is value in being able to create something that is common term that people can use to quickly understand. I never liked the word DevOps, but it's a quick term you can use to help people understand there's some mode of collaboration that's required. And so I think sometimes attaching yourself to some of these things is a quick way to actually get some attention. The problem is when it doesn't work, that's when it feels like it's just hype, right? If it's hype and you show me something like I'm hyped up and then it actually does what it says, it doesn't feel like hype. It feels like, oh my God, this is great. Wish I would have known about it earlier. What more are you going to do? It's kind of hype when you go and it's like, oh. You didn't even do the getting started guy doesn't even work, right? That's what I think it's a little bit dangerous, but we're in that error now. That if I go to KubeCon and I see a company like Spotify say, hey, this is how our developers work. And we use a tool called Backstage, and you can do it too. The delta between idea and the ability for everyone else to do it is shrinking. That's why it feels like these hype cycles are here because it's like, wow, you can actually touch these things. And there's that saying that says, some people have ideas and some ideas have people. Where we're at with the product development space, people are taking their one idea, and when they introduce it to the world, they do it in a way that you can go and try it yourself. And then what happens? You go show someone else. And before you know it, in a matter of days, everyone seems to be talking about the same thing. And sometimes we confuse that for a hype cycle when really that's just the name of the game. That was never possible with traditional marketing. Hey, you were at the same magazine? I did. That ad was phenomenal. That's not how it works now. Now it's like, oh, I touched it. Let me show you. So that's just where we are. So I would say this, the competition is getting really, really good, really, really fast. When a new idea appears, five or six startup teams will rally and compete for the best implementation of those ideas. And now we're starting to introduce these ideas on the common words and terms that allows everyone to understand what's happening. And ideally, the best two or three tend to take the prize. And then those same teams move on to the next opportunity, right? That's the phase that we're in. And then the larger companies look around and they just acquire the top three, and now they have that capability. It's just the cycle. So that's what I look at when I see these cycles. And people are making noise. That tends to tell me that there's still a problem. And now there's an opportunity in that and the people that can go from hype to real tend to do well. Thank you. All right, we'll take two more. Yeah, we'll take two more. We'll go here. Hi, so we have very related questions. If that's okay, we'll ask. You know, that's dope. You all stood there by the mic and got consensus. All right, go ahead. Let's do it. So I'm Niki Manoledaki. I'm a software engineer at WeaveWorks and a contributor to the environmental sustainability tag. And, you know, GreenOps is gaining traction. You have KEDA that's introducing a carbon aware scheduler, tools like Kepler for energy, monitoring and efficiency. And we have contributors and the advocate for environmental sustainability in the clownative ecosystem working. Double shifts to move things along. But it's very difficult to, you know, even though we pitch features and do so much work around this, it's very hard to allocate resources, time and funding for this topic, even though it's related to FinOps, et cetera. There's regulation, net zero pledges, et cetera. So I would love to hear your, if you could share your wisdom for this growing tag in community and what would you like to add? Hi, my name is Jochen, Jochen Joswick. I'm also a member of the tag for environmental sustainability. And I guess because we've talked about making revenue and we talked about accountability, how do we move from that to also taking into account sustainability and making that a part of the conversation and putting it somewhere on the hype curve already because last year's CubeCon we had, I think, one or two slots for environmental topics and this has tripled almost and this year's conference at least for Europe. And yeah, my question is how do we how do we get that as a part of the conversation not only to make revenue but also to protect our future planet and our environment through the work that we do daily? I don't know. All right. I'm just being very honest. I actually don't know. So now I'm going to go to opinion mode because I just don't know. When electric cars came out, there was this push by some people around the same line as you said, right? Ideally, this thing could help us get to a better place regardless of what you believe in this become a political issue, which is sad. But worse, if people are lying, we just have a cleaner place to live. That should be OK. But people looked at that and they started to do some analysis. These electric cars take energy to build. And so there's a deeper question behind only the good side. And a lot of times the proponents of the good side are unable to explain the trade-off. If you can't explain the trade-off, that means someone else will. So I go to the page and you only show the good parts. Then I'm getting the other part of the conversation from someone else. It may not be as nuanced as you're willing to give. It's an incomplete picture. And so now I go to the other thing. And it says, don't worry about what they're talking about. Here's some alternative facts. That thing at best makes you feel good. And so they ignore it. They don't come back to your page. That's a problem. You got to own the whole narrative. And I remember there were a group of people that said, I'm never driving an electric car. I'm going to drive this gas car forever. And the gas prices went to $5 a gallon. They started to reevaluate because there was now this aligned interest. There was a reason to reconsider. And then Ford came out with this F-150 truck. And they're like, oh, that looks like the truck I like to drive. It looks like a better truck. Environmental stuff aside, it just looks like a better truck. I'm going to be honest with you, I care about these things. But that's not the reason why I bought an M1 Mac from Apple. I bought it because it was all up a better computer for what I was trying to do. And so I think when we're thinking about these particular things that are actually serious and important, there's a nuanced conversation. You've got to decide, do you want to be a part of that nuanced conversation or someone else will? And you may actually lose the mind share. A lot of people like to discredit these other sides of the arguments. And people are looking for that particular nuance because they need to do a little bit more to convince themselves. And also, when there's aligned interests like supporting my actual business with my limited resources and there's extra work required to do what you would consider to be the right thing, you know what most people are going to choose, especially when no one's looking. These developers are making this decision and ain't nobody looking. So it's going to take a lot more interest alignment, in my opinion. You're going to have to show them the true value of the thing that you're using. When that MacBook became super light, I was like, wow, this is a light computer. Maybe I didn't think so much about it being made from recycled aluminum, right? So I think Apple is a good kind of way of like getting this interest alignment while holding their commitment to the environment. I think they've done a lot. There's a lot to criticize, but I think they've done a lot to hold that commitment largely because the interest aligns. They need these precious metals to make these machines. There's only so many of them, so they need to have a recycling program. So it's good for them too. It's good for business. So in the software space, if you're asking your company to give you more resources to work on a thing, how does it make sense? We did this in GCP. So there's a couple of things that make sense. In cloud, there are certain regions that cost more than others. Sometimes they cost more than others because of how much the power costs there. People's salaries, the limited amount of compute and space. So then the prices are reflected in the services. So to help people understand, we put this little green leaf on certain regions. Now, if you were into the environment stuff, you're like, oh, this is great. This region is all renewable energy, and we passed that cost on, and that service is cheaper. Some people don't care about the climate at all. It's like, ooh, cheaper price. I'm just gonna move all of my stuff to the region. We went on both fronts. The interests align. So to me, at least for being very honest and transparent, I tend to get active on the interests align. And then it also feels good that I'm doing something that I believe is also right, but I think you need both. I know it would be better if people just did the right thing because you told them and you showed them the way, but I don't know if it's enough, and I'm just being honest, and it requires this level of nuance. So take that passion that you all have and give people that nuance. Give them the size in an authentic way so they can make that better decision. And when that doesn't work, align the interests and they're gonna do it anyway. Very powerful and an important question. I hope people understand who you all are and decide to help contribute. We'll take one more question. Yeah, I'm very thrilled about these questions because I don't wanna thank you for the special talk that you gave us today. I think you gave us much more than it was advertised. Also the empathy you gave us, like it's a good energy, I have this ball because I cannot stop doing something, I have too much energy to control, I'm very happy about this cube con overall. And yeah, so I would usually ask these questions to judge GPT when I feel very alone and I don't know what to do in my life. So it usually lacks the empathy that I think you have your really excellent communicator. And yeah, so I feel like in the beginning of this whole path I basically came to know a bit how open source works better in those days. This is my first cube con, I'm 26 years old. And sometimes I just feel so fucking lost in this jungle of software, like so many things, so many frameworks, so many things to look at. And I understand the power of delivering more and I understand getting fired up because that's how I feel right now, like you really fired me up. And these nights I couldn't stop thinking about where do I get my metrics? How do I solve my problems? How do we get faster on production? Like this kind of question, just boom, boom, boom, boom, like all together. So I would like just two suggestions, like one from practical advice on how to lead the path, like what would you be like an advice to me as a person? And another one like from more philosophical perspective, like how to embrace this journey correctly. Yeah, so I'm a self-proclaimed minimalist and it means a lot of things in the physical world and also mentally. Someone asked me what my favorite Marvel character was from Superhero. And this character's complex there because they're mostly a villain. And I said, Magneto, that's the guy that walks around with a helmet on. And he puts it on because he needs to protect his mind because he has no idea some mutants have powers that control the way you think and make you do things. And you can't tell the difference sometimes. And so for me, I also protect my mental space. And as a minimalist, I look at all of these projects. You walk through that sea of vendors, they got all the boots and t-shirts and swag. You look at it all and you're like, oh, look at all this new stuff. But if you just peel back one step, it's all usually based on the exact same fundamentals for about 20 years ago. Most of the new stuff is simply a checkpoint on the last two years. There's a pattern that people start to do and emerge or there's a new project that causes more problems than it solves and the whole industry springs up around it, right? And so when that happens for me, I just peel it back and I look at the fundamentals and it makes me calm. There isn't a lot to learn. I just need to choose where I would want to focus. Like when you go to the grocery store, as I always say, don't go to the grocery store while you're hungry. And it's probably smart to make a list. Most people don't do that. They come to a conference because they hate their teams, like, oh, vacation. And they don't have a list. And what I mean by a list, when people get very excited about Kube and they're like, oh, Kelsey's coming. We're going to geek out on Kube. And I'm like, no, we're not at all. Kube is no replacement for where it actually needs to happen. The list in this analogy is the roadmap. You as a platform team or person that's buying these products from these companies, you should already have a grocery list before you go to the grocery store. You already have a roadmap of features and capabilities that the company needs to do what they need to do. Now you look at that and you have to make a buy versus build decision. If you have the skills and the timing, it makes sense you do it yourself. If it doesn't, then you go shopping. Literally a lot of people are straight up doing it. You're literally going shopping, but it's easier to shop with a list. So then you only walk down the aisles that are necessary. You only put the things in the cart that are necessary. There's nothing worse than buying a bunch of stuff and I'm guilty of this. You go in your refrigerator and it's like, oh, half of this stuff is spoiled because I didn't use it. Literally a waste of time and money. So for me, I stay focused. I have a list before I go shopping, including mentally shopping. So for example, I'm looking at Wazim. It's a lot of hype around Wazim right now. I mean, it's unbelievable. People believe that this will be the only computer abstraction we will have in the future. And you talk to them and they're like, hey, I'm getting a little nervous because I just can't see it. Because this is how I know computers to work. There's a kernel, there's a binary, there's actual business logic. What does that have to do with Wazim? It's like fair point, because we don't change that. I was like, so what do you do? And they talk about the sandbox and one day they're gonna add sockets, one day they'll add threads, one day they'll let you talk to a GPU, one day they'll let you use your computer. And so I become calm. And I said, I don't have anything to worry about for a while. And I'll check back in three years. I'm gonna wrap it one thing, is this is how your customers look at your open source projects. If you're building a business and it ain't clear why I need to pay attention, it's okay if you're just simply remixing the fundamentals and you give people a better experience in order to do networking or compute or security. People are looking for a better way to do those things, but don't fool yourself. You will never be the center of the universe because the thing that you're probably building is one of 100 things that that person needs to worry about. Do not spend all your time making an enterprise single pane of glass. Do not waste the first part of your website talking about faster, cheaper, better dev ops and journeys. Literally, I'll waste a time if I read that and I still don't see myself in the future using your product to solve a problem. That's the name of the game. And if you do it well and if you establish a trustworthy feedback loop, then your customers, the community will tell you what the roadmap needs to be in order for them to be willing to pay for the thing that you're building. I really appreciate you all hanging out with me for this hour and a half, it was dope. Thank you.