Talk: The top 5 InnerSource myths, Martin Woodward, GitHub

In this session, Martin Woodward from GitHub talks about InnerSource, what it is, and how it works within high performing DevOps teams while also explaining what you do to make it work in your company and talk about the problems it can’t fix.

Linda (00:04):

Martin Woodward is the Director of Developer Relations at GitHub, and he will talk about an intriguing concept called InnerSource. So how to create those open source style communities inside your company. And take it away, Martin.

Martin (00:24):

Hey, everybody. It's good to be here. Thanks for having me over your lunch break and we'll see how it gets on. Feel free to get up, walk around, definitely get some water and stay hydrated, it's very important. So thanks for having me. As I said, my name is Martin Woodward, martinwoodward@github.com where you can just, you want to send abuse to me, feel free, it's @martinwoodward on Twitter, so it's all good. And you say, we're just going to have some fun. Talk about some of the top five myths that I've seen around this thing called InnerSource as I've been working, as I've been sort of rolling it out across a few different organizations. And then some of the ways that you sort of get through those myths and all that sort of stuff. Yeah, we'll see how it goes. Hopefully it'll be a good little way to pass the lunch break while you're having something to eat and things.

Martin (01:10):

Now, what the heck do I mean by InnerSource? What, what on earth is this? Yet another buzzword. InnerSource is just the concept of sharing knowledge of skills, of code inside your organization using open source style collaboration. So what do I mean by that? I mean things like having permissive read access, so everybody in your organization inside the organization has read access to everybody else's source code, with very restricted write access. Just like with open source, the people who can approve pull requests are a limited team of people that are maintainers of that library. Inside the project as well, inside the organization, having permissive read access, restricted write access. So the community who's maintaining it gets to approve the changes it makes to it.

Martin (02:05):

And really kind of sharing knowledge, sharing best practices, sharing those little sequel scripts that are buried around on the DBA's desktop. Because we all know that these smart DBA folks and these smart sort of infrastructure people and SREs, they have tons of little scripts buried away that can do all sorts of magic, but sharing of those and sharing the best practices can take within them amongst the team is a great way of doing InnerSource as well. Typically, what we'll cover is actually how on earth, how does this relate to DevOps and the whole thing why we're here today, so hopefully I'll get that covered as well. Because inside organizations that I deal with and also inside a lot of organizations that are looking at implementing DevOps best practices we see a struggle of communication. And that's fundamentally what DevOps itself is trying to address in terms of bringing people together, enabling communication, enabling faster iteration and enabling lots quicker testing and quicker learning from production.

Martin (03:19):

And with InnerSource it's a way of breaking down those communication silos inside the organizations. We see typically in sort of large enterprise organizations, many of which when I had a real job before I came to work here at GitHub, we see a lot of these kinds of monolithic systems. There's little code reuse in those systems. Everyone's kind of got siloed knowledge and quite often code ownership actually kind of follows structural lines inside the organization. So I remember having conversations with people, especially when I've been looking to take some code and share it, or reuse some code inside the organization. You have to go talk to a VP or a CVP of something, because they're the person that owns that code. They're the owner because it's a system that's part of their company. And that's completely nonsense when you think about it, the people who own that code are the shareholders of the company. The VP, the team that are currently working on it, are just the current maintainers. And that will change over the life cycle of that project.

Martin (04:37):

So traditional enterprise culture with this notion of code ownership and this notion of very siloed communication doesn't really reflect the reality of how that code flows over time in the life cycle of a system. And we also see quite often in these teams that are beginning their DevOps journey. They are sort of focused on short-term gains, and they're not really focused on sharing as a priority for management. So, yeah that's kind of why we think InnerSource is a good thing.

Martin (05:13):

And if you look into sort of more modern engineering practices. So people who are heading towards DevOps and heading towards these modern engineering ways of working, we see a lot more innovation from all directions inside the organization. We see this culture, it's a term shift left, which gets used a lot in DevOps, doing things sooner in the process. We were just listening to a fantastic talk now about integrating security into your core DevOps practices. And so some people call that DevSecOps or whatever, but it's making security part of the core process earlier, not just slapping it on at the end.

Martin (05:55):

