Dr. Wolfgang Gehring – A Frictionless Inner Source Journey #FOSSBack

This talk focuses on the concept of inner source, which operates similarly to open source, but confines collaboration and sharing of code within organizations. The speaker discusses their experiences at Mercedes-Benz, highlighting the use of GitHub and GitLab for internal development. They outline key components necessary for successful inner source implementation, such as a common platform, guidelines for engagement, and a training process for new contributors. The speaker presents a case study involving an internal time tracking system that has successfully garnered numerous contributions from colleagues. Challenges faced in scaling inner source adoption are addressed, including time constraints, compliance complexities, and necessary community management. Finally, a commitment to improving the process and encouraging contributions through incentives is emphasized.

So, let's talk about inner source. Um who has not heard of inner source? Thanks for being honest. So then, in this case, just a very brief description that just captures it. So, inner source is like open source except everything stays within the company. All right? So, you inner source it, meaning you have the same practices like in open source, but you work and collaborate together with colleagues

within your company, but you don't publish it externally to the outside world. That's inner source, right? Good. So, um just wanted to briefly introduce here my colleague Sim Kolamkani. She's from Mercedes-Benz Research and Development India, and unfortunately, she couldn't be here today, but she designed the talk with me together. So, thank you, Sim. And um so, inner source definition was very easy. You can talk more about

that, but that's basically it. And so, to make inner source happening, to get it going in your company, is actually very easy. Because we have it all figured out. And you know, so at Mercedes-Benz, we do things really well. And and so therefore, um we did all of these things uh to make inner source happen. And it's so, we have a common inner source platform. That's very

important. Like years and years ago, we had many platforms on which we developed our source code. Now, we just have well, two. So, one is GitHub and one is GitLab, and GitLab is mostly used by our colleagues in the R&D department, so car IT. And in the remainder of this talk, I will focus on the GitHub version, which is more common in the in the regular business

IT at Mercedes-Benz. And so we have very important, you know, for you to be able to exchange code and uh work and collaborate together. And then we have inner source process that gives you guidance what you need to do when you want to engage in inner source activities. what you need to watch out for and so forth. So it guides you through that. That's very nice. And

uh when you're new, we ask you to do an inner source training. So we have that done. Uh that's working very well. We have an inner source license. That's also important. Actually, you know, years and years ago, when we started, we weren't sure, do we need an inner source license? Is that important or not? We said, yes, it is important for reasons I won't dive into right

now. But we have an inner source license. Um then we have the Mercedes-Benz FOSS Manifesto. So uh if you don't know it, this is our public commitment to open source and inner source. Uh if you haven't seen it before, go to our open source landing page at uh opensource.mercedes-benz.com. And then in the top right corner, you will find the FOSS Manifesto. And uh it mentions inner source

in uh at least two places. It says, "Please be active in the inner source communities." Uh so that's there. Um so it's, you know, not just you're allowed to do inner source and open source, but we actively send our engineers on that mission to engage in inner and open source. And uh if you still have any questions, we have uh consulting hours at our OSPO. yeah, we

have it all figured out. It's pretty nice, huh? And um here is one of our latest inner source success stories. So we have a an internal time tracking system where you put your working hours, you know, when you start and when you stop, breaks you take and so forth. And that's used by everyone, not at the big Mercedes-Benz Group, but at a Mercedes-Benz Tech Innovation, which is

uh where I'm from, right? Our it's a uh uh internal uh supplier, so to speak, uh we're the IT techie guys for the big mothership. And uh so everybody at Mercedes-Benz Technovation uses it, and uh we recent recently uh innersourced it because we also established a new system, so we said, "Hey, why not make it innersource?" And uh it actually does get uh quite a few uh

contributions from colleagues all around in the And so we get code and non-code contributions. And uh so I just asked our uh repository owners, "How many contributions do you actually get?" And so it was reported issues and feature requests from 34 different users, you know, it's not just that one guy who keeps complaining. So it's 34, that's that's nice. And uh we have almost uh 50 pull

requests as well with code contributions from also uh many different colleagues. So again, not just that one guy who is working. So this is actually really really uh uh nice example of a good working innersource uh project. And so why is it working look at this here. Uh Here is some typical characteristics that a promising innersource project would have. So it needs to solve a common and

widespread pain or demand. So it's used by a lot of people, not just by a few, and uh with company specifics, cuz if it didn't have company specifics, then you could just open source it, right? Um and it needs a or at least one better at least two dedicated maintainers. That's the case here as well. And you need community management. So, you know, they wrote articles in

the internet and they said, "Hey, if you if you find a bug, please help us and so forth, right?" So, it has all these characteristics. The time tracking system, you know, it's completely useless outside of the company, so it's not an open-source project. It's inner-source. And so, that's why I think this is working quite nice, and everybody in the company needs it. So, that's 2 and 1/2

