Welcome to The Open Source Way.
This is our podcast series,SAP's podcast series about thedifference that open source can be.
And in each episode, we'll talkwith experts about open source andwhy they do it the open source way.
I'm your host, Karsten Hohage.
And in this episode, I'm goingto talk to Danese Cooper, RussRutledge, and Guilherme Dellagustinabout InnerSource Commons.
Hey all, nice to have you here.
Hi, Karsten.
Hi, Karsten.
Thanks, Karsten.
Great to be here.
All right let's look atwho these people are.
Danese Cooper is a well-knownadvocate for open source.
She is also the founder of theInnerSource Commons Foundation.
During her career in tech, she hasfocused on manifesting better softwareengineering outcomes by fostering
healthy community practices andimplementing transparent processes.
She says that she abhors silos.
Russ Rutledge is the executivedirector of the InnerSource Commons.
He also serves as senior directorof InnerSource and collaborationat WellSky, the health technology
company leading the charge to makehealthcare better for everyone.
And Russ's drive and passion is to enableall software engineers worldwide toachieve incredible results via streamlinedcollaborative InnerSource processes.
Absolutely.
All right.
Guilherme is a software developer whoacts as InnerSource officer at SAP.
He is also a member of the InnerSourceCommons Foundation, and as InnerSourceOfficer, Guilherme co-leads the
InnerSource program at SAP and helpsto spread the practice in the company.
He was also the producer of thisvery podcast all through 2023.
In his free time, he has his own podcastand talks about retro video games, whichI don't even think I knew, but I'd like
to get into this now, Guilherme, butthis is not really our topic today.
InnerSource comments is the topic, and weshould maybe start with a quick reminderwhat InnerSource even is, in case people
haven't listened to the 2 - 3 podcastepisodes we already did about this topic.
Danese, do you want to take that?
Sure.
When people ask me what InnerSourceis, I usually say first thatit's using open source methods.
to get better engineeringoutcomes inside a firewall.
So, acting as though you'redoing open source, even ifyou're just inside your company.
And.
that would be mostly using which aspectof open source inside the firewall?
Well, open source could bedescribed as massively parallel,peer reviewed computing.
So, the idea that everything you do istransparent to the other people thatwork in your company and that they havethe right to read the code learn from
it, occasionally contribute to it, andprobably make it better, but also knowmore about how the software that theircompany 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 developsilos inside their engineering
organizations, but I can't see thatthe benefits of siloing outweighthe detriments, which are many.
It's very common for people to leavea company and be the only expert inthat silo and leave the company kind of
rudderless around that piece of code,and then they, it becomes concretized.
People never change it becausethey're afraid to break it, but theyalso don't go in and learn about it.
They're more likely to mount aproject to replace it, but it'sjust inefficient and unfortunate.
You could just as easily developlocal expertise by fosteringinformation across the whole company.
So, the people that have to usethat software can get involvedin its creation and maintenance,even if it's not their normal job.
Another way to think of it isengineers don't have to wait aroundfor somebody else to do something.
They can actually scratchtheir own itch, which is a bigpart of open source as well.
All right, there was one interestingaspect that I had never considered so far.
That is basically thesuccession management type ofresilience that it produces.
yep, I'd never really thought about that.
I always thought about the openinnovation, collaborative and so on.
But that's another interesting point.
Yeah.
There's a couple of other interestingthings like that, that it does.
One of the things that open source doesis because so many people are lookingat the code at the same time, we say,many eyes make all problems shallow.
So, they can find answers, they can fixbugs because, you know, everybody hasa different take on what the problemis, and some of them are unique.
The person who wrote ithasn't thought of that yet.
But when you look at the aspect ofhaving more people in the companyunderstand the code, it is shocking to me.
how many companies have devolved intobasically warring feudal factionsinside the engineering organization,where they're competing for resources.
They're all pretty sure that whatthey're working on is the crownjewels of the company, and they'reguarding it exactly like a fortress.
And they don't want anybodyelse to understand how it works.
And there's lots ofreasons why that happens.
But the fact is, the peoplethat wrote that were paidto do it by their employers.
It belongs to the company.
and the idea that you would lockother people in your same companyout of understanding all the code
is pretty, short sighted becauseit creates all kinds of problems.
Yep, absolutely.
That's why, I guess, Guilhermeand I are also glad that we workin this organization, with an
SAP that has the exact task tonot do this and work cross areas.
But let's come to the InnerSourceCommons more specifically: Russ,as you're currently heading that,
what exactly are the InnerSourceCommons or what's the foundation?
So, the InnerSource Commons Foundationis a nonprofit organization tosupport the InnerSource Commons and
its mission of spread and adoptionof InnerSource in the industry.
The InnerSource Commons is an onlinecommunity, wonderful group of peoplethat's just growing larger andlarger, every day and every week.
The foundation supports this communityby providing, tools and an onlinespace for the community, to meet.
There's an online continuous, chat inour Slack instance where people arecontinuing to talk about InnerSource.
And really, it's about bringing acommunity together so that we canall learn from each other about
best ways to practice InnerSourcein our respective organizations.
This online community and foundation, onething that's really unique about it andthat we're proud of is that its mission
is to educate and spread InnerSource toevery person, every company in the world.
It's not a pay to play model wherethe foundation is only supportingor interested in working with thosethat pay, money to the organization.
In fact, there is a membership programin the InnerSource Commons Foundationand membership is given to individuals
and it's, irrespective or outsideof their company of affiliation.
and that membership in the foundationtransfers and goes with them,even if they change employers.
Membership has to be earned throughcontribution and activity in theInnerSource Commons community.
So, in the way that the InnerSourceCommons Foundation and theonline community is set up, we'rereally practicing what we preach.
A lot of the problems around InnerSourceand the challenges and opportunitiesthat are had as people are working
on InnerSource in their differentorganizations, a lot of those are shared.
We hear from people at companiesall across the world that sometimeshave very similar problems andchallenges in rolling out InnerSource.
and opportunities.
And the InnerSource Commons provides away to solve those challenges together, sowe don't have to have people at companiesacross the world re-implementing them.
So, the thing I love about this isthat InnerSource is about breaking downsilos and not reinventing solutionsto challenges within a company.
Yet, across the industry, we'repracticing that same principlein the InnerSource commons.
It's truly an open source community wherewe come together to collaborate in theopen, using open source methodologies on
producing educational material, tooling,documentation, to help in the adoptionof intercourse across the industry.
So, the InnerSource Commons is thelargest and only significant onlinecommunity dedicated to learningand education around InnerSource.
So, it is the worldwide centralneutral hub that stewards the body ofworldwide knowledge of InnerSource.
Nice.
I particularly like the concept thatyou cannot buy the badge basically andstick it on your website, member of
the InnerSource Commons, but ratherhave to contribute to become a member.
I love that.
Not that we won't take your moneyif you're a company and you seevalue in InnerSource Commons andyou want to see it persist, right?
but most of the design features ofthe InnerSource Commons communitycame straight out of the ApacheSoftware Foundation community.
which is a famous project I'vebeen involved with basicallyclose to the time that it started.
And they also have membershipthat you cannot buy.
You have to earn.
but they also take sponsorships andpatronage from interested partiesthat can afford to support it.
Okay, okay.
You don't get the fame for themoney, but we're not afraid ofyour money is the message, right?
That's correct.
Okay.
Okay.
And I think it's really a testamentto the mentality and meritocracy,way of thinking of our sponsors to
support this model, and incidentally,SAP is a sponsor of the InnerSourceCommons, which we're thankful for.
And I think it's really a testamentto that enlightened state of mindto be able to sponsor and support
financially a community which then turnsaround and is based on meritocracy.
And because of that, the community,I think, is an amazingly,welcome and fruitful placefor knowledge collaboration.
When you're rewarding and elevatingthose who are tangibly committing to thespread of InnerSource and the furthering
of the community, what you get ispeople that are motivated to have thathappen and to help each other to do it.
And so, the InnerSource Commons is anincredibly welcoming place and a placewhere there's real tangible advancementin the mechanics of effective InnerSource.
there's not an activity that's happeningthere, that stays just at a surface level.
People are there.
Because of the setup, because they wantto be, and I think that shows in thequality of output and, publication,
documentation, and videos that areproduced in the InnerSource Commons.
Okay, now that we hopefully allunderstand what the current mission isand what's happening in the community,let's maybe jump back in time a bit.
Danese, for all I know, you arethe founder of the InnerSourceCommons, or at least one of, youtell me, how did that come about?
Well, I've been working in tech for about40 years now and, I've worked in somefamous proprietary companies, and I was
often very frustrated as an engineeringmanager with the artificial roadblocksthat internal politics can create.
The famous story is theguy who wrote QuickTime.
Peter Hottie was 16 when he wroteit, which isn't even legal inAmerica now, but back then it was.
And he was a hotshot kid, and hewas pretty sure that his way ofdoing things was the right way.
The project that I worked on forApple that became what is nowcalled FaceTime, was an attempt to
figure out if we could use QuickTimeover the internet to communicateand, in sound and pictures, right?
Peter was mad at us for taking half of theengineering resources out of the QuickTimeteam to work on this other thing.
because his prime directive wasto make the Mac the preferredvideo editing tool in the world.
And we all thought that this otherthing was going to be more importantin the long run, touch more lives.
And so, we were working on it, buthe cut out our ability to look atour own code trees in QuickTime.
He basically closed down his treesand we had to reverse engineerand guess and wheedle and do all
kinds of really time-consumingstupid things to make progress.
Alright, now the reason I can namePeter Hottie, and he won't mind that Inamed him is, he has since apologized.
He found me in front of Moscone Centerin San Francisco at a Java 1 to tellme that he really admired the work
we were doing in open source and thathe was wrong all those years ago.
He was young.
He didn't know.
But it absolutely cemented my resolvethat we had to find a better way towork on engineering inside a company.
And when I went to Sun, they had promisedto open source Java and they hired meto 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 waywas that this was in fact thebetter way that I was looking for.
And if I could figure out how to makeit palatable to companies, that wouldonly be better for everybody concerned.
You know, once you get a taste of thatfreedom and the ability to solve yourown problems, you don't want to go back.
And so, I was involved in a lot of famousopen source projects over the years.
I was the CTO of Wikipedia at one point.
which means I ran the engineering sideof Wikipedia because I just felt it wasthat important to take on that crazy job.
But I also did a lot of consulting.
Tim O'Reilly, who, is a famous publisherin our world, O'Reilly Media, had alsoseen that the open source methods couldbe used inside a company to good effect.
And he and Brian Bellendorfactually started a companythat was supposed to do that.
But it was too early.
Because open source hadn'twon in the marketplace yet.
So, the big companies were stillspending a lot of time downplaying itor making fun of it, because some ofthe people involved were kind of kooky.
Let's just say extra normal,but not, not so normal.
And that was to our advantagein the open source race.
But what I found over my years ofconsulting was that they weren'table to make that into a businessin 2000, 2001, because it was too
early – but a time was coming when opensource would be declared the winner,and which happened in about 2015.
And then I immediately switched to,we have to start talking about doingthis for every engineer, regardless ofwhether there's their code is public.
Because I was only about 15 percentof the engineers in the worldworking in open source, and so
very outsized impact for the numberof people actually working on it.
But the other 85 percent of ourengineering brothers and sisterswere still, toiling away in the
salt mines of silos and exclusionsand, counterproductive patterns.
And so, I realized in my ownconsulting to PayPal that they weregoing to have to learn how to share
internally before they could beexpected to do real open source work.
I've seen a lot of companies spend alot of time and energy and politicalcapital trying to do open source beforethey learn how to share internally.
that's kind of the root cause problemthat 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 todistinguish it from open source.
So, I decided I was going to useInnerSource methods to help PayPal getto a point where they could be successfulin their open source aspirations.
then as I was drivinghome that day, I realized.
from my other consulting, that actuallyevery client that I had ever hadneeded to take that step and that thenumber of clients that were going to
get to open source was diminishingbecause most everybody that was leftwas even more stuck in the accretionof old habits in their engineering.
And so, I called up my assistantDuane, O'Brien and I said, geton GoDaddy and, grab as manyvariations of InnerSource as you can.
And he couldn't get “innersource.org”because there was already somebodyusing it to describe a yoga practice.
So, we, so we went with“innersourcecommons.org”.
And then when we named theorganization a few years later, whenwe finally incorporated, we called
it “InnerSource Commons Foundation”because of Apache Software Foundation.
So yeah, that's why I did it.
My secret, secret mission?
I believe that once engineers geta taste of working this way, theywon't go back to the old way.
And the best place for themto feel that pure experienceis in the open source world.
We cannot make open sourcedevelopers fast enough.
The demand is much greaterthan the output of engineersthat we're creating worldwide.
And so, tapping into existing engineersthat already know how to maintaincode and just don't understandhow to do it in a transparent way.
When they fall in love with workingthat way, it should be easy to get afew of them to go work in open source.
So that's the secret goal, butit helps your organization,even if that never happens.
Apparently you have already convinceda good number of people and largerorganizations there, and I guessthe ‘which is driving which’?
Sometimes I believe that theopen source approach can alsodrive the InnerSource approach.
Yup, it sure can.
And vice versa, as you just put it before.
But so that we convince even more people,let's just name the website again.
As you said, “Inner Source” was already…
It's a mouthful.
It's “innersourcecommons.org”.
Yeah, and all in one word.
By the way.
I can see how “InnerSource” is a yoga website.
I see the point here as well.
Yeah, we use the one word.
We ‘camel case’ it; that's anold 90s term from Pearl, right?
So, it has a capital ‘S’ in themiddle of the word, but we use itas one word because when we startedusing the term ‘inner’ and ‘source’
with a space in between, [it] got youanswers in your Google search thatwere not what you were looking for.
But if you did it in one word, you couldfind stuff that actually pertained.
Okay; so, if I go there, toinnersourcecommons [in one word].org, Russ, what do I find these days?
Innersourcecommons.orgis the gateway to our
community and also the showcase of theoutput of the community, which again ishelping you to adopt and be successfulin the practice of InnerSource.
The most important thing, right away, whenyou arrive at the webpage, is to clickthe link to join our Slack – so you can
stay connected with the community and haveconversations with other practitioners.
There's a lot of bleeding edge scenariosand challenges that people are findingaround InnerSource, and those aregoing to be discussed in our Slack.
I think we're a young practice,as software practices go.
We recently showed up, [starting lastyear in 2023] on the Gartner Hype Cycle,and we're on the beginning part of that
curve, so there's a lot still to discover,so you want to stay connected with thecommunity through joining the Slack.
Now, just having a conversation withpeople on Slack about InnerSource isnot a scalable way to educate the world,and to support everyone in the world.
And so, a lot of our goals as a communityis to produce more durable materialsfor training and spreading InnerSource.
One of the first of these was what wecall the InnerSource Learning Path.
And all these that I'm goingto share, you can find themin the Learn menu at the top.
It's a menu for learningabout InnerSource.
So, the Learning Path is a seriesof short videos and articles justintroducing the fundamental conceptsof InnerSource and how it works.
the first videos weremade by Danese and myself.
I think it's been maybesix years or so ago now.
It's hard to believehow that's gone around.
So, those were produced in partnershipwith O'Reilly Media, one of theirrecording studios, and those are availablefree to the world, linked on our website,
and they're also on our YouTube channel– so it's a great place to go just foran overview of what is InnerSource,how does it work at a high level.
But then, understanding these basicconcepts, you're gonna have some morequestions about specific situations,
like, ‘when the rubber meets the road,what do I actually do for such andsuch a situation about InnerSource?’.
When you get there, the next usefulasset to you is one of our online booksin our Books menu, InnerSource Patterns.
It's our most popularbook that we've published.
It's, online.
You can read the book online.
There's a few that's been printed, but notmany, mostly just an online book that hasover 10, 000 views every month from peoplelearning about InnerSource Patterns book.
And what it is, it's not a book thatyou need to read from beginning to end.
Each article in the book might be two tothree pages in length, and it addressesjust one particular aspect of InnerSource.
if you're having this kind of challenge,and this is the setup at your company,here's something that you can try.
And so, all the patterns are creativelynamed, there's, InnerSource Portal is apattern, or Gig Marketplace is a pattern.
You can go and read about how thesesimple ideas can help you withchallenges that you're having withInnerSource in your organization.
So, you can check out the Patterns book.
also, those patterns can beread individually or as a set.
You don't have to read the whole book.
You can just read one, one pattern thatyou're interested in, that's just fine.
Can I jump in here?
Because when you say patterns in this.
tech context that we're generally in Ithink of architectural patterns, like,is this a push or a pull process orwhatever pattern, does it relate to that
It's patterned after the work ofChristopher Alexander, who was anarchitecture professor in Oxford.
he wrote two books the first one iscalled A Pattern Language of Architecture.
And what he did was use scientificmethod to describe elements ofarchitecture and the emotional effect
they have on people to try to getarchitects to make choices based onthat, what they were trying to create.
Yeah, and this is physicalconstruction architecture.
You're talking about Danese, right?
Just to clarify, not softwarearchitecture here in this example.
Yeah, physical architecture.
But then it became very popularto talk about pattern languagesfor object-oriented programming
around the time that Lisp wasinvented, and we did one for Java,we did one for Genie back at Sun.
All of this was sort of invented at BellLabs, and, you know, this is the advantageof having been in the industry so long.
I have been collectingtricks like this forever.
And it was clear to me the sameday that we got the domains forInnerSource Commons that we weregoing to need a pattern language.
And when we talk about, “Okay, now wehave physical architecture, we havesoftware architecture, we have patterns”,now you say InnerSource patterns.
Just so we can picture this,do you have an example?
Oh, yeah, we had several.
One that you can describewithin 17 seconds or something?
Sure.
So, the engineers at PayPal thatmanaged the big silos were verynervous to take contributions fromengineers that were not in their group.
And one of their concerns wasthat those people wouldn'tbe around if something broke.
And because they hadn't written the code,how would they support it in real time?
Because, you know, PayPal isbasically a bank, so time is money.
And so, we landed on a pattern that isin the book called the 30 day warranty.
And that is the engineers that aredonating the code the contributors promisewhile they're donating the code that
they will be around for 30 days afterthe code is commercially deployed by thecompany to address any issues that arise.
And it was important that it be fromdeployment, not from, merge into the codebase because sometimes it's too risky to.
change things like around Christmas,PayPal doesn't change anything if theycan help it, because that's when all
the money moves, and they don't wantto destabilize the system at all.
Okay, so if you wanted to retain employeesin the company, you would just accept thecode, but totally wait with the deploymentand then they'd have to stick around.
Uh, no, it doesn't work quite that way.
We wanted to be sure that they werearound when they needed to be around.
Okay, okay, just kidding.
Guilherme, in the first place,what are you doing here?
Anyway?
No, I said what you're doing here.
You are the InnerSource guy within SAP.
Do you have examples or stories?
similar ones to tellfrom within our company.
Yeah, of course.
you asked what I have been doinghere so far, I have been delighted tolisten to our other guest speakers.
I mean, especially the story aboutthe foundation, the foundationof the foundation, let's say.
And that's one of the things that makesme proud of, us at SAP having thispodcast and having participated inthe production of the podcast before.
So that's always, very interesting.
And coming back to yourquestion, about the patterns.
as you mentioned in the beginning,I am an InnerSource officer at SAP.
And what does that mean?
It means that I am taskingwith scaling the practice ofInnerSource in the whole company.
When we think about patterns, we havedifferent types of patterns, and I liketo divide them into patterns that can
address problems that projects adoptingInnerSource might have, and alsopatterns that might address problems
people like me are having, like tryingto scale in our source at the company,so I like to divide them like that.
One of the examples, the onethat Danese mentioned, it'scalled 30 day warranty, right?
when one team defines a certain type,or when one team defines a certaintime in which the contributor hasto be available for maintenance.
And this is something that we haveseen already being adopted at SAPfor some projects and that we oftenrecommend because when we talk to
people, when we want to influencethem in adopting in our source, thisis a very common fear that they willhave to take code from other people.
So, we preemptively already tellthem, hey, this is a pattern thatyou can use to mitigate that.
Now, we also have some patterns thatfall a little bit in between what is aproblem of a project and what is a problemof scaling the practice in the whole
company, like for instance, we do havetemplates that we give to the projectsand there we adopt one pattern that iscalled the standard base documentation.
So, there are well known files inour source projects and also opensource projects that document thingsthat are expected by contributors.
Like for instance, what is thecontribution guidelines in the projectthat we put in the contributing.
md or what are ways of users of theproject to get support in the support mdor how is the governance of the project.
So, we already provide that.
So, we adopt that pattern in two ways.
When we tell the projects to adoptit, and we adopt it when scalingthe practice to the whole company.
Another example was already mentionedbefore is the InnerSource portal.
And this is a very interestingcase because we can alsouse it to showcase how.
We as a company engagewith InnerSource Commons.
So, this is a pattern that we adoptedat SAP to showcase all the projectsthat are adopting InnerSourcein their source code repository.
So, it's an internalwebsite where they can go.
And every project that is adoptingInnerSource can put themselves outthere, and anyone looking for InnerSource
projects will look into this websiteand learn what is already out there.
So, this is not a problem that is specificto one project, but for the whole company.
So, anybody in the company can go thereand search for these projects there.
And this raised the need toanother, problem that we had tosolve, 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 youhave to decide how to sort them.
So, we decided that we would not simplytake a metric like number of commits,or number of stars, or something like
that, but we came up with a magicnumber that we called activity score.
and we shared with the community howto, or how we decided to calculatethat score through a pattern.
I think this is a very good example ofthe give and take from a company and theirrelationship within our source commons.
I mean, we consumed a pattern, welearned about how to do something,we implemented that pattern, then we
contributed back to the community bysharing the source code of our portal.
So that incremented the patternwith examples of how to do it.
And we also createdanother pattern out of it.
So, we took content from InnerSourceCommons and we contributedback to InnerSource Commons.
I think that's a very interestingway to see how companies benefitfrom what is there in InnerSourceCommons and how they can give it back.
Let me just add on a little bit to that,Guillaume, because after you releaseyour InnerSource portals and open
source project, which was shared in theInnerSource Commons community, therewere other organizations participating
in the InnerSource Commons that wereable to adopt that project and becomeusers of that open source project.
And then there was one that released asecond open source project as a companionto your InnerSource portal that would
automatically generate the metadata theportal needed from a company's GitHub.
So even after that, more companiescame on as adopters in a second.
Open source project to enableusage of the portal was sharedin the InnerSource Commons.
So, it's neat to see as a community.
And since this is the Open Source Wavepodcast, everyone, familiar with OpenSource should see the magic of OpenSource working to enable InnerSource.
It's a really great story.
Okay, so a couple of the importantthings I've understood is an importanttype of content that I find on theInnerSource Commons website is patterns.
Of course, as anything else, the patternsgrow from contributions, from the membersor even the non-members who may yetbecome members by, contributing patterns.
Well, okay, you say individualsare members, but can I find alist of companies that practiceInnerSource and their stories?
Yeah, absolutely.
Okay.
You got at the top, there's a Storieslink, I think in our community section.
You'll find there, I'm not sure how manywe have, 50 to 100, several dozen stories.
Each is linked to a written ora video describing what thatcompany is doing with InnerSource.
Lots of examples.
And as a member of the community andalso putting here from the perspectiveof how companies tell their stories inInnerSource Commons, SAP has already
participated in that way by presentingits own story and its own practicesin several of the InnerSource Commonssummits and InnerSource events.
And we have also shared blog posts,we have created podcasts about it.
And although we have created and hostedsome of this content, we also usedInnerSource Commons to multiply it because
they have a newsletter, and they collectthis kind of content from companies.
So, if you subscribe to it, everymonth, you're going to have acollection of stories from differentcompanies and how they are doing.
And I think that by contributingto patterns, by exchanging, thisinformation in the community bycreating this blog posts and every
kind of content that this is one wayin which the companies tell theirstories there in their source commons.
And I think that's really importantbecause showing people what benefitothers have had has always been, call it
InnerSource, call it knowledge management,the hype term of the early 2000s.
It was always about showing peoplereally what the benefit is, rather thanjust putting information out there.
So, I think this is great.
Now, we've talked that thisis a lot about community.
You've mentioned a coupleof the channels and so on.
I want to get back to something.
I think Russ, you briefly mentionedthat in, how far would you saythis is going ‘hype term viral’?
As in, how much growth of individualsfrom different organizations doyou see, and is it geographicallyglobal or are there certain hotspots?
Yeah, it's a good question.
InnerSource is, gaining momentum, evenoutside of what we're, pushing on orevangelizing in the InnerSource Commons.
I remember when starting withDanese in that 2015, 2016 timeframe.
It felt like we personally knew everyonethat was doing InnerSource in theircompany and, you know, we gatheredoften, our little band of InnerSourcers,
half dozen, dozen, twenty, and so on,and now we're at the point where thereare new stories around InnerSource,
showing up, we have no idea how theyfound out about InnerSource, and theyshow up in the InnerSource Commons, too.
Luckily, we're the center ofInnerSource in the industry enoughthat we do hear about it when peoplespontaneously find out about InnerSource.
and join us.
So, I mentioned before, we showed uplast year in the Gartner Hype Cycle.
So, we're on the way up to thepeak of the hype cycle right nowis where they showed us on there.
We also appeared in the Gartnerreport of top technology trends,last year for 2023 is the, first.
technology trend, listed.
InnerSource, we're right there next to AI.
we haven't seen the 2024 report, sowe don't know where we'll show up.
But it is gaining andhaving, a life of its own.
Of course, we're very happy to seethat as the InnerSource Commons.
So, because it has such a life ofits own and new people are findingInnerSource Commons all the time.
A lot of what we're focused on rightnow as a foundation is supportingthose who are finding InnerSourcealready so it can live up to the hype.
We don't have to do a whole lot rightnow of intentional spreading, although wedo do that, but as people find out about
it anyway, our goal is just making surethey're finding the InnerSource Commons.
and they have the tools they needto deliver on the hype so it canlive up to what they're hoping.
So yes, it's spreading.
It has legs of its ownand we're excited for it.
You mentioned a little bitabout, it being a community.
I can give some testimonial here, as botha person who is interested in the topic,and as an employee of a company who wants
to apply the practice and wants to be alsoseen as a thought leader for the practice.
Often other people reached outto me as an SAP employee who isrecognized as a practitioner.
So, I am building a network and see alot of people that were interested fromother companies, like I already spoke
with people from Mercedes Benz, fromLufthansa, from Siemens, many importantcompanies are interested in this topic.
Bosch, of course.
And so, this shows thatthere is a lot of interest.
There is a lot of opportunity forpeople to grow a network, to exchange.
But in the other hand, I also want togive a word of caution here, becauseif people are familiar with the Gartner
Hype Cycle, the word hype shouldalready tell you, to be careful, right?
You start with a steep slope goingup in this ‘innovation trigger’, andthat's where we are within our source.
And we will eventually reachthe peak here, that is thepeak of inflated expectations.
I think anybody that works in theindustry is familiar with this andhas seen this happen with other
methodologies.
agile, like agile software development.
It is a real thing.
It gives real benefits.
A lot of people do it right, butalso a lot of people do it wrong,understand it wrong, and promise
wrong things here, or force people toadopt it with the wrong expectations.
This creates a lot of resistance, andthat's where I think we should be verycareful within our source to prevent that.
So, coming back to the hype cycle:from there you go down and you godown a lot where people realize thatthey expected too much from the topic.
You go to this ‘trough of disillusionment’and then from there, you can eitherbecome obsolete or you can go up theslope to the ‘plateau of productivity’.
So, I really hope that we reach thisplateau, and I hope it's not a plateau– that we continue to get more out ofit, but that we don't become obsolete.
And then we are careful enough thatthis doesn't become a buzzword, andit continues to deliver the real
value that it can deliver withoutinflated expectations or without peoplethinking it's yet another buzzword.
Guilherme, you know that I'moriginally a geologist by trade, right?
This totally reminded me of thetypical carve of stock pricesof small mining companies.
What you just said, it's the, “Oh, wefound diamonds!” – bam, it goes up, right?
Here's the hype.
And then, “Oh, we don't have theresources to exploit them.” Itgoes down again, just as deeply.
And then they get the resourcesfrom somewhere, and then theyreach the plateau of productivity.
So, this is a pattern thatrepeats itself, basically.
Yeah, truthfully, the hardest thing isthe expectations by senior executives.
They almost never want togive change enough time.
And so, one of the very successfulpatterns that has emerged is onegroup starting to solve one problem
but doing it in a way that allowsmaximal reuse of that solution.
That's how we met Russ.
Russ solved a problem in his last company.
he did it cause it was his day job, buthe couldn't see the point of doing it justonce and then having to start over and doit again for the next team that wanted it.
So, he wrote it in such a way that it wasextensible and then he did the work toevangelize across the company and get asmany people involved as possible in that.
what I find over and over again is whenpeople find that it's safe to collaborateand help each other, they go all in on it.
Most people, because it's so muchnicer than, having to wait around forother people to do stuff and not really
understanding everything that you needto know in order to get the job done.
It just – it works; you know, managementnotices that that's happening.
They then immediately want to turn thatperson into the person that's goingto make it work across the company.
Scaling this is hard, because theparts of the company that don'twant to do it have their own reasonsand they're usually not very pure.
But fear is, a valid reason.
People are afraid of change.
And I think the fear of change and alsothe fear of, is it safe to collaborate?
I think you could probably fill entirebooks with the considerations, the changesyou have to make so that it feels safeto do all that in larger organizations.
We talk about psychological safetya lot in InnerSource Commons.
Yes, I bet, but we don't have the timeto put entire books into the rest, ofthis episode of The Open Source Way.
So let me ask, just two more things.
When people go to theinnersourcecommons.org, what wouldyou advise them to start with,the videos on the very top, or…?
Well, Russ is correct that youwant to immediately get a Slackaccount because most of the activeconversation is happening on Slack.
Okay.
And there's been some criticismin the open source communityfor using a non-open tool.
But one of the learnings that I took awayfrom PayPal's implementation of Agile isif you make people use tools that they're
not already using every day, it is justone more thing they can push against.
And everybody was using Slackwhen we started in 2015.
So, we used it too.
Yep, you use the established toolif you want communication to happen.
I see that point.
And then let's move to ourtraditional final question here.
From this podcast, from everythingyou said, or on top of that – eachone or two points, what wouldyou like people to take home?
The key takeaways, onewould classically call it.
Danese, you want to start?
Sure.
I think it is very possible to fixthe things that are wrong with legacyengineering, with some courage and some
trial and error and enough grace frommanagement to get the time to do it.
It is an investment totally worthmaking if you're planning to survivepast the next decade, say, because.
The more accretion that occurs in yourengineering, the less agile you are, theless nimble you are, and the less ableyou are to address real world problems.
So that's point one.
point two is, if you're not havingfun at work, you're doing it wrong.
And we really espouse that atInnerSource Commons as a groupof people, we do like each other.
We hang out and have conversations.
We spend time together that wedon't have to spend togetherbecause we're like minded, butalso, we want our work to be fun.
We don't want to go back to the saltmines, and we don't want anybodyelse to have to live there either.
Okay, then Russ, do youwant to add to that?
Yeah, I'll focus mine on theInnerSource Commons specifically,which is the title of this podcast.
So just walking away, what toremember, I want to say the InnerSourceCommons is the central neutral hubof InnerSource in the industry.
So come participate in the InnerSourceCommons by joining, learning,and sharing with the community.
All right, Guilherme,anything to add to that?
Yeah, so in the beginning, youmentioned my hobby of retro gaming,and I want to make a reference to that.
So, people may be familiar with thephrase, it's dangerous to go alone.
‘Dangerous’ is not the term I would usehere, but it's not nice to go alone.
But you don't have to go alone.
So, InnerSource is there,InnerSource Commons.
Go with us, let's go together,don't start from zero.
And InnerSource, just like opensource, is here to stay, so onemore reason to join a party.
Okay, then, so, everyone, join the party.
Thank you, Danese, thank you,Russ, and thank you, Guilherme.
Thank you, was a pleasure.
Thank you, Karsten.
Thanks for having us.
Wonderful to be here.
Thank you, Karsten.
Very, very kind to invite us in.
And I was having fun at worktoday, so that point taken.
And thank you all out there forlistening to the open source way.
I hope you had fun listening toit or enjoyed it in some way.
If you did, please share it.
Don't miss the next one.
We're a bit on an irregular schedule bynow, but you're probably well subscribed.
You'll find out and you'll find usin all the regular podcast channels:through your Apple or Spotify app,
or any open source podcast clientthat you could, of course, also use.
So, thanks again and bye bye.
Bye.
Thank you.
Bye bye.
Goodbye.
This is our podcast series,SAP's podcast series about thedifference that open source can be.
And in each episode, we'll talkwith experts about open source andwhy they do it the open source way.
I'm your host, Karsten Hohage.
And in this episode, I'm goingto talk to Danese Cooper, RussRutledge, and Guilherme Dellagustinabout InnerSource Commons.
Hey all, nice to have you here.
Hi, Karsten.
Hi, Karsten.
Thanks, Karsten.
Great to be here.
All right let's look atwho these people are.
Danese Cooper is a well-knownadvocate for open source.
She is also the founder of theInnerSource Commons Foundation.
During her career in tech, she hasfocused on manifesting better softwareengineering outcomes by fostering
healthy community practices andimplementing transparent processes.
She says that she abhors silos.
Russ Rutledge is the executivedirector of the InnerSource Commons.
He also serves as senior directorof InnerSource and collaborationat WellSky, the health technology
company leading the charge to makehealthcare better for everyone.
And Russ's drive and passion is to enableall software engineers worldwide toachieve incredible results via streamlinedcollaborative InnerSource processes.
Absolutely.
All right.
Guilherme is a software developer whoacts as InnerSource officer at SAP.
He is also a member of the InnerSourceCommons Foundation, and as InnerSourceOfficer, Guilherme co-leads the
InnerSource program at SAP and helpsto spread the practice in the company.
He was also the producer of thisvery podcast all through 2023.
In his free time, he has his own podcastand talks about retro video games, whichI don't even think I knew, but I'd like
to get into this now, Guilherme, butthis is not really our topic today.
InnerSource comments is the topic, and weshould maybe start with a quick reminderwhat InnerSource even is, in case people
haven't listened to the 2 - 3 podcastepisodes we already did about this topic.
Danese, do you want to take that?
Sure.
When people ask me what InnerSourceis, I usually say first thatit's using open source methods.
to get better engineeringoutcomes inside a firewall.
So, acting as though you'redoing open source, even ifyou're just inside your company.
And.
that would be mostly using which aspectof open source inside the firewall?
Well, open source could bedescribed as massively parallel,peer reviewed computing.
So, the idea that everything you do istransparent to the other people thatwork in your company and that they havethe right to read the code learn from
it, occasionally contribute to it, andprobably make it better, but also knowmore about how the software that theircompany 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 developsilos inside their engineering
organizations, but I can't see thatthe benefits of siloing outweighthe detriments, which are many.
It's very common for people to leavea company and be the only expert inthat silo and leave the company kind of
rudderless around that piece of code,and then they, it becomes concretized.
People never change it becausethey're afraid to break it, but theyalso don't go in and learn about it.
They're more likely to mount aproject to replace it, but it'sjust inefficient and unfortunate.
You could just as easily developlocal expertise by fosteringinformation across the whole company.
So, the people that have to usethat software can get involvedin its creation and maintenance,even if it's not their normal job.
Another way to think of it isengineers don't have to wait aroundfor somebody else to do something.
They can actually scratchtheir own itch, which is a bigpart of open source as well.
All right, there was one interestingaspect that I had never considered so far.
That is basically thesuccession management type ofresilience that it produces.
yep, I'd never really thought about that.
I always thought about the openinnovation, collaborative and so on.
But that's another interesting point.
Yeah.
There's a couple of other interestingthings like that, that it does.
One of the things that open source doesis because so many people are lookingat the code at the same time, we say,many eyes make all problems shallow.
So, they can find answers, they can fixbugs because, you know, everybody hasa different take on what the problemis, and some of them are unique.
The person who wrote ithasn't thought of that yet.
But when you look at the aspect ofhaving more people in the companyunderstand the code, it is shocking to me.
how many companies have devolved intobasically warring feudal factionsinside the engineering organization,where they're competing for resources.
They're all pretty sure that whatthey're working on is the crownjewels of the company, and they'reguarding it exactly like a fortress.
And they don't want anybodyelse to understand how it works.
And there's lots ofreasons why that happens.
But the fact is, the peoplethat wrote that were paidto do it by their employers.
It belongs to the company.
and the idea that you would lockother people in your same companyout of understanding all the code
is pretty, short sighted becauseit creates all kinds of problems.
Yep, absolutely.
That's why, I guess, Guilhermeand I are also glad that we workin this organization, with an
SAP that has the exact task tonot do this and work cross areas.
But let's come to the InnerSourceCommons more specifically: Russ,as you're currently heading that,
what exactly are the InnerSourceCommons or what's the foundation?
So, the InnerSource Commons Foundationis a nonprofit organization tosupport the InnerSource Commons and
its mission of spread and adoptionof InnerSource in the industry.
The InnerSource Commons is an onlinecommunity, wonderful group of peoplethat's just growing larger andlarger, every day and every week.
The foundation supports this communityby providing, tools and an onlinespace for the community, to meet.
There's an online continuous, chat inour Slack instance where people arecontinuing to talk about InnerSource.
And really, it's about bringing acommunity together so that we canall learn from each other about
best ways to practice InnerSourcein our respective organizations.
This online community and foundation, onething that's really unique about it andthat we're proud of is that its mission
is to educate and spread InnerSource toevery person, every company in the world.
It's not a pay to play model wherethe foundation is only supportingor interested in working with thosethat pay, money to the organization.
In fact, there is a membership programin the InnerSource Commons Foundationand membership is given to individuals
and it's, irrespective or outsideof their company of affiliation.
and that membership in the foundationtransfers and goes with them,even if they change employers.
Membership has to be earned throughcontribution and activity in theInnerSource Commons community.
So, in the way that the InnerSourceCommons Foundation and theonline community is set up, we'rereally practicing what we preach.
A lot of the problems around InnerSourceand the challenges and opportunitiesthat are had as people are working
on InnerSource in their differentorganizations, a lot of those are shared.
We hear from people at companiesall across the world that sometimeshave very similar problems andchallenges in rolling out InnerSource.
and opportunities.
And the InnerSource Commons provides away to solve those challenges together, sowe don't have to have people at companiesacross the world re-implementing them.
So, the thing I love about this isthat InnerSource is about breaking downsilos and not reinventing solutionsto challenges within a company.
Yet, across the industry, we'repracticing that same principlein the InnerSource commons.
It's truly an open source community wherewe come together to collaborate in theopen, using open source methodologies on
producing educational material, tooling,documentation, to help in the adoptionof intercourse across the industry.
So, the InnerSource Commons is thelargest and only significant onlinecommunity dedicated to learningand education around InnerSource.
So, it is the worldwide centralneutral hub that stewards the body ofworldwide knowledge of InnerSource.
Nice.
I particularly like the concept thatyou cannot buy the badge basically andstick it on your website, member of
the InnerSource Commons, but ratherhave to contribute to become a member.
I love that.
Not that we won't take your moneyif you're a company and you seevalue in InnerSource Commons andyou want to see it persist, right?
but most of the design features ofthe InnerSource Commons communitycame straight out of the ApacheSoftware Foundation community.
which is a famous project I'vebeen involved with basicallyclose to the time that it started.
And they also have membershipthat you cannot buy.
You have to earn.
but they also take sponsorships andpatronage from interested partiesthat can afford to support it.
Okay, okay.
You don't get the fame for themoney, but we're not afraid ofyour money is the message, right?
That's correct.
Okay.
Okay.
And I think it's really a testamentto the mentality and meritocracy,way of thinking of our sponsors to
support this model, and incidentally,SAP is a sponsor of the InnerSourceCommons, which we're thankful for.
And I think it's really a testamentto that enlightened state of mindto be able to sponsor and support
financially a community which then turnsaround and is based on meritocracy.
And because of that, the community,I think, is an amazingly,welcome and fruitful placefor knowledge collaboration.
When you're rewarding and elevatingthose who are tangibly committing to thespread of InnerSource and the furthering
of the community, what you get ispeople that are motivated to have thathappen and to help each other to do it.
And so, the InnerSource Commons is anincredibly welcoming place and a placewhere there's real tangible advancementin the mechanics of effective InnerSource.
there's not an activity that's happeningthere, that stays just at a surface level.
People are there.
Because of the setup, because they wantto be, and I think that shows in thequality of output and, publication,
documentation, and videos that areproduced in the InnerSource Commons.
Okay, now that we hopefully allunderstand what the current mission isand what's happening in the community,let's maybe jump back in time a bit.
Danese, for all I know, you arethe founder of the InnerSourceCommons, or at least one of, youtell me, how did that come about?
Well, I've been working in tech for about40 years now and, I've worked in somefamous proprietary companies, and I was
often very frustrated as an engineeringmanager with the artificial roadblocksthat internal politics can create.
The famous story is theguy who wrote QuickTime.
Peter Hottie was 16 when he wroteit, which isn't even legal inAmerica now, but back then it was.
And he was a hotshot kid, and hewas pretty sure that his way ofdoing things was the right way.
The project that I worked on forApple that became what is nowcalled FaceTime, was an attempt to
figure out if we could use QuickTimeover the internet to communicateand, in sound and pictures, right?
Peter was mad at us for taking half of theengineering resources out of the QuickTimeteam to work on this other thing.
because his prime directive wasto make the Mac the preferredvideo editing tool in the world.
And we all thought that this otherthing was going to be more importantin the long run, touch more lives.
And so, we were working on it, buthe cut out our ability to look atour own code trees in QuickTime.
He basically closed down his treesand we had to reverse engineerand guess and wheedle and do all
kinds of really time-consumingstupid things to make progress.
Alright, now the reason I can namePeter Hottie, and he won't mind that Inamed him is, he has since apologized.
He found me in front of Moscone Centerin San Francisco at a Java 1 to tellme that he really admired the work
we were doing in open source and thathe was wrong all those years ago.
He was young.
He didn't know.
But it absolutely cemented my resolvethat we had to find a better way towork on engineering inside a company.
And when I went to Sun, they had promisedto open source Java and they hired meto 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 waywas that this was in fact thebetter way that I was looking for.
And if I could figure out how to makeit palatable to companies, that wouldonly be better for everybody concerned.
You know, once you get a taste of thatfreedom and the ability to solve yourown problems, you don't want to go back.
And so, I was involved in a lot of famousopen source projects over the years.
I was the CTO of Wikipedia at one point.
which means I ran the engineering sideof Wikipedia because I just felt it wasthat important to take on that crazy job.
But I also did a lot of consulting.
Tim O'Reilly, who, is a famous publisherin our world, O'Reilly Media, had alsoseen that the open source methods couldbe used inside a company to good effect.
And he and Brian Bellendorfactually started a companythat was supposed to do that.
But it was too early.
Because open source hadn'twon in the marketplace yet.
So, the big companies were stillspending a lot of time downplaying itor making fun of it, because some ofthe people involved were kind of kooky.
Let's just say extra normal,but not, not so normal.
And that was to our advantagein the open source race.
But what I found over my years ofconsulting was that they weren'table to make that into a businessin 2000, 2001, because it was too
early – but a time was coming when opensource would be declared the winner,and which happened in about 2015.
And then I immediately switched to,we have to start talking about doingthis for every engineer, regardless ofwhether there's their code is public.
Because I was only about 15 percentof the engineers in the worldworking in open source, and so
very outsized impact for the numberof people actually working on it.
But the other 85 percent of ourengineering brothers and sisterswere still, toiling away in the
salt mines of silos and exclusionsand, counterproductive patterns.
And so, I realized in my ownconsulting to PayPal that they weregoing to have to learn how to share
internally before they could beexpected to do real open source work.
I've seen a lot of companies spend alot of time and energy and politicalcapital trying to do open source beforethey learn how to share internally.
that's kind of the root cause problemthat 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 todistinguish it from open source.
So, I decided I was going to useInnerSource methods to help PayPal getto a point where they could be successfulin their open source aspirations.
then as I was drivinghome that day, I realized.
from my other consulting, that actuallyevery client that I had ever hadneeded to take that step and that thenumber of clients that were going to
get to open source was diminishingbecause most everybody that was leftwas even more stuck in the accretionof old habits in their engineering.
And so, I called up my assistantDuane, O'Brien and I said, geton GoDaddy and, grab as manyvariations of InnerSource as you can.
And he couldn't get “innersource.org”because there was already somebodyusing it to describe a yoga practice.
So, we, so we went with“innersourcecommons.org”.
And then when we named theorganization a few years later, whenwe finally incorporated, we called
it “InnerSource Commons Foundation”because of Apache Software Foundation.
So yeah, that's why I did it.
My secret, secret mission?
I believe that once engineers geta taste of working this way, theywon't go back to the old way.
And the best place for themto feel that pure experienceis in the open source world.
We cannot make open sourcedevelopers fast enough.
The demand is much greaterthan the output of engineersthat we're creating worldwide.
And so, tapping into existing engineersthat already know how to maintaincode and just don't understandhow to do it in a transparent way.
When they fall in love with workingthat way, it should be easy to get afew of them to go work in open source.
So that's the secret goal, butit helps your organization,even if that never happens.
Apparently you have already convinceda good number of people and largerorganizations there, and I guessthe ‘which is driving which’?
Sometimes I believe that theopen source approach can alsodrive the InnerSource approach.
Yup, it sure can.
And vice versa, as you just put it before.
But so that we convince even more people,let's just name the website again.
As you said, “Inner Source” was already…
It's a mouthful.
It's “innersourcecommons.org”.
Yeah, and all in one word.
By the way.
I can see how “InnerSource” is a yoga website.
I see the point here as well.
Yeah, we use the one word.
We ‘camel case’ it; that's anold 90s term from Pearl, right?
So, it has a capital ‘S’ in themiddle of the word, but we use itas one word because when we startedusing the term ‘inner’ and ‘source’
with a space in between, [it] got youanswers in your Google search thatwere not what you were looking for.
But if you did it in one word, you couldfind stuff that actually pertained.
Okay; so, if I go there, toinnersourcecommons [in one word].org, Russ, what do I find these days?
Innersourcecommons.orgis the gateway to our
community and also the showcase of theoutput of the community, which again ishelping you to adopt and be successfulin the practice of InnerSource.
The most important thing, right away, whenyou arrive at the webpage, is to clickthe link to join our Slack – so you can
stay connected with the community and haveconversations with other practitioners.
There's a lot of bleeding edge scenariosand challenges that people are findingaround InnerSource, and those aregoing to be discussed in our Slack.
I think we're a young practice,as software practices go.
We recently showed up, [starting lastyear in 2023] on the Gartner Hype Cycle,and we're on the beginning part of that
curve, so there's a lot still to discover,so you want to stay connected with thecommunity through joining the Slack.
Now, just having a conversation withpeople on Slack about InnerSource isnot a scalable way to educate the world,and to support everyone in the world.
And so, a lot of our goals as a communityis to produce more durable materialsfor training and spreading InnerSource.
One of the first of these was what wecall the InnerSource Learning Path.
And all these that I'm goingto share, you can find themin the Learn menu at the top.
It's a menu for learningabout InnerSource.
So, the Learning Path is a seriesof short videos and articles justintroducing the fundamental conceptsof InnerSource and how it works.
the first videos weremade by Danese and myself.
I think it's been maybesix years or so ago now.
It's hard to believehow that's gone around.
So, those were produced in partnershipwith O'Reilly Media, one of theirrecording studios, and those are availablefree to the world, linked on our website,
and they're also on our YouTube channel– so it's a great place to go just foran overview of what is InnerSource,how does it work at a high level.
But then, understanding these basicconcepts, you're gonna have some morequestions about specific situations,
like, ‘when the rubber meets the road,what do I actually do for such andsuch a situation about InnerSource?’.
When you get there, the next usefulasset to you is one of our online booksin our Books menu, InnerSource Patterns.
It's our most popularbook that we've published.
It's, online.
You can read the book online.
There's a few that's been printed, but notmany, mostly just an online book that hasover 10, 000 views every month from peoplelearning about InnerSource Patterns book.
And what it is, it's not a book thatyou need to read from beginning to end.
Each article in the book might be two tothree pages in length, and it addressesjust one particular aspect of InnerSource.
if you're having this kind of challenge,and this is the setup at your company,here's something that you can try.
And so, all the patterns are creativelynamed, there's, InnerSource Portal is apattern, or Gig Marketplace is a pattern.
You can go and read about how thesesimple ideas can help you withchallenges that you're having withInnerSource in your organization.
So, you can check out the Patterns book.
also, those patterns can beread individually or as a set.
You don't have to read the whole book.
You can just read one, one pattern thatyou're interested in, that's just fine.
Can I jump in here?
Because when you say patterns in this.
tech context that we're generally in Ithink of architectural patterns, like,is this a push or a pull process orwhatever pattern, does it relate to that
It's patterned after the work ofChristopher Alexander, who was anarchitecture professor in Oxford.
he wrote two books the first one iscalled A Pattern Language of Architecture.
And what he did was use scientificmethod to describe elements ofarchitecture and the emotional effect
they have on people to try to getarchitects to make choices based onthat, what they were trying to create.
Yeah, and this is physicalconstruction architecture.
You're talking about Danese, right?
Just to clarify, not softwarearchitecture here in this example.
Yeah, physical architecture.
But then it became very popularto talk about pattern languagesfor object-oriented programming
around the time that Lisp wasinvented, and we did one for Java,we did one for Genie back at Sun.
All of this was sort of invented at BellLabs, and, you know, this is the advantageof having been in the industry so long.
I have been collectingtricks like this forever.
And it was clear to me the sameday that we got the domains forInnerSource Commons that we weregoing to need a pattern language.
And when we talk about, “Okay, now wehave physical architecture, we havesoftware architecture, we have patterns”,now you say InnerSource patterns.
Just so we can picture this,do you have an example?
Oh, yeah, we had several.
One that you can describewithin 17 seconds or something?
Sure.
So, the engineers at PayPal thatmanaged the big silos were verynervous to take contributions fromengineers that were not in their group.
And one of their concerns wasthat those people wouldn'tbe around if something broke.
And because they hadn't written the code,how would they support it in real time?
Because, you know, PayPal isbasically a bank, so time is money.
And so, we landed on a pattern that isin the book called the 30 day warranty.
And that is the engineers that aredonating the code the contributors promisewhile they're donating the code that
they will be around for 30 days afterthe code is commercially deployed by thecompany to address any issues that arise.
And it was important that it be fromdeployment, not from, merge into the codebase because sometimes it's too risky to.
change things like around Christmas,PayPal doesn't change anything if theycan help it, because that's when all
the money moves, and they don't wantto destabilize the system at all.
Okay, so if you wanted to retain employeesin the company, you would just accept thecode, but totally wait with the deploymentand then they'd have to stick around.
Uh, no, it doesn't work quite that way.
We wanted to be sure that they werearound when they needed to be around.
Okay, okay, just kidding.
Guilherme, in the first place,what are you doing here?
Anyway?
No, I said what you're doing here.
You are the InnerSource guy within SAP.
Do you have examples or stories?
similar ones to tellfrom within our company.
Yeah, of course.
you asked what I have been doinghere so far, I have been delighted tolisten to our other guest speakers.
I mean, especially the story aboutthe foundation, the foundationof the foundation, let's say.
And that's one of the things that makesme proud of, us at SAP having thispodcast and having participated inthe production of the podcast before.
So that's always, very interesting.
And coming back to yourquestion, about the patterns.
as you mentioned in the beginning,I am an InnerSource officer at SAP.
And what does that mean?
It means that I am taskingwith scaling the practice ofInnerSource in the whole company.
When we think about patterns, we havedifferent types of patterns, and I liketo divide them into patterns that can
address problems that projects adoptingInnerSource might have, and alsopatterns that might address problems
people like me are having, like tryingto scale in our source at the company,so I like to divide them like that.
One of the examples, the onethat Danese mentioned, it'scalled 30 day warranty, right?
when one team defines a certain type,or when one team defines a certaintime in which the contributor hasto be available for maintenance.
And this is something that we haveseen already being adopted at SAPfor some projects and that we oftenrecommend because when we talk to
people, when we want to influencethem in adopting in our source, thisis a very common fear that they willhave to take code from other people.
So, we preemptively already tellthem, hey, this is a pattern thatyou can use to mitigate that.
Now, we also have some patterns thatfall a little bit in between what is aproblem of a project and what is a problemof scaling the practice in the whole
company, like for instance, we do havetemplates that we give to the projectsand there we adopt one pattern that iscalled the standard base documentation.
So, there are well known files inour source projects and also opensource projects that document thingsthat are expected by contributors.
Like for instance, what is thecontribution guidelines in the projectthat we put in the contributing.
md or what are ways of users of theproject to get support in the support mdor how is the governance of the project.
So, we already provide that.
So, we adopt that pattern in two ways.
When we tell the projects to adoptit, and we adopt it when scalingthe practice to the whole company.
Another example was already mentionedbefore is the InnerSource portal.
And this is a very interestingcase because we can alsouse it to showcase how.
We as a company engagewith InnerSource Commons.
So, this is a pattern that we adoptedat SAP to showcase all the projectsthat are adopting InnerSourcein their source code repository.
So, it's an internalwebsite where they can go.
And every project that is adoptingInnerSource can put themselves outthere, and anyone looking for InnerSource
projects will look into this websiteand learn what is already out there.
So, this is not a problem that is specificto one project, but for the whole company.
So, anybody in the company can go thereand search for these projects there.
And this raised the need toanother, problem that we had tosolve, 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 youhave to decide how to sort them.
So, we decided that we would not simplytake a metric like number of commits,or number of stars, or something like
that, but we came up with a magicnumber that we called activity score.
and we shared with the community howto, or how we decided to calculatethat score through a pattern.
I think this is a very good example ofthe give and take from a company and theirrelationship within our source commons.
I mean, we consumed a pattern, welearned about how to do something,we implemented that pattern, then we
contributed back to the community bysharing the source code of our portal.
So that incremented the patternwith examples of how to do it.
And we also createdanother pattern out of it.
So, we took content from InnerSourceCommons and we contributedback to InnerSource Commons.
I think that's a very interestingway to see how companies benefitfrom what is there in InnerSourceCommons and how they can give it back.
Let me just add on a little bit to that,Guillaume, because after you releaseyour InnerSource portals and open
source project, which was shared in theInnerSource Commons community, therewere other organizations participating
in the InnerSource Commons that wereable to adopt that project and becomeusers of that open source project.
And then there was one that released asecond open source project as a companionto your InnerSource portal that would
automatically generate the metadata theportal needed from a company's GitHub.
So even after that, more companiescame on as adopters in a second.
Open source project to enableusage of the portal was sharedin the InnerSource Commons.
So, it's neat to see as a community.
And since this is the Open Source Wavepodcast, everyone, familiar with OpenSource should see the magic of OpenSource working to enable InnerSource.
It's a really great story.
Okay, so a couple of the importantthings I've understood is an importanttype of content that I find on theInnerSource Commons website is patterns.
Of course, as anything else, the patternsgrow from contributions, from the membersor even the non-members who may yetbecome members by, contributing patterns.
Well, okay, you say individualsare members, but can I find alist of companies that practiceInnerSource and their stories?
Yeah, absolutely.
Okay.
You got at the top, there's a Storieslink, I think in our community section.
You'll find there, I'm not sure how manywe have, 50 to 100, several dozen stories.
Each is linked to a written ora video describing what thatcompany is doing with InnerSource.
Lots of examples.
And as a member of the community andalso putting here from the perspectiveof how companies tell their stories inInnerSource Commons, SAP has already
participated in that way by presentingits own story and its own practicesin several of the InnerSource Commonssummits and InnerSource events.
And we have also shared blog posts,we have created podcasts about it.
And although we have created and hostedsome of this content, we also usedInnerSource Commons to multiply it because
they have a newsletter, and they collectthis kind of content from companies.
So, if you subscribe to it, everymonth, you're going to have acollection of stories from differentcompanies and how they are doing.
And I think that by contributingto patterns, by exchanging, thisinformation in the community bycreating this blog posts and every
kind of content that this is one wayin which the companies tell theirstories there in their source commons.
And I think that's really importantbecause showing people what benefitothers have had has always been, call it
InnerSource, call it knowledge management,the hype term of the early 2000s.
It was always about showing peoplereally what the benefit is, rather thanjust putting information out there.
So, I think this is great.
Now, we've talked that thisis a lot about community.
You've mentioned a coupleof the channels and so on.
I want to get back to something.
I think Russ, you briefly mentionedthat in, how far would you saythis is going ‘hype term viral’?
As in, how much growth of individualsfrom different organizations doyou see, and is it geographicallyglobal or are there certain hotspots?
Yeah, it's a good question.
InnerSource is, gaining momentum, evenoutside of what we're, pushing on orevangelizing in the InnerSource Commons.
I remember when starting withDanese in that 2015, 2016 timeframe.
It felt like we personally knew everyonethat was doing InnerSource in theircompany and, you know, we gatheredoften, our little band of InnerSourcers,
half dozen, dozen, twenty, and so on,and now we're at the point where thereare new stories around InnerSource,
showing up, we have no idea how theyfound out about InnerSource, and theyshow up in the InnerSource Commons, too.
Luckily, we're the center ofInnerSource in the industry enoughthat we do hear about it when peoplespontaneously find out about InnerSource.
and join us.
So, I mentioned before, we showed uplast year in the Gartner Hype Cycle.
So, we're on the way up to thepeak of the hype cycle right nowis where they showed us on there.
We also appeared in the Gartnerreport of top technology trends,last year for 2023 is the, first.
technology trend, listed.
InnerSource, we're right there next to AI.
we haven't seen the 2024 report, sowe don't know where we'll show up.
But it is gaining andhaving, a life of its own.
Of course, we're very happy to seethat as the InnerSource Commons.
So, because it has such a life ofits own and new people are findingInnerSource Commons all the time.
A lot of what we're focused on rightnow as a foundation is supportingthose who are finding InnerSourcealready so it can live up to the hype.
We don't have to do a whole lot rightnow of intentional spreading, although wedo do that, but as people find out about
it anyway, our goal is just making surethey're finding the InnerSource Commons.
and they have the tools they needto deliver on the hype so it canlive up to what they're hoping.
So yes, it's spreading.
It has legs of its ownand we're excited for it.
You mentioned a little bitabout, it being a community.
I can give some testimonial here, as botha person who is interested in the topic,and as an employee of a company who wants
to apply the practice and wants to be alsoseen as a thought leader for the practice.
Often other people reached outto me as an SAP employee who isrecognized as a practitioner.
So, I am building a network and see alot of people that were interested fromother companies, like I already spoke
with people from Mercedes Benz, fromLufthansa, from Siemens, many importantcompanies are interested in this topic.
Bosch, of course.
And so, this shows thatthere is a lot of interest.
There is a lot of opportunity forpeople to grow a network, to exchange.
But in the other hand, I also want togive a word of caution here, becauseif people are familiar with the Gartner
Hype Cycle, the word hype shouldalready tell you, to be careful, right?
You start with a steep slope goingup in this ‘innovation trigger’, andthat's where we are within our source.
And we will eventually reachthe peak here, that is thepeak of inflated expectations.
I think anybody that works in theindustry is familiar with this andhas seen this happen with other
methodologies.
agile, like agile software development.
It is a real thing.
It gives real benefits.
A lot of people do it right, butalso a lot of people do it wrong,understand it wrong, and promise
wrong things here, or force people toadopt it with the wrong expectations.
This creates a lot of resistance, andthat's where I think we should be verycareful within our source to prevent that.
So, coming back to the hype cycle:from there you go down and you godown a lot where people realize thatthey expected too much from the topic.
You go to this ‘trough of disillusionment’and then from there, you can eitherbecome obsolete or you can go up theslope to the ‘plateau of productivity’.
So, I really hope that we reach thisplateau, and I hope it's not a plateau– that we continue to get more out ofit, but that we don't become obsolete.
And then we are careful enough thatthis doesn't become a buzzword, andit continues to deliver the real
value that it can deliver withoutinflated expectations or without peoplethinking it's yet another buzzword.
Guilherme, you know that I'moriginally a geologist by trade, right?
This totally reminded me of thetypical carve of stock pricesof small mining companies.
What you just said, it's the, “Oh, wefound diamonds!” – bam, it goes up, right?
Here's the hype.
And then, “Oh, we don't have theresources to exploit them.” Itgoes down again, just as deeply.
And then they get the resourcesfrom somewhere, and then theyreach the plateau of productivity.
So, this is a pattern thatrepeats itself, basically.
Yeah, truthfully, the hardest thing isthe expectations by senior executives.
They almost never want togive change enough time.
And so, one of the very successfulpatterns that has emerged is onegroup starting to solve one problem
but doing it in a way that allowsmaximal reuse of that solution.
That's how we met Russ.
Russ solved a problem in his last company.
he did it cause it was his day job, buthe couldn't see the point of doing it justonce and then having to start over and doit again for the next team that wanted it.
So, he wrote it in such a way that it wasextensible and then he did the work toevangelize across the company and get asmany people involved as possible in that.
what I find over and over again is whenpeople find that it's safe to collaborateand help each other, they go all in on it.
Most people, because it's so muchnicer than, having to wait around forother people to do stuff and not really
understanding everything that you needto know in order to get the job done.
It just – it works; you know, managementnotices that that's happening.
They then immediately want to turn thatperson into the person that's goingto make it work across the company.
Scaling this is hard, because theparts of the company that don'twant to do it have their own reasonsand they're usually not very pure.
But fear is, a valid reason.
People are afraid of change.
And I think the fear of change and alsothe fear of, is it safe to collaborate?
I think you could probably fill entirebooks with the considerations, the changesyou have to make so that it feels safeto do all that in larger organizations.
We talk about psychological safetya lot in InnerSource Commons.
Yes, I bet, but we don't have the timeto put entire books into the rest, ofthis episode of The Open Source Way.
So let me ask, just two more things.
When people go to theinnersourcecommons.org, what wouldyou advise them to start with,the videos on the very top, or…?
Well, Russ is correct that youwant to immediately get a Slackaccount because most of the activeconversation is happening on Slack.
Okay.
And there's been some criticismin the open source communityfor using a non-open tool.
But one of the learnings that I took awayfrom PayPal's implementation of Agile isif you make people use tools that they're
not already using every day, it is justone more thing they can push against.
And everybody was using Slackwhen we started in 2015.
So, we used it too.
Yep, you use the established toolif you want communication to happen.
I see that point.
And then let's move to ourtraditional final question here.
From this podcast, from everythingyou said, or on top of that – eachone or two points, what wouldyou like people to take home?
The key takeaways, onewould classically call it.
Danese, you want to start?
Sure.
I think it is very possible to fixthe things that are wrong with legacyengineering, with some courage and some
trial and error and enough grace frommanagement to get the time to do it.
It is an investment totally worthmaking if you're planning to survivepast the next decade, say, because.
The more accretion that occurs in yourengineering, the less agile you are, theless nimble you are, and the less ableyou are to address real world problems.
So that's point one.
point two is, if you're not havingfun at work, you're doing it wrong.
And we really espouse that atInnerSource Commons as a groupof people, we do like each other.
We hang out and have conversations.
We spend time together that wedon't have to spend togetherbecause we're like minded, butalso, we want our work to be fun.
We don't want to go back to the saltmines, and we don't want anybodyelse to have to live there either.
Okay, then Russ, do youwant to add to that?
Yeah, I'll focus mine on theInnerSource Commons specifically,which is the title of this podcast.
So just walking away, what toremember, I want to say the InnerSourceCommons is the central neutral hubof InnerSource in the industry.
So come participate in the InnerSourceCommons by joining, learning,and sharing with the community.
All right, Guilherme,anything to add to that?
Yeah, so in the beginning, youmentioned my hobby of retro gaming,and I want to make a reference to that.
So, people may be familiar with thephrase, it's dangerous to go alone.
‘Dangerous’ is not the term I would usehere, but it's not nice to go alone.
But you don't have to go alone.
So, InnerSource is there,InnerSource Commons.
Go with us, let's go together,don't start from zero.
And InnerSource, just like opensource, is here to stay, so onemore reason to join a party.
Okay, then, so, everyone, join the party.
Thank you, Danese, thank you,Russ, and thank you, Guilherme.
Thank you, was a pleasure.
Thank you, Karsten.
Thanks for having us.
Wonderful to be here.
Thank you, Karsten.
Very, very kind to invite us in.
And I was having fun at worktoday, so that point taken.
And thank you all out there forlistening to the open source way.
I hope you had fun listening toit or enjoyed it in some way.
If you did, please share it.
Don't miss the next one.
We're a bit on an irregular schedule bynow, but you're probably well subscribed.
You'll find out and you'll find usin all the regular podcast channels:through your Apple or Spotify app,
or any open source podcast clientthat you could, of course, also use.
So, thanks again and bye bye.
Bye.
Thank you.
Bye bye.
Goodbye.