And doing everything earlier in the process at the most efficient time is part of the core way that we ship software, rather than just tacking onto the end, throwing over the wall to a different team, that sort of thing. And we also see in modern engineering teams and high performing engineering teams a culture of sharing, not silos. And we see that represented in the research as well. I'm fantastically privileged to work with a wonderful woman called Dr. Nicole Forsgren here at GitHub. And she was one of the authors of the very, very influential State of DevOps report. And in that report they point out the practices exhibited by these elite DevOps teams are exactly the same kind of practices that InnerSource and InnerSource culture helps organizations kind of lead towards. It's this creating of community structures of communities of best practice inside of the organization, of building these informal networks. And so all InnerSource is, is just an infrastructure, is just a way of working the backbone, which allows these communities to form.

Martin (07:15):

If you start sharing code, communities won't happen. It's the infrastructure that you put in place to enable these communities to happen, but you still need to encourage community building and community kind of sharing inside your company. By focusing on the maintenance of code and making sure everybody has a mindset of maintaining the code. They don't own it, they are maintaining it on behalf of the shareholders for a limited period of time before they move on to their next project. Or until this part of the project goes from active development into maybe sustain support or something like that. By encouraging that mindset, you encourage collaboration as well now, because people understand that they are the current maintainers, they're the people who currently are looking after this code and their job is to leave this system in a better state than they found it.

Martin (08:13):

But encouraging collaboration is what they're trying to do. And then by focusing on this building an economy of sharing inside of the company, you can encourage more modular less monolithic systems, and we'll talk a little bit about that. Again, just to bring in some data from Dora, but also from others, we see that higher performing organizations are twice as likely to have internal communities. So what I'm not saying is there's this correlation, there's not causation. If you have internal communities, if you have these internal networks, then you're twice as likely to be in a high performing organization. For these sorts of companies we're also seeing 200 times more frequent code deployments, eight times more likely to have security baked into their processes, just like we were hearing earlier. And a 100 times faster time to develop every environment creation sign. So we see these communities and we see them, and it's kind of a natural side effect of building some of these practices in.

Martin (09:21):

Now I've been working on different InnerSource roll outs in a few different places. The last place I worked before coming to GitHub was a small sort of cheeky startup in the Pacific Northwest called Microsoft. You might have heard of them, not many may have heard, maybe a few people have. And their infrastructure was they'd trying to put in a culture of sharing as they were going through their sort of life cycle. But they had lots of sorts of steps along that way where they did a site called Toolbox, which was actually a, basically it was a website where people would dump their projects and the source code for them. And it kind of allowed this discovery of, "Hey, here, I've got some code you might want, what do you think of this," kind of thing.

Martin (10:11):

And that eventually sort of morphed into a fork of a website that I used to maintain and look after called CodePlex, which was a kind of a much more, had a few sort of bits of code sharing kind of functionality in there, as well as just being able to dump code onto it. That then morphed into adding the ability to share their proprietary source control systems. So their source control systems that they use in-house, which at the time was Azure DevOps and Azure Repos. And the ability to share that with the entire enterprise was a big first step for them. But what they needed and what they kind of need to get to is a point where you can have this notion of cross the ability to do a fork and a pull request. And the ability to do forks and then pull requests is kind of like a key part of source workflow and also a key part of the InnerSource workflow. Because it allows you to go use a library and go work on it on your own, but also send that eco back to the thing you're trying to share with.

Martin (11:21):

An example of an application that was InnerSource over on that side was actually the Xbox Adaptive Controller from Microsoft that started in 2014 from Matt Hite, who was a Microsoft engineer who made a custom gaming controller. Sort of took that and kind of made it work. And then in 2015 when we did a hackathon inside the company in 2015 based a version on the Kinect controller and try to make it a more accessible controller. And then came back the following year in the hackathon in 2016 and worked with a different team of employees, about eight people this time. And they actually sat down and made this Adaptive Controller, did some thoughts. And again, this was just all completely InnerSource, completely like a group of engineers working together on a project during the hackathon. Which then has become a fully commercial product from the company and is helping people play games and helping people get the most out of their Xbox controllers and things.

Martin (12:24):

Now, as we move on, when we went into the sort of fork and pull request model, that's where we kind of adopted GitHub more. But one of the key products I like to point out inside of Microsoft that actually started out as InnerSource and then has now become actually open source is Visual Studio Code. So Visual Studio Code was originally an InnerSource component called Monaco. And then that became this massive open source editor now. So yeah, and there's a fantastic example because it's kind of like an editor control that lots of people are using.

