# InnerSource Commons  ## Episode metadata - Episode title: InnerSource Commons - Show: The Open Source Way - Owner / Host: SAP SE - Episode publish date: 2024-12-17 - Duration: 45:07 - Episode URL: [Open in Snipd](https://share.snipd.com/episode/f00ad993-b20c-45c2-9420-4331b6b091a8) - Show URL: [Open in Snipd](https://share.snipd.com/show/b1b29f2a-adba-4a31-a243-ef177053789c) - Export date: 2026-02-17T23:36:37 ## Snips ### [InnerSource Breaks Engineering Silos](https://share.snipd.com/snip/f18c0266-0c5f-44a6-a864-7693cf46425c) 🎧 02:34 - 04:25 (01:50) <iframe src="https://share.snipd.com/embed/obsidian-player/snip/f8a796ab-06c8-4aec-8f9a-e5cfdf34394d" width="100%" height="100" style="border: none; border-radius: 12px;" sandbox="allow-scripts allow-same-origin allow-forms allow-popups allow-clipboard-write" ></iframe> - InnerSource uses open source methods within company firewalls to improve engineering outcomes. - It breaks silos by allowing transparency and peer review across internal teams. #### 💬 Quote > when people ask me what inner source is i usually say first that it's using open source methods to get better engineering outcomes inside firewall. > — Danese Cooper Danese Cooper on defining InnerSource #### 📚 Transcript when people ask me what inner source is i usually say first that it's using open source methods to get better engineering outcomes inside firewall. So acting as though you're doing open source, even if you're just inside your company. And that would be mostly using which aspect of open source inside the firewall? Well, open source could be described as massively parallel peer-reviewed computing. So the idea that everything you do is transparent to the other people that work in your company and that they have the right to read the code, learn from it, occasionally contribute to it, and probably make it better, but also know more about how the software that their company depends on actually works. So it's sort of the anti-silo. And when I say that I abhor a silo, I understand why companies develop silos inside their engineering organizations, but I can't see that the benefits of siloing outweigh the detriments, which are many. It's very common for people to leave a company and be the only expert in that silo and leave the company kind of around that piece of code. And then it becomes concretized. People never change it because they're afraid to break it, but they also don't go in and learn about it. They're more likely mount a project to replace it, but it's just inefficient and unfortunate. You can just as easily develop local expertise by fostering information across the whole company so that people that have to use that software can get involved in its creation and maintenance, even if it's not their normal job. --- ### [Many Eyes Make Problems Shallow](https://share.snipd.com/snip/999115e8-e1fa-46a9-933a-fb1fc2546b30) 🎧 04:59 - 05:57 (00:58) <iframe src="https://share.snipd.com/embed/obsidian-player/snip/f1e1dfd5-23e7-4530-9636-e2e276c463ab" width="100%" height="100" style="border: none; border-radius: 12px;" sandbox="allow-scripts allow-same-origin allow-forms allow-popups allow-clipboard-write" ></iframe> - Open source enables many eyes on code, making problems shallow by collective review. - Silos cause fragility when only one expert understands critical code, which InnerSource prevents. #### 💬 Quote > One of the things that open source does is because so many people are looking at the code at the same time, we say many eyes make all problems shallow. > — Danese Cooper Danese Cooper on the benefits of open source code review #### 📚 Transcript Yeah, there's a couple of other interesting things like that that it does. One of the things that open source does is because so many people are looking at the code at the same time, we say many eyes make all problems shallow. So they can find answers, they can fix bugs because, you know, everybody has a different take on what the problem is. And some of them are unique. The person who wrote it hasn't thought of that yet, right? But when you look at the aspect of having more people in the company understand the code, it is shocking to me how many companies have devolved into basically warring feudal factions inside the engineering organization, where they're competing for resources. They're all pretty sure that what they're working on is the crown jewels of the company, and they're guarding it exactly like a fortress, and they don't want anybody else to understand how it works. And there's lots of reasons why that happens, but the fact is the people that wrote that were paid to do it by their employers. --- ### [Danese's Apple Silo Experience](https://share.snipd.com/snip/92d83bc2-93ab-48a3-bad6-7f3ea8bccbf6) 🎧 12:29 - 18:34 (06:04) <iframe src="https://share.snipd.com/embed/obsidian-player/snip/d8de2c95-90ea-4bca-8833-2be1eb34f122" width="100%" height="100" style="border: none; border-radius: 12px;" sandbox="allow-scripts allow-same-origin allow-forms allow-popups allow-clipboard-write" ></iframe> - Danese shared how internal silos at Apple hindered collaboration on QuickTime and FaceTime efforts. - This experience motivated her to found InnerSource Commons to improve internal software collaboration. #### 💬 Quote > He cut out our ability to look at our code own trees in quick time. He basically closed down his trees and we had to reverse engineer and guess and wheedle... > — Danese Cooper Danese Cooper on Apple's engineering silos inspiring InnerSource Commons #### 📚 Transcript Well, I've been working in tech for about 40 years now. And I've worked in some famous proprietary companies. And I was often very frustrated as an engineering manager with the artificial roadblocks that internal politics can create. The famous story is that the guy who wrote QuickTime, Peter Hottie, was 16 when he wrote it, which isn't even legal in America now, but back then it was. And he was a hotshot kid, and he was pretty sure that his way of doing things was the right way. But the project that I worked on for Apple that became what is now called FaceTime was an attempt to figure out if we could use QuickTime over the internet to communicate and in sound and pictures, right? Peter was mad at us for taking half of the engineering resources out of the QuickTime team to work on this other thing. Because his prime directive was to make the Mac the preferred video editing tool in the world. And we all thought that this other thing was going to be more important in the long run, touch more lives. And so we were working on it. But he cut out our ability to look at our own trees in quick time. He basically closed down his trees and we had to reverse engineer and guess and wheedle and do all kinds of really time consuming, stupid things to make progress. Right now, the reason I can name Peter Hottie and and won't mind that I named him, is he has since apologized. He found me in front of Moscone Center in San Francisco at a Java one to tell me that he really admired the work we were doing in open source and that he was wrong all those years ago. He was young. He didn't know. But it absolutely cemented my resolve that we had to find a better way to work on engineering inside of companies. And when I went to Sun, they had promised to open source Java and they hired me to be the person that made that happen. And it wasn't a straight line. It was quite an interesting process. But what I learned along the way was that this was, in fact, the better way that I was looking for. And if I could figure out how to make it palatable to companies, that would only be better for everybody concerned. You know, once you get a taste of that freedom and the ability to solve your own problems, you don't want to go back. And so I was involved in a lot of famous open source projects over the years. I was the CTO of Wikipedia at one point, which means I ran the engineering side of Wikipedia because I just felt it was that important to take on that crazy job. But I also did a lot of consulting. Tim O'Reilly, who was a famous publisher in our world, O'Reilly Media, had also seen that the open source methods could be used inside a company to good effect. And he and Brian Bellendorf actually started a company that was supposed to do that. But it was too early because open source hadn't won in the marketplace yet. So the big companies were still spending a lot of time downplaying it or making fun of it because some of the people involved were kind of kooky. Let's just say extra normal, not so normal. And that was to our advantage in the open source race. But what I found over my years of consulting was that they weren't able to make that into a business in 2000, 2001, because it was too early. But a time was coming when open source would be declared the winner, which happened in about 2015. And then I immediately switched to, we have to start talking about doing this for every engineer, regardless of whether their is public. Because I was only about 15% of the engineers in the world working in open source. And so very outsized impact for the number of people actually working on it. But the other 85% of our engineering brothers and sisters were still toiling away in the salt mines of silos and exclusions and counterproductive patterns. And so I realized in my own consulting to PayPal that they were going to have to learn how to share internally before they could be expected to do real open source work. I've seen a lot of companies spend a lot of time and energy and political capital trying to do open source before they learn how to share internally. That's kind of the root cause problem that we now had to solve next. I decided I was going to use InnerSource, and I didn't come up with that name. Tim O'Reilly did in 2000 to distinguish it from open source. So I decided I was going to use InnerSource methods to help PayPal get to a point where they could be successful in their open source aspirations. And as I was driving home that day, I realized from my other consulting that actually every client that I had ever had needed to take that step. And that the number of clients that were going to get to open source was diminishing because most everybody that was left was even more stuck in the accretion of old habits in their engineering. And so I called up my assistant, Dwayne O'Brien, and I said, get on GoDaddy and grab as many variations of InnerSource as you can. And he couldn't get InnerSource.org because there was already somebody using it to describe a yoga practice. So we went with intersourcecommons.org. And then when we named the organization a few years later, when we finally incorporated, we called it Intersource Commons Foundation because of Apache Software Foundation. So yeah, that's why I did it. My secret mission, I believe that once engineers get a taste of working this way, they won't go back to the old way. And the best place for them to feel that pure experience is in the open source world. --- ### [Apply and Share InnerSource Patterns](https://share.snipd.com/snip/fc8e5bea-085f-4532-ac5d-150d0a568902) 🎧 25:47 - 30:39 (04:51) <iframe src="https://share.snipd.com/embed/obsidian-player/snip/3e6195d3-160f-49e3-8237-cb161b4aa2d2" width="100%" height="100" style="border: none; border-radius: 12px;" sandbox="allow-scripts allow-same-origin allow-forms allow-popups allow-clipboard-write" ></iframe> - Use InnerSource patterns like the '30-day warranty' to encourage contributor responsibility after code deployment. - Share successful practices and tools back to the InnerSource Commons community to help others. #### 💬 Quote > One of their concerns was that those people wouldn't be around if something broke... So we landed on a pattern called the 30-day warranty. > — Danese Cooper Danese Cooper describing the 30-day warranty InnerSource pattern #### 📚 Transcript called the 30-day warranty. And that is the engineers that are donating the code, the contributors, promise while they're donating the code that they will be around for 30 days after the code is commercially deployed by the company to address any issues that arise. And it was important that it be from deployment, not from merge into the code base, because sometimes it's too risky to change things. Like around Christmas, PayPal doesn't change anything if they can help it, that's when all the money moves and they don't want to destabilize the system at all. Okay. So if you wanted to retain employees in the company, you would just accept the code, but totally wait with the deployment, and then they'd have to stick around? No, it doesn't work quite that way. We just wanted to be sure that they were around when they needed to be around. Okay, okay, just kidding. Guillermo, in the first place, what are you doing here anyway? No, I said what you're doing here. You are the inner source guy within SAP. Do you have examples or stories, similar ones to tell from within our company? Yeah, of course. You asked what I have been doing here. So far, I have been delighted to listen to our other guest speakers. mean, especially the story about the foundation, the foundation of the foundation, let's see. And that's one of the things makes me proud of us at SAP having this podcast and having participated in the production of the podcast before. So that's always very interesting. And coming back to your question about the patterns, as you mentioned in the beginning, I am an inner source officer at SAP. And what does that mean? It means that I am tasking with scaling the practice of inner source in the whole company. When we think about patterns, we have different types of patterns, and I like to divide them into patterns that can address problems that projects adopting inner source might have, and also patterns that might address problems people like me are having, like trying to scale inner source at the company. So I like to divide them like that. One of the examples, the one that Denise mentioned, it's called 30-day warranty, right? When one team defines a certain type or when one team defines a certain time in which the contributor have to be available for maintenance. And this is something that we have seen already being adopted at SAP for some projects and that we often recommend because when we talk to people, when we want to influence them in adopting Inner Source, this is a very common fear that they will have to take code from other people. So we preemptively already tell them, hey, this is a pattern that you can use to mitigate that. Now, we also have some patterns that fall a little bit in between what is a problem of a project and what is a problem of scaling the practice in the whole company. Like for instance, we do have templates that we give to the projects and there we adopt one pattern that is called the standard-based documentation. So there are well known files in inner source projects and also open source projects that document things that are expected by contributors. Like for instance, what is the contribution guidelines in the project that we put in the contributing.md or what are ways of users of the project to get support in the support.md or how is the governance of the project? So we already provide that. So we adopt that pattern in two ways. One, we tell the projects to adopt it, and we adopt it when scaling the practice to the whole company. Other example was already mentioned before is the InnerSource portal. And this is a very interesting case because we can also use it to showcase how we as a company engage with InnerSource commons. So this is a pattern that we adopted at SAP to showcase all the projects that are adopting InnerSource in their source code repository. So it's an internal website where they can go and every project that is adopting InnerSource can put themselves out there and anyone looking for InnerSource projects will look into this website and learn what is already out there. So this is not a problem that is specific to one project, but for the whole company. So anybody in the company can go there and search for these projects there. And this raised the need to another problem that we had to solve and that became a pattern, that is the activity score. I mean, if you have a lot of projects, you have to sort them and you have to decide how to sort them. So we decided that we would not simply take a metric like number of commits or number of stars or something like that. But we came up with a magic number that we called activity score. And we shared with the community how to or how we decided to calculate that score through a pattern. I think this is a very good example of the give and take from a company and their relationship with InnerSource Commons. I mean, we consumed a pattern, we learned about how to do something, we implemented that pattern, then we contributed back to the community by sharing the source code of our portal. --- ### [SAP's InnerSource Portal Journey](https://share.snipd.com/snip/7ff3c0a7-4e77-4859-9bca-bd68e3615f39) 🎧 30:39 - 31:49 (01:10) <iframe src="https://share.snipd.com/embed/obsidian-player/snip/4efda83f-1823-4f13-ba26-5e1cda95cd70" width="100%" height="100" style="border: none; border-radius: 12px;" sandbox="allow-scripts allow-same-origin allow-forms allow-popups allow-clipboard-write" ></iframe> - SAP adopted the InnerSource portal pattern to showcase their projects and shared code with the community. - Other companies improved the portal tooling, illustrating collaborative benefits of InnerSource Commons. #### 💬 Quote > After you released your InnerSource portals and open source project, other organizations adopted it and released companion projects for it. > — Russ Rutledge Russ Rutledge on SAP's contribution inspiring further community development #### 📚 Transcript So that incremented the pattern with examples of how to do it. And we also created another pattern out of it. So we took content from Intersource Commons and we contributed back to Intersource Commons. I think that's a very interesting way to see how companies benefit from what is there in Intersource Commons and how they can give it back. Let me just add on a little bit to that, Guillermo, because after you released your Intersource portals and open source project, which was shared in the inner source commons community, there were other organizations participating in inner source commons that were able to adopt that project and become users of that open source project. And then there was one that released a second open source project as a companion to your inner source portal that would automatically generate the metadata the portal needed from a company's GitHub. So even after that, more companies came on as adopters and a second open source project to enable usage of the portal was shared in the inner source comments. So it's neat to see as a community. And since this is the open source way podcast, familiar with open source should see the magic of open source working to enable inner source. --- ### [Beware the Hype Cycle Trap](https://share.snipd.com/snip/6b394780-c484-4188-a664-1d1cef9d16ea) 🎧 37:21 - 38:28 (01:06) <iframe src="https://share.snipd.com/embed/obsidian-player/snip/89ac9c9e-1c27-4aa7-9924-a284decfacba" width="100%" height="100" style="border: none; border-radius: 12px;" sandbox="allow-scripts allow-same-origin allow-forms allow-popups allow-clipboard-write" ></iframe> - InnerSource is on Gartner's hype cycle entering the 'peak of inflated expectations.' - Avoid hype traps; aim for sustainable adoption reaching the plateau of productivity. #### 💬 Quote > I hope we reach this plateau... that we don't become obsolete and that we continue to deliver real value without inflated expectations or buzzwordiness. > — Guilherme Dellagustin Guilherme Dellagustin on InnerSource's Gartner hype cycle position #### 📚 Transcript You start with a steep slope going up in this innovation trigger, and that's where we are within our source. And we will eventually reach the peak here that is the peak of inflated expectations. I think anybody that works in the industry is familiar with this and has seen this happen with other methodologies. I will mention here Agile, like Agile software development. It is a real thing. It gives real benefits. A lot of people do it right but also a lot of people do it wrong, understand it wrong, and promise wrong things here or force people to adopt it with the wrong expectations. This creates a lot of resistance. And that's where I think we should be very careful within our source to prevent that. So coming back to the hype cycle, from there, you go down and you go down a lot where people realize that they expected too much from the topic. You to this drought of disillusionment. And then from there, you can either become obsolete or you can go up the slope to the plateau of productivity. So I really hope that we reach this plateau. And I hope it's not a plateau that we continue to get more out of it, but that we don't become obsolete. --- ### [Join and Engage on Slack](https://share.snipd.com/snip/6c832f7b-7b49-4bf3-a4bf-1a056c1d4d20) 🎧 41:17 - 41:50 (00:33) <iframe src="https://share.snipd.com/embed/obsidian-player/snip/7b23ea2c-26cd-4ba2-8852-04048ede593a" width="100%" height="100" style="border: none; border-radius: 12px;" sandbox="allow-scripts allow-same-origin allow-forms allow-popups allow-clipboard-write" ></iframe> - Join the InnerSource Commons Slack to engage with active practitioners. - Use familiar daily tools (e.g., Slack) to ease community interaction and adoption. #### 💬 Quote > Most of the active conversation is happening on Slack... everybody was using slack when we started in 2015 so we used it too. > — Danese Cooper Danese Cooper on using Slack for InnerSource Commons community #### 📚 Transcript The videos on the very top or? Well, Russ is correct that you want to immediately get a Slack account because most of the active conversation is happening on Slack. And there's been some criticism in the open source community for using a non-open tool. But one of the learnings that I took away from PayPal's implementation of the Agile is if you make people use tools that they're not already using every day, it is just one more thing they can push against. everybody was using slack when we started in 2015 so we used it too yep --- ### [Fix Legacy Engineering Courageously](https://share.snipd.com/snip/49c3e70a-102c-431b-96ab-1f9c0743994c) 🎧 42:13 - 43:13 (00:59) <iframe src="https://share.snipd.com/embed/obsidian-player/snip/c45aeec4-1581-4d8a-8b5e-60f82faf5716" width="100%" height="100" style="border: none; border-radius: 12px;" sandbox="allow-scripts allow-same-origin allow-forms allow-popups allow-clipboard-write" ></iframe> - Fix legacy engineering problems with courage, trial, and management support. - Make work fun and foster community to avoid burnout and increase collaboration. #### 💬 Quote > If you're not having fun at work, you're doing it wrong. > — Danese Cooper Danese Cooper on improving engineering culture #### 📚 Transcript Sure. I think it is very possible to fix the things that are wrong with legacy engineering, with some courage and some trial and error and enough grace from management to get the time to do it. It is an investment totally worth making if you're planning to survive past the next decade, say, because the more accretion that occurs in your engineering, the less agile you are, the less nimble you are, and the less able you are to address real world problems. So that's point one. Point two is if you're not having fun at work, you're doing it wrong. And we really espouse that at Inner Trust Commons. As a group of people, we do like each other. We hang out and have conversations. We spend time together that we don't have to spend together because we're like-minded. But also we want our work to be fun. We don't want to go back to the salt mines and we don't want anybody else to have to live there either. --- Created with [Snipd](https://www.snipd.com) | Highlight & Take Notes from Podcasts