GitHub Demo Days, 21 May 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: #InnerSource: A practical guide on how to get started #DemoDays

Description

2:03 - Program Start
3:34 - Introductions
6:23 - What is InnerSource? A brief recap
7:23 - Why adopt InnerSource?
18:42 - How did Microsoft open source their documentation?
22:15 - Where to begin with InnerSource?
22:55 - Seed projects
30:05 - Processes and tools
49:20 - Getting buy in
56:17 - Creating a culture of sharing
1:01:50 - Measuring the success of an InnerSource project

Part 3 in our series on InnerSource, Jamie Strusz and Gus Stewart Implementation Engineers talk through the practical steps needed to get a successful InnerSource project off the ground. From your first seed project to a fully developed program, here's exactly where to begin!

A

A

Hello, hello, linkedin how's it going. I see lots of you in chat, hello, hello, nice to see y'all, see folks from brazil, india, germany, dutch, hello to everyone, hopefully you're all staying safe. I see everyone from the world and it's uh important time to think that we are really in a very small world at that, so I hope you're staying safe and uh hopefully enjoying this friday, and um you know once again welcome everyone to the third and final part in our discussion of inner source.

A

If you joined us over the past few weeks, we talked about the distinctions and synergies between inner source and open source. Why discoverability is such an important consideration for any inner source effort and today we're going to go super practical and break down the necessary actions for starting an inner source effort at your organization?

A

If you happen to find this conversation, useful cool or even funny and want a more contextualized discussion, just use our qr code, which I'm going to put up now in the corner, and um you can use it to book time with us now, I'd like to introduce our guest for today, jamie and gus implementation engineers here at github, jamie gus, take it away. Please.

B

Awesome, thank you so much aj for that very kind introduction. um So yeah, I'm gus, I'm an implementation engineer here in uh london and with me. I have jamie.

B

And yeah jamie go ahead.

C

uh Let's go ahead and throw up the slide just waiting there. We go.

B

Amazing excellent perfect! So, yes, today we are talking about the final part of the inner source series and this is a practical guide to getting started. So everything you need to know about getting your inner source initiative off the ground and we just did the introductions, but just if you want to have either of our github handles, you can see mine is there gus shaw's stuart and you can see jamie's there as well. So both of us are in the professional services team here at github.

B

By way of agenda today, we're going to just be recapping slightly on what we talked about before. So what exactly is inner source? What are we talking about when we say that, and why should you adopt it? Why is it a good thing to do so that will be how we kick things off and then we'll look into planning uh your first step. So what do you need to do to get things off the ground?

B

And what do you need to be thinking about first and then how we should determine our seed project, so the first project we're going to do then we'll look at getting the involvement, the interest getting the buy-in from everybody, and then the processes you're actually going to be putting in place to drive this thing forward, and these are all so very much intertwined with one another and very important there, and then this idea of the culture of sharing, so how you know why inner source is so valuable and sharing information, transparency, sharing ideas and then we're going to be measuring success on the back of that for our sort of first steps into inner source, and so so, with this uh sort of presentation that we're going to be doing today.

B

We also want to be keep in mind, we're going to be doing it through three lenses, so the the lens of the leadership, your leadership team inside your business and then your managers as well. You know of the various teams and then the people on the ground. The contributors who are actually going to be making things happen we'll also be having the three phases of uh inside of this as well so getting started, and then, after a bit of time, you know establishing your regularity and then finally, what happens when you start gaining momentum.

B

So if you can bear those things in mind too, as we make our way through, but to kick us off, we want to look at what is in a source.

C

Yeah, what is inner source uh here? We have the logo for the inner source commons, and that is a community of practitioners that create and share knowledge of and around inner source.

C

So when we talk about what inner source actually is, most people say it's open source, but inside your organization- and that is true, but what does it really mean and is it just code?

C

So we want to take a look at the definition of inner source itself, so in context, inner source is a methodology right and it's designed not just for code, but also for documentation and other collateral, and the idea is that it is publicly accessible internally.

C

So anyone inside your organization can see it modify it and distribute it as they see fit.

C

So why adopt it? That's a great question: there's many different reasons why you should adopt inner source and it kind of depends on your role within the organization.

C

So leadership, management and contributors we're going to break this down into these categories, so ultimately for leadership. They have to make decisions to invest in inner source because it can be a really large cultural shift and it's going to affect the entire organization, but the return on investment is really really high.

C

In fact, paypal had such a great outcome from adopting inner source that they literally wrote a book on it included in their statistics.

C

They said they saw a 25 increase in code quality and they also freed up about 65 of developer time that was previously spent on bottleneck escalations and when they tried to undo their inner source initiative, developers actually ended up leaving the company because they didn't want to go back to the old way of working, so brands have really found value in inner source and paypal isn't the only one right, so inner source has actually been around for over two decades.

C

Now the term was originally coined back in the year 2000 and more and more companies since then have realized its value example. Florian freshmath at ford said our environment allows developers to find solutions that have already been developed and they can collaborate on those and then reuse them and brian blackman. A consultant at microsoft. Premier developer, says in a technology driven world developers are at the heart of your communities or excuse me the company's future and their innovation.

C

So we want to give developers the best tools to unleash their know-how and increase their productivity and that's central to the company's success potential.

C

So if we go back- and we look at all of the things that we have here- that are key to getting buy-in with leadership and why they should adopt inner source, the tldr here is that companies invest in inner source because of that huge return on investment and part of that investment is in the people.

B