Martin (12:59):

Okay, so I'm going to go through now and just kind of do our top five myths of InnerSource, of the kind of things I've heard about when people have had these problems. So let's do the first myth. So if we get a drum roll, please. I'll make some noises for you. So number five in the top five myths of InnerSource is that you're going to get free work. The magic code Pixies are going to come down and just, "I'm going to InnerSource something." And all of a sudden just magically I'll get free work and I won't have to write a team to go collaborate on this code anymore for me. And that's just not true. If you InnerSource something, you still need to pay people to work on it. It's not this magic free work machine.

Martin (13:45):

In fact, if we look at data from, this is actually from a Microsoft's internal systems, if we look at the data there, when we look at the number of code changes into a well-established InnerSource project, and this is across the whole organization, across a company that's well established InnerSource practices, 90% of the pool requests coming into that project actually originate from the team that are paid to work on that code. Duh, of course, because they're paid to work on it and it's work, and so that's what they do.

Martin (14:18):

But interestingly, 9% of the changes that come into that code base come from a nearby team, so come from somebody within the same org charts. Often actually the same building, maybe the same floor, above floor, below kind of thing. But they come from a nearby team and then only 1% of the code coming in is coming in from this magic, different parts of the org, bringing in changes. Because that's not the point. The point of InnerSource is not to get code changes from everywhere inside the organization into your code base. You can, and you do, and it helps. But the usual point of InnerSource is to share code in the organization and is to share best practices and then allow people to understand how you're working.

Martin (15:11):

So what I do very, very often is go to other parts of GitHub for example, and go see how they are doing something. How is the team that looks after billing actually doing things? I had a, one of my friends was having a query about sponsors, and rather than bothering people on support and rather bothering the sponsor's team, I just went and looked it up, figured out how it worked and went and helped that person use this particular part of the system, because I could go figure it out myself. So I could go answer my own questions.

Martin (15:43):

I could go figure out how we're using Kubernetes to do our deployments so that then I understand how to use it in my side of the application. I go learn a bunch of other stuff. And it kind of helps me identify the people who are doing these things. And then I can go hit them up on Slack. I can go join their Slack channels and we can have a discussion and it helps build these communities. It isn't about getting free source code from everywhere. And if we think about it, I like to think about what I call the contribution funnel. So inside a typical open source project, but also InnerSource projects as well, you have this notion of how the code comes together. The vast majority of people are just consuming your library. Are just coming in, taking a code and then never coming back. In fact, they never even told you they've taken your code. They've just taken it and they run with it, 99.9% of the time. And that's a 100% fine. That's what this is about. It's about sharing.

Martin (16:50):

But of the people that are consuming your library, a small percentage of them will come back and they will actually contribute time to you. They will give you some time back. They'll tell their friend about your library. They'll contribute some code back to your library. But you've got to remember, only people who are consuming your library and your application will give you time. And only people who are giving you time will actually get to the point where they're contributing code. And so you need to maximize every part of this funnel and then maximize bringing people onto the next stage of that funnel.

Martin (17:32):

So consumption. You need to make it easy for people to understand what this library does. Easy to find it. Easy to understand. Easy to consume it. Because only once they're consuming will they give you some time? And so it's a numbers game. So the more people you have consuming it, the more time you will get if you help people cope it out]. And then you need to maximize the number of people who would give you time by making it as easy as possible. So how can you contribute? How can you log a bug? How can you help with documentation? How can I get started in giving back? What are the procedures in place? Is there a standard way of doing this inside your company? Do you have standard infrastructure? You know, all that sort of thing. You're more likely to encourage people to contribute time.

Martin (18:16):

Of the people who give you a bit of time, you want to be as welcoming as possible to those people. Because only they are the people that are going to contribute any code back to your library. They're going to give you a book fix. They're going to give you a new feature, that sort of thing. Only a tiny percentage of them do, but they come from the people who contribute time. So how can you maximize the amount of people and the ease of which people can contribute code? Well, you make sure you document your prerequisites. So how easy is it for you to actually contribute to this library? How easy is it for me to get started with a development environment? You know, if you can spin up a development environment inside of a container and have it running instantly and then just go run, fantastic, that's the best place to be.

