 Hey everyone and thank you for joining me today for my session here at the open source strategy forum I hope you're all safe and well wherever you may be now. I'm so thrilled to be here. I've got a bit of a soft spot for Finna I think they do they do really really important work and they used to be a client of mine and the people who work in there Who are doing this work are just fabulous people. Okay, so this is a great event I'm so thrilled to be playing one tiny part of it now today I'm going to be talking about how to build open source in locked down environments Okay, there's a little bit of background for those of you who are unfamiliar with who I am My name is John a bacon and I am a community strategy consultant So I work with with with a variety of companies from small early kind of early-stage Startups through to very very large businesses like Santander Deutsche Bank, Sony mobile Samsung to help them to build effective communities and a large chunk of the work that I do is in helping Large businesses utilize open source effectively and contributes to open source projects effectively and This is often a bit of a tricky challenge and one of the main reasons for this is that open source is complicated You know, it's not a particularly simple Concept to wrap your head around especially if you are in an organization that is large that is command and control driven You know whether the the you know the directives come from the top and then they kind of sprinkle down through the ranks open sources is Is is more decentralized and operates in a very very different way So a big chunk of this is kind of bridging these two worlds together So what I wanted to talk about in this session was some really practical recommendations for how you should think about Building open source and helping to be successful with open source inside of a lockdown organization now This is going to apply to a few different areas the recommendations I'm going to provide today will apply to if you're an organization that wants to contribute code into an open source project That's outside of your business for example Or if you want to build open source projects inside of your organization, which is known as inner source Okay, so everything I'm going to cover today is going to apply to both of those different contexts Now the tricky thing here is that when people think about doing open source and do an open source Well, they tend to think about this right? They think about code that it's all about understanding how code is created and all the different pieces from how you write the code How you deploy it how you test it all these different elements of the of the software development lifecycle Well, that is true with open source You do need to be able to understand how to build code to contribute to an open source project as a developer However, within the context of really understanding open source, especially in businesses. It's all about culture and workflow Okay, it's not just about engineering because open source communities really are you know First and foremost communities who then develop code Okay When you talk to a lot of people who contribute to open source communities the thing that they cherish the most is the Communities that collaborative group of people who work together to create software that is gonna be better than any one of them could produce themselves Okay, so where this becomes complicated is that you're really talking about bridging many many different cultures You know, you've got people such as this guy Linus Torvalds, you know Who is all about the community and building software that everybody can utilize and then you have people such as this guy Who is for the intents and purposes of this conversation is business dude, okay? He cares about driving profits delivering growth for his business Okay, you know, if you look at if you look at him He is very very interested in the health and the vitality and the sustainability of the open source project This guy is very much looking at it from the perspective of his business So how do we make sure that these different worlds come together? Well, what makes this a little bit more complicated is that in the business context you it's not like you don't operate in a Network, okay, but you are one critical piece of that network and you really look out for your own best interests Okay, if you're a business you're looking out for your your business's best interest And then you you want to play well and be a good citizen within the business world that you operate However in the open source world, it's a little bit different because there are many other Organizations that will be playing a role that you'll need to work collaboratively with in many cases in open source You get for example Two or three or four companies many of which may compete with each other collaborating together on the same feature On the same piece of software because it's going to benefit all of them So the dynamics not just the code is complicated and how the code is created But the dynamics of all is pretty complicated too However, the good news here is that there are a lot of opportunities and there are some Challenges, okay So if you if you understand how to do this Well, you can you can develop efficient or productive engineering You can lower the costs of software acquisition and deployment You can become more efficient. You can gain it gain all kinds of insight and experience You can diversify the level of participation innovations happening in your organization You can have a real impact and staff And in terms of you know their impact and their level of empowerment, you know As a general rule engineers love working on open source projects And then building personal relationships and growth and just that network effect But there are some challenges, you know, it's confusing in how you get started with this It does challenge that command and control culture You know, if you manage and run your own software project inside of a business, you're in charge But if you're participating in open source, you're participating in the commons It's a little bit different and then of course there are fears of failure and the sense of lost investment And it takes a while to really see the the fruits of your labor when you start participating You know, it's it I've met with lots of companies, for example Where people will start contributing to open source projects and then four or five or six months in they'll be saying like Why are we doing this? What is the value that we're getting out of this? It takes a little while for them to really understand and see that broader value because sometimes it takes A longer period of time for that value to manifest And then sometimes you just get people inside of a business who just don't want to do it They don't think that open source is valuable They don't see the point of it They don't see why that we should be investing in it and therefore you get those internal blockets as well Okay Now what I want to cover I you know when When tosher and the team reached out to me about speaking at the event Um, I really wanted to deliver something that was going to be very practical in nature So I'm kind of setting the stage now But what I really want to dig into are five recommendations About how to do open source well and then three pitfalls that I think you should focus on avoiding. Okay So let's dig right in The first recommendation here is getting clarity on your goals and the current state So what I mean by this is looking at the future state. What do you want to achieve? What do you want to get to which are your goals? And then being aware of where you are right now and being reactive to it One of the biggest problems I see with companies who I work with Is they don't have an accurate view of their current state of their limitations But also the potential that they've got and then they just kind of say well I just want to kind of participate in this open source project I want to just publish some code and they don't really have any crisp reasons why Or they don't have clarity on the broader value that they want to get out of it Okay So the first thing I'd recommend is sit down and look at the goals that you've gotten your objectives and make sure You're clearing them. Is it about reducing your overall infrastructure costs? Is it about increasing the security of your deployment? Is it about collaborating with other companies to create something that will be too big for one individual organization to create, for example So think about what those are draft them down get feedback on them get input on them And make sure that all of your stakeholders the executives the developers are involved in this are clear in why we're doing this You don't want any ambiguity The second element is to really get a sense of what's required in terms of in terms of resources You know, how many developers do you need on a project? How many docs writers, you know contributing to open source isn't just about writing software It's about creating documentation. It's about creating tests. It's about It's about testing and deployment And you know all kinds of different pieces that kind of glue together And then of course, even if you just contribute to the project Then how do you bring that software back into your organization and deploy it within your product to your service? Okay So think about what's going to be involved in that and then assess like what is your open source experience inside of the Business right now, you know, it may be none in which case you're going to have to think about how to develop that experience and kind of Build the necessary skill to be able to participate And then also what is the level of support or opposition? And this is a really really important question really evaluate Who's on your side in terms of working with open source and why are they supportive and to what extent do they have support? But more importantly who is against it who's going to stand in your way They may not state that they're going to stand in your way But the main fact we stand in your way and you want to figure out how those people are because it's not about squashing them down It's about building alliances And what's the thread that you'll hear throughout the rest of my talk is the way in which we make change happen Is that we understand that people are going to be our biggest critics and then we we turn them into allies That's the way in which we make the right kind of changes. Okay All right, so a second recommendation here. Let me just let me just reiterate this before going Seriously clarity on your goals and the current state. You can't do any of this without focusing on that first All right, so the second one is really building a very clear open source workflow So as I mentioned earlier on open source is incredibly confusing I mean, I've been working in open source now since 1998 so 22 years and I find elements of it confusing Let alone, you know, someone who doesn't come from an open source background Who's brand new to it and open source is more complicated now than it was when I got started It's it's just confusing. Okay The solution to that is to understand the different pieces that are involved in the process And to develop a clear workflow for how you engage with a project So the first element here is going to be the legal requirements. What is necessary to be able to participate You know, can you work on software that has that license? Can you sign the contributor license agreement, you know and assign some kind of copyright? Okay Are you able to meet the needs of the open source project that you want to contribute to in some kind of manner? Okay If you're working on an internal open source such as an inner source project Then you need to determine whether you can create that with whether you can build that internally Even if it doesn't go outside the walls of it, you need to make sure that you can legally do that Now, I can't think of many reasons why you wouldn't be able to do that internally But you want to check that anyway, but then think about the workflow of code Okay, so if you are going to contribute to another open source project If you've got a branch How do you how do you how do you contribute it? You know with most open source projects, for example, you'll you'll take a copy of the code You'll make your branch and you'll submit it as a pull request It'll get reviewed There'll be comments in the pull request with anything that you might need to fix Once it's ready to go in it then gets merged into the main branch That's a workflow So if you determine that that's the way in which you're going to be working with the projects that you're targeting Document that so people internally can understand how to work with it. Okay Because the biggest one of the biggest drawbacks of open source is understanding of how all these pieces work together So if you want to do open source well in a lockdown environment You're going to want to make sure that you're making it as easy as possible if you're a staff to understand how to get started The same goes for issues. How do you how do you submit issues? What kind of things go into issues? Is it bugs? Is it defects? Is it security issues? Is it feature ideas? Is it wishlist ideas? Make sure that you define that and get that clarity And I'm going to be talking a little bit about training later on but getting that workflow clear is really important You know to use a little bit of a comparison about Two years ago I hired my assistant Mindy and one of the things that people had recommended to me in bringing a new assistant in was uh that you create essentially document how you like to operate so for me it's you know What what you know my preferences in terms of travel and my calendar and And publishing my podcast and various other different bits and pieces and I learned through this process That if you document that workflow even for someone who comes in who has no idea about it As long as they've got that available and they can refer back to it makes it much easier for them to get started I'd heard horror stories about people who hire assistants And it takes them months to get spun up because they didn't document it So that's why this is so important and the documentation doesn't have to be a War and peace it can just be you know single pages of documentation internally on your network Off you go. Okay The other thing that you're going to want to get clarity on is going to be communication making sure that your Your staff and your team understand how to communicate within the open source world and one of the things I'd recommend Is that they always look first? You see there's a lot of Unwritten rules in open source Ways in which we engage and we collaborate with each other And there's just some cultural norms like there's any cultural norm You know the culture of walking into a pub on a saturday night in ireland Is very different to the culture of walking into a museum In london on a thursday night. Okay, we behave and speak and and operate differently And it's the same thing with going into an open source project So make sure that you're clear on the communication elements as well How to communicate effectively and and go in there first of all look watch listen read And gradually you'll get a sense of the culture and then start participating And it'll be much easier to get started Also, just as a general rule, especially when it comes to inner source building open source internally in an organization As a general rule, you always want a default to open one of the biggest challenges with doing inner source Is that you've got a company that operates with a command and control kind of methodology that's so used to A very small number of people making decisions and defining requirements And then it getting distributed to other people who then make those changes Whereas open source is different, right? So if you if you build an internal open source project and it operates like a command and control project It's not going to succeed So for example, I work with a client one time and they wanted to do inner source And they didn't have an internal github or gitlab where everybody could access these different projects and start participating That was the first thing that we focused on and when we did that it made it much easier for all the other Lego bricks to fall into place All right, so let's move on to the third one and this is really really important There are a lot of organizations who I've worked with that could very easily Do great work with open source. They've got the skills. They've got the expertise internally in certain pockets They've certainly got the talent and the skills and they've got the time and they've got the permission But they don't succeed because they don't put the necessary training and recognition in place Training and recognition are critical in anything that we do If you want somebody else to deliver a predictable set of behavioral patterns Which is what we want to do with open source that we need to train them in those behavioral patterns, you know It's just like kids like My wife and I have got a seven year old and if we want him for example to Unload the dishwasher Then we need to teach him how to unload the dishwasher and when he should do it and how to do it right and not to balance glasses on the edge of the Countertops and things like that. We need to do the same thing for our teams as well So first of all system systematize that workflow that we've already talked about what I would recommend is that you create a series of playbooks So these are basically Okay, it can be a powerpoint presentation a libre office presentation Whatever it might be it could be a google docs presentation or google's google sheets. No google What is it google slides? That's the one It's been a long day and it's uh 10 to 10 at night. So yeah, it's been a long day to give me people um But basically what you do is you you formulate into a short set a small set of slides um The necessary training pieces how to do code well, how to do issues well How to do communication well in open source and then what you do is ideally you record a little bit of a video Just share your screen kind of like what i'm doing right now and going through some slides And then provide a bit of training in that form. So people got access to the video training That's a great way to get started But also have somewhere that people can go and ask questions So have an engineer or a couple of engineers or someone else It could be an internal like an open source programs manager of Leader or it could be somebody else who can answer questions people are going to be have questions It doesn't matter how much training you've got or how good the training is people are going to have questions Things that they need to figure out So have a place where they can go and ask questions It could be one on one or it could be an internal forum or an internal zen desk whatever it might be But then the key thing is always delivering regular recognition The very first time you have an engineer submit a pull request that gets reviewed and merged in You should be you know popping champagne corks right or the equivalent of what would be appropriate for your organization You need to make sure that that person is celebrated as recognized for breaking new ground You know people celebrate when they literally break new ground when they're building a building. Okay Do the same thing here think about the perks that you can apply to your organization when they start achieving these new things One of the things I write about in my book called people powered This is what's called submarine incentives And this is where you detect when somebody does something and then you celebrate them by reaching out to them So for example Detecting the first time somebody submits an issue that gets resolved or the first time One of your engineers fixes a bug in a public open source project Or the first time somebody contributes a bit of documentation to an open source project Or the first release of of an inner source project that you make internally in your organization Recognize it and reward it. Okay. This is one of the most wonderful elements of open source Is that it's really fulfilling it's really rewarding to participate in open source people love doing it again Like I said earlier on it's not just about the code the code is one tiny piece about why people love open source People love open source because of the community because of the sense of meaning because of the sense of accomplishment because of the sense of purpose And if you can bring those similar principles that have driven open source for 25 30 years into your organization Then you're going to see those same kind of patterns with your staff members as well This is where it's all about culture. This is what drives me crazy when I work with some clients where They only look at it from a carving code perspective is that carving code is important But it's building the culture the recognition providing the skills and the education to succeed that will help you to do this well, okay All right The other thing that I just want to touch on here, which I think is important And again is a mistake I see a lot of companies making is that when they do open source They kind of go in with their sleeves rolled up and they Bite off a massive project and they try to get started with that and while I admire the enthusiasm and the gusto When we try to do anything new it's much better to start small and to get quick wins Okay, just to start with something small and and and and And get some success there now this is important for two reasons one is that one is that it's going to I'll just hold my finger up and I realize you couldn't see me in the camera So one the first good the important reason is that it gives you an opportunity to just start doing okay There's a there's a time for preparation and there's a time for doing okay, so reading books and watching seminars and Going into training courses and interviewing people about your open source approach methodology is one thing But at some point you've got to start just doing it and I'd much rather you start doing it and making mistakes Than read every conceivable piece of education and guidance and documentation And try to do it perfectly because it won't be perfect But the second reason why this is important is to make mistakes Okay, it's to make mistakes and figure out what those mistakes are and then to win to do something Right to to get that very first pull request merged in okay What that does is it builds a sense of confidence and builds a sense of achievement. That's really really important So focus on first of all building some internal software like building your internal branch that you want to contribute to an open source project And then navigating the code submission review process Navigate how to communicate with these projects and then iterate and improve too many businesses They don't start small They focus on a massive chunk of code and by the way most open source projects don't like massive code dumps They want someone to start small And build manageable code because it's not going to be perfect So that gives the the project an opportunity to kind of refine and I'd apply the same principle to Inner source as well, you know with inner source projects start small Just even if it's just a tiny little project that adds a small integration start there Start getting contributions from your other colleagues and engineers and then you'll start seeing the results start flowing And then the fifth one I just want to really summarize very quickly before we get onto the pitfalls is about regular reporting you see um There are going to be many different stakeholders in a company who are going to be interested in your open source strategy Whether it's inner source or whether it's contributing to external open source projects One is going to be your teammates It's going to be people who are on the same team and people who are On on related teams. So if you're on an engineering team, it could be your other engineers and developers Um, but it could also be people on the product team or people on the customer success team Or it could be people on the community management team or the dev rel team So the first thing is to provide simple cross team updates. Okay focus on On just updates about what's going on what you're working on and the success that you're seeing I like to recommend that you do this as bullet points in an email Do it once every couple of weeks and share that with people So someone can read it like they can grab their phone and you know within five minutes They can get a bit of an update on what's going on and they're off to the races But also do the same thing for your executive and your stakeholder teams. Okay If you've got for example of a vp or an svp of engineering or a cto giving them Just a simple plain text email every couple of weeks with bullet points of what's going on, you know accomplishments roadblocks Insights that you're seeing is incredibly valuable. Okay. We we don't have enough information sharing in many businesses Okay, information gets hollowed out into silos and that's one of the reasons why we can't we have any problems in businesses So definitely focus on that. I think it's going to be really critical. Okay Okay, so let's now get into some pitfalls now This is a half an hour talk and I can't necessarily, you know, go into every piece of detail with everything Okay, if you want to do that, you should Reach out we can talk about maybe working together But um, I did want to cover what I think are some really really important pitfalls to be aware of The first one and it's kind of an inverse of of starting small and getting quick wins Is to learn to walk before you run um One of the things I think is fascinating about getting older Um and just kind of doing the same thing for longer is you see Similar stories manifesting in different areas and similar principles And one of the things I've seen a lot of is companies to get really excited They come into the open source world with a big bang and then before you know what they've gone and they've gone after a year and a half two years and and some of these companies are never quite fully trusted or embraced because It's too much too soon. You know, it's kind of like meeting, you know Meeting someone's boyfriend, you know for the first time and they're too flashy and you're thinking What's going on here? Okay Learn to walk before you run. Okay. So this again is about starting small But think about your engineering workflow. Just learn the basics get started with how to write good code How to how to submit it how to get it reviewed all of those different pieces Learn about the collaborative workflow about how how pull requests are reviewed about the role of issues About the relationship between discussion on issues and pull requests and in slack channels Okay, the only way to really do this is to immerse yourself in it And there's kind of two areas to focus on here. There's the community culture. So that's being a part the project And the great news about open source is that we document our history Everything that we do in open source projects is documented, right? If you go into any project in github, you'll be able to see how the code was written the discussion around the code The issues that were considered to varying degrees. You'll be some open source projects They're really good at that kind of documentation some that aren't but as a general rule You can see how the project was formulated because you know, when a pull request gets Emerged into the main branch, for example, it's not like it gets a vanish from the banished from the internet It's just you know, you got to go and dig it up to go and go and look at it Okay, so go and learn go and go and listen go and learn But then there's also the company culture is if you're learning to how you know how to to adapt your company to Um to the open source community if you push too hard, then you'll get some pushback Okay, so just take it step by step in understanding how the company's reacting people liking it people against it People nervous that they're fearful those kinds of things if you'd go take it step by step and importantly set expectations that you're going to learn to Walk before you run that is important because if your stakeholders are expecting you to go a million miles an hour Then it's not going to work. You're going to get you're going to get better results The second pitfall here is that plans don't mean action There's been many times when I've worked with companies where people are nodding and are agreeing in the middle of a strategy session But at the end of the day until you can get people actually doing the work It doesn't mean anything. Okay, and the way in which we get people to To to build new habits and to build new skills is to be collaborative Is that they play a role in shaping the project? You don't go away as the subject matter expert and craft the plan Is that they play a role in helping to design the plan as well? So, you know Include them in how you're going to define that workflow in how the training is going to look In what the goals are going to be in how you're going to recognize people and what the reports look like Gather their feedback and be reactive to it. And the thing here as well is is to say to people I want to be in support of your goals. Okay, and I mentioned at the beginning of this session That the way in which we affect any kind of change Is that we identify the people who are with us But also people who are critical of what we're doing and not really convinced and we support their success as well I remember one time working for a company and the head of marketing was not a fan of building communities at all She saw it as a complete threat. So I kind of sat down with her With a coffee one day and I was like, tell me what your goals are like, what do you want to achieve? Because I really want to get a sense of how we can pursue those goals Even if you're not convinced by community, I want to make sure that I'm in service of your goals as well There's a wonderful author who's in the marketing world called Seth Godin and his philosophy is If you're in service of other people, you'll get better results. Okay You'll good things will happen to you if you serve the success of other people and I think that's absolutely true And also, you know provide mentoring and support You know, if you've got people who aren't really sure in terms of what they're what they're doing It's one thing to kind of have a plan and people people start building open source technology and open source code But providing that mentoring and support to them even if they're critical I think is a good way forward And then the final pitfall here and I've just realized my numbers are the wrong way around that was three That's one one three two Hmm. I think I should have reorganized these slides my friends The final pitfall is what I call I can convince them Uh, and I've seen this time and time again and I was guilty of this where If you're watching this you may be thinking, okay, I know what I'm doing when it comes to open source I'm working in this really lockdown slow moving organization And um, you know, I'm the expert they should listen to me and I can convince them It's just a matter of time before I get them on my side. Well Convincing people doesn't work. Okay, unless you're brilliant at convincing people. It doesn't work What gets people to change their behavior and to change their their their habits Is when they can see And feel the benefits themselves. Okay, you know, it's one thing to for example I'll give you an example. Which doesn't sound like an example, but it is if you describe virtual reality to someone They can kind of get it like oh, yeah, I get the idea if you put a helmet on and you can kind of see this virtual world and you can look around it And you can even convince them that this could be really useful in lots of different environments But it's only when you put that VR headset on that you really get it when you feel it when you experience it It's the same thing here as well. People usually make three arguments when it comes to Convincing they either say we should be doing this because this is ethically the right thing to do I see this a lot in open source but Ethically open source is good for the world. It's good for humanity. Therefore, we should be doing it People don't like to be lectured about ethics. So that usually doesn't work The second approach is that I've got more experience in you and I know more about it I've got more expertise and therefore we should do it because I know more about this and you should listen to me Again, that doesn't work people don't like to be lectured and patronizing that regard And then the final argument is often the energy argument and that is, you know, let's do it I'm really excited about this. This is gonna be amazing. This is gonna be fabulous. We're gonna rock the world and That kind of energy is infectious and many people love that kind of energy But it feels dominant. It feels pushy to some and and it varies culturally like a lot of Americans are like kind of like Yeah, you take that kind of energy to japan or you take it to norway, for example You're going to get a very very different kind of response. Okay different kinds of energy So these these kind of convincing approaches don't tend to work from what I've experienced What what works is start small develop a bit of a, you know, simple workflow provide the right kind of training Recognize when people, you know, break new ground to get the first pull requests in that are successful And then bit by bit what you're going to find is that you're going to be able to penetrate into understanding the open source community Deliver great work or build in the source more effectively. Okay. Anyway, that's it. I hope that was useful I hope that was, you know, got the kind of the wheels turning I'm a complete open book if you've got any questions about this that you think I can help with Drop me an email to johnno at johnno bacon.com I always love to hear from people who watch my presentations or videos or read books or read my books or whatever But a complete open book. So let me know if I can help and enjoy the rest of the summit Okay, bye-bye