So that's the leadership level and then the second kind of tier we look at is the management level so in charge of the various teams, and you know what's in it for them. Why is it going to be beneficial for the management team and there's lots of different reasons for this, but primarily you once you start adopting the inner source way of working.

B

You have very informed decision making and the way in which your projects are managed is so effective because you have this real transparency in the way that you communicate and it sort of allows the so much cross-pollination between teams, sort of thinking, ideas and helping really drive the value for everybody.

B

So everyone understands why they're working towards something and everybody is contributing, and with this for the management team, there's a culture of growth for everybody for not only for them, but for everybody who is working in their various teams and they're all getting so much out of this there's mentorship going on there. You know experimenting in new technologies having and and making real contributions to the company as a whole, and that really does bring a lot of job satisfaction.

B

I mean we all know how good it is when you learn something new when you really provide value on a on a big uh scale, for you know not just yourself, but for the company too. So this is is brilliant and you can drop really drive forward. The vision of the company and kind of rally, everyone's expertise- and uh you know with this mentorship with this guidance from all this cross-pollination and the other beauty of this, is you have fewer escalations with the inner source, because everything is documented?

B

Everything is talked about, transparently and out in the open, so people can find the information they need without having to you know, uh escalate and indeed uh worry about bottlenecks and bottlenecks also require escalations, but because in a source you can actually just go and fix the problem yourself. Then you, you know your your building and your contributions are much more uh consistent and you don't, and this idea of slowing down because of bottlenecks is removed.

B

So ford we have tom erickson here from ford. He said if you want to ship higher quality software faster inner sourcing just makes sense, so ford moved away from using waterfall and inner source wasn't the original objective, but they actually started talking about code, reuse and in a source then spread through those kind of ideas of reusability, and now they don't just share inner source methods. They actually have scrums to work together across teams.

B

So it's this cross-pollination, that's really happening, and if you want to unblock your dependencies by initiating changes you need, then this is the the uh way to go. So bloomberg discovered that and uh this kind of idea of inner sourcing and it's really benefited. So we have someone called becky plummer who is at bloomberg, and she put it like this ten years ago.

B

Someone would say: hey guys, who owns this program. Please fix it today, bloomberg engineers say: hey. Can I fix this? The answer is usually yes, so we can. Actually, you know, that's obviously brilliant you're fixing you're not just uh seeing problems but you're fixing it, and we can take that a step further and actually go ahead and open the pull request to be reviewed rather, rather than actually having to ask for permission.

B

You can just do it yourself and then let your maintainers decide whether or not it should be accepted into the main project that you're in a sourcing together on.

C

Yeah, absolutely um and last but not least, are our contributors what's in it for actual individuals. uh The obvious answer to me personally is just that.

C

It's incredibly rewarding you can build something that works across the entire organization, and you have that possibility to identify opportunities to contribute software back to the larger company mission and bloomberg actually compares pull requests that were opened versus pull, requests that were accepted and merged, and these are contributions from people not actually required to work on those projects, but comparing those two numbers, they really saw that those outside contributions from people not required to work on the projects really did make a difference. So you are really connecting to that larger.

C

Why everyone at your organization has that same mission and they follow the same company values and it really is uh uniting. um You also have the opportunity to improve existing skills, and, just you know, get better with your own code and your own documentation quality, and that in itself also helps to build your resume. um And then you know like we were looking at with some of these examples. It's really empowering to be able to make changes, even if they're, really small ones and not be blocked by other things.

C

You know and waiting for that escalation and that bottleneck to you know be fixed and resolved. So you can move forward with your own road map with inner source comes a lot of that transparency and we heard it earlier.

C

You can make the most out of existing solutions, we're not having to reinvent the wheel, which is something that's often said, um and with that comes an increase in the velocity and uh gus mentioned that a bit with the management section.

C

We also get to again work across teams, there's more cross-pollination, that's happening, and that creates more lateral mobility within your organization. So you're not just on your team on that project, in your role forever, you have that um opportunity to move laterally within the organization um and then, as we saw with one of our examples where they freed up 65 extra time because of escalations that went away.

C

uh Think of all the things that you can do with that free time, uh so you could fight technical debt as an example, you can fix those paper cuts that are you know, driving you mad. You can refactor code and documentation, you can increase automation and actually hp also moved from waterfall to agile and they freed up 23 of their time and they then turned around and invested that into code maintenance and test automation.

C

Now zolando has written a blog post, if I remember correctly on their experience with inner source.

C

um So you know what's faster coding, everything yourself or you know having that review um where you're reviewing someone else's code, so you can get reviews of your own work from a variety of people on a variety of projects and that again goes back and it helps you improve your own personal skills and when another person is looking at your code and giving it that same level of tension as you did, when you were writing it, your work is going to get better and reviews become a conversation not just a rubber stamp and pass to the next stage.

C

So again, all of these benefits for contributors.

C

You you gain that self-determination again, you can follow through on new ideas, enhancements fixes anything your heart desires, essentially within reason, and you don't need permission to offer up a suggestion which is really unique to this, and then uh we can't say it enough removing your own bottlenecks, so you can keep working, it's just so wonderful um and then all of this added up together really does create contributor happiness and that's you know one of the ultimate goals.

C

So let's look at the benefits. Thank you. Let's look at the benefits for everyone all together um and we've got some real world examples. Are you ready gus all right, um so I want to talk about how microsoft open sourced their documentation.

C

um So what happened here was microsoft's documents all used to be private and internal.

C

They were in all kinds of different source control methods and they decided to open source them a really great seed project, because it's organization wide lots of variety and stakeholders. People across products can contribute to their own product documentation as an example, and it's not just the technical writers anymore, but the technical writers turned into maintainers and we'll talk about.