Martin (19:01):

But if you've got documented prerequisites, if you've got scripts so that people can get set up easily, all these things you do to help outside contributions also help you inside the team as well. And these are all, if you read things like The Unicorn Project and The Phoenix Project and things, these are all things that Gene Kim talks about in terms of helping teams get onboarded, helping people inside the organization. And you can see how optimizing for InnerSource is also helping optimize inside your teams as well. And helping optimizing the onboarding of people and all that sort of stuff. So it leads to lots of healthy, good practice behaviors. And then sometimes inside of an organization, but not with every project, you want to get to the point where you can co-maintain a library.

Martin (19:49):

So it might be that you're not up for ever having somebody helping maintain this library that doesn't work for a particular CVP of something or other. And that's fine. It doesn't mean InnerSource won't work inside your company. But you should be clear about that with people, and you should kind of set those expectations upfront if that's the case. But if you're up for, if you're welcoming of people, if somebody wants to co-maintain, understand they won't, unless there's a reason for them to. So just because they can, just because you'd like them to doesn't mean there's anything in it for them. So what's in it for them in co-maintaining? Do they have an equal stake in influencing a project direction, in reviewing code, and all that sort of stuff. Because if they do, then they'll help you drive this library forward. But if you're not prepared to give up control of co-maintenance, then these people are always going to stay at the contribution of code level.

Martin (20:50):

And so it's up to you if you want to do that though. And again, the same pattern doesn't hold for every single project. It depends on what the goals are of the project and what you're trying to do. But if you are trying to invite help for contributions, make sure that you've got good documentation. Sorry, folks, InnerSource doesn't mean you can stop documenting all your code, "Because my code is self-documenting." That's another myth I should've given a number to. That's just not the case. When you're doing the source, you need to do better documentation because you're coding for a system that's optimizing for asynchronous collaboration and collaboration that's more geographically distributed. And so you want the documentation to be inviting. You want it to be welcoming. You want people to come in, you want your code to be well commented so you can actually understand what the heck's going on.

Martin (21:37):

And you're not relying on the tribal knowledge that's contained around a particular team room or a particular floor of the building. That you are writing down a lot of that information. And you're sharing with people and guess what? This means that it's a lot easier to do remote work as well if you're moving towards kind of InnerSource style workflows.

Martin (21:57):

Having good governance around the project. So having some kind of code of conduct is fine. What can we expect in terms of when we're talking with you in this project? How's that going to work? Making sure that you've got a good test suite though is also important, because making sure you've got policies enforced, so the maine is always working. When somebody gets their first experience of downloading that code to make a small book fix, they're able to do that easily because maine is always working, the CI builds are always working, the PR verification builds are always working. And all of those things being in place really helps encourage contribution.

Martin (22:42):

And then finally being open to pull requests, being open to collaboration is important. If you not tell people being open is an important first step in terms of doing it, even better, if your team follows the same process that you would like external teams to follow when sending in changes, then that's the best way we've found in terms of encouraging contribution.

Martin (23:05):

Marking issues. If you've got an issue which is super easy to fix, we just haven't got time for it this sprint, marking it as a good first issue. So this is an issue that somebody could come in and pick up and actually go run with is a great practice as well. Because you kind of say, "Yeah, we'll totally accept this as a thing. We just haven't got time to do it right now." So go but if you wanted to do it, if you wanted to send this in, we will definitely merge that pull request. We will make the time to do that.

Martin (23:33):

Right, if we just sort of show you some examples. So this is an example of kind of like a read me describing the project's intent. Making sure you've got the contribution process documented. Making sure that contributors don't need any magic permissions that only the team members have. Make sure this is kind of an easy thing for people to get hold of. And also, try and keep the code clean. Try and keep it approachable.

Martin (23:57):

Right, at number four in our top five myths of InnerSource is, press the button, gamification. I hear this all the time, "Let's give people stickers, let's give people badges and then we'll get more code contributions." Now don't get me wrong. I work at GitHub, like there's a lot I'll do for a sticker and your stickers get you a long way. But putting badges on things and doing gamification is that if that's the level of commitment your organization will get to, is that enough incentive for people inside your organization to share? If the only thing you're going to give them is a little badge that says, "Well done, you've been sharing," but you don't give them ... But their boss is never asking them about sharing. Their boss themselves is never incented to share, then how much sharing is actually going to happen inside your organization?