thousand people. And um So, it gets a lot of interaction. So, as I said, inner-source is easy. We have it all figured out. Yeah, but so, yeah, but still It's actually all together. There are some nice examples. We have more nice working examples, but overall, it is I have to admit, sadly, still staying behind its expectations. Now, why is that? If you look at certain factors, I

mean, for one, open-source is usually created for sharing from the start, whereas inner-source projects are usually tailored to very specific needs of smaller groups of people, right? And then also, if you look at open-source, only about 2% of open-source projects are considered successful. And I put with a skewed distribution, meaning the the you know, 0.5 out of those two take the largest chunk, and then it like

really degrades from there. So, there's no reason why this should be any different in inner-source, right? You cannot realistically expect that, "Oh, this is inner-source. Everybody from all over the company will all of a sudden contribute." It's not going to happen, right? 2% So, 2% is just an estimate. Um probably about right, yeah, but um remember that 73.5% of all statistics are purely made up. Sometimes even

just on the fly. Now, what are stumbling blocks that keep InnerSource from happening, from really taking off? So, time and availability of your engineers. Of course, everybody's too busy. Everybody's got No, no, I don't have time to work on this person's project over there cuz I'm really focused and and I have my day only has 25 hours anyway. Yeah, then you have to meet deadlines. So, sorry,

I can't spend time on your project. Although, it's a nice project, but sorry. Um you don't want to solve somebody else's problem because they're not helping you, maybe. Um also, need to fulfill the numbers. Uh there can be a, you know, perception in the middle management that, you know, I have to report my numbers. If my engineers work on other projects from that guy over there, you

know, we really like each other, but my numbers are going to be bad, his numbers are going to be good. And uh that is a bit of a problem, so I understand InnerSource is good, but I can't really um have my engineers devote the time over there. Um no tangible incentives. We'll talk about that in a bit. And uh community management. It's again like, you know, you

put it there, it's InnerSource now, you can contribute. It's going to happen by itself, right? Obviously, uh not. So, these are stumbling blocks. And uh on top of that, there's also some pain and friction. And uh let me show you a very short video what I mean with that. A lot of times when we ask our developers why they don't participate more in InnerSource, they say, "You

know, I really like InnerSource, but sometimes it's just too painful." What? Too painful? Tell us all about it. And so, we asked our developers about the struggles that they are facing in our current inner source process. It wasn't just about tools or rules, but something deeper was in clicking. Some were aware, some were struggling, but some were leaving inner source. On November 13th at the InnerSource Summit,

we'll show you what we found on our InnerSource journey and how we're going about to remove the hassle so that the InnerSource is with us. Yeah, okay. Sorry about the wrong date, by the way. Um so, what we did is um we wanted to understand what exactly are the pains of the developers. Why don't they participate more? And um so, what we did is we created a

survey, basically, uh to map out the full InnerSource journey. So, what exactly is it that you as a developer have to do when you participate in InnerSource activities uh from the very beginning until your first contribution. What do you have to go through here? And um so, we asked not very We didn't ask really experienced InnerSourcers because, you know, they would know what to do. So, for

them it would be easier. Um also, maybe not complete beginners, sort of in the middle. You have I know what InnerSource is, haven't really done much, but kind of know a little bit, but yeah, help me out here. So, we asked them to go through all the process steps and um we asked them, "Where do you find the information? Do you find it hard or easy? How

much time do you spend on uh process steps?" And uh "What were the problems that you encountered?" Okay, and then we documented this and uh evaluated it and came up with an action plan. So, here this here I like this. This really sums it up, basically. I'm going to give you a second here. >> Yeah, thanks for all comes the part I like to have put a

private reference but not supposed to but thanks for the comes here. They said okay, Jack Sparrow come on. He's a he's a friendly pirate, right? And so thanks Sim for the picture. So that's the thing is you know they're need you know the process has problems but you really want to deal with it. Yeah, we really wanted to and so what we did we identified these internal

frictions. So first of all um the information how to work on inner source and where the process is and everything we had you know we have a internal first wiki um but it grew organically. So that means the information is there but it is scattered in certain places and and kind of like not just in that system but then other stuff is on GitHub and the other

thing is over there. So that's obviously a bit of a problem. The inner source process again didn't grow organically but you know we devised it at first so that it's also safe to do inner source and so forth and uh it that we found the feedback was it can be a bit overwhelming. It's a bit why is it so big? promotion or outreach effort that's kind of