C

You know what a maintainer role looks like later, but the docs are more likely to stay up to date when you have them open for other people to contribute to, and I know we're talking about inner source, but this is like a really great example of how that translates. So with um the microsoft documentation, anyone can go, you know, do a search for any piece of information, they're looking for on a microsoft product or a tutorial or whatever um so this.

C

In this example, we have the azure cognitive services for big data, and let's say I found a typo. There is some outdated information. I wanted to contribute to it.

C

Gus has the option to click on this edit button in the door top right corner, and it takes you to the repository on github where the documentation is, and you can see the contributors. You can click that pencil icon again to edit it, and you can open a pull request on this and then the maintainers or perhaps a trusted committer is going to take a look at your pull request and choose whether or not to accept it, or they might have a conversation with you about the documentation or the pull request whatever it is.

C

That you've contributed and I think, that's a really wonderful way- to keep documentation up to date, especially with a company as large as microsoft, with as many products uh as are available. um Another example that we have is github's super linter, so the super lender is github action and it takes a combination of various linters written in bash to help validate source code. So we started using this internally on just me and gus's team, but other teams at github wanted to use it and we started to realize the value for other companies as well.

C

So this project, then, after being intersourced at github, became open source under the mit license, and the journey of this project alone is really interesting because of how it did grow organically inside github and github has worked to cultivate a culture of inner source. It's a natural part of the way that we work and we do things and if you take a really close look at the documentation for the super linter, it's really strong and the engineer that contributed. The bulk of this documentation was able to do so.

C

Despite being a self-proclaimed bad documentor because of mentorship. He got mentored on his technical writing and now he's a really really wonderful technical writer. So if we can go back to the slides thanks next one.

C

Yeah, so this all sounds great. What a paradise can't wait to go there with you, jamie and gus, but how do we get there? That's a very poignant question. um So no we can't magically do it all at once. We're going to show you a phased approach with tangible steps, so it does start with seed projects.

C

We'll also talk about the processes that you will need and how to get buy-in from everyone and then, lastly, how to build and expand a culture of sharing within your organization.

B

So that's exactly right and the first part of this is at building a seed project. So a seed project is the first project that you're going to be working on when you start employing innosource. So it's the first one. You want to keep it nice and you know not nothing too complicated.

B

You know you don't want it to be your core product, and you know it's just going to take baby steps to bring about this change in the way that we work so used to to sort of dip our toes into inner source. We normally start with a seed project. So that's what it is and just as importantly as um knowing what it is, we need to know what makes a good seed project before we dive in.

B

So it is first of all, you want it to be something that entices contributions, so something that individuals across your company can play with, and experiment with, and you know start adding uh different features to and and if you want it to be accessible and also there's something that's genuinely useful that they genuinely feel like they're bringing value to the company and that can bring about. Not only is that rewarding, but you can also have actual rewards for contributions made and you know, uh give people sort of uh you know titles like a trusted.

B

Committer things like that that really make people feel part of what you're doing.

B

This also enables mentorship, which is what we were talking about with this uh person for the superlinter who wrote the documentation, so you can really bring about that transparency and everybody's learning and again this comes back to being a very rewarding experience and makes people want to contribute, and this word of mouth will start spreading, that you also want it to benefit the whole organization, so something that's worthwhile for the company to spend its time on like documentation which is going to be helpful for absolutely everybody.

B

So you want to have intrinsic value so that everybody in the company, including the leaders, can see that there is a point to this, even if it starts initially small and then this will prove the value of inner sourcing and show everybody why it's worth doing and why it's worth considering this as a way of working.

B

Another key component of your seed project is: have it remove a known bottleneck or something else that might be very uh costly to your resources? So bottlenecks tend to form when one team is dependent on another team and rather than waiting for the bottleneck, the team can actually to be fixed. You can actually go in and fix the problem yourself. You can do it yourself and that's the beauty of inner sourcing. Is these bottlenecks get smashed and then you can just go ahead and do it yourself.

B

Another part of the seed project is you want it to have as diverse a range of stakeholders, as you possibly can, and the reason for this is a diverse range of stakeholders. Maximizes your learning opportunities for absolutely everybody.

B

So you know the more people you have who are able to uh and and the more people you take into account the more you are sort of uh provide you you're, showing that this program is really going to provide value and people are going to be really excited by it. So you want it to be something that everybody can get involved in and not just one or two teams, but you get and it starts to bring about this cross pollination and uh building these communities that lots of people can really get behind.

B

Another thing to think about is uh having a sufficiently modular structure or something or with your seed project so or something that can become modular down the line. So, as it says here, small modules that work together can sometimes be easier to maintain. So if you have smaller more loosely coupled modules that are designed to work together, then this can actually um make it more coherent and easy to maintain uh in the future.

B

So that is the you know a way of thinking about this, and that is going to make your life a little bit easier and people might not be put off. But if something you know you have a big monolith, then developers might be slightly hesitant to get stuck in and start making changes to it. Having said that, there are um a lot of popular models like google, twitter, facebook things like that, and they have very successful uh monorepos that have uh that use specialized tooling to help manage them.

B

So again they come with their own sets of challenges. But if it's well organized and well documented, then if you have one large repository, then your contributors will know. You know it's all in one place, so they don't have to go looking for it right. You know in lots of different place in lots of different modules, so there is an argument for that as well.

B

So I guess the point is just: it takes a little bit of thought a little bit of um you know just understanding and planning to make sure that you get the right seed project, that's going to hit these boxes and make sense for your company so that the inner source program doesn't fall flat on its face, because it is a big change and it does require work and planning.