Martin (24:55):

How can you make sharing, make InnerSource a core part of the culture of your company? The way to do that is actually to encourage some incentives around collaboration. So here's an example of an incentive structure from, again, a company I used to work at where we take the core incentives of the company, the bonuses, the salary rises, and we make them dependent on sharing. So when you come to your end of year review in engineering, you have to say what impact you had, but you also have to say, and it has equal measure, what contribution you made to the success of others. And importantly, what contribution you had that was built on the work of others. So you're encouraging both supply and demand of sharing, supply and demand, because you need to build an economy of sharing inside of your company. And it's no good having all the supply, but no demand. So you need to encourage demand by forcing people to get their full 100% of their incentives, forcing people to say, "This is the work we've done that's built on the work of others."

Martin (26:12):

Because now they're going to go look for others to go work with. And it wants, and they're going to pay the tax. They're going to pay the investment that's required to go talk to somebody else who's not on the same floor of your building or the same corporate vice president. They're going to pay that tax, because they know they need to do it because this is what my company values and this is what we're being paid on. By doing that, by encouraging the demand of sharing, then you, people who start to share have success, because they are now sharing with these people, so that's good.

Martin (26:43):

But also by encouraging that demand, you're encouraging the economy of sharing credit, of saying, "Hey, this team over here are the ones that contributed to their success," because you need to, to get your full rewards. But by doing that, you're making sure they get credit and it makes them more visible for doing that thing, makes them more successful.

Martin (27:03):

Don't get me wrong. The core fundamental part of every engineer should be achieving the goals, delivering value to the end users of the system that they're building for. That's the whole point of DevOps. But by encouraging an incentive model that takes some account of sharing, that is how you could really make a difference and really change the culture. And by imposing that model the whole way up the org chart as well, so even the leaders inside the organization have those same three core pillars of what they have to do as part of how they build things. Then all of a sudden managers will start asking people on teams, "Hey, are we sharing such and such? What are we doing?" Because they know that their awards are also based on this. So anyway, it's just, think about your core incentive structures inside your organization. Are you incentivizing the right things?

Martin (27:54):

Right, number three in our top five myths of InnerSource is dah, dah, dah, dah, dah, dah, dah. We need to tidy this code up before we publish it. Every single team I've worked with, every single one is like, you come to them, you say, "Right, we're going to InnerSource it, so maybe even open source it." Yeah, great. I'll do that. I just need to refactor some stuff. I'm going to scrub the code for all those to do's I never did, because they're always there still and decades later. I'm going to fix all these things I've been meaning to fix for 25 years, I'm going to get those fixed and then I'll share it with people. Because I don't want people to see my code because my code sucks because I'm just an impostor here. I clearly don't know what I'm doing. Completely natural. Everybody feels that way. And you need to understand that every team feels that their code is not good enough, that they need to clean things up.

Martin (28:49):

But let me ask the team this. Is this code word running in production? Is this code delivering value to our business and to our end users? If it is, it's good enough to share. It's good enough, there's stuff in there that's good enough to share with people. And you can allow the community around the organization. They can come with you on the journey as you tidy things up and as you improve things. So, especially for InnerSource you start to get over it. And it's one of these kinds of emotional jumps that organizations have to do to kind of know that the world doesn't end when I start sharing this way.

Martin (29:29):

And know that they don't get random CVPs coming down from a different part of the org and telling them, "Oh, you didn't, you've got a to-do here that you never did, Or you're not using the ganga four kind of factory pattern in this particular class. Or ooh, look at this code, it's spaghetti code." Nobody does that anyway, because they've got, they're far too busy doing their own jobs. The world doesn't end if you share things. And encourage that behavior, encourage the sharing, allow people to get over it for the first time. And then you'll get to the point where they start to do sharing by default, that sharing is just the natural way that they work.

Martin (30:09):

Right, number two in the top five myths of InnerSource where it was sort of coming fast upon the number one here. But number two is that people think, "Great, I'm doing InnerSource now." They're going to say, "Fantastic. I'm going to build a team that just does the framework." Doesn't do anything that delivers value to our end customers directly. They're just going to work on a component that's only for internal consumption.

Martin (30:41):

