A Frictionless Inner Source Journey #InnerSourceSummit2025  Hi everyone. So my name is Sim and I am very passionate about force. I'll just say one line about it. You know I believe that force is magic and with this great power comes great responsibility and my role is spreading this power of magic. >> Exactly. Very good. Very good. So, Inner Source is easy, right? That's why we're all here. And at Mercedes-Benz, we do things really well. Just gauging people's reactions there. Okay, we'll talk later. So, we have it all figured out. Inner source is easy. At Mercedes, we've got it all figured out. We have a common inner source platform. Okay. Two that means uh Mercedes-Benz enterprise IT is mostly on GitHub. Uh our R&D colleagues vehicle IT are mainly on GitLab and uh vehicle IT has some very special prerequisites. you know they have um they have uh requirements that are very strong with regards to safety of course and it's a very highly regulated industry uh some stuff is not open you know like it's internal or secret even so in the remainder of this talk I'm going to talk about mainly enterprise IT okay uh just to be clear so we have an inner source process which is wonderful we have okay we'll talk. Um, we have an inner source process. We have uh uh inner source training specially uh dedicated for this purpose. We have a wiki platform that talks all about inner source and open source but has a special inner source section. We have an inner source license. Uh lots of discussions about that back in the day but it's there now. It works. Um we have the Mercedes-Benz FOS manifesto. If you haven't heard of that or don't know it, then I encourage you to take a look. Go to open source Mercedes-Benz.com, our open source landing page, and in the top right corner, you'll find a link to it. And um Peter Giza has mentioned uh their manifesto as well, and several other companies have one. And uh in our manifesto, there are a few passages with regard to innersource. And we have consulting hours in our OSPO, our open source program office, which also caters to inner source, uh twice a week. So our engineers uh can come with their questions and ask if they have uh if anything is unclear. So and here is our latest inner source success story. Uh this is actually really cool. Uh so we have an internal time tracking system where every employee this is now for Mercedes-Benz tech innovation specifically. Um so 2 and a half thousand people uh a lot of engineers there uh they have to you know we put we record our working times. You start in the morning you have this break and you end your your day at this time. And uh we recently were like well at the beginning of the year we introduced a new system. it was completely revamped and introduced and now everybody uses this system and uh it wasn't working 100% well at first and so people started complaining ah and we should do something to fix it so we came up with a suggestion why don't you insource it you know and then people can work on it collaboratively and that actually worked really nicely so I just spoke to the colleagues from uh this time tracking tool uh two weeks ago last week or two weeks ago And uh they said you know really nice we're very grateful you know we advised them how to do inner source how to you know get all the prerequisites done and how to uh work the magic and they said so we've gotten I I think uh north of 50 contributions they got from uh they got code contributions and non-code contributions you know issues um for for uh all kinds of areas also code contributions that's obviously quite valuable uh from 12 or 15 different people you know not just one person but like from different people so the team reported you know it was additional effort that we had to put in um for documentation and for onboarding and so forth but it was well worth the time and we as the main team we learned a lot because again you know that's what happens in open source as you engage with the community and so in this case an internal community and so they got other engineers uh that came up with pull requests and and and code contributions you know there was an interaction and so they said it was really uh worth it. So very good story. Um now here why is it a success this particular project because if you look for promising inner source projects they tend to have these characteristics. So uh need to solve a common and widespread pain not just developer pain but in this case it's everybody's pain or demand and everybody uses it two and a half thousand people uh with company specifics because if it's not company specific you know you could just open source it but this is an internal time tracking system that's completely uninteresting for the general public. Um and it needs to have a team that actually caters to that project and takes care of it. So you need to have uh one or better at least two dedicated maintainers and you need to do community management. So we did some uh you know articles in the internet and we said hey everybody now it's inner source please help us and so forth. So this is this is really nice. Yeah. Uh so as I said in source is easy we have it all figured out. Yeah. Okay. So still um you know it's so in general we have some projects that are really nice like this one but in general it's staying behind its expectations still and uh why is that? I mean if you look at it uh you need to do some expectations management you know it's not like we're doing inner source now every project is inner source and every project gets contributions from everybody all over the place and so it's not that's not how it works and I mean obviously you know this um open source projects are created for sharing from the beginning usually but inner source are usually tailored to very specific needs and please notice is that only about 2% of open source projects are considered successful. Yeah. Um with a skewed distribution meaning the first.5% are hugely more successful than the remaining 1.5%. Yeah. Uh this is just an estimate and uh remember that about 63.48% of all statistics are made up on the fly. And uh so but the thing is you know why should this be any different inner source? It's not reasonable to expect that everything is inner source and is successful. So here are some big stumbling blocks. The time and availability of your engineers. Everybody's way too busy. They have to meet certain deadlines. Uh I I don't have the time to think about your problem. Sorry about that. I need to fulfill the numbers in my department. You know, this is especially a management thing. like if you know my engineers are working over there then I have bad numbers they have good numbers but I have to report up you know my numbers so I don't really want to you know give like hand them out to the engineers so that's a problem no tangible incentives sim will talk about that and the lack of community management but also adding to these points there seems to be a bit of a pain and there seems to be some friction Yeah. Um, whoops. Wait. Here's a short video that we made. It's just like less than a minute. We used this on um for the announcement for this talk. So if you haven't seen it uh here >> a lot of times when we ask our developers why they don't participate more in inner source they say you know I really like inner source but but sometimes it's just too painful. What? Too painful? Tell us all about it. And so >> and so we asked developers about the struggles that they are facing in our current innosource process. It wasn't just about rules or rules, but something deeper wasn't clicking. Some were aware, some were struggling, but some were living in a source. >> On November 13th at the Inner Source Summit, we'll show you what we found on our Inner Source journey and how we're going about to remove the hassle so that the Inner Source is with us. So, thanks. Heading over to Sim. Uh, we did this analysis and she will tell you all about it. Here we go. Here's the clicker. >> Okay. So we saw all about our idol innos state and also that something deeper wasn't clicking. Innos adoption hadn't grown the way we expected. So what we did? We went deep. We wanted to not assume what the problems could be but we went directly to the source. And what was the source? Our developers. We asked them share with us what are the pain areas that you see in our current innosource process and they did not hold back. So once we gathered everything we sat down and categorize this feedback. Once we started this we sat we observed that there were some patterns and when these patterns were repeating it says that something is wrong with the system. From there on we moved into action mapping. We started resolving things where we found the pain areas. Okay. Do you all want to see what the feedback was about? But before that, this was it. So when you know the process needs a fixing, but you would rather be handling the sea monsters than dealing with the feedback. The amount of feedback that we got required time to handle. It was better to face the sea monsters than dealing with those. Okay. So these were the frictions that we identified. You know we had all the informations, the documentations, the trainings, everything was there but all of this was scattered. Our developers had to put in extra effort to identify where to begin with. The overall process itself was overwhelming. Too many steps, too many touch points. The projects that deserve the spotlight was not getting it. You know, our organization embraces innosource and open source. But this enthusiasm, it fades down the hierarchy. The middle managers they are focused on the delivery deadlines not on the contribution. So what happens the place where it matters the most this momentum was lost. We did not have a feedback loop. So if something was not working it stays that way. And in this case it doesn't mean it is satisfaction it's disengagement. We do not have a recognition model for our contributors and most importantly culture. You know some teams they prefer to keep the code within themselves or even contribute beyond their bubbles. They just prefer to be within that area. Okay. So now we identified what are the frictions, what are the pain areas. What is the next step? The next step was to identify why this pain is caused. Because a process is having some pain, it translates into human friction. And in our case, we identified three frictions that was holding our developers back. The first one, emotional friction. So this was about how our developers feel when they contribute. You know we heard things like I have put in effort but I have not received any recognition. Nobody sees my effort. Isn't it demotivating? If motivation is low, no amount of documentation can fix that. Next up is the cognitive cognitive friction. So this is the mental effort that is required to go through the process understand things. So this is not inner source it's inner stress if you have to go through a lot of things. Next is about interactive friction. So barriers that hinder collaboration and communication between teams and individuals. So now we wanted to make a sense of what all these was. So we created some strategic moves which was simple, scalable and measurable. The first step was to map each of these frictions into actionable initiatives. We just did not want to define in things that we were not going to work upon. We wanted to have each of this having proper implementation framework that each of these initiatives could be properly measured and held accountable that yes this is working and someone is already looking into it and the most important was embedding a continuous feedback loop because innosource isn't a one-time initiative it's a continuous process and the most important thing that we realized was that we need to have a continuous feedback loop with our developers. If they are facing any kind of problems, we should be aware about it and we should know ways how we can handle it. You know, spreading this magic of force is also about understanding. Yes, is there a problem in the magic? How do I fix it? So, let's now have a look at what we are doing. Let me be transparent. This is a journey. So, some of these initiatives are in progress, some are in pilot and some are in planning. We have launched various initiatives like new joiners awareness session where the new joiners are well informed about the process so they can be boarded early on. Now when there are successful Inosus projects we give a shout out to them in the in newsletters we have social intra pages and even during events we tell about these successful NUS projects because if that particular team can work on an innocus project which is very successful why not this team so they get inspired too. Now we have false advocates from each and every department who push this topic within their teams within their departments and that's how we are handling that level of hierarchy where the momentum is lost and we also held various events like first day events which gives us a platform to promote inner source activities. So are we done? Not yet. The rule is simple. We gather the feedback, reanalyze it, improve it and this process keeps going. We are solving the friction bit by bit and we are reaching closer towards a smooth, efficient and impactful developer experience. You know next time when we see we'll tell you about where we are and how how far we have achieved. Over to you. Thank you. >> Thank you. So, uh in summary, um inner source is easy, but it's working in parts and for some projects, but we're not satisfied with the overall adoption. And this is why we started this. We have also created metrics for open-source adoption but also for inner source uh to make it measurable and visible because you know management approaches us and says inner source is not working is it I'm like no no it's working it's show me you know and uh so because uh as Daniel also says you know sometimes is uh um if you don't have data you're just a person with an opinion and uh that's very true and so also so we need the metrics to prove that right that's why we started with them um we analyzed our process framework as Sim has pointed out around inner source and we asked the colleagues what their pains are and they gave us the feedback and now it's on us to implement the findings and make the changes so we cannot present to you yet and we have changed all of these things and the outcome was this we will do that next time all right uh but we're in the process of of as Sim pointed out you know some things we've already done some things we're in the process uh of doing and then hopefully we'll report next time so that that we have more inner source and less inner stress. Thank you very much., A Frictionless Inner Source Journey #InnerSourceSummit2025, YouTube, 01kchemyryhwnv6cdtve34zv9x.