B

And the other thing you can consider with uh a seed project is actually having a range of experiments rather than just one, so you might want to have you know a couple of uh little ones or set up sort of infrastructure, centric inner source programs, where anyone inside of your company can upload one of their own software assets that people can start. uh You know contributing to the danger with that is that you then get this graveyard of dead projects that people stop.

B

You know lose interest in and then your whole program has fallen on its face and not work. The inner sourcing hasn't worked, and so that's a danger.

B

So you just got to make sure that when this does happen, when you do start to put these uh experiments in place, that you have community leaders and trusted committers, which will so you know you assign definitive roles which we'll talk about shortly on each of these projects, to make sure that you, you know they they that there's enough sort of weight behind the project to make it actually grow and help build the community around each of these projects with a major branch. That's always working and that everybody can contribute to.

C

Yeah, um those were really wonderful, visuals that you you gave us guys. I was imagining. You know the the graveyard of dead inner source projects and.

A

C

Just like um it's it's super common. You know we have companies that come to our team and ask for help doing these initiatives because they are a big undertaking and we've simply, you know we simplified it here right. We have an hour to tell you how to do this, but really you know it takes time it takes months and months and months and lots of planning and part of that is going to be your processes and the tools.

C

So you know once we've determined a few good seed projects and the number of seed projects that you have is really going to vary. It's going to depend on what meets the sort of suggested requirements that gus went over and it's going to depend on. You know the size of your organization, if you're a small organization, then it's okay, if you only have maybe one seed project to start, if you're a larger organization, it's okay, if you only have one seed project to start, you just need to take the things that gus outlined into consideration.

C

So once you determine what those few good seed projects are, we also need to back them up uh with processes and tooling. We had an image of you know a little seedling growing earlier, and you know just to use that metaphor like we can't just plant it and forget about it. We have to use the processes and the tooling as part of our strategy, and all of that is really going to start with transparency.

B

Absolutely so, transparency you want to open everything up to anyone who wants to contribute. You don't want you want it to be to get as many people as involved as possible, so and and with that you want to create a safe environment for everybody to contribute and establish some house rules that make it nice and uh you know easy to not only easy to contribute. But you know it's encouraged and you know uh you feel safe when doing it, and one of the other things to think about is using internal repos.

B

So if you're part of an enterprise, a github enterprise, you can use internal repos which are available to anybody inside your organization to then make contributions to so they don't have to have been added directly to that uh repository. They can actually make contributions. There then they'll be able to find it and see it nice and easily.

B

So those uh that kind of idea of transparency and and the communication around it keeping it open is, is such an important part of this.

B

And so, in terms of the processes that you use, you want to make it as easy as possible for someone to make a contribution to it. So simplicity is better because it can be explained clearly and quickly and it's not. It doesn't mean that you have. uh You know that your project is is trivial and weak. It just means that it's easy to make a contribution to which is exactly what you want when you are starting out with your inner sourcing.

B

So you you don't having lots of hoops to jump through is not where you want to go. So that's the first thing: how easy can you make it it have you got the documentation in place to you know, make it easy for people to contribute, and you know, keeping those barriers to entry, nice and low.

B

The second thing is visibility. So how visible are your projects? Are they easy to find? How do they go about finding them? So we have. We've talked in the previous sessions about an inner source portal, which would be a portal to all of your inner source projects and that you know- or you know, if you just have one and they're very easy to find, and you can find them there and that's. You know, and that's another key part of this.

B

If you want people within your enterprise to be contributing, then absolutely do uh use something like an inner source portal and make sure people are aware of it, and this is where to go to find this and the other part is, um you know you can do regular showcases of what you're doing in a source um you know shows to the wider teams and and teams to see exactly what it is you're working on how it's going.

B

One thing on this as well is: if you're on github enterprise server. We also have something called the. If I show you here, we have the project showcases, so you could perhaps so this is under the explore tab here.

B

You can see it up there and then we would see the showcases and you can just put forward your most important projects, and so if your inner source c project is the one you want to highlight, you can put it here in your show cases, and then lots of people can come and see the seed project and start making some contributions to that.

B

So it's all above board and very easy to find.

B

The other thing is making to giving everyone the time the teams time to actually make contributions, because obviously, if you're very busy with your projects, your own projects and then you're told you're not able to start, you know you don't have the time to make contributions, then you're never going to get off the ground. So that comes from the leadership saying yes, we'll. You know pre-vet some planned work and make sure that everyone is given the space to that. And while you do this, you know you want to pre-negotiate some.

B

You know expected outcomes from the project and allow the teams to fit the inner source activities into their day-to-day work schedules. Ultimately, you're still a.

C

B

It's you know, so you know that open source open-ended, it's done when it's done is not exactly what you want. You want. You know saying and again, if that's the case, then you're not going to get this off the ground. So you want to make sure that people have the space to work and that they are allowed to make contributions to show the value of this.

B

And then the final piece of the puzzle for your processes is having some sort of quality assurance in place with your trusted, committers and maintainers, so they're, the ones who are going to make. You know sure that everything is being reviewed properly before it's merging driving the whole thing forward and we'll talk more about what those roles are with maintainers and trusted commissioners uh shortly, but just bearing those in mind that they're going to be roles on these projects who are going to be making sure that all bugs are shallow.

B

And that leads us nicely to actually defining the roles.

C

Yeah we we keep talking about all of these things um kind of like their steps, but these aren't necessarily like sequential steps right. These are all moving pieces that are happening all at one time and that's why we're talking about this phased approach? And you know the the inner source portal was a really really great example of one way to to share things that are being intersourced, and you know uh you can make it an interactive automagically, updated uh page.

