 My name is Rich Bowen, and I currently work on the open source group at AWS. I've also been around the Apache Software Foundation for about 25 years and I'm currently serving on the board. And a lot of us live at that intersection between passion for open source and trying to keep your job. And some of you, I think a few of you were in a runes talk before this and he talked about this some as well for the past nine years. Well, previously to joining AWS for nine years. I was at Red Hat and talking about open source at Red Hat is easier because theoretically everyone there knows and believes in open source. And so when you're working for another company, you have to start developing strategies for how you talk to management about open source in ways that they will hear. So ideally you are interested in the success of your company. You're not just there to have a good time or work on your pet project. You want your company to succeed because that in turn benefits you. And correct understanding of open source is a long term investment in the success of your company as well as in your own career. So this is some of the some of the things that I'm going to talk about. And this leads to the question of why do you do open source? What are what are some of the reasons that you all got involved in open source? Anyone have some some thoughts on that? Don't be shy. All right. Well, some of the some of the common reasons that people come up with when asked this question in surveys are because it's fun. It's something that I do for enjoyment. It's a hobby or I want to solve a problem that I personally have with a piece of software that I've been using. I want to make it better for myself. But a lot of the other reasons that we hear are things like socialization, making friends, giving back to the community. Some sort of sense of moral obligation and maybe some in some way making the world a better place for those that come after us. This this graph here is from a survey that was conducted by open source dot com several years ago and the the top reasons that are listed here are to learn something new career development resume building. Fun is another one that that that got a high ranking here and altruism was the third thing that got a high ranking here. And one of the great things about this event and some of the other events that I attend is there this this great opportunity to sit around the campfire with friends and make new friends. We all have stories about our management that really just doesn't understand open source and we like to laugh about that around the campfire and it's it's a sense of camaraderie and a shared experience and this is absolutely not why your company is involved in open source and so keeping that passion alive while also doing the things that keep your company alive is kind of critical to those of us that like to to pay our bills. So a little bit of clarification when I say doing open source this can mean obviously a wide variety of activities. It can mean contributing to existing projects or it can mean taking an internal project and making it open source and whatever the reasons that the company has for doing that are are varied and nuanced across different businesses. Or it can mean consuming open source as part of either your tool chain or just as a way to do daily business. So these are very different things that that a company might mean by doing open source. Now I should mention that because you're sitting here in this room and presumably your manager supports open source in some way they've sent you here for a for some sort of purpose maybe they thought through that purpose or maybe they haven't. I I'm aware that not everyone has a manager that is as deeply involved in open source as mine is my manager is the president of the Apache Software Foundation and so he he really gets open source at a deep level and has been involved in open source for 20 some years. The guy that was on stage right before me Arun Gupta he's been he's in management at Intel and he's been involved in open source for 20 plus years and those sorts of people are heavily represented at this event. But not everyone is as lucky in management as I have been over the years. So you have to be able to speak their language. The other disclaimer that I have is that open source is weird and each project is weird in its own unique way. Oh by the way this is my my wife and my goddaughter wearing tinfoil hats so they're weird too. But just just to mention that nothing in open source is a guarantee and just because you can do everything right if you follow all of the cultural rules of open source that project can still fail your your contributions might not be accepted. You might not mesh with the particular weirdness of the projects that you care about because as you all know open source is part culture and part religion and part science and part law and part ego with a lot of language and time zone and network like latency thrown in. And so it's it these these things are not guarantees. But like I said when you're talking to management about open source you must speak their language. And when I was when I was writing this presentation it occurred to me that I might come across as saying you should light and management about your motivation so that they'll let you do what you want to do and that's that's really not what I'm saying what I'm saying is that open source is above all a practical pursuit. A lot of us do it for fun and a lot of open source projects are not business oriented in any way. But a lot of open source is there because it's objectively a better way to build software. And doing what's good for the community is doing what's good for the customer because there's an overlap there. And I'm definitely not telling you to lie to management about what you do and why you do it merely to understand where they're coming from helping them to understand where you're coming from and that those things serve a mutual interest. So what's in it for the company well it would be it would be reductionists to say that companies only care about money only care about profit. They also care about recruiting the best workers. They care about serving the customers. They care about building a reputation and a lot of companies actually care about making the world a better place about leaving a legacy leaving something for the coming generations that's better. And so I don't want to say it's necessarily all about money but that is at the heart of business. The reason that a business continues to exist is to generate a profit. So when you talk with management about open source the first thing that I want to encourage you not to do is jump straight to philosophy. This book that I have here I I hugely recommend that you read it it is a bunch of philosophical essays by luminaries from the early open source movement and there's actually a second edition of this book as well with another set of essays and these are these are great essays like the Cathedral in the Bazaar and Larry Wall's got something in there about the attributes of a of a of an open source revolutionary. There's discussion in here about the nuances between free and open and this is not what you want to talk to your manager about because their eyes will glaze over and they will try to figure out what this crazy hippie is talking about when I just want to talk about business value. Certainly not in the first conversation anyway certainly not in your five minute opportunity with your CEO in the elevator up to the top floor. So these these are conversations to be left much later if you if you focus on these deep philosophical questions in that first conversation you will have lost your opportunity to speak with them again. Don't spend a lot of time talking about the nuanced differences between open source licenses. That also is a much later conversation. And that will make them think that they are getting themselves into legal trouble and maybe this is a thing to avoid rather than to embrace. And certainly don't get involved in the jargon try to avoid jargon when you're discussing open source with management that's not deeply familiar with the community because we use words in open source in ways that the rest of the world does not. We use terms like upstream that make people confused as to whether you're talking about software or fishing and that is a distraction from the core point. The other thing I want to mention is that you have a brief you have a very short period of time at the beginning of conversation to convince management that what you're saying is worth their time. They've got another meeting that they need to go to next hour. They just came out of a meeting and they have a lunch date with an important executive from another company. And so you need to make sure that you understand your own message. You need to make sure that you know the core message that you're trying to communicate and don't go rambling off on the deep details of the patch that you're trying to get into the kernel. If you spend that time discussing about whether it's free as in beer or free as in freedom or free as in puppies. Then again you have you've missed that brief window of time that you have to talk with this with this person whose time is valuable. All right. So philosophy the next thing that you want to do in open source is to give back to the community. You are you're you're building something. Your company is relying on this thing in the Commons and so it is your moral obligation to give back to it. And I happen to believe that but that is not that's not really why your company is involved in this. Your attitude that open source contribution is a moral obligation or for the greater good or something like that comes across as nonsense to somebody who is trying to run a business profitably. Don Foster in a talk yesterday made the point that if you talk about what you do in open source as charity then that becomes the first thing that will be cut when there are budget constraints because we're running a business we're not running a charity and so we need to understand what we get for what we give. So what should you talk about instead you should talk about the supply chain. If you are building a multi-billion dollar business on the back of an open source project then you want to make sure that that open source project exists next year and if you do not contribute meaningfully to that project then you are simply taking and that gives that project no incentive to stick around. It doesn't keep its staffed. It doesn't keep the lights on. It is not because of a moral obligation. It's because you are trying to ensure the sustainability of the thing that you're building your business on. And if the open source project is that little paperclip there and you are not strengthening it then you might not have a business next year and trying to what one of the questions that we asked at AWS we have this concept of of I'm sorry I'm drawing a blank I always do this of open source projects that are strategic to the business and one of the questions that we ask in the strategic project process is what would be involved to replace this functionality if the project went away tomorrow do you have the staff or expertise to ensure that that functionality would continue and that your service would not fall over the next month and this is not simply a question to help to say you should hire more people that's part of it. It's a question to help the team understand that they are making an investment in a project they should understand what's involved in keeping the lights on there and be participants in that. Be ready to demonstrate with numbers to your manager how this project is a critical part of your product and your supply chain don't just say all we use this library somewhere in the code help them to understand what percentage of your profit comes from this open source project how you're you're not simply giving back out of moral obligation but in order to sustain your supply chain. Also remember that this is long term thinking because it can look in the short term like you're wasting your time working with a project that is humming along quite happily it looks healthy why should we be concerned you should be concerned because next year and the year after that the things will change around this project and if you are not involved in directing that change then it's going to happen in ways that you do not anticipate or desire as part of this don't be afraid to tell scary stories. These logos here if you don't recognize them are heart bleed and meltdown inspector these were highly publicized bugs in security related open source software a few years back and they cost the industry many billions of dollars and each one of them happened because projects that were critical to the entire world supply chain were maintained by a handful of underfunded people now as a result of these scary stories these particular projects are now much better supported both financially and with developer power then they were when these problems happened log for shell is another great example of it that is more recent in people's memories the project that was maintained by a relatively small group of people and so didn't have a lot of attention on it but was critical to the projects and products of many or even most of the companies across the world. And you need to be involved in projects that you are relying on otherwise you don't get a say in how it happens and you don't have the insight into whether there's going to be a catastrophic failure next week. I would caution you to communicate that in each one of these cases the problems didn't happen because they were open source and they were in fact fixed faster because they were open source and so that the focus here is on the lack of community engagement rather than on the fact that they were open source now I'm sure you've seen this this cartoon a hundred times this week the emphasis that I want to make here is that your company is one of those things that's teetering up on the top there and if you are not actively involved in shoring up the tiny pieces down at the bottom then you are risking your in your company's future on your inaction so we are all in this together I would encourage you to focus on data your manager wants data they don't want your speculations about how open source is a fun community good they want data that maps the success or failure of that project to the success or failure of the company and aligning that with numbers preferably profit numbers is an important part of this message that will ensure that they get the message and understand that this is not optional let's see sustainable open source is a topic that other people have spoken on at this event and each one of these bullet points is an entire other presentation or indeed another conference as a whole but one of one of what I believe to be the core values of a sustainable open source project is that there are multiple voices involved if there's only one voice involved then that project will only reflect the values of that voice not the values of your company or of your customers only the values of that that voices customers and community so you want to make sure that your stockhold your shareholder and your stockholders but your shareholders your your stakeholders is the word I'm looking for there are all heard in the conversation around this project you know the obvious the obvious statement here is that single vendor projects are only about that vendors priorities and if that vendors priorities change at some point then you will be left out of that conversation we've seen a number of examples over the last couple of years where an unimportant open source project has been controlled by one company and that company's that company's priorities have changed they've changed the license or they've stopped supporting it at all and the project has died leaving the rest of us to scramble to fill that hole in our supply chain and of course single maintainer projects are even scarier for the same reasons but more so you know every time that that we discover that one of our one of our service teams is relying on an open source project that's supported only by one individual in their spare time we strongly encourage them to either get involved in that project or if they're unable to that they find something else to fill that hole one thing that has become evident in the last to you in the last year is that Ukraine has a thriving open source community that has been greatly harmed by the news of the last year the war and we've seen a number of situations where we have had to either help somebody get out of the country in order that that project doesn't die or you know find some other and this sounds like a very selfish way to talk about it but this is what your management wants to hear how are we shoring up our supply chain based on the uncertainty of the world alright another reason that people give for getting involved in open source is to earn merit and reputation and to stoke our own egos I see that there's a few people in the room that are old enough to have watched the breakfast club when it came out and of course these were two individuals in there that were very concerned about their image and your company is not interested in you being popular in open source projects that is not a priority for them so you you want to do these things on it's a it's a very common reason that people give for getting involved in open source but what you should talk about to your manager instead is building trust and influence in projects that your company depends on because if you have that influence in that project then you are able to steer that project in ways that benefit your company now I don't want to encourage anti-community behavior in projects also this can be really dangerous if your company does not understand open source social norms and so if you are not familiar with how to correctly behave yourself in an open source community this is the building to be in there's people here that can tell you about that make sure that you understand that you spend time steeping in the culture of the open source project to make sure that you are behaving in ways that are appropriate and are going to not alienate you and do the opposite of what you're trying to do in gaining trust don't claim that your company owns or invented or drives an open source project because that is not something that the rest of the community will find to be terribly encouraging to them be very it's it's perceived as being very dismissive of the other players in the project if you claim in your marketing we're the ones that drive this project and I know that sounds very ham-fisted but I've seen that kind of marketing even at this event where companies say we are the driving force between Apache thingy or whatever it is and that is never well received by those of the company community that don't work for your company and then also there's no guarantee that your contributions will be accepted or that your your your country your presence will be welcome and so be careful about promising too much to your management about what we will be able to do as soon as we get in there and start changing this project because that might not happen and this is as I said before a super long-term investment Arun mentioned just a few minutes ago on stage here that that the things that we do in open source today we'll see the fruit from in three years and your salespeople don't think in those terms they think about the next quarter's earnings report and so being very clear in communicating that we are making long-term investments you know you need to be careful about that messaging with management so that they understand what they're getting into your customers often will see and this this is something anecdotally I don't have a survey to reference but our customers tell us that leadership in open source projects is a reason to trust the company and so if somebody is looking to AWS for a managed Kafka service for example which we have they look for leadership in that community and say these people know what they're talking about they're not just they're not just taking somebody else's thing and running it they are also playing in that same field and providing leadership and direction in that community so they understand the pains that we feel as a customer also talk about driving adoption healthy open source communities encourage adoption of services based on those projects or products based on those projects because they see those projects as being sustainable what one thing that we've been told repeatedly is that people don't come to in particular they don't come to AWS and then say what database should we run no they choose a database and then they look around for the best place to run that in the cloud and so we strive to be that but if you have a leadership position in a particular project then they'll say well maybe these people know what they're talking about all right the next thing that people say that they do open source the reason they do open source is because it's a lot of fun this is a photo from a conference that I attended in November in Nairobi, Kenya and a bunch of my new friends on the party bus and I've been coming to these conferences I think the first one I went to was in 1996 I come here to meet and hang out with my oldest friends and I am shameless about that to my manager that I want to attend this conference in particular because I know there's people here that I won't see anywhere else and open source is an endless party and definitely the source of my longest friendships and your company does not care about your fun despite what they said when they were recruiting you or in your onboarding that's not why you're there and so one of the things that I try to emphasize when we're talking about how much fun open source is is that my employer believes in open source if you come work for us you'll get to keep working on open source and this is a great recruiting tool it's a great tool for developer happiness I attended a great talk yesterday about improving the happiness of your developers which is not something that a lot of managers care a lot about but investing in the happiness of your developers keeps them around it keeps them productive it helps prevent burnout and being involved in healthy vibrant open source projects is one of the ways to keep developers happy a little warning here I have a colleague who last year went to work for a large company that told him that he would be working full-time on open source and that he could continue to work actively upstream and after several months of working for them it became clear that that was just a hook to get him in the door and they didn't mean it at all and he was not spending any of his time of working on open source and that is a really super fast way to both burn out good talent but more importantly I now know that I would never recommend for someone to work at that particular company because I know that they're dishonest and that they are taking advantage of the open source community to to meet their own ends and so you know be careful that if you make these sorts of promises that you mean them the number of people that I've talked to in the last 10 years who got a great open source job and then suddenly realized well you're only going to be working upstream when you have time after the more important things that we have for you to do it's truly discouraging because a lot of really talented open source people have been burned out that way let's see also if you are hiring open source people whatever that means whatever an open source person is one of the traits that I've seen among open source people over the years is that they tend to be very opinionated and tend to lean towards being a bit anarchic so it can be a little difficult to manage so make sure you know what you're getting into because open source people feel overwhelmingly that they know what is the right thing to do and they're going to do it and this is a valuable valuable personality trait but can lead to people that may be a little difficult to manage so know what you're getting into all right resume building resume building is an important reason that people get involved in open source and if you're doing this in college where you get involved in open source projects is a way to build your skill and make sure that you have a leg up in the business that's really cool if you're doing this as part of your job your manager might see this as you trying to simply use them as a stepping stone to your next real job your employer is very not interested in you building your resume so instead talk about continuing education talk about building your skill set talking about building the skill set of your team the very best way to become an expert in a technology is to dig into the code and become an expert on the technology not just to be a user not just to read people answers off stack overflow but to get in there and not only understand the code but also participate in inventing the next generation of the code making you the world leading expert on that talk on that technology rather than just one of the many people who read a blogpost and so I find this to be a very compelling argument for especially if you happen to be working for a software company like many of us do this is a very compelling argument for allowing people to work in open source because it is it's it's free training on the inner workings of that particular project now I say free and we throw the word free around very very loosely one of the things that you will hear from management that is not very involved in open source as well as an open source isn't it free you know don't we just get it for free we're allowed to use it however we want this is a free kitten that my daughter brought home from the park and now destroys our curtains and eats our food and you know gets in our hearts as well but but you know open source is free as in puppies a free puppy a free kitten is not free it is a long-term investment open source is every bit as expensive as proprietary you're just putting your your expertise you're putting your money somewhere else however that money that you're putting into that is building your expertise it is building your trust with your customers with those projects that you rely on and you're not just paying a bill to receive a product you are actively engaged in creating that project that product and so instead of sales emphasizing the monetary savings that go along with open source which are are real but nuanced instead talk about creating customer value when we're engaged in open source we are ensuring that the software that we're delivering is what the customer wants because the customer will tell us what their pains are and we can go solve those pains in those projects because we're involved with them because we have earned the trust of that community and our voices are listened to and presenting this to the project takes the form of saying well this this project is great but the customers have this particular pain with it and if they do then your customers do as well even if they're not telling you and as a community we improve that software stack together to produce something that solves everyone's needs so one of the phrases that you'll hear coming out of the mouths of people that work at Amazon is undifferentiated heavy lifting and this refers to the notion that the stuff that we all care about is the commodity it's the open source project we all work on that together some of it's boring but we want to solve the problems that everybody has so that we can focus on the thing that we do exceptionally well and you can focus on the thing that you do exceptionally well and this allows you to be very clear in communicating with your customers what your particular value proposition is and that value proposition is usually not the underlying software if you happen to be AWS that value proposition is large-scale and operating clouds if you happen to be Intel that is creating the the silicon that those things run on and it allows you to be very focused when you're selling to your customers so that they know what they're getting from you the other thing that open source gives is the ability for those customers to build and test at home and understand the technology themselves and then look at the vendor that best serves their other needs and then you can focus on being that vendor all right I am getting to the end of my time I believe there's there's a bunch of other things that you might want to talk to your community to your manager about because these are common things that we hear for management can't we just take this open source thing and fork it and run it ourselves well that's a whole other presentation because you know I know that some of you are aware of the pains of trying to maintain your own forked version of a of an upstream project another topic that comes up frequently is can't we just hire or throw money at the the person that one individual that's maintaining this project and perhaps you can this is a complicated question there have been several sessions about that at this event and there is no no one answer that will that will fit in all of these situations because money is not necessarily the reason that motivates that particular developer or team so these are all questions that you need to think about in the context of your company's needs and what projects you rely on and they will simply not have one simple answer the final thing that I want to mention is that this is a long-term investment this is my son finishing his first half marathon and it took him all year to train for that and that is now benefiting him in other ways he's now an assistant coach on a cross-country team and you know the analogy only stretches so far but investing in open source is not going to show immediate gains in your next quarterly profit report it takes a long time to earn trust in an open-source project it takes a few minutes to lose that trust it takes a long time to master a complicated project codebase it can take a frustratingly long time to get your your pull requests merged into a project and that's another entire conference talk what do you do when you when you you've promised your manager that we were going to have influence in this project and then it takes two years to get your first pull request merged that's it's a complicated question so what I recommend is to look around and have conversations here about the success stories that you can point to as places where people have invested their team and their money and their time in open source projects and how that has paid off in the long term because this is a long-term investment so that is that's what I had to say I hope that that was was helpful if anyone has any questions or comments please make sure you grab a mic because I'm deaf and we're streaming so thank you all for for coming