that's like that's a little bit like number seven. They they go together. Here's like when you participate in nobody says thank you. It's like it goes unnoticed. Not always but you know for a large part and that can be a bit demotivating, Uh leadership motivation diminishes down the hierarchy. Yes, that's actually true you know the engineers they understand the value of inner source the very high management

also and the middle management understands it but the problem that I mentioned earlier is like yeah but not sure about the numbers and not exactly sure how we should really go about this and okay, so that's a bit of a problem here. Then five, the compliance process feels burdensome. It's like, why do I need to do this? Because of compliance. Okay, good. No, um tell them really

why why is important. And then six feedback. Yeah, so you find flaws in the process. Where do I go to? I send a mail to [email protected]. can take a long time until you get feedback. It can go un-un-unnoticed as well. It should be easy. Here, feedback. There's there's something wrong here. Okay? Uh and then cultural and behavioral barriers as well. It's still I mean, we've been doing

this for a long time, but still um it not everybody's convinced because like, oh inner source, it's not really working that well, is it? Well, let's work together, but that's hard. Yeah, so culture is always the the most important or the the most difficult, I think. So, these things and then we kind uh put them in categories. So, you know, you have emotional friction, negative feelings. It's

like, I don't know, inner source, yeah, but it doesn't feel right somehow. the yeah, the belonging as that I mentioned, that's that's a thing. Uh the second cognitive friction, it's actually difficult to understand some process steps when you don't find where they are and where to go from here and then to there and so forth. So, once you have it, you know, once you have engaged yourself

a lot with it, then it's okay, but at the beginning, it's it is a bit difficult. And then the interactive friction, as I said, the feedback loop, the the the barriers between legal entities, for example, and other things. Yeah, okay, so then we we went and um thought about all these things and try to get actionable initiatives. You know, the whole this will take a bit longer.

This is the low-hanging fruits. And what can we do here? And then prioritize them in in based on impact, urgency, and feasibility. And then have ownership for the the goals and make sure, "Hey, what is what is happening here? Can we can we have someone who's taking care of of this?" And then the feedback loop, that's a very important part again as well. So, um in these

categories, these are the things that we wanted to do or these are the things that we're doing, have done, and will do. So, uh emotional uh we're going to we're in the process of um implementing a contributor reward program for open source as well as inner source. And uh this is surprisingly difficult to do in a company, right? Like especially in a big company when workers council

who say, "Yeah, but you um you're judging people's behavior based on what they do with a contribution and so forth." So, we have to we're in the process of discussing this. The workers council is very open to this, right? I don't misunderstand me. They're not blocking this at all, but we just need to map out some guidelines and rules, but we're in a very good path. So,

this one I think will be really nice. Um false culture advocacy, so more also in in in connection with management, talk about inner source and the importance and how this will make the company better for the the common goal. Uh celebrate success stories, you know? If somebody contributes to open source, give them a shout-out maybe in a newsletter uh or in um, in in another format in

uh, a talk or in company company gatherings and things like this. Uh, newsletter, okay, just mentioned Then for the cognitive one, um, make more inner source awareness sessions. Then a centralized knowledge repository, not scattered among um, more sources. And then the feedback loop, already mentioned that. Then we have a Foss coordinators and Foss advocates network that we actively use. This is something that's already been established, but

we're going to use that more for inner source purposes as well. Do Foss events where we celebrate success stories. And again, the the leadership alignment and uh, awareness is something that we'll work on. Okay, and then here on the right, uh, prioritize, already mentioned this, ownership, timelines, and so forth, and then keep on going. Okay? And so with points that I mentioned, for example, the scattered resources,

uh, we have the inner source discovery platform uh, that we have had before, but we just moved now to a new instance, uh, on uh, GitHub Enterprise Cloud, and we re-implemented it there. And now it's not just you can discover the projects that are inner sourced, but you can also have this as a central knowledge hub where, you know, you have questions, here's a tutorial, or here's

the link to uh, the process and so forth. So, in one place, and that that I think is a is a good thing. Yeah, also the trainings, you can access the trainings from there and so forth. And so, makes it easier to find the information that you need. And oops, Then, uh, the process, number two, uh, we're we're taking a simplified holistic view of the inner source

workflow, and we'll take away things from the complicated process, make it simpler. And that's very important, I think. So, you know, the old process that was basically I mean it was a starting point. Uh but now is the time to rework a few Number three, uh so um that's something also we need to talk to the workers council still or is it ongoing? Uh but we want

to give people shout outs and and just reward them and say thank you. Uh number seven is the the reward program as I already mentioned that. uh number four leadership motivation. Okay, that's also an ongoing process that uh we I mean you know, they kind of demand inner source. But at the same time, uh they need to also, you know, maybe motivate their people in their departments