C

You know: we've used github pages before to build um like a scraper that is going to scrape your internal repositories and then take the information from them and build them into that website. So it's automatically updated for you, whereas with like a static documentation, site or like an internet site, or something like that, it's it's there and you have to manually go in and update it. So we're talking about like getting time back because of um you know, reducing bottlenecks and being able to you know, spend that time uh with automation.

C

That's part of that automation. You know we don't want to start intersourcing only to have a static website right, um so the scraper and hopefully zac has dropped. The link is a really really wonderful tool to do that, but yeah. We also need to define roles super important and gus, and I have alluded to it and we allude to different parts of the talk while we're giving it because again it's it's all happening at once. It's all layers that are happening together.

C

um So when we're talking about defining roles, you know we can't just release our seed projects into the wild and just expect people to follow these processes on their own. So we have to clearly define these roles. That's really really important and also the responsibilities that come with them. So the first thing that we have here is just designating a team of people to create these formal processes and also track the success of the initiative overall and also just fits facilitate the community building and again we will talk about it later um layers.

C

uh So this this kind of team of people to you know create these processes and stuff. It's usually called ospo or open source programs office, and if you came to uh the first talk on inner source earlier this month with uh zack and prem, they talked about this a lot, and you know we talk about ospo. We talk about open source programs office um and sometimes that just doesn't really resonate uh with with your internal people. They're like oh well, we're not open sourcing. This are we well, you can name it whatever.

C

You want, whatever makes sense for your organization, we're going to refer to it as ospo or the open source programs office, but you could call it something else that that makes sense like the inner source initiative, team or something um so they're. You know again responsible for creating these processes building the community tracking success.

C

Then we also have maintainers and maintainers are essentially the project owners. They can be developers, they might be product managers, technical writers, etc. It really depends on you know what the project is and we're talking about, having a diverse set of stakeholders right.

C

This is a part of it, so the maintainers, uh those that's a group of people that are really driving those projects forward and defining the vision for them, they're, making decisions, they're prioritizing requirements and they're, enabling contributions through having a transparent roadmap, having open work items and managing the contributions that are made to it. So if you looked at an open source repo or really any repo, that's public on github.com and you go into the issues tab. There are issue labels and often times with open source projects.

C

You will see an issue label for good, first issue or help wanted something like that and then there's there's programs that help people go in and find those and uh start contributing in open source. uh One thing I can think of off the top of my head is hacktoberfest, um which is really great. I participate in it every year. I sign people up to participate in it every year, um but it's it's the same idea. So if you have something like that internally, you can mark things in you know as inner source.

C

You can mark things, help wanted and give people something to make contributions on, because it can be overwhelming, as we've mentioned, to walk into a product or a project and want to contribute, but not really know how to get started. So having that uh issue label is super helpful and then the trusted committers, which are also you know you could call them trusted contributors.

C

um It's members of that project's community and we'll again talk about it later, um but they really help the maintainers with their responsibilities, and they also make a lot of contributions. um Those can be contributions to the actual code or documentation and collateral, or they can also help other contributors get started.

C

Working on the projects, like, I said, with those issue labels as an example, when you compare the trusted committers to the contributors, the trusted committers have earned that responsibility to perform tasks that have a higher level of risk associated with them, and the contributors may or may not be members of the projects community. um So there's a there's, a distinction there so trusted committers are part of the projects you know community.

C

They have a higher level of risk, with the actions that they're doing and then the contributors could be a part of that community or maybe not you know they might be working on something for their own project um to unblock it, or maybe their team needs something in that product added, but it's essentially like they're they're aghast and they may or may not stay and um they could potentially become a trusted, committer or maybe not um so committers and um trusted.

C

Committers and contributors are also different because um you know trusted committers are going to submit their changes and more often than not the code review process is a little bit quicker because we know like they understand the rules of the game. They follow the guidelines they're following the suggested format for that particular project.

C

um So with contributors they can make suggested changes and usually it's the trusted committer that goes back in you know, in addition to the maintainers, to review that code or documentation, um but either way you know, regardless of which role you're feeling you still have to follow that project's contribution guidelines and just make sure that you're, essentially playing by the rules.

B

And that sort of segues nicely into talking about the low barriers to entry. So when jamie there was talking about um the contribution guidelines, you can actually write those out and have those inside your repository uh in a contribution guidelines markdown file where that can be updated, and you know you can just make sure that anyone wanting to contribute can just go and read exactly how they go about making a contribution in a very transparent way, and so you give everybody that opportunity to come together and start providing value for the company or whatever.

B

It is that you are working on with that. You also have the code of conduct, which I mentioned before, to help you know make sure that everyone is working in a safe, transparent way that is going to be beneficial for everybody. Inside of the project to you, know, abide by and then finally just an effective readme, so the readme is always going to be. Does it you can have again.

B

This is in your root directory of your project, and this will be displayed just below and it just a good readme should always tell you how to get up and running nice and quickly any scripts. You need or anything that is needed to get up and running you up and running as quickly as possible and point you in the right direction for things like documentation or anything like that.

B

So with that, you have all these tools to make sure that these barriers to entry are kept nice and low, and the other thing is making sure that everyone has access to these project leaders that jamie was mentioning so maintainers trusted committers those kind of people. We want to make sure that you know you can have you can get in contact with them nice and easy. So are there details on the readme this? You know very helpful if they are somewhere like that, so they are very easy to get in touch with.

B

Should you need to.

B

