 Thank you for joining me today. My name is Josh Gross and I'm going to be talking to you about achieving the tipping point for open source software. How to make the business case obvious for your management. Now there are going to be two takeaways. One for you as the person that's evaluating technologies and looking for technological solutions for the problems your company faces. You're going to get a template for selling open source software solutions to your business and helping to drive change management. Now for the management side, so those folks that are actually evaluating the proposals that their team is bringing to them, you're going to get not only the rationale for choosing open source software over potentially competitive proprietary solutions, but also a framework to evaluate technology recommendations from your team. Now as individuals, what are you going to be able to do with these two things? One, for you, it's going to allow you to wield greater influence within your organization and garner respect potentially leading to promotions or being included in business level conversations. Now by working with open source, you also create friendships and grow your professional brand. For management, this is where it's all about delivering outcomes by empowering developers to be more engaged. And by working with open source solutions, you're going to be perceived as an innovative organization and you're going to have a wider talent pool to choose from because of the accessibility of these technologies to developers all across the world. Now to get here, we probably need to take a walk down memory lane. Now many of you won't remember this moment because there are only 500 people here. This was actually the keynote for the first cube con. You'll probably recognize that person on the stage. That's Kelsey Hattire, probably one of the most famous people within the Kubernetes community. And then to his right, my left, you're going to see Brendan Burns, one of the founders of Kubernetes at Google. Now let's fast forward from 2015 to 2019, the last time we had a North America live cube con event. There were 12,000 people or roughly 12,000 people and you see Brian Lyles on stage there. He can't even see everybody in attendance. Now since this is a business value conversation, let's look at the Kaggle here. So in that five years, we saw a Kaggle of 90% growth annually. Now to do that on a regular basis, that's going to surpass what you're seeing the best startups grow at. And so when we think about this community and the contributions to open source based on the attendee count, we're growing faster than any of the startups out there. Great. That's a great stat. But it actually began before cube con and the CNCF because there are studies that were done where individuals had to go through researching the open source communities to find what does an active project look like. In 2006, they're estimated at about 5,000 active open source projects. By 2012, they're already 26,000. And if you look at the stats from 2012 in the study that I used, they actually used a much more critical eye to determine what was an active project. So we were already on this trajectory where people were contributing to open source more. And what we saw is in 2012, one of the key findings was that with corporate sponsorship and corporate partnership within open source communities, we saw greater traction. And then GitHub just released their study for Octaverse. And we saw that in the last year alone, contributions to open source grew 25%. Now these numbers are not anomalous anymore. We're seeing that open source communities is where developers like to spend their time, but also look for answers and look for solutions for the growing number of problems they're encountering. They're also looking for peers that they can work with that are tackling the same problems. Now that brings me to think, well, are we at a tipping point? Well, when I looked at what Malcolm Gladwell said about tipping points, there are really three key areas that drive what a tipping point is defined as. Now you don't need to have all three. You could just have one to make a tipping point. But when I did the research, I saw that all three existed here in this community of open source. So the law of the few, what is the law of the few? The law of the few is where you have key individuals that not only attract more people to participate and to create a movement. So they're charismatic, knowledgeable, they bring new fresh ideas and they bring people together. The stickiness factor. The stickiness factor is a concept that or a group that everybody kind of associates a movement around the power of context. Power of context is all about timing. And timing is always important with any movement. Now when we break down what is the open source movement that we're working with today, we see that there are so many famous individuals for a good reason that have contributed to where we are. You've got your Adrian Krocrofts, your Kelsey Hightowers, your Joseph Jacks, who led the first KubeCon. Gene Kim, who doesn't need an introduction for Phoenix Project. You've got Dan Kohn, who led the CNCF. Martin Fowler with 12 immutable stateless apps. You've got Serenovotny leading the OZCon. You've got Jez Humble, his contributions to the DevOps reports. You've got John Alspa, who was delivering at Flickr and Etsy and Blameless Postmortems teaching agile software development. You've got the Godfathers of Kubernetes. And you've got Nicole Forsgren, who has done so much for how developers engage with software and how management looks at development. And these people attracted such a large group, not just developers, but business people, like analysts, corporations to contribute and participate in these communities. But then you get to the stickiness factor. And no, I was not paid to give this presentation, but as I thought about it, so come 2015, you've got KubeCon just spinning up and the CNCF comes up. And what they do is not only do they bring corporations in, so to participate, to give that foundation, that investment from resources, dollars, marketing, to build these communities, but they took a project that already had a lot of movement, which was Kubernetes. And they started to work with these corporate and customer members to identify all the problems facing how shipping and running containers in production. And so what they were able to do was create a map, the CNCF landscape. And I remember at early KubeCons, when I would ask customers, I'd say, how'd you hear about this project? And they'd say, oh, the landscape. And what the landscape did was it was inclusive. It made this community approachable. It made the technology approachable. And what it did was it made everybody kind of have some foundational understanding of what they're about to get into. Now, finally, timing. So what big things were going on at the time? Well, the cloud, of course, and we know all the cloud vendors that are in the space, velocity. What the cloud did was it allowed any startup to compete with any big company by being able to ship software faster with less capital intensive work. And so what happened were businesses expected their teams to ship faster? Well, you couldn't really do that without something called containers, which made it really easy to develop and ship technology on your own laptop in any cloud without worrying as much about the dependencies. So when you see all of these things and how they drove open source software development and the communities and the interest in developing technologies that complement and enable different software architectures, you're thinking this was obvious. Open source software is here to stay. Like why wouldn't management be interested in using the software? Well, it's because management doesn't think necessarily about the individual technologies in the same way that you do. Now, what we've just done in the last couple slides is we were actually working towards that business case. And one of the aspects of building a business case for management is de-risking. And we just de-risked open source software. So we saw the herd theory, we saw the movement, we saw that there are many ways to show or to prove that open source software is just as viable as any proprietary software out there. But there are other ways that you can quantify that and data drives decisions. And so now, thanks to the CNCF, thanks to a lot of other projects out there, which you can see in these resources, you can now determine what is the project maturity, what does the activity look like, corporate participation, community growth, new contributors. The CNCF DevStats is a phenomenal place to start. Of course, you could always go with GitHub Stars as well. But now you're armed with justifying a technology decision at the technology layer. But when you're thinking about how business decisions are getting made, I can tell you from first hand experience that this is just a small component of what you need to be doing to drive that change. See, I actually have been selling against open source for most of my career. Now, at some point during the Kubernetes era, 2016, 2017, I saw that it was no longer as simple to just say, we're going to deliver a solution for you as a proprietary vendor. I knew that we were part of an ecosystem that delivers an outcome. And so when you think about what executives care about, they care about outcomes and they care about the projects that are tied to the outcomes and the business strategy objectives that are most important to their survival, to their growth, to their valuation, to their shareholders. And so understanding the criticality of the project you're working on to business outcomes is rule number one. Kelsey Hightower recently in a panel mentioned about understanding OKRs in the value line. AWS has talked about undifferentiated heavy lifting for the last nearly 10 years. It's all about understanding what are the projects to deliver value and am I working on one of those today? How can I link or bridge the technology to what we need to do as a company to thrive? Second, how fast can we do this? If we need to deliver something in the next year, but you can't find a technology or an implementation path within that time frame, it doesn't matter how great the technology is. And then finally, something we've already covered in from that beginning is about risky. And how are we going to mitigate it? So when you think about why we mitigate risk, it's all about have we done the due diligence so that I can trust that your decision was well thought out. So let's take a look at a frame for you to work in when you're thinking about the project you're working on or technology recommendation. Now the four questions. First question. How is what I am working on related to our immediate company goals? So whatever project you're working on, you need to be able to tie it to objective key results or business outcome or a strategy or mission statement or something. Typically that is going to be available to you. If not, that is a great opportunity to talk to your management to understand why is this important and how critical is it? Second, you need to be able to convey that that what the outcome is going to look like should you choose and implement that technology. It's really important for you to be able to say, here's the outcome because if that outcome is not what management was looking for, then there's no reason to start on the project. Third, this one is really critical as well from an expectation standpoint. When you talk about design principles, so what are the tenants that you used when you chose to recommend that technology or when you chose to pursue a technology for this project? You may say it's cost. You may say, and we'll go through some examples, but you may say it's scale and it may be speed. It doesn't really matter what it is, but the important thing is that you've outlined those because when you go through your business justification and your management sees that, hey, these design principles are important, but it's actually not the most critical thing. That's going to allow you to have an open, collaborative conversation. Plus by writing these type of things down, it makes the work visible and it makes the decision making visible. In a distributed work environment, a remote work environment that we're seeing today, having these written down makes it very easy for someone to come in and get context. Finally, what were the other options I considered? Did I truly do due diligence? If you didn't, then that is going to be something that you're going to be asked to do or you're going to have to come back to later if it doesn't work or if somebody else has a recommendation that's competing with yours. I find that it's really beneficial to be able to go through examples. I've got three examples coming up for us to look at specifically in choosing open source software. However, these examples could apply to any change management process or recommendation that you have. Example one, reducing mean time to detection. This actually came from a conversation with an executive that I worked with previously. His issue was that their mean time to detection had reached greater than 10 minutes due to the amount of data being processed and the complexity of that data. Essentially, because they had so much data coming in, their systems weren't able to keep up with that to alert teams to understand what was going on or if they even had an issue. If we deliver a solution, the outcome needs to be to improve that. By moving to a stream processing architecture, we'll become aware of issues within seconds and get customers back up significantly faster. So we jumped through three layers there. One, the technology which may or may not be as important at this point. The second is what will the outcome be in terms of time reduction. The third is who is going to be impacted the most, the customers, the people that pay our bills. Now, what were the design principles? Well, we need to scale to our volume and probably our growth volume. We have to be able to process our data types and we need to be able to handle modularity in case we bring in new data types or new applications that need to send to us. And of course, let's do it at cost. And finally, what else was chosen or what else was considered? Well, what were the other options that we could have used other than say like an open source tool like Flink or some other data processing? Well, we could have looked at cloud provider offerings because everybody's got something out there. We could have looked at other open source solutions, could see third party commercial solutions, or we could do something DIY. So build it yourselves. And these are all viable depending on what the needs are, the timeframes and what the business outcome you're trying to deliver. Example two, something anybody that's worked with an existing code base is probably dealing with today is a refactor project. So taking an existing application and possibly breaking it apart, possibly changing the code base in a way that improves. Now for this one, our growth has been limited due to capacity constraints within our current monolithic architecture. So the outcome that we'd like to deliver is by removing critical architectural bottlenecks, we'll be able to increase the number of customers we can support to keep up with our growth plan. Pretty simple. The design principles. Well, we know that we're trying to scale 15x within the next three years. So we need to be able to accommodate that because although we do not expect technology to necessarily survive for more than three to five years, we need to make sure that any decision we make is compatible with that. Let's reduce the cost per unit delivered by 30% so that we can maintain higher margins. Is there compatibility with existing tech? Because we always know when we bring in new technology, whether it's open source or it's proprietary, we're going to have to be able to integrate it. And finally, and this is where open source really shines, is what's the talent concentration within that tech stack. So whatever solution we choose, can we find talent to come in and be productive quickly? That's really important because of the cost of recruiting, the cost of developers, the cost of developer attrition, are there people that understand this technology well enough that can come in and contribute. And then in terms of what we looked at, we investigated adding capacity to the current solution via alternative hardware solutions, scaling up. You can say we looked at other open source solutions and commercial API gateways. So could we break this up in other ways? Was the database the bottleneck? Could we look at open source solutions for our database or commercial? And finally, building multi-cloud SaaS. So this one is for more of those mature companies, I see this predominantly. And again, these are all examples that I've even worked with customers on or seen or discussed with other customers or worked with within the company event. So building multi-cloud SaaS. So why would someone want to do that? Well, maybe we need to expand our addressable market and find new growth opportunities. We need to be able to offer our services in any cloud. Okay. So what would the outcome that you deliver from a technical standpoint? Well, the outcome would be that if we could ship our code base across any cloud via automation, which lends to speed with little to no code change, it would enable us to spin up and spin down providers and regions based on customer demand. Not to mention it may actually help with cloud partnerships if that's an area that you're investing. Now design principles, well, we've got to operate it all and we need to deliver the SLAs we're already delivering. So we need to use common components that can be operated by a single SRE team or rotation. We need to deliver SLAs in line with what we're giving today. And of course, we need cost transparency because if we can't run it cost effectively, then is it really worth that growth paying for that growth? Now in terms of how we looked at it and how we evaluated other solutions, well, we thought about just rearchitecting everything into open source. What does it make sense? Are there some commodities within cloud providers that have similar API interfaces that we can work with? We looked at provider hosting offerings. So should we go full stack with each AWS, GCP, IBM measure doesn't matter? Could we look at third party abstractions? When I say third party abstraction, could that be like a platform as a service, like a Heroku or something else where we just ship the code, it hooks it all in and we're off and running. But does that create dependencies that we're not comfortable with? And then also based on the cloud that we want to work in, is there a time or cost estimate for each migration? Are some going to be harder than others? Now just think if you presented this to your management, or if you're a management hearing this, where do you see gaps? It seems like they thought about everything. And that's where you want to get to. You want them to think, they understand what we're trying to accomplish, we gave them the problem, they identified a solution, and they already addressed all the concerns I may have had. Let's go give them the keys, drive away. It sounds like a lot of work. But candidly, you're already doing that. You may not be documenting it to the same level, but you're doing the work, and you need that work to be visible. And that's why a template or a framework is so critical. Because the next time you say it, why didn't this person think it was obvious that we chose open source or we chose a technology for this? Open source has been around the community, all the members that are participating have the same problems as us. Why aren't we doing it? Well, you need to have that business level understanding of the impact. And you need to present it in a way that's consumable by different stakeholders, whether it's the business, whether it's technology, whether it's finance or even legal, worrying about security, worrying about any liabilities. It's totally worth it to your company because the thing is, if you've done this diligence, chances are you're going to deliver better outcomes. And you're going to be able to tie that context of technology back to the business, which brings a lot of people with you. Plus, we talked about recruiting, like you may start just as a consumer of open source technologies, then you may start contributing and then you may actually be producing. And what that does is it creates a culture around innovation that's very, very attractive in today's world. Now, if we go back to why we're here, for you, you're going to get a template and there are resources here, I'll share with you shortly. But really the outcomes that we want to see for you are to wield greater influence among your colleagues, your management, your peers, garner their respect, not only for your technical aptitude, but also for your understanding of how businesses work and how to prioritize the work that you're doing. Now, you're going to create friendships. Working within communities, especially in this remote distributed world is one way to create connections that you may not be getting working specifically with one customer success manager or a couple of your peers. Once you start to become a contributor with an open source, a maintainer, that's where that inclusiveness really grows and you start to have people seeking you out and wanting to connect in mentorships and so many great things. And then finally, all of that equates to growing your professional brand, which depending on your aspirations, whether you want to do a startup later, you're going to be able to raise funding easier, you're going to be able to attract talent to help you build that thing that you've been wanting to build. Now for your company, achieve better outcomes. Why? Because if a developer knows the problem, chances are they're going to find the solution. Jeff Lawson recently talked about this in his new book, ask your developer, and he does a phenomenal job detailing why it's so important to allow developers to be creative by understanding the context of the impact on the business. Empower your developers, build a brand perceived as innovative and agile for that matter, because you're giving developers the ability to influence outcomes. And then finally, expanding the talent pool. And this is really about when you're working in a large community of open source, not only is your brand out there, but you're also able to find people that know the technology stack very, very well. Just want to say thank you. This has been a really fun talk to give, and there's so much more we could go into about this topic. And so if you want to continue the conversation, please DM me at Sudotaki, or you can connect with me on LinkedIn. Also, I've put my GitHub here because in here I've put a template for you to fill out for your next business justification. You're welcome to do pull requests. But really, this is about helping you be more effective at your job and getting rewarded for all the technical due diligence and the knowledge that you have in there. Thank you very much, and have a great day.