to participate a bit more. Uh feedback limit feedback mechanism number six is uh oh wait, I skipped number five, right? Oh yeah, the compliance process. You know, for example, I mentioned inner source license. And when you inner source your repository, then you need to put the license there. And if you don't, you know, there's a bot that will come and say, "Hey, um you probably forgot to

include the license. Here it is." But as a pull request, you know, so you just actually need to click click and then you have the license in your repository. So, you know, reduce the friction there, make it easy for people. that's one example here the compliance simplification. Then also uh then six feedback. Exactly, I mentioned the inner source discovery portal. Here feedback. Now there's a button. You

can just click on it and then it will reach the right people with the feedback. And uh number seven already mentioned, cultural and beha- that's that's still the toughest one. Yeah, we need to do more talking, I guess, more motivation. here's a summary. Innersource is working in parts, but we're not yet satisfied, so we created metrics as well um where we can measure it uh the success

rate and the adoption and so forth. So, now that you know, after we've implemented all these measures, then we can maybe in a few months we can use the metrics and say there's a higher adoption right now. Now it's working better. Okay? Obviously, that's something that's a very useful. if you don't have data, you're just a person with an opinion. Right? With the data, it's like, here,

look. I can prove it. Um we analyzed the process framework. We asked the colleagues what their pains are and analyzed the feedback feedback and now we're in the process of continuing to implement uh the measures that we found. And so, for you to take away, if you're in the same position, Innersource is there, but it's not working, right? Maybe, you know, think about this. What is the

pain and the friction of your developers? Go and ask them. They will tell you. And then think about how you can make it better. Okay? And uh we have a few minutes left. If you have any questions, but uh so far, thanks very much for your attention. Do you have any Can you give us an insight on your the metrics you're using for Innersource or is that

still uh a secret sauce? No, no. So, um several metrics. Uh one is how many repos do we have all together internally and then how many of them are innersourced? How many are private versus inner visibility, so public internally. That's one. Another one is the adoption rate of the Innersource license, you know, I mean, you kind of have to have it in there. Um the bot helps,

that So, that number should go down, but again, we need to we want to see if that is working. What is another I find probably the most important metric and it's a also the most difficult one is contributions does a repository get from somebody outside of the core project team? Because that's when you know inner source and collaboration across teams is actually working. As I said, it's

actually very difficult to see, you know, because who's outside of the project team? We know who kind of who who's in the project, but you want to optimize it auto- automated. That's the main problem, right? When you you kind of know, okay, these are the contributors to the project. Everybody else who's not in that list is an outsider. Yeah, but what if somebody from the team becomes

an outsider? Then all of a sudden like, you know, 25% of all pull requests come from somebody from outside the project team because it's still connected to that person's name. So, yeah, okay. That's when it's not work. So, this is really difficult. We haven't solved it yet. We're we have some some implementations that are working sort of, but not like if they're not very accurate. Okay, but

so this is another thing. And then a few more that don't come to my mind right now. Thanks. Do you have any targets for those metrics or like Uh no, no targets. Not yet anyway. Why not paying for inner source contribution? Paying? Like pay who? Like bonus for developers to contribute to inner source, right? Inner source contributions they should have uh compound effect within the company, right?

If you create a source code that helps everyone to do work suddenly you have one engineering doing um work for a company of what, 10,000 engineers? And why is not there's why don't you simply put a bonus on that and pay the developer? Okay, so that's very difficult. Um because look, why should somebody get a bonus for helping another project out versus the person who's doing a

very great job on the the project? You know, from the inside of the project team. Do you know what I mean? Why should somebody get more or a reward extra? Yes, but uh at the same time, it's funny how open source software of foss software culture is relevant when we're talking about giving things away for free, but and everyone wants to copy that, but when it's about

maintaining and making something sustainable or engaging, um you're copying the same mistakes, right? Well, but so you see, I mean, we're talking about internal employees. You know, it's a different story if somebody contributes to an open source project, right? But internal employees, you know, why should one person get a bonus for contributing to an inner source project versus another person who, you know, puts in the same

amount of work and is a great developer, but only contributes to his own project? Right? That is very difficult. Also, you know, there are in fact, because of that, there are restrictions, you know, that we're not allowed to judge um your behavior as a developer according to the number of contributions to make, because that says nothing about how well you do your job, Uh so so yeah,

very difficult. What we do want to do is the contributor reward program, you know, for open and inner source, but it would be, you know, non-monetary incentives. Like, for you do a lot of contributions to open source, you're probably very interested here's a free ticket to FOSDEM stage, for example, you know? But, not here's X amount of euros on your salary, cuz that would be not very

justifiable. Yeah? Okay. Thanks. And, time-wise, how are we doing? >> we're on time. We're on time. So, thank you, Wolfgang. >> very much. See you around.