And this then brings us to the way in which we communicate with each other in an inner source project. So I get how we use issues everywhere. Github issues for everything that transparent conversations about anything to do with the project that you are working on and everyone can see it's almost as if the documentation is sort of a live documentation. That's changing all the time, then you can keep.

B

You know it's a real time documentation, and so you can see what's going on what people are trying to achieve and as jamie said, you can put labels on them to categorize uh the different issues and the different discussions that are ongoing.

B

You can then also you know, you've got a list of these issues, but you can have them inside project boards, which we have on your github repository as well, and then you can automate your any tickets on your project boards, which a project board is essentially a kanban board that uh you know that has to do doing done, but obviously you can make it more complicated, but just as a very rough example, and then those issues that we talked about, you can apply as tickets to this kanban board and then have nice automations.

B

So when you move something to, if you close an issue, then that'll be moved to done on your project board and the beauty of it is it's all in one place, it's all on your github repository and so there's no context shifting it's all there, and this then leads us to another newer feature on github, which we have github discussions where you can have discussions on the repository. So I'll just show you an example here. So we, this is just a test repository an actions repository.

B

So we mentioned about the issues here and we mentioned about the projects here, which would be a kanban board, and we also have discussions as well so discussions you can have about any features that you want to. You know talk about anything that is around this repository, particularly good for inner sourcing, and then you can see that you know something like this. We can start. You know having a shake up having some uh ideas shared around whatever it is, can all be done in the discussions as well.

B

So you've got that feature too, and we can categorize them label them in much the same way and then, finally, we have this idea of using something like microsoft, teams or slack making or whatever it is you're using making sure that you have these channels open for these transparent discussions and that's the key. Is this transparency and having as many people as involved as you possibly can to bring it all together so again, something like that. I'm sure most of you have something like that and just making sure that you have bespoke channels for these.

C

Yeah, um so when we're talking about all of this transparency and being able to share the communications, you know that's going to help us get buy-in organizational changes like this are really really hard, especially when you know we're talking about cultural changes. So having that buy-in across the different levels like we've been mentioning, is really tantamount to success of the whole initiative. You know we keep talking about the phased approach and the different levels of stakeholders and there's a reason for that. We all have to work together, we're all cogs in a giant machine.

C

That's trying to create this change. um We have already cited some of the big name, companies that are utilizing inner source culture and we've gone over the reasons why what we do need to talk about is how you know the levels of leadership the managers and the contributors um can actively buy into it. You know we're no longer just selling this idea and gus and I are enthusiastic about it because we believe in it. You know we work this way and we really really enjoy it.

C

um So as a participant, how can we buy into this idea of inner source so with leadership level buy-in um this one is really really big. So without buy-in from leadership itself, no one else at the organization is really going to feel empowered enough to act in the organization's interests when there's pressure to just get things done, so leadership has to regularly communicate their buy-in to everyone else in the organization, and that includes talking about the strategy.

C

Like we've been mentioning, you know the layers so transparency, the seed projects, the clearly defined roles, the well-documented processes for contributing to these projects, the discoverability of the inner source projects with the portal and things like that and ultimately- and we cannot stress this enough- is leadership really needs to be clear about giving people time to do this? You have to encourage the community to participate. You have to encourage a conversation around projects and interests.

C

You have to encourage uh resource, reuse and contributions right. It's not just making things all the time. It's about reusing them too, and ultimately, leadership is responsible for addressing all of the fear, the uncertainty and just the doubt that really ultimately goes into establishing trust inside the organization, and that is why this this greater message really really needs to be discussed regularly. It cannot be a once and done thing.

B

That's exactly right and with that you also have to have the management level buy-in, so the tier below the team leads who will be below the kind of key leadership so for them to be successful and to get their buy-in. You know they need there's two real things that they need, and the first is, as jamie said, the air cover, as it were so from above the leadership and then the second is the ground support so from the engineers or whoever you're having contributing below.

B

If you don't have those two things, then that then the management aren't going to want to buy in because it's going to be a sort of it's gonna, be too difficult for them to push things forward. So that is the uh key with this is having a support from those two groups to get everyone moving in the same direction and giving them the space to move in the same direction.

B

So the management can do their jobs effectively, and the second part of this is when you're starting out with inner source to make you know, don't be obviously be ambitious, but don't be too ambitious and you know under promise and over deliver, so make sure that you know they can see the the value and- and you know, you'll you will over deliver and if everybody's moving in the same direction, you will get these absolutely.

B

You know brilliant results, but you know if you promise the world and it doesn't happen, then obviously that's not going to work out with the the top leadership so having that idea of under promising, but over delivering in in a project. That's manageable that you can do is going to get your uh support from the management.

C

Yeah, uh I really like what you said with us be ambitious, but not too ambitious, um because that's that's true, right um and again like I. I feel like a broken record talking about this, but you know as a contributor how how do you personally buy into this idea this methodology of inner source? um I was talking about leadership earlier and stressing leadership has to give people time and as a contributor, you have to take that time.

C

Don't feel, don't feel bad, don't feel guilty, but take that time so join communities which again we'll talk about in a bit and just use that inner source portal to find projects to contribute to to familiarize yourself with.

C

So you know what's out there, so you can take it and reuse it and when you're contributing to projects again, it doesn't matter if it's code, if it's docs, if it's other collateral and it doesn't matter whether it is a direct contribution or maybe you're reviewing someone else's stuff, maybe you're just leaving a comment, an idea suggestion, but as long as you're a part of that conversation, that's a contribution right and ultimately, you can become a trusted.

C

