 Good afternoon, how's everyone doing? So my name is Jared Smith and I want to talk today about how you can create a culture of sustained contribution within your company Before I get into too much introduction though. I want to talk just a little bit about how thrilled I am to be here in Hong Kong It's a pleasure to be here and I've had a great time in the last couple of days here in the city and Really looking forward to the rest of the week Anybody know what this Chinese symbol on this hat represents? The lights are a little bright, but I don't see if somebody raises their hand. What is that? What does that symbol stand for? as I understand that that's the Chinese symbol for good luck or good fortune and I feel pretty lucky to be here today. How many other people in the audience feel lucky? I See a couple of people that feel lucky. That's good. It's always good to be lucky I think I'm about the luckiest person I know And I'm gonna tell you why just really briefly here Because when I started my career, I studied electrical engineering got my degree and I thought that was that was pretty cool And then I got the best job in the world I had to be a programmer and I could really make make things happen with code And that got me into systems administration. I thought wow, that's really lucky. I get to play with big big things set up servers in the data center That got me into lots of networking and I thought oh, that's that's the best job in the world I get to play with networks and see how things packets go from one side to the other and how things route and all kinds of fun things Then that got me into voice over IP and telephony and that was kind of a mixed bag but I still felt pretty lucky because I got to help write a book about open source voice over IP platforms and Have a lot of fun doing that ended up teaching training classes and doing consulting on voice over IP for a number of years And then I got really lucky because red hat hired me Asked me to be the Fedora project leader and help wrangle about Pins the thousands of volunteers Who helped contribute to Fedora in a number of different ways whether that's writing code packaging software Writing documentation doing QA translation, you know design a number of different things and I thought that that was just the luckiest job in the world and then I got hired by Bluehost and I have the best job in the company my job is is director of open source outreach is to Reach out to open source communities like the open stack community and others and really support them in in fun and interesting ways whether that's through sponsorships whether that's through speaking at conferences whether that's Writing code, you know pushing code upstream helping organize events those those sorts of things so I really am the luckiest person in the world and That's really good and that brings me to why I'm here today at the open stack conference to talk to you about building a Culture within your company of giving back to open source and contributing to open source The reason I went through that that series of slides on just how lucky I am was just to show you that in each one of those jobs People kept asking me the same question Can anyone guess what that question might be? They keep asking me. How did you possibly convince your boss to pay you to work on open source software? You ever heard that question before? Well, I've heard it a lot and so that the topic of my talk here today is You know is to share some of the things that I've learned About how to really create a culture of contribution inside of an organization Anybody recognize recognize this guy. I Wouldn't recognize him by by the picture if I didn't already know the picture This is a guy by the name of George Wallace George Wallace was one of the co-founders of the London School of Economics and in 1926 he wrote a book called the art of thought and in that book he He wrote out a methodology for for what he thought was the perfect method for helping the creative process when you're trying to think through a problem When you're trying to solve a problem What's what's the process you need to go through to be your most creative? And that that creative process that he came up with really has a has four steps And so I'd like to go through those over the next few minutes and talk about what those four steps are and apply those to this Problem of well, how can I convince my boss to let me contribute contribute back to open source? And then build a team within my organization that contributes back to open source So the first step is preparation makes sense right you need to be prepared before you go ahead and and start your down the road The second is incubation you need to give it a chance to start to grow start to flourish start to develop With that will come illumination. You'll start to have those aha moments. I said, oh, yeah, that's that's what I need to do that's that's how this is going to go and Last but not least we get to the implementation phase where we actually get to go do the thing that it is you're trying to do And so I'm going to take the the next few minutes and talk talk through these four steps in in a little more concrete detail about how to give back to You know to open source and really build that culture with it in your organization I think one of the most important things especially during the preparation phase is To Think not just in terms of oh, I've got this patch. I want to contribute it back upstream But to think in terms of connections one of the things I absolutely love about The time I get to spend in open source communities is the the connections that I make the people I meet the events I get to go to Absolutely a lot of events like like this and and other open-source conferences and I as much as I like the the talks like this The design sessions and those sorts of things. I really also enjoy the hallway track Because I like making connections with people. I like you know sharing ideas I like bouncing ideas off of other people and see their reaction and so From the beginning when you when you start going down the path of trying to build a A team of contributors within your organization think about connections and what connections they're going to make both inside your Organization and obviously on the outside in the greater open-source community another thing that I'll I Think is very very important that you go down this road is to prepare yourself from a legal standpoint Make sure you understand the nuances of you know, how does copyright law apply to open-source code? How does trademark law apply to open-source code? How does patent law apply to open-source code and those as much as we as developers often want to say I don't want to have to worry about that. I don't want to have to lead deal with the legal team You know, that's that's just implementation details. I'll get to that later I Found through through lots and lots of experience for both good and bad that having a good strong understanding of the legal aspects of Software development really really helps Especially when you're talking with you with the executives in the organization when you're talking with the legal team If you can talk in their language that really helps so it's going to take a little bit of study It's going to take a little bit of work, you know for you to really be prepared You know to talk on on those terms, but it will help you as you build your team Now let's talk a little bit about the incubus that incubation phase And I had to put a cube on the screen a little verbal pun there, you know the incubation Phase when you start to say, okay, let's let's start let's get a project together Let's let's make let's make an effort to try to get this pushed through. Let's and Contributed back upstream Do I happen to have any Canadians in the room by chance? I think we had a Canadian earlier if he was on stage But I think he's he's left the room. All right, anybody recognize that that logo by chance It's for the Hudson's Bay Company out of Canada. Anybody know what the Hudson's Bay Company is? so the Hudson's Bay Company was founded by King Charles the second of England in the year 1670 and it was a company specifically set up for for doing trapping and fur management of animals in North America, Canada and the north northern part of the United States And it's the longest continually running Corporation in the in the Western Hemisphere, so it's it been an active existence since 1670 When the the members of the Hudson Bay Company were out doing their trapping and catching their furs They often had to carry everything they needed often for months at a time with them And they were often wandering through the wilderness all alone or in small groups And so they had did they really had to make sure they had all the supplies that they would need for that those extended periods that they were out on there you know on Going through the wilderness looking you know trying to trap animals and that sort of thing So they had an interesting methodology that they used when they started any new big Venture the very first day they would get up in the morning. They would get all their gear together They would hike down the road maybe a mile maybe two miles just a just a short distance And then they would stop and they would set up camp and they would try to have camp set up, you know before noon Then they'd get all their gear out test it all make sure it was working that way if they forgot something Or they realized them their gear wasn't going to work. Well, they could always hike back the two miles back into town Buy or borrow or steal whatever they needed and then and then make it back to camp that day So they made always just made a very very short for a the very first day Then the second day they would go on and do a normal a normal-stay journey And I think we can use the same thing whenever we embark on a new project whether it's a new software project or or something like continuous deployment like the like was in the last presentation or Or if we're rolling out a new piece of software Anytime you can try to just make a small Incremental step that very first step just to test the water see how the gear goes see how the equipment works See how the the business processes work. That's a good thing So I recommend that if you're if you're actively trying to contribute back to an open-source project that you make a small step the very first time and that brings us to to step number three Which is the illumination phase and probably one of the hardest phases in this whole prospect In this step, this is where you have to go convince your manager You go have to convince the CEO you convince the legal team to to let you work on open source now Maybe you're lucky in your organization that you know gets open source and and it's not that hard to convince them to let you Do that but in many organizations That's that's simply not the case Either either they don't have an understanding of open source or they don't have an understanding of why it would be important to contribute back to to communities of practice like that and so this is your chance to You know reach out to the executives reach out to the legal team and explain why it is that you want to contribute back Now the very first thing you need to do is need to speak their language They often don't speak, you know source code language. They they often don't speak, you know Geek to put it bluntly, but they you know typically a business manager. He's gonna speak Finance that's his language of choice, right? He's gonna look at this in terms of dollars and cents and he's gonna ask you Oh, if you're spending your time contributing back to open source, how does that make me money? Or how does that save me money? Right, so what what's what are the kinds of of responses? You might have to that question to help him understand that there really is some economic value and Value in general and contributing back to open source What are what are some of the ways you might you might help convince him of that? So we'll talk about that first the first thing I typically do when a when a when an executive asked me Well wife, you know, why should I let you work on open source? You know, what's what's the the economic benefit to that? It's to talk about infrastructure And ask what does it cost for us to reinvent the wheel now? How many people in here are software developers of some sort or another? How many people in here are systems administrators? Or integrators those sorts of things quite a number So how many times have you gone out and written a piece of code or gone out and Build a system only to find out that somebody else has already done that and they've already done it better And you should have just looked at their stuff in the first place I'll admit I can't tell you how many times I've done that probably you know I can count five or six times just off the top of my head and so You know you can ask the executives that you can ask your boss You know if we keep reinventing the wheel or if we go pay some vendor to reinvent the wheel for us and then find out It's the wrong size wheel What does that cost us both in terms of time and in times of in terms of money and so That's you know, that's the first thing is kind of structure The other thing you need to explain to your boss is that you know participating in an open source community is a two-way street It's not that just I'm taking my time And and using that give code back to the community, but you're taking back from the community as well and Typically in open source communities because the cost of copy and reuse of code is is fairly inexpensive almost free Then you know you almost always get more than you then you give back simply because you know It's the economies of scale there. So so think of it in terms of you know structure infrastructure tooling Most of the times you're in the business not of building scripts or writing programs or or that sort of thing You know you're in the business of web hosting or you're in the business of selling services to your customers Or you're a restaurant or you're a bakery or or something like that, right? Your expertise as a as an organization is typically not in you know running an IT team It's in delivering what you deliver to your customers And so anytime you can not have to reinvent the wheel not not have to You know build everything from scratch. That's a that's a good thing The second thing I typically talk about with with executives when they're asking why why contribute back to open source has to do with Employees labor costs labor costs as you all know continue to go up and up and then you know are typically a major part of a of a business owner's budget and if if labor costs are tight then Why wouldn't you want to do something that either increases the value of your of your current employees or encourages more employees to want to come work for you and so Typically I see that when when a person participates in an open-source community, they typically have a broader vision of the both of the technology that they're that they're dealing with but also a You know a broader Set of communication tools because they're used to talking to people whether it's via email or mailing lists or forums or IRC chat they they typically are better communicators Because that's that that's the way they interact with people. It's not always you know face-to-face communication You know, I also find that typically you can use you know This opportunity for maybe you've got some junior developers or some junior admins You want to help you know bring them you know up to speeds a little quicker. You want to help them? You know be be more valuable as employees and that participation in an open-source community is a great You know a school house so a way for them to learn and grow and stretch and develop and And that really participation in open-source communities is a very low-cost training program oftentimes for helping them get up to speed I see too many times business Managers look at an employee or hire an employee simply on what they know now and Not necessarily for what that person is going to grow into over the next six months or a year or two years or five years Taking that attitude of you know, we want to make our employees the best the best we can is Often a very good thing So that's that's kind of the language that that I typically use when I'm talking with with the business leaders Talking with the legal team is a little bit different. They speak a different language It's not English. It's not code. It's not financed typically They speak this language and I'll give you a guess as if you can figure out what what that's called Some of you have played this game before what's this game called? It's called risk Right, this is this is this is the language that attorneys typically speak And so typically when you're when you're speaking with the legal team about hey Can we contribute this code back to open source? Can we participate in this open-source community? Can we take you know and launch our own open-source community around some of our code? Typically the answers you're going to get back from them are not based on you know rational thought They're not based on you know, is the code awesome or not? It's not based on you know Will this save us all kinds of money? It's it's based on risk And typically you know participation in an open-source community, you know the risk is fairly small But the attorneys like to you know check those boxes off and and go through the thought process of analyzing The risk and figuring out what those risks are The other thing that I've found through experience is that typically attorneys like to hear this sort of a of a message From other attorneys So if you can find an attorney that's up to speed on open-source law And and get them to talk to your legal team that often helps There are groups out there like the software freedom law center Or the free software foundation or other groups like that where you can have their attorneys talk to your attorneys Since they all speak the same language and help, you know, I'll lay some of those fears You know help them understand what those risks are and And move forward that way. I've been very lucky at At bluehost in that our legal team Both you know understands open-source and is very Happy to see us contributing back to open-source It was very very refreshing when I started working there to see that they really got it and really you know Understood those risks and not only we're willing to take on those risks, but we're we're You know, we're willing to help support those of us who in the company who do contribute back to open-source because it's a big part of what we do as an organization All right, so now we're on to step four Which is the implementation phase and this is where you actually get to dive in and actually do the do the real work, right? So I have a number of slides here that I want to go through To talk about you know What are kind of best practices as you go through this and actually start the the work of contributing back to An open-source community or are trying to build an open-source community around a piece of code I will warn you that this is a lot of work. It's not simple to do. It's not something that's that's trivial I put this slide up here Because this is I have a favorite chinese proverb that says Talk doesn't cook rice Right, so what do I what do I mean by that what I mean is that We can talk about what what's the best practice and what do you need to do? But oftentimes people take shortcuts oftentimes people don't really want to you know Go through all the steps necessary to do the hard work to contribute back in a proper way So here's some best practices that that I've seen throughout the years that that help with that First of all Figure out what your what your measurement metric is going to be. How are you going to know whether you're successful or not? How is your boss going to know whether you're being effective or not? How is the legal team going to know, you know, how are they going to measure the risks that are being taken? If you don't set those things ahead of time, it's often A little surprising when you get to your year-end review and your boss doesn't know whether to give you a thumbs up Or thumbs down for your work because there's no metric there So I strongly encourage that you think about what metrics do I want to use to either, you know Measure our contribution or measure the community that we're that we're building those sorts of things Another thing that I I see way too often is that an organization says yeah, we want to we're going to take this code And we're going to make it open source and what do they do? They take a snapshot in time. They package it up. They throw it over the wall A nothing happens And I've seen that time and time and time again And that doesn't really build an open source community. That doesn't often help a community Because Contribution to a community is more than just lobbing a a piece of code over the wall and hope You know hoping that it's useful for somebody I was I was Asked to come in and do a little bit of consulting a couple of years ago on a on a A government-led project in the united states um to do with To do with veterans affairs and health care information for veterans And it was amazing to me that that that the managers over this project absolutely got the concept of open source They wanted to make the code open source But they didn't want to have any kind of a feedback loop. They didn't want to accept patches from anybody They didn't want all the great things that come with you know Building an open source community around around a piece of code What they really wanted to do is just have this code and then lob it over the wall and forget about it Not have to deal with the other aspects of Of you know maintaining a community having a feedback loop letting other people contribute back and help make your Your project better So let me let me ask a quick question How many people have you know work with really great engineers within their organization are really great developers are really great networking folks Anybody want to publicly raise their hand and say they don't work with really great folks? Okay, just kidding Um Oh, my co-workers are gonna get me now No, um One of the secrets of open source communities is no matter how great the people are within your organization And no matter how many of them you hire There's always smarter people on the outside and there's a whole lot more smarter people on the outside So I strongly encourage you to find ways to to build those feedback loops Find ways to let people outside your organization help you do your job better And help you solve your problems faster. So don't just lob code over the wall try to build bridges instead of walls um Another thing that uh that comes to mind Especially as I've been in the in the summit here this week and talking to some of the open stack developers And in particular to a couple of the technical leads Is the difference between strategic contributions and tactical contributions Now I think it's an easy trap to fall into as a as a developer to say I'm going to go solve that particular bug or I'm going to go add this feature Or I'm going to fix this little thing so it's more efficient Or you know, I'm going to go write this piece of documentation so other people can can help us You know understand how this you know piece of code works Too many times we get focused on the individual tools or the individual bugs or the individual features kind of the tactical side of things And it's often helpful and refreshing to take a step back and try to help out with strategic contribution Um, I can't tell you you know how many times I've talked to people in in in big software projects like open stack Where the the kind of the core maintainers say, you know It's great that so-and-so is working on his little driver over here And so-and-so is working on his little piece over here and and george over there He's working on his little piece over there, but I wish they would take a step back and look at the broader picture of the project in contribute To things that help the project overall and not just the one particular aspect that they're they're focused on And I know I can understand that sometimes, you know If you're a you're a software vendor and your software needs to work with another piece of software You're focused on that interoperability But that doesn't mean that's the only place you have to contribute to that project Please take a step back. Take a broader view and try to help the the the projects overall Um, honestly, I don't know what this map is really meant to meant to to be other Other than somebody had a big strategy about how to map out parts of north america and connect it to europe I'm guessing it's some sort of network map or something from the 60s But but it made me think there's some strategy behind it, you know Take take the strategic view even while you're in the trenches and working on those tactical things You know don't don't don't forget to take a step back and look at the broader view Another thing that I strongly encouraged You know companies to do is is find someone who who kind of has the passion for open source within the organization who really gets it and can communicate that well and I'll point them as either the the open source officer of the company or you know Or the or the lead of an open source committee within the organization So that when people are contributing open source code when people when they're questions that come up from the executives or the legal team That they have somebody to go to to get the right answers And try to avoid the problem that we often have a fear and certainty in doubt when there's not one person that That has a clear answer to to some of those questions And this is one of the things we've done inside the blue host in our our parent organization is Is is come up with some some open source policies and an open source officer to handle these sorts of things So that everybody knows where to go to get it to to get a question answered and you know when when contributions happen That we can also take those and market those and kind of highlight the work that we're doing inside open source communities So that's a that's a very valuable thing to do This also helps helps lead you down the path of creating an open source policy within your organization And again every organization is going to be different on what level of you know Policy they need but you know, we all know how the attorneys are we all know how the business leaders are They like to check the little boxes and make sure that everything is in order They like meetings So, you know have a monthly meeting or a or a bi-weekly meeting or maybe it's a meeting every three months Just depending on your organization get the people who are enthusiastic about open source together Have a chance to ask questions, you know build a policy around contributions And then get signed off on that from the from the executive team Um In in in our case our our open source policy is is very very easy It's if you want to contribute back to an open source project make sure your manager knows about it So that he can say yeah, yeah, that's okay to contribute and make sure the open source officer knows about it So that he can highlight that inside the community and inside the company And make sure that those things are being highlighted and then and then you're good to go I've been in other organizations where it's a slightly more formal policy But either way, you know come up with what works and and build a policy around it so that you can apply that consistently Last but not least I want to leave you with a a little bit of an analogy And if you can't tell from my slides, I'm I'm really a visual person. I I really like photography I I like capturing people's attention with the you know with images that I put on my slides And I heard a really really good analogy a couple of months ago that applies to photography But I think it also applies to Some of the things I've shared here today And that that analogy is that in photography Amateurs worry about gear Professionals worry about billing and invoicing and and where their next client is going to come from And masters worry about light And I think that that analogy fits really really well with creating a Corporate culture of contribution to open source and that amateurs are going to worry about the exact mechanics of you know, how do I You know, how do I contribute? What do I what policy do I need to pet me a check off? You know that sort of thing, you know professionals are worried about okay What's this going to cost me to let these guys contribute back to open source? And masters are going to understand the light of open source the the really why do we you know The philosophical reasons of why we contribute to open source and why that's important And so your job during this You know really during the illumination phase and then during the implementation phases is to really help people see that Light and then be be you know be almost like a mirror of reflecting that light and capturing that light in inside your organization So with that, uh, I wish you all the best of luck in in in your endeavors I've left a few minutes at the end here for questions So, uh, we'll open it up for questions. We'll see if we can track down a microphone Otherwise, oh, it looks like there's a microphone in the in the middle of the In the aisle there if you've got a question. I'd be happy to answer questions for a few minutes Don't be shy if you've got a question. Please step up to the microphone Oh question right here So the question was in my experience is the is community contribution Typically written into the job description for the for the team members For some of the companies I've worked for absolutely it is So I've had the the opportunity to work for a voice over ip company that was all about open source Like I said, I had an opportunity to work for red hat, which is all about open source Blue host is very much an open source oriented company in all three of those those cases Either my job description or or co-worker's job description actually did have contribution to open source as a major piece of the job description In in in a couple of cases. I've got two full-time developers who report to me who their entire job description is Contribute back to open open source and upstream communities. They're not even focused on what our needs are internally in the company They're focused on what is the upstream community need So yeah, that's that's not typical But but I have seen that and it really really helps because then you have a good way of gauging are those people Not only helping us, but are they helping the greater good? And I'm helping helping get the company's name out there inside these communities to to highlight the good work that's being done What what kind of key performance indicators do you have on those? It depends on the individual and and the role So for the for the two people the two developers that report to me The way I I judge their performance is by following the upstream community and seeing are they active in the community? Are they participating in the meetings? Do I see them participating on the mailing lists in the forums? Are they submitting code patches? Are they doing bug triage and the bug tracker? Those sorts of things in other communities. I've been in it's been measured in you know How many how many lines of code did you contribute back to that or how many meetings? Did you participate in or you know are the features that you're working on being accepted by the greater community? Those sorts of things it just it really depends on the individual You know open source project that you're working in and and what the you know What the business needs are around that interaction with the open source community? Question right here in front So the question is in the hosting industry in particularly what are my predictions Around you know the communities and and and what's coming next and those sorts of things You know, I really hate to make predictions, especially on stage I think you know in general I would say that you know that you know hosting is it is an industry where In in general there's there's a lot of people that that still don't understand why they might need hosting And so I think it's a wide open field for you know more and more businesses to get their their You know their business online more and more people having a personal website for for whatever reason You know blogs and those sorts of things. I think you know I think it's a it's a pretty interesting time to be in the hosting industry right now and Luckily, you know my my job isn't to focus on you know growing the business or anything like that I get to focus on taking care of our customers and taking care of open source communities Predictions beyond that. I'm not really at you know liberty to to to to venture a guess on question over here You're gonna have to speak up. I can't hear you What what is in my experience is the best way to adverse advertise an open source product You know open source marketing is a is a whole ball of wax that's very very difficult and it's fraught with danger Too many times people try to use traditional you know marketing techniques in an open source community And those usually fall on deaf ears And so I would be very very Hesitant to to use the traditional marketing techniques, you know advertising, you know paid sponsorships those sorts of things I think word of mouth is the number one way to get your you know to get the word out about an open source project I think doing things like building easy tutorials documentation You know Meetups, you know video presentations, you know youtube videos those sorts of things are a good way to help get the word out About your project to help people get started Typically with open source projects that at least that I've seen over the last several years It's not a problem of of getting people to know hey that you've got this project out here and here's how it works It's helping people get to that next step of I'm actually installing the software. I'm actually trying the software Oh, I'm learning how to use the software. I know look now. I'm contributing back I'm participating on the mailing list or the forums or oh, I wrote a patch or now I'm you know Now I'm contributing modules those sorts of things Word of mouth is very very important and people you know people in the open source communities tend to be you know Make snap judgments. They'll they'll download a piece of code and if they can't get it working in five or ten minutes That goes ah, this is garbage. I'm gonna move on to something else And so anything you can do to lower those barriers to entry again, whether it be you know You know documentation tutorials You know You know quick start guides those sorts of things to help them You know get get their feet make get those first two steps into the community That really really helps great Other questions we've got just a couple more minutes for for questions I'm sure you don't see any other hands out there Well, if there's no other questions, thank you for your time best of luck in everything you do in open source