That is usually a bad idea. And again, this takes us down to why DevOps teaches us. DevOps teaches us having these vertical teams that are focused on the flow of value to the end users and iterating quickly, and that are learning from in production. They're continuously monitoring. They're continuously observing. That way of working is the best way of building software. And I truly believe that. And so if you don't have end users that are consuming your software and continuously giving you feedback and allowing you to test ideas, see what works, what doesn't work, it's too easy to just head off into kind of architecture astronaut land where you're just building stuff and you've got nobody who's consuming it. You're not getting any feedback, and so you just go off in completely the wrong direction.

Martin (31:35):

DevOps should be like going for an eye test. It should be making small changes to the system. Have you made the system better or worse? So it's like better or worse, better or worse. And you're constantly making small iterative changes. And so you end up on the better solution until you've made the system better. And it's the culmination of all those small incremental changes that makes it better. If you've just done a framework team, just building around their library so that somebody can consume it, usually you're not getting that rapid feedback. And so don't go, that would be my advice. Have end users, people who are working on teams, that are working on end user delivered value, have those teams think, "What components can we take out and share inside the company? How can we componentize this so that somebody else could consume this, and it's not just part of a big monolith?"

Martin (32:32):

And so by taking those components out for sharing and allowing people to consume them, what you're also is a more modular, less monolithic way of building systems inside your organization, again, which is not healthy. So it helps you as a company build these more componentized systems that are more modular because you're trying to help them be shared. But the team that works on them isn't just incented to go build that one thing, they're incented to be delivering value. So they can't over-focus on that one thing. So it was always fit for purpose. And if you want to make it fit for somebody else's purpose, then they can make it shareable and componentized. But quite often that relies on the other team to add the two, 3% of things that make it better that allow them to use it.

Martin (33:21):

This was the example with the visual studio code team. They built the Monaco Editor control for what they were building. But that Monaco Editor control that they shared internally was also picked up by other teams like the Internet Explorer team, like the Azure DevOps team. Different teams around the organization that needed an editor control. Rather than build one from scratch, because it turns out editors think they're easy, but there's a lot of work in them. Rather than building one from scratch, "Hey, if we bring this component over here, it's got 90% of the functionality we wanted. It's got another 40% of the functionality we didn't necessarily wherever going to build, but it's cool that it's there, and it makes it even more valuable."

Martin (34:08):

But then we still need to add 10% stuff for it to be able to do the thing that we needed it to do. Make that in a source library, the person, people consume it in. They contribute the things in, usually extension points actually so that they can then build things on top of the core component that's being shared, but they can add those components into the shared library and then move on. And then before you know it, you have a shared library that's useful for a greater number of people inside the organization.

Martin (34:34):

So my last tip, the number one tip in InnerSource, the myth that I hear the most frequently across all companies that I go to speak to is that, "Yeah, yeah, yeah, that's great for you, but InnerSource won't work here. We're special. We're a bank. We're a medical company. We have compliance concerns. We build rocket ships for space. We can't possibly share things, because we're special. That's not how it's done here. It's not how it's ever been done. Never going to work. Sorry, just not going to work."

Martin (35:08):

And I'll say that InnerSource can work in the vast majority of companies I've worked in. In fact, I think it can work in every company I've worked in, not always everything you do has to be shared with everybody inside the organization. You know, you can work on shared components and have these shared libraries, but you still can have private projects. It doesn't stop you from having them. But it's about building a culture that defaults to sharing with the whole organization, and is very deliberate about the things that it keeps private. Either for compliance needs. You don't want, in a bank, you don't want the traders to have access to the systems which are looking for fraudulent trading so that they can detect how to circumvent them.

Martin (35:55):

Though you know, you could argue security by obscurity is probably not the right thing to do anyway. But the regulators are not going to look favorably on you for doing that sort of thing. So, you can still keep things private, but have an economy of sharing by default. And some of the largest organizations in the world that I've worked with actually, are doing InnerSource and are sharing. And they've got some companies up here, but you've got people like Comcast. You've got people like Verizon Media, you've got all of these companies that are massive companies that you wouldn't necessarily think of as sort of software companies. They can do InnerSource and they can share.

Martin (36:39):