Committer, like I talked about earlier, so if there's projects that you're really interested in or that you find yourself working on regularly, maybe you need to step up and start really looking at things and becoming a trusted, committer and ultimately again, consume and use the content that is available to you. We saw it in a quote earlier, like why reinvent the wheel find what's out there reuse, it save yourself time, move your road map forward. Have that velocity and start.

C

You know shipping things that you're working on more regularly faster and, ultimately you know stronger quality like we've been discussing, um and another thing that you can do at the contributor level is just encouraging your colleagues to contribute and use the content as well um yeah. Let's talk about a culture of sharing, um so I I love this idea of having um you know these little communities. You know we want to work together and create this.

C

This culture of sharing, like we're, saying and and build these small communities and they're going to be led by that ospo um team or whatever it is. You want to call that open source program office, but in order to really build yeah go ahead. Guess in order to really build this culture of sharing, we really we have to market.

C

We have to do marketing, you know we have to generate outreach and do internal marketing, and when we talk about building and cultivating this culture over time, just remember phases, you know, so we have to do the outreach we have to do the marketing and we have to encourage it and grow the initiative.

C

um So you know we've broken it down here generally into these three phases. So in phase one we're just focusing on raising awareness and helping people get started connecting people to one another and just answering that greater. Why? Why should we invest in this at all the different levels?

C

So what we really want to do is invite people to join these communities and participate in them and then in phase two we're just establishing regularity. You know it cannot be a once and done thing or a casual once in a while thing. We want to really entice people to regularly get involved, whether it's you know through being a trusted committer or just showing up to community events and discussions and again we'll talk about that in a minute.

C

um But we essentially want to design a mechanism or some sort of way to recognize and even reward contributions and community participation, and maybe that's something as simple as just giving shout outs in chat or email meetings, newsletters whatever it is that you all do. um Maybe we could even start doing small contributor showcases just to highlight people's work as individuals.

C

We could do project highlights for things that are both popular and even less popular and that's going to bring attention to them and raise that awareness.

C

We can show things that have been getting reused and how they're being reused- um and we have this picture of these android ugly dolls on the screen, because I know of some companies that have reward systems where you kind of earn participation points for prizes. And when I was at google, we had a system like that, and I got one of these stuffed ugly android dolls. So that was like a really nice surprise.

C

I didn't even know that we were keeping track of that sort of thing um so kind of surprise and delight there and then with phase three. That's where we're gaining momentum, so we can put all of this together and expand it. So we can go back to the seed projects. We can establish even more inner sourced projects, for people to to use and to contribute to. We can do again user highlights to show how people are going from becoming less involved in projects and then becoming a trusted committer.

C

What does that pathway look like and how do more people follow that pathway?

C

We could also look at perhaps creating a series of technical talks at a regular cadence, and people can start talking about the things they're passionate about whether it's a language, a library, a project whatever it looks like and just get people excited we want to know you know what gets you excited? What what do you wake up for every morning excited to go and do that's the sort of thing that inner source can help cultivate and we're talking about.

C

You know. Building more communities, um so, if you're watching and you want to take a minute to you- know, put something in the chat and let us know like what would entice you to start contributing to stuff that is inner source to your own company um other than what we've just discussed. Let us know what might help you to be enticed to get involved um so yeah building communities. This is one of my absolute favorite topics and if I'm not mistaken, it's also zach's favorite topic too. I don't know zack. Is that correct?

C

um So there's there's a few different types of communities right, so we can do role-based or interest-based the intersource project based and then you know we can have a mentorship program.

C

Spotify is a really really good example here, so at spotify they have tribes and communities of practice for people based on different roles, different skills, etc and inside those communities they have weekly meetups and you know pre-pandemic.

C

They would sometimes even have like a breakfast or a lunch, and it's it's just a really good way to entice people to come. Like hey, free food, come learn about things and hang out with people that are like-minded, or perhaps that are not like-minded and that's kind of the beauty of inner source right. We're cultivating the community and that invites diversity and thought which is really special.

C

Spotify, also created communities of interest, and that allows people to share knowledge and tools and best practices in monthly style meetups. So you can uh meet people who are interested in similar things and that's really cool.

B

Excellent, so this all, that is how you get things off the ground, but at some point you know, obviously, when you first introduce in a source, you'll have a little bit of leeway as to you know the making. It happen from leadership that at some point the leadership will expect some evidence to show that you know this is creating value and is the way you know is taking us to. um You know where we want to be and bringing us in that direction.

B

So measuring um you know your progress is an important thing to do so we will break when we measure success with just getting off the ground and you're. You know, starting out, there's jamie mentioned before there's these three phases, which are getting started, establishing regularity and then gaining momentum, so just to look at phase one here.

C

Yeah phase one um yeah just getting started, you know the things that we're looking at um are largely, um I don't want to say ineffable, but they're really hard to get numbers from right. We want to focus on you know getting the buy-in and building the community. We can take a look at how many people are going to these things. How many people are attending who's participating?

C

um What kind of teams are from? Are we getting a wide variety of people? Are they all from one project that uses this project that we're talking about? Take a look at those sorts of things. We can take a look at the number of seed projects we have um so to start, like I said, depending on what your organization needs, we might have one seed project, we might have a few seed projects and, let's track how many intersourced projects there are over time and then, let's also see if we can measure increased learning.

C

uh One thing that you could consider doing is just sending out a survey and having people kind of rate, their own skill level and you know make sure they know it's not because you're assessing them for like salary or something like that, but just to figure it out, and you can use that to also build a mentorship program. So at github one thing that we did was we, you know every six weeks we have a different mentorship.

C

