 here. All right, thank you all. So, like I said, I've been doing open source for a while and one thing that I've learned over the years is that when you talk to your management about open source, they know that you're passionate about it, but they don't know what you're talking about because your priorities are very different from theirs. So, yeah, I have been working with the Apache Software Foundation since some year that started in 19, and I started out that way. You're extremely passionate about open source, and then you go and you talk to your manager about it and they say, like, you know, and how many of you all work with open source at work? So, you want to keep doing that. That's why you want to learn these things. You want to persuade your manager that this is a worthwhile thing for you to spend your time on. So, let's start with a question. Why do you do open source? Somebody tell me why you're interested in open source. Speak up. Scratching an itch. Alright, scratching an itch, implementing a feature that you want. What else have we got? Make a lot of friends. That's something that's not important to your manager. And in fact, you know, some of the things that we hear scratching your own itch, it's fun, socialization, altruism, giving back, making the world a better place, building your resume. These are some of the top reasons that people give for participating in open source. And your manager doesn't care about most of these things. And, you know, what what we love about post Asia is that we get to sit around a campfire with the people that share our interests and we get to talk about these things that excite us to talk about the technology that we're interested in. We all have funny stories about our management. We just doesn't get it and we like to laugh about it behind their backs. But next week, you have to go back to work and you have to tell them that your time here was worthwhile. And all of those reasons that people give for participating in open source, that is not why your company cares about it. Your company cares about making a profit. They care about serving their customers and making their customers happy. They care about making a profit. They care about retaining employees and they care about making a profit. And so see just most of the things that you want to persuade your manager about. Now, of course, I'm not talking about your manager. Your manager let you come here. And so obviously they're awesome. My manager is the president of the Apache Software Foundation. So when I talk to him about open source, he gets it. He understands it. But his manager is a brilliant person who knows a lot about product marketing, not a lot about open source. So when we talk with her, we need to make sure that we are communicating. Now, as I was writing this talk, it started coming across as how do you lie about what you do in order to persuade your manager that really you're working for them. That's not what I'm talking about at all. Because open source is primarily about pragmatism. It's not solving problems in ways that work and collaborating with people in ways that work. But the way that we talk about it tends not to communicate that. We talk about how fun it is and how we like hanging out with our friends, which is true. But again, not what they care about. Now, the other thing that I want to mention is that different open source projects are different. They're weird. They each have their own unique culture. And some of them have unpleasant people as maintainers. And so maybe the things that you try to do in open source won't be successful. So don't think that the things that I'm saying here are in promise. It's just sort of that you need to speak the language of management. This is about translation, translating the things that you're passionate about into things that your management will actually care about. And like I said before, it's important that these are things that are true. You know, we're not trying to we're not trying to pull the wool over management's eyes so that we can go and play with our friends. So remember that open source is above all practical. It's objectively a better way to build software. And this is supported by study after study. Open source software has numerous advantages. We just need to talk about it in ways that convince our management of that. And in order to do that, you need to think about what's good for the company. What's good for your customers. And so, you know, I work at AWS, one of our catchphrases is that we are aggressively customer focused. Everything that we do is about doing what is good for the customer. And so you need to know who your customer is, right? Well, like when you're giving a conference presentation, you need to know who your audience is. When you're building a product, you need to know who your customer is. So you can't just go and hide in your office and write code. You have to understand what your customer is. You have to understand what you're delivering to them. And that's part of what's in it for the company. Another thing that's in it for the company is the cost. What does it cost to develop software? Does open source help that? Maybe it does. It depends upon what particular part of the industry you're in. Another thing that open source gives to your company is reputation. And so that's one of the other things we'll talk about. Now, rule number one when you're talking to your manager about open source is don't get bogged down in philosophy. They don't care about the distinction between free software and open source software. And you and I could talk about that for two hours, and just scratch the surface of it. Your manager does not care. And if you start talking about that, their eyes will glaze over and they will cut your budget. So another thing that they don't care about is license. They don't care whether your software is Apache or MIT or AGPL 2, 3, or 4. It doesn't matter. What they care about is whether it serves the needs of the customer. The other thing to remember is that you have a minute. You don't have two hours. You don't have the opportunity to say, what you really need to do is go read Eric Brayman's Cathedral in the Bazaar and then get back to you. You have a minute. You have the time between two floors right in the elevator. And if you cannot communicate during that time, then you have missed your opportunity. I remember one of the earliest open source conferences I went to. Richard Stahlman and Miguel de Acasa were discussing the relative benefits of open source versus free software. It was just high glazing. It was there was no point that came out of it. Except when Miguel said, if we have this conversation in front of our management, they're going to fire us. What we need to focus on is the solutions, the problems that we're solving. So so what are you going to talk to them about? Some of you all said some of the people in the survey said that they're interested in giving back to the community. Your company is not a charity. They are not interested in giving back to the community. Management sees open source typically as a renewable resource. It's this free thing out there. We go at harvest. And then we build our product with the harvest. And your attitude that open source contribution is a moral obligation or for the greater good, or something like that comes across as complete nonsense. If you don't tie it to a business benefit. So giving back the way that you should instead talk about this is the supply chain. Your manager read a book last week about the supply chain and software bills, bills of material. And they're they're anxious to talk about that, because that's actually relevant to their business. Now, if you are building a product on top of an open source project, that is in your business's best interests, that that project is healthy and sustainable. So if that project is hosted at the Apache Software Foundation, maybe you should consider sponsoring the Apache Software Foundation. If that project is at the CNCF, maybe you should consider having one of your engineers working full time on that upstream project. These are ways that you can sustain the project so that your business is around next to you. It's not just about downloading the version that was released yesterday. It's about ensuring that there will be a version released next to you. And so talking about getting back to the community, it sounds very philosophical, talking about sustaining the supply chain, so that that little red paper doesn't break next week. That's that's what's of more interest to your manager. obligatory xkcd and you've seen three times already this week. If you are working on this project here and it fails and your business is a thing about up on top, you might be out of luck. support these arguments with data. If your product is based on open source, then you can say 73% of our profit is directly related to the success of this project that you haven't heard of until last week. But if we don't contribute our fixes back upstream, then that portion of our profit is at risk. So this is a quote here from that's actually not a quote. It's a made up press release. But if you can say something like this, Apache Commons is a critical component of our product. And that product earned us this much profit last year. And if that project fails, our company fails, data is your thread. Sustainable open source is a project that's around next year. You have to think long term. So things that you need to think about in sustainable open sources, are we building this project? Are we building our product on top of a project that is developed by our competitor? Is that a problem? Maybe we should go be more participating more in that project so that it's not a single vendor project. Are we building our product on top of a project that is maintained by one engineer who lives in the Czech Republic and is unemployed right now? Maybe we should hire that guy. And then also maybe we should devote an engineer to that project. So that it's not just that one person, but it's two or three people that are supporting this so that maybe that engineer can take a vacation and not burn out quit next month. If we participate in this project, then we are by proxy making our customers heard in the roadmap for that project. That sounds important. These are all aspects of sustainable open source projects. To make sure that your stakeholders are heard when they're discussing what's going to go into the next version, rather than just waiting around and hoping that maybe that next version will fix this bug that we care about, because it won't if you don't participate. All right, another reason that people give for participating in open source is earning merit and reputation. And I'm probably the only person in this room old enough to have seen that movie. So maybe that's not a good screen there. But it's from a movie called The Breakfast Club in the 80s, where these two individuals were vying for reputation in school. But your manager doesn't really care about your reputation in open source. So instead, talk about earning trust and influence in the project. So for example, if you are building a cloud based solution based on top of Kubernetes, and there's a bug that's affecting your customers, and you go and complain on the mailing list, you're going to get ignored if they have no reason to listen to you. So if you participate in that open source project, if you have an engineer in your company that is contributing actively to that project, then your company will buy by osmosis gain a reputation within that project. And they'll be more likely to listen to you when you complain about a particular bug. So this is a way to convince your your manager that participating in that project is actually worth their time and their money to invest in that. You should be careful when you participate when you try to participate in open source, that you actually understand open source culture. It can be dangerous to talk about how your project, how your product is built on top of an open source project. And then the people in that project say, this is not somebody that participates. This is not somebody that contributes. They're just they're just benefiting from our work. And you know, this is a problem with many big companies, not naming any in particular, that build their products on top of open source software, and then go out and talk about how they're an expert in this field. And then the community comes back and says, no, they're really, they're really not. So you need to be careful that you what one of the phrases that I use at work is be don't seem, which means don't pretend that that you're that you're great in a particular open source field actually be that way. Go do the work put in the time become an expert, contribute and earn that reputation be don't seem. Also talk about adoption. Slide in my on I need to pick up the things just a little bit. Talk about how the adoption of an open source project benefits your company that's based on top of that open source project. If you have expertise. So what we found at AWS is that people don't choose AWS. What they do is they choose a technology. And then they go and they look to see who's the best at running that technology. Is it Google Cloud? Is it Azure? Is it AWS? I want to run Kafka. What's the best place to run Kafka? Is it Confluence? Is it AWS? Let's look and see what the reviews say. But first I've chosen Kafka. And so you need to talk about how participating in open source builds that reputation, which then drives adoption. Alright, here's a fun one. We love to talk about collaboration. I work at Amazon. And if I work on this project, I'm going to be collaborating with Google. And management says wild earth would we want to benefit our competitor? So what your manager hears is that you're going to lose control of your product by seeding that control over to a competitor. Instead, talk about focusing on what your company excels at. So again, I work for AWS what we excel at is infrastructure and scale. You know, we have some people that are working on Kafka and they're they're good at it. But that's not what we sell. What we sell is the man chose it, right? So talk about and so making commoditizing the software allows customers to build and test home on the software that they can download and use for free. But what we're selling is not the software what we're selling the service. So this this notion of loss of control is is a bit of a sidetrack because it's not about controlling the software. It's about influencing where it goes based on your customers. But everybody's customers have similar issues that they're trying to solve. And that's not what we're doing. All right, some of you all said that you do open source because it's fun. Open source is an endless party. I get to travel around the world and hang out with my best friends. And I've been doing that for 20 years. And it's awesome. And I'm very careful not to say that to my manager. Instead, talk about recruitment. Talk about how participating in open source makes your office a great place to work. And that makes it easier to acquire the best employees. Your company doesn't mind you having fun, but it's not really what they're there for. Now, the flip side of this is make sure that if you hire someone with the promise that they will get to work on open source, that they get to work on open source. Because if you hire someone and then retake, hire someone and say, you're going to get to work on a patch of airflow all day every day. And then when they get there, you say, but you know, actually, what I need you to do is spend the next six weeks solving this JavaScript problem over here. They're going to tell all their friends, and it's going to be harder to recruit people. So make sure that you make good on your promises. Note that open source people, whatever that means, can be very opinionated. They tend to lean towards being archaic and libertarian. It can be difficult to manage. They want to go and do their own thing. So make sure you understand what you're getting into when you hire open source people. But they're also very creative. I mean, look around you with the brilliant people in this room. It's really a great opportunity. If you let people work on open source, it feeds that creativity. It gets the best of the world's engineers to work on your product. You know, one cool thing about open source is that no matter what company you work for, the smartest people in the world work somewhere else. And if you can get them to collaborate on your product, then you're winning and they're winning. Another thing that people often say open source is good for is building your resume. Your manager is particularly not interested in you building your resume. Instead, talk about continuing education. I can go work with some of the best engineers in the world on a piece of software. I can learn from them and someone else is paying them. This is really, this is a really win-win situation. Now, one of the other things that your manager might think is that open source is free. And I like to say it's free as in free puppies. When somebody gives your kid a free puppy, that is not free. Be very cautious about talking about open source as free or cheap or reducing costs. You know, it might, but those costs go somewhere else. The software is free. You start to hire people to maintain it and to build it. So instead of talking about customer value, open source builds better software. Software is easy. People are hard and you want to ensure that you are investing your people in the right kind of development. And I am almost out of time. But you want to, you want to avoid letting your management think that they can just go grab a piece of free software, bring it internal, make the changes that they want and then sit on it forever. Because that means that they have to maintain it forever. So make sure that your management understands the right way to interact with open source. And that's basically my day job is helping management understand the right way to interact with open source. Let's see. Yeah, I'm out of time. Does anybody have any questions? I can talk about this literally for hours, but does anyone have any questions in my last one minute? Yes. How do I have the conversation about getting them to open source something that I've created for internal use? So the question is, how do you get your management to agree to open source something you built internally? And it's really hard. You have to be able to demonstrate. So first of all, you need to know why you're open sourcing it. And you need to have an answer to that question. And that's going to be different for every project. And there are many reasons to open source something. The other thing you need to be able to convince your management of is that you're not giving away the secret sauce. And in order to do that, you need to understand what your business is. And so this is what I was talking about earlier. AWS doesn't sell open source software. We sell the services on top of that. And so you need to be able to clearly communicate that the software is not the value and that the collaboration is only going to enhance that. But yeah, it's a hard conversation and everyone's different. You need to make sure you know your own reasons first. There is someone over here. Yes. Yeah, it's just values now for, for, I would say software, but the, the fact that you cannot do that. I mean, I, I, I just try to get a full of all that. Because now, like, oh, why she's one of all that. Yeah, that's cool. Yeah. That is a very large question that we don't have time for. But yeah, I mean, you know, again, it's, it's always going to be very, very dependent on a specific type of project that you're working on. But I don't know, maybe take that after this is completely out of time. Any suggestions for the managers? So what I would suggest for the managers is that they attend this conference. I mean that very seriously that they attend this conference or if they're in Europe, that they attend FOSDA or if they're in North America that they attend the open source, the Linux foundation's open source summit. And the reason for that is that open source is 75% culture and, you know, 25% software and understanding the culture and the collaboration behind this, understanding that when you get into a room with people like this, you hear weird presentations like the one that you gave that open your eyes to something that you hadn't really thought about before. That's, that's really, you know, that's not something that I would have studied on my own, but attending your talk, my eyes were open to something that I had sprang in, right? And so attending events like this, I think is the answer. Thank you so much.