Obviously right now we're all watching this amazing Perseverance Rover that's rolling around on the surface of Mars. And we're all looking forward to when Ingenuity, the helicopter, is going to go take off for its first sort of powered flight on a planet, powered by open source and using consumer grade electronics. Basically powered by a couple of Arduinos and a Raspberry Pi Zero.

Martin (37:04):

But it's just amazing that all this stuff actually kind of works and can kind of be shared. And people at JPL they saw as they're doing InnerSource and as they're adopting things like GitHub and stuff, they're seeing code reuse greater than 90%. And this collaboration inside their organization increased 20 times. And this is massive. And this is a heavily regulated industry. You can't just send military grade secrets around the world all the time. But this is a very, very, regulated industry. And yet code reuse is up there. We have again, different companies like Walmart Labs and people like that who did some great stuff. So InnerSource can work inside your organization. You just have to find out how to get it to fit inside your culture and how to make that work. And that's work, okay? This is why they call it work. It's not easy, and you're the best person to help make that happen inside your company.

Martin (37:55):

So what are the key attributes that you want to look for when you're trying to encourage more InnerSource or more InnerSource engineering practices? You want to make sure teams are incentivized and encouraged. Encouragement is the most important thing first, you can incentivize later. Encouraged to share, encouraged to consume.

Martin (38:14):

You have this permissive read model, so lots of people inside the organization can read and you get to a point where you default to having a permissive read model. But a very restricted write model to sort of control. You still have the same level of permissions, maybe even greater control over who has write access to the source code. But you have very, very, very permissive read access.

Martin (38:35):

You need discoverability of source code inside your organization. If you're going to help people consume, you need them to be able to find that code. So think about how you can improve discoverability. Obviously, if you've got things like GitHub, then that's kind of built in, but if you're not using it and you're being used to other things as well, you can build an index, you can just build a Wiki page where people list them. It doesn't have to be high tech. You know what I mean? You can start simple and then build up as you go along. Good documentation is important. And then using this pull request model and having pull requests validated by reliable tests that give people instant feedback, they're all excellent kinds of attributes with InnerSource engineering.

Martin (39:14):

Okay, I'm bang on time, so we can have a bit more of a break. So I just wanted to say, thank you very much for listening. Again, my email address is martinwoodward@github. And if you want to get hold of me on Twitter, it's @martinwoodward on Twitter. I'm going to head over to the GitHub booth now. So once you've grabbed a drink and grabbed a bite to eat, come on over to the booth and they'll be there chatting if you want to ask questions. Or if you want to learn more, github.co/innersource, there's some white papers there you can share with your colleagues. And then finally the InnerSource Commons is a fantastic organization of like-minded people who are all trying to do InnerSource and all who talk to each other from the InnerSource departments, lots of different companies. So it's like like-minded people try to do InnerSource inside their organizations. We all kind of hang out at the innersourcecommons.org. Okay, thank you very much for your time. I think we're going to head to some break music now, so people can get lunch, but thank you very much. Take care.

Linda (40:12):

Thank you, Martin. We're going to keep you for a few more minutes over here-

Martin (40:15):

Okay, cool.

Linda (40:15):

... because I have a ton of questions for you.

Martin (40:17):

Yeah, okay.

Linda (40:17):

There's a very lively discussion around owning code and what that actually means. And it really made me think about the Philippe Patek thing that you don't own the clock, you keep it for the next generation. So the specific question over here was that in many talks you hear about the importance of code ownership for the dev teams. Am I understanding correctly that you are saying that teams should not own code?

Martin (40:45):

What do we mean by code ownership, okay? So people tend to take that like, "It is mine. I get to say exactly what everybody should do with it." If you think of being a maintainer of that code base, I'm going to say that's a healthier mindset to have. Because you are the person that is responsible for that code, that is making sure that code gets better and you leave it in a better place than you found it. But how many times in your career have you taken a project all the way from research in Greenfield development to building the thing, to maintaining the thing, to sunsetting it and then switching the system off. How many times have you ever done that the entire way for a project that's been successful, I'll say?

Martin (41:36):

I've been involved in some projects where I've created them and then thrown them in the bin again, sadly, but there we go, planted far too many that I'd like to admit. It doesn't happen very often. And so you kind of realize that you are just the maintainer of this code at this point in time. How can you make it a better place? But how can you also make sure you lead the organization when you move on to the next project, you have left the organization in a better place, so this code is going to outlive your participation in it, and is going to keep getting better as you move on. So yeah, it depends how you define code ownership. So I prefer to think of it as code maintainership.