We send out a survey that says what are the skills that you're able to help people with and we send out a second survey for what are you interested in learning and we match people up and they're encouraged to spend time together at least an hour every week and- and you know, exchange that skill and again meeting people across the company boosting your own personal resume. Those are all wonderful things. uh You can also take a look at employee retention and this is going to be a little bit different because of the pandemic.

C

But if you take a look at you know employee retention and nutrition rates for any given month compared to previous years. That's potentially a really good indicator. You know compare that with the people who work on open source projects versus don't work on um or excuse me, inner source projects and people who do work on enter source projects and take a look at those numbers and see what the the response is like.

C

Also you can take a look at you know. I keep thinking about that 65 reduction in escalation blockers and that seems really really high, and I don't know how they measured it. um It doesn't actually go into that detail, if I remember correctly in that particular resource, but measuring the number of escalations for blockers. So if you have a dependency and you have to wait for someone else to resolve it, you have to tell your manager they have to talk to the other manager.

C

You know how much time does that all add up to how many times does it happen? You can track that sort of thing and then also just again. The inner source portal for setup and awareness make sure it's ready to go, and you know if you use that scraper and it automatically updates your portal, so anything that gets added over time can pop up there just see you know what people are looking at. You can track those sorts of things and then that lets us move into phase two.

B

So phase two, this is looking at. You know establishing regularity. So this is, you know, looking at our community participation. Is it where we want it to be and encouraging leadership, check-ins, making sure it's a regular, cadence and happening. uh You know as regularly as you want to, and that again is an indication that things are going in the right direction, then adding more seed projects. You know this is working. We can start to. You know sprinkle some more seed projects in here and start to encourage.

B

You know we started just doing documentation now we're gonna, try on this. You know small application and have different people start to make contributions to it, and with that is learning being increased, is the mentorship program taking off and again employee retention? Are we keeping our employees? Is this? Is this looking the way that we expected it to? Is it or are we getting? You know, are people you know buying into the culture more and that's a real uh indicator that things are going in the right direction.

B

Then, with you know any particular projects? Are you getting outside contributions? So you might have you know your primary maintainers and uh trusted committers, but are you getting you know how many contributions are you getting from different people who are from different teams? You know, what's the breadth of that and that's a really good indicator that it's going well and also is the whatever you're working on being reused. How much is it being reused? Is it bringing value you know and again, this reusability is all part of inner source and making sure that things are.

B

You know we're all moving in the same direction and again tracking your inner source portal analytics. So if you have something set up, as we talked about in the previous weeks and jamie mentioned to as well, you can see from the analytics of that. How much is it being visited? How much are um people enjoying.

C

Yeah thinking thinking about what you said in that second to last point there guys I just am going back to that bloomberg example of how they measured. You know open pull, requests versus ones that were accepted immersion. That was a really interesting measurement. If you saw that graph um yeah phase three gaining momentum, this is kind of the the fun bit right. This is where we really start to dive heavy into data science. uh So, let's think about you, know, cross-team contributions.

C

The open versus accepted, like I mentioned, for bloomberg as an example, the number of unique clones, if you do have forking enabled number of visitations to docs and that one's a little bit trickier, you know you have to figure out a way to take a look at you, know individual ips and clicks and who stays for how long on what page, etc um and then also just the number of trusted committers. Is that increasing over time? If it is great, if it's not, maybe we need to figure out why?

C

So it also is kind of a diagnostic tool, and so with all three of these phases, you know we don't just go one two three and that's it. Your inner source is not how you know it works. It's not how life works um again. Huge cultural chef, huge cultural change, so you know, even though you've made it to phase three we're gonna, go back and add seed projects, we're gonna, go back and add communities and we're gonna start over we're. Gonna.

C

Do this again, we're gonna reaffirm what we have and we're also going to build upon it, we're going to expand, we're going to add more people, we're going to add, more communities, more interests and it's going to grow and grow and grow, and hopefully that's really organic, but ultimately that that ospo team, the open source programs office or whatever again you want to call. It- is really encouraging this to not just grow roots but to really take shape, and you know open up a different world for everyone.

C

That's involved in the organization- and you know thinking about again that paypal example where people started leaving when they undid inner source. um That's a really strong indicator if you're doing things well is people are really really happy and that's one thing that we said with: why adopt inner source you know. Is we want people to be happy? You spend so many hours doing this and we we want you to have a good time and again gus and I are enthusiastic about it and all of the presenters.

C

You know zach prem matt and chris and gus, and I we we love this. You know we live this every day and we really believe in it and we really find it helpful and we love helping companies be able to do it too. um Gus. You wanna, you wanna, take us out yeah.

B

Just all that's left to say is thank you so much jamie um and uh and thank you, everybody for attending really really appreciate you and all getting stuck in in the in the chat as well. So thank you for that um and, as jamie says yeah, we uh we really believe in inner source. It's it's been sort of transformational for us and lots of other companies and so yeah. We we've really enjoyed uh talking about it today and talking to all of you.

B

So if you want to connect with github and get a demo on it and you know take it further, you know we have lots of um opportunities there, and you know our professional services can really help you on your journey. There's and we'd absolutely love to, because we do uh love doing it. So yeah.

C

Please um yeah yeah yeah. We have a qr code, I don't know if I'm pointing to the right way um on the bottom of the screen and if you want to go ahead and scan that and reach out to us get a demo like, I guess is saying talk to us and just connect with us and we are really enthusiastic. We are ready to go. We love this. We believe in this and again uh thank you for attending. Thank you. Aj zack rowena, everyone else that came out to support us and thank you all aj.

A