Linda (42:13):

Beautiful.

Lauri (42:15):

So like, think of yourself as being replaceable. There's another question, more on a management level, any data on a recruitment from the contribution funnel back to the maintainer team?

Martin (42:30):

Yeah. So that is a really interesting question actually, that's kind of, it's got two points to it there as well, in terms of when you talk about recruitment. So there's recruitment and retention of engineers. And I'm trying to think of some papers. I'm trying to think of what papers, I'm trying to think of what research is out there that points to this. We definitely see correlation between high-performing teams people who are building these cultures of sharing and cultures of collaboration and employee satisfaction, employee retention. We've directly tested this inside of a lot of engineering systems I've worked on, where we asked the developers inside of the teams for their satisfaction with our engineering systems. And as we encourage more collaboration and more sharing, we see the satisfaction of the engineering teams rise.

Martin (43:25):

You know what the biggest number one driver of engineers satisfaction is? Shipping stuff. The quicker you can get stuff into production, there's a direct correlation between the quicker you ship stuff and how happy your engineers are. And I'll tell you what else is a direct correlation between, sorry, while we're on this point, and then we'll get back to your question. There's a direct correlation. If you look at the amount of test coverage and the number of defects, number of books found in production, there isn't a correlation between those. Once you get above 60%, there's no correlation. However, there is a direct correlation between how complicated the org structure is of your company and the number of bugs in production. So how complicated the org structure is of the people building this code and the number of, there's proven, there are papers on this. So, there's something interesting.

Martin (44:15):

Anyway, so recruitment, yes, there is a direct correlation between, the question was about maintainers, recruiting maintainers from the funnel. Nobody becomes a maintainer without first consuming, without first contributing time, and then contributing code. And so that's why you need to bring people down that funnel. And it's a numbers game. Only a small percentage come through. So you need to make sure you're maximizing every part of that funnel, and maximizing the number of people who get through that funnel to get to the point where one or two people will ever be a code maintainer. But that's super rare, and you're only going to have that happen by numbers.

Martin (44:54):

Inside of a company you can kind of put forth things because you've got ... As well as another dial of how interested people are, you've got the other dial of how much you can pay them to be interested. You know what I mean? That's what you think about in the inside of a company, you are maintaining some code base, because somebody is essentially oftentimes paying you to work on that code base. But that doesn't keep you from maintaining it, because if they're paying you to do something which you hate, you just leave and go get another job. Because we're very, very lucky and privileged. So yeah, there is a direct correlation, but you've got to think about why, what's in it for them is the thing I would say. Sorry, long answer.

Linda (45:33):

No worries. I have a kind of a follow-up question from here. How hard is it to share code and hope for good contributions with broken windows everywhere? And how to argue for nice code there? So if you had any tips or tricks for someone who is trying to encourage good [crosstalk 00:45:50]?

Martin (45:50):

Yeah, yeah, no I completely get the point. This is what I was pointing to around, oftentimes people don't want to share yet because this isn't nice code and there's too many broken windows kind of thing. First of all, the broken windows thing is a fallacy and is quite big, quite well-proven of that. So we'll park that aside and we'll not talk about Mary Giuliani and all that sort of stuff, because it's definitely been, that's been proven not to be the case. But by getting out of that and then starting to invest in things that are helping your DevOps processes like CI, like a good test coverage, things that give you the confidence to be able to accept changes from people.

Martin (46:36):

All those investments, all those things you do that you're wanting to do by coming to this conference anyway and learning about this stuff, these are very, very, very important things which encourage things, and then also help encourage sharing as well. So you've just got to, you can't just stop work while you pay down technical debt. We've got to be continually delivering value to our end users as we go. And so it's trying to figure out ways of paying down a little bit of technical debt, in the sprints over iterations, while also shipping some value to our customers. And it's our jobs. That's what you are paid to do is to lead this code in a better place than you found it. And how can we improve the productivity of our development teams this week so that we'll be able to do more next week, while we also keep on shipping something this week? It's a tricky balance. That's why they call it work.

Martin Woodward
Director of Developer Relations, GitHub
www.linkedin.com/in/martinwoodward