The Changelog: Software Development, Open Source - Fostering open source culture (Interview)

Episode Date: February 13, 2025

Arun Gupta is back, this time with his latest book in hand titled "Fostering Open Source Culture" to share his wisdom and experiences of fostering open source culture. BTW you can use the code `OSCULTURE20` to get 20% off (both print and e-book). Use this link and enjoy.

This week on the change law we're joined by Arun Gupta back again. Arun is the VP and General Manager of Developer Programs at Intel and he's also the author of Fostering Open Source Culture, a new book out for fostering open source culture. We talked to Arun a few years ago back at All Things Open and we had to get him back on seeing this book out there, digging into the details. This is Arun's seventh book and it is a blueprint, a map for any of the companies out there trying to foster open source culture

inside your organization, increase innovation and deliver faster, of course, with open source. A massive thank you to our friends and our partners over at fly.io. Fly is the public cloud built for developers who ship that you that's me that's us. Over three million apps have launched on fly and you can too. You can learn more at fly.io. OK. Let's foster some open source culture. Well, friends, I'm here with Samar Abbas, co-founder and CEO of Temporal. Temporal is the platform developers use to build invincible applications. But what exactly is Temporal? Samar, how do you describe what temporal does?

I would say to explain temporal is one of the hardest challenges of my life. It's a developer platform and it's a paradigm shift. I've been doing this technology for almost like 15 years. The way I typically describe it, imagine like all of us when we were writing documents in the 90s, I used to use Microsoft Word. I love the entire experience and everything. But still the thing that I hated the most is how many documents or how many edits I

have lost because I forgot to save or like something bad happened and I lost my document. You get in the habit when you are writing up a document back in the 90s to do control S. Literally every sentence you write. But in the 2000s, Google Doc S. Literally every sentence you write. But in the 2000s, Google Doc doesn't even have a save button. So I believe software developers are still living in the 90s era. Where majority of the code they are writing

is they have some state which needs to live beyond multiple request response. Majority of the development is load that state, apply an event and then take some actions and store it back. 80% of the software development is this constant load and save. So that's exactly what Temporal does.

What it gives you a platform where you write a function, and during the execution of a function of failure happens, we will re-select that function on a different host and continue executing where you left off without you as a developer writing a single line of code for it. Okay, if you're ready to leave the 90s and build like it's 2025 and you're ready to

learn why companies like Netflix, DoorDash and Stripe trust Temporal as their secure scalable way to build invincible applications, go to Temporal.io once again Temporal.io. You can try their cloud for free or get started with open source. It all starts at temporal.io. We are back with Arun Gupta. It's good to see you Arun. It's been a couple of years. Yeah, it's been about a year and a half or so. You know, I was really encouraged by our conversation we had at All Things Open.

Love All Things Open by the way. It's been a while. Going back later this year, Arun, you are at Intel. You wrote an awesome book. You've been in open source for, would you say a very long time? Is that how you describe it? A very long time? Or do you say the years? Well, over a couple of decades, let's say. So it's been a while. It's been a while. Gotcha. I like the way you say in your book, of course, too. The book I'm

talking about is Fostering Open Source Culture. We just got our copy today, so we don't have super deep depth, but. There it is. Arun is holding it up. Covering open source culture, business alignment, OSPOs, of course, internal events, inner source, external communities, employee enablement, and then also getting started.

So I mean, this is a book for anybody really trying to do what you've done in your career, which is jumpstart and prime, you know, worthy corporations to really foster and share the joy of open source, but help others do it well. Where should we begin? What made you write this book?

Yeah, I mean, this got my fifth or sixth company where I built that kind of open source culture. My experience really goes back to back in Sun Microsystem, gosh, 2003, four, I mean, literally over two decades ago, where we were taking the entire company from closed source to open source. And back in those days, the Java EE reference implementation was Glassfish. And as we were building that reference implementation, we were putting that out on the internet and simple things like we would have

like a hallway conversation and somebody reminding that, hey, you can't have a hallway conversation less than an email out on the public mailing list so that people in the community can understand what's going on over there. Those are simple cultural nuances. And we did that over a couple of decades ago. And since then, I spent a couple of years at Red Hat,

a couple of years at Couchbase, a few years at Amazon, and about two years at Apple, and now at Intel for about three years. Across all these companies, I've been building developer communities. I've been building, bringing that open source cultural change. And I recognize that the pretty much the recipe is rinse and repeat in that sense.

And as I was moving across these companies, I recognize I kept doing the same things again and again. And I said, hey, and I was also talking to a lot of startups, a lot of other enterprises, a lot of other friends. I'm part of several open source foundation boards. As I talk to senior leaders across the enterprise, I recognize these are very similar recipes. And that frankly said, okay, how do I scale this element? That's what I decided to write the book. So half the book is about my theory in terms of how do you build that open source culture, why that culture is important.

And the other half, the more interesting part I would say is sort of about 40 plus case studies by 55 plus contributing authors on how and why they have built that open source culture. I always love a good case study, that's for sure. Especially whenever it's applicable. Sometimes case studies are just case studies for case studies. Say, because hey, you gotta have white papers

and somebody on your page or whatever, right? Wow, I was digging into some of these. And like I said, I just got my copy today, so I haven't gone through a thorough depth with it yet, but excited to do so. So Arun, you've been at Intel for a few years now. I think when we met, you had just joined, or maybe you were there six months,

or something like this, and you really came on at Intel to foster this open source effort, or I don't know if you call it a community, or this OSPO, this office, perhaps. Can you speak about your experience there, and maybe how you've applied your learnings inside of Intel and what's changed as a result?

Yeah, totally. So I joined Intel about three years ago, April of 2022. And I was hired to build the open ecosystem team. And that's sort of what I built for about a couple of years. Now for the last few months, I lead the broader developer programs effort at Intel. And so for the open source culture part of it, open source program office was part of my team.

My team had the dev rel folks. My team would sponsor the open source foundations. My team would sponsor these open source foundations. My team would sponsor these open source events. We would do speakerships across the industry. We would recognize people internally at Intel who would do the chop wood carry water work, which is so, so essential in terms of keeping an open source project thrive. Because oftentimes code is glory, but the top would carry water is what keeps the project going. So I think those were some of the key elements that we did.

We participated very actively in the inner source practice. We ran a lot of internal open source summits, enablement, advocacy, all sorts of stuff that we did, frankly, to energize the internal engineering community and also telling the story in a credible manner, in an authentic manner to the outside developer community why Intel cares about open source. We have a very long history. I mean, I was looking at it.

Our first commit back to open source was back to the GCC compiler 40 years ago. And over the last 20 years, Intel has been the top corporate committer to Linux kernel. We are one of the top contributors to Kubernetes, OpenJDK. We're among the top three contributors to both PyTorch and TensorFlow. So in that sense, it's the hidden jewel that we never talked about it. So my goal was to really find those stories inside Intel

and tell those stories in a credible, authentic manner to the outside world. Yeah. Yeah, I recall that from our conversation because it was news to me. I just thought Intel, there's not an open source story there. And it just sounded like it was always there to a certain extent, but nobody was telling that story.

It was too far inside, you know, to use your guys' Intel inside. It was too inside for a lot of us devs to even know that Intel was doing open source. So the company was already bought into the overall idea. Does your book also talk about the process of like, advocating not just we should use open source because it's great for our business,

but then taking that next step of like, let's not just be should use open source because it's great for our business, but then taking that next step of like, let's not just be users of open source, let's participate, let's contribute, let's support, et cetera. Was that already established inside of Intel or did you have to bring that to them? No, I think it was very well established inside the Intel. We just had to kind of set up some formal programs where that is more recognized.

And once that is recognized, then it becomes a lot more sustainable. Like, I'm at Intel, but prior to that I was at Apple and prior to that at Amazon. And those are the companies where we had to do a lot of grind work in terms of why open source matters. Like, sure, you can leverage Kubernetes, you know, to the best of your advantage. But if there are issues, if there are challenges in the project, how do we enable our engineers to participate in the open source community? Because you can't expect, you know, to win an NBA game by standing on the sideline. You know, you got to get into the field, you know, get under the three-pointer line, and shoot

something over there to score. And that was the whole narrative there, that, hey, your problems are very unique to you. You can't just file an issue in the GitHub community and say, the community, quote unquote, will resolve it, because there is no nebulous community who going to care about your issues. Open source is all about understanding that fabric, understanding that dynamic, doing the chop wood carry water work so that when you need help, others will be willing to help you out over there. So a lot of it was Kubernetes is built by 80,000 developers across 5,000 companies. There is no need to invest into any such engineering effort.

One or two maintainers is all it takes. Either hire the top maintainers or groom inside the company for somebody to become a maintainer so that then your issues can be resolved. Then, of course, once you become a maintainer or you hire a maintainer, then you don't put them into dark. You only gonna work on my issues, because that's what brings the credibility to the maintainer as well.

That's what brings authenticity to the maintainer as well, that in addition to solving your own engineering challenges, they're continuing to help the community, because that helps them expand their network, their skill set. And what's the best way that a large org, because you're mostly working with enterprise, I mean your history is all enterprise. Of course there's small business and startups as well, but for enterprise to engage obviously like you said, hire existing maintainers or groom

future maintainers of the project. What are the most, that's to me seems like the obvious one of like that's probably the most impact you can have. But so set that one aside, what are the best ways that enterprises can engage with their open source communities? A lot of different ways actually. Oftentimes we think that just the code contribution is the only way you can engage.

One of the chapters in the book is really talking about 10 different ways by which you can contribute to open source communities in a non-code manner. Coding is just one part of it. Project management, these projects are heavy on project management. Bug triage, reviewing the code, technical documentation. And again, these are more on the technical side, but then let's get into a little bit more non-technical side. Usually these projects sit in an open source foundation, and these projects require security

audits. These projects require infrastructure, CI, CD infrastructure. These projects run their events. So you need all sorts of different skill sets in order to sustain these projects. So sponsor those foundations, participate in the governing boards. There are working groups, there are special interest groups like SIGs that drive the technical discussions in these projects. So encourage your employees to participate in those working groups so that they can actually continue to have an impact over there.

For example, Intel allows me to be their rep on the governing board of CNCF, Cloud Native Computing Foundation and Open Source Security Foundation. And about a couple of years ago, when there was an opportunity that, okay, I could stand up for a open source security foundation governing board chair,

so I talked to my boss, that, hey, you know what? This is not an additional job that I'm taking up because it's going to consume a non-trivial amount of my time. She helped me out, said, okay, what do you need? Then she basically allowed me to hire a person who I can offload a lot of my work in terms of internal open source strategy so that then I could take over this role. So I think creating those incentive mechanisms,

recognizing the employees, putting that as part of their annual focal or quarterly insights or their OKRs goes a long way. Because end of the day, we humans are always looking for incentives. So creating those intensive mechanisms, being very deliberate about it, and saying, hey, your bonus really relies upon this or your individual performance kind of relies upon this, goes a long, long way as opposed to like, I don't know why you're contributing to this open source. This, if you start getting down to micro level, that this pull request that you reviewed

does not help to my bottom line, that does not get you anywhere. So I think step back, think at a macro level. How does it help your effort? How does it help the community? Because end of the day, the sustainability of the open source project is super critical. So for example, at

Apple, pretty much all of their services run using OpenJDK. So the sustainability of the project is super critical to them. Because if you were to internally fork the project, OpenJDK is built by thousands of developers. The community knowledge, the intellectual knowledge it brings across that diverse set of developers and use cases is what makes JDK strong. You can't have that kind of a complexity,

that kind of engineering expertise from just one company. So, and that's the beauty of open source. And that's where the management, the middle management, everybody across the chain has to understand that, okay, this is why contribution to open source is critical. What's the hardest pitch to actually sell on the inside of these? Because you're preaching to the choir here,

and so we're very much like nodding along in agreement but certainly people get pushback. And some pushback probably appropriately because it's a lot to commit a lot of resources to something that you don't actually kind of have to commit to. Like yeah, it'd be nice but we do have a quarterly report to get done and we have things to hit and things to sell.

So what are the kind of pitches that struggle to get through and how do you overcome such things? I think the biggest impetus that I've seen across these companies is just purely lack of awareness. You know, when I was at Amazon or when I was at Apple, either of those places, oh, we've always done it this way and we are fairly successful. Why pivot? What is this open source thing? Who cares about it?

And again, granted, this was about a few years ago and a lot has changed over those years. Amazon has definitely become a lot more open source friendly, not so sure about Apple, but it was purely lack of awareness. And so in that sense, the strategy that we saw worked at Apple was that, hey, all of this business around iPhone, Mac, we don't want to touch that at all.

There is no need for that. Then we kind of create those isolation areas that, hey, this Kubernetes thing, this OpenJDK, this PyTorch, this all heavily lives in the open source world. This is completely undifferentiated heavy lifting for you. If we make that work better, that only runs our infrastructure in that much more scalable manner. That helps us cut down our cost

of running that entire infrastructure. One developer, maybe two contributors, two maintainers goes a long way building Apple's credibility. So for example, when I joined Apple, and I've been on the CNCF board for about eight years, when I joined Apple, there were about 40 people that joined after I joined, because that's sort of how the open source world moves.

Oh, this person is big in open source, and he's joining Apple, and I don't know what is going on on Apple. That builds trust and credibility. So in that sense, it becomes like a hiring magnet. So I think all of those things really take time to simmer. I would say first few months were a little challenging because you walk in there and you start questioning everything, you start asking everything and inertia is always hard. Right?

Newton's law of motions always kick in that thing is moving in a certain direction, you're trying to change the direction, say, wait, wait, wait, what's going on here? So I think in that sense, that was a bit challenging, but I was talking to my team, you know, my ex team from Apple, and they're saying, hey, we have, because that team now exists, I built the first open source program office at Apple, and they were saying, we have such a wonderful relationship

with engineering, with legal, with marketing. They understand the value that we bring, a lot more streamlined operations. In that sense, I would say a bit of a patience is required that, okay, things are going to work out and perseverance is required. Understanding what the management wants, understanding how you're going to operationalize it across middle management to the engineering level is all that it takes. Being very patient, being very perseverant, and being very clinical about it.

That, okay, I'm not trying to change the world, I'm not trying to boil the ocean. Here are a few simple steps that would make it work for us. Because in open source, we talk about self-interest. Does that matter? No. That's exactly what works actually as a matter of fact. I'm not doing this for the charity.

It's enlightened self-interest. I'm participating in the open source community so that when there are issues, I can just jump in and fix my issue and that really reduces my downtime of an application. So I think those are some of the pitches that I've seen that seem to work better and be more acceptable. In case of Amazon, for example, Amazon is always, always keen on working with the customers, right? So when I joined Amazon back in 2017, we were launching Amazon EKS.

I joined in March or so, and then I learned about, hey, we're going to launch EKS at reInvent that year. So that whole next seven, eight months was helping Amazon understand how do you work with the open source community? You don't just walk in, in AWS, in that sense, is the biggest hyperscaler. You just don't walk into an open source community, I want it done this way. So teaching sort of the dynamics of the open source community, helping them build those open source relationships goes done this way. So teaching sort of the dynamics of the open source community, helping them build those open source relationships

goes a long way. There's kind of two angles into open source as an enterprise. You have let's support, embrace, extend, not extinguish, but extend the stuff that we currently are already using, right? Like we already depend on this thing. It's core to our business. We're going to actually put some money into it

or put some engineering effort into it. And then the other one is like, let's take something that we have built that's internal and proprietary and let's open source that. And I think that there's different concerns and different pushbacks to those two different types of embracing on the actual, let's open source some stuff front.

Certainly there's people inside of large enterprises say, yo, we can't do that. This is our competitive advantage. What do you say when people says, why would we just like, this is what we sell. Let's not give it away, for instance. Yeah, it's always my first question. Anytime a team comes to me that we want to open source this my question

is why why do you want to open source this what's in it for you to open source this are you looking to gain mindshare are you looking to get more engineering contribution is that a mandatory requirement say the partners are telling you we would not adopt this technology until it is open source, because then we are not just relying upon you, but we can fork it if we need to, or we can contribute to it directly. I think there are several reasons.

If I go through the book essentially, this is the book that we're talking about. There are several why that we talk about. Is it a faster innovation? Is it a more sustainable code base? Because then essentially, you're not just reliant upon your engineering teams, you know, you could do fun things. But then in the project, you can also create good first issue where you can encourage developers from around the world to help contribute over there. It could be cost savings as a matter of fact. For example, I may not want to run CI CD infrastructure and a hyperscaler may be

interested in contributing credits for you to give those infrastructure. It may be a strategic initiative for the company. So for example, when Google launched Kubernetes, it was made very clear. If you keep it as a Google project, even though open source, nobody would care about it. That's the reason they ended up contributing Kubernetes to a foundation so that it's now a neutral governance body, et cetera. And then everybody else kind of jumped onto the bandwagon and became a success. It could be a compliance and security as a matter of fact, or community building, or it could be sheer market visibility that, Hey, um, this company, Apple,

for example, launched Swift and they just want market visibility because the only way to build developers around that is getting Apple's name out there and bringing all those students and those developers who can then contribute directly to the language. The reason Intel contributes to these open source projects, I mean, we contribute to 300 plus open source projects. You pick an open source project and we likely contribute to it. The reason we do that is because our customers, for example,

who use our Intel Silicon, whether it's a hyperscaler, a laptop, a network, an edge, wherever it is, they download these open source projects and they expect them to work in an optimal manner. So the why really is because our customers expect these open source projects and they expect them to work in an optimal manner. The why really is because our customers expect these open source projects to leverage the latest chipset. That's the reason we contribute back to these projects.

I think whether you are contributing to an existing project or you are open sourcing an existing project, the why, the business alignment is fundamentally critical and why you want to do that. Well friends, I am here with a new friend of mine, Scott Deaton, CEO of Augment Code. I'm excited about this. Augment taps into your team's collective knowledge, your code base, your documentation, your dependencies. It is the most context aware developer AI, so you won't just code faster, you'll also build smarter. It's an ask me anything for your code.

It's your deep thinking buddy. It's your stand flow antidote. Okay, Scott, so for the foreseeable future, AI assisted is here to stay. It's just a matter of getting the AI to be a better assistant. And in particular, I want help on the thinking part, not necessarily the coding part.

Can you speak to the thinking problem versus the coding problem and the potential false dichotomy there? Couple of different points to make. AIs have gotten good at making incremental changes, at least when they understand customer software. So first and the biggest limitation that these AIs have today,

they really don't understand anything about your code base. If you take GitHub Copilot, for example, it's like a fresh college graduate, understands some programming languages and algorithms, but doesn't understand what you're trying to do. And as a result of that, something like two-thirds of the community on average drops off of the product, especially the expert developers. Augment is different. We use retrieval augmented generation to deeply mine the knowledge that's inherent inside your code base. So we are a co-pilot that is an expert and they can help you navigate the code base,

help you find issues and fix them and resolve them over time much more quickly than you can trying to tutor up a novice on your software. So you're often compared to GitHub co-pilot. I gotta imagine that you have a hot take. What's your hot take on GitHub co-pilot? I think it was a great 1.0 product and I think they've done a huge service in promoting AI, but I think the game has changed.

We have moved from AIs that are new college graduates to, in effect, AIs that are now among the best developers in your code base. And that difference is a profound one for software engineering in particular. You know, if you're writing a new application from scratch, you want a webpage that'll play tic-tac-toe piece of cake to crank that out. But if you're looking at, you know, a tens of millions of line code base, like many of our customers, Lemonade is one of them. I mean, 10 million line mono repo as they move engineers inside and around that code

base and hire new engineers. Just the workload on senior developers to mentor people into areas of the code base they're not familiar with is hugely painful. An AI that knows the answer and is available seven by 24. You don't have to interrupt anybody and can help coach you through whatever you're trying to work on is hugely empowering to an engineer working an unfamiliar code. Very cool. Well, friends, augment code is developer AI that uses deep understanding of your large code base and how you build software to deliver personalized code suggestions and insights.

A good next step is to go to augment code.com. That's A U G M E N T C O D E dot com. Request a free trial contact sales or if you're an open source project, augment is free to you to use. Learn more at augment code dot com. That's a U G M E N T C O D E dot com. Augment code dot com. You mentioned having some case studies. I don't know if you have any cases around this, but the question really is, is like

aside from kubernetes, that's a good example of Google open sourcing it, not holding on to it. They gave it to the foundation. What are other good examples? And maybe you've written about them in your book, I'm not sure, that are beyond Kubernetes? That are examples of a large corporation giving something, or even a smaller startup even, like not even so much a corporation, but like what are some of their examples beyond Kubernetes?

Yeah, I think the book has about 40 plus case studies, and these are case studies from companies like Mercedes-Benz, Bloomberg, Toyota, GitHub, Infosys, Dell, Amazon, a wide range of companies, Fidelity, Johns Hopkins, UC Santa Cruz. So from a wide range of verticals as well. And these case studies really talk about why they care about open source culture, and what have they done within their company to foster that open source culture. So for example, for Bloomberg, one of their big corporate philosophies is philanthropy.

And for them, contributing to open source fundamentally aligns with that corporate philosophy. And as a matter of fact, what they also do is for developers who contribute to open source, they do matching dollars. Now that, OK, hey, we're going to contribute dollars to open source foundation of your choice. So in that sense, lots of these.

So the beauty of these case studies is no matter where you are in that sense, loss of these. So the beauty of these case studies is no matter where you are in your journey, are you starting? Are you an expert? Because the wide range of case studies that have been incorporated into the book, there is something for everybody. And frankly, I reviewed each and every of these case study. I did not write them because they were written by 55 contributing authors.

But even to date, and I'm sure over the next several months and years, whenever I read these case studies, I say, aha, I missed this nugget and this is how I can apply it to my day-to-day life. So I think in that sense, there are lots and lots of different case studies. So I would encourage you readers to go through the book and say, which vertical do you align with? Oh, maybe I'm a medical, you know, in the pharma industry. So I will take a look at Johns Hopkins.

Maybe I'm a retailer. I'll take a look at Amazon. Maybe I'm a GSI. I'm going to take a look at that. I'm a device manufacturer. I'll take a look at Dell case study. Or I'm into a technology company. Several examples in there.

So I think in that sense, hopefully the diversity, the quality and the quantity of case studies gives everybody a nugget that they can pick up and apply into their day-to-day work. I think going back to the why is really important and well said by you, because if you have a solid why that aligns with your business incentives, everything else kind of makes sense.

And if you don't, then you're kind of perpendicular and you shouldn't be doing this in the first place. And so if you can find the why right away, I think Swift is another good example. You brought that one up Arun, where it's like Apple put a lot in the Swift. And if they just wanted an awesome language for iOS or Apple platform engineers,

they probably didn't need open source. And of course there's non-open source languages of the past that are just fine for that. But if they want a general purpose programming language that's adopted by everyone around the world, it had to be open source. And so like that was their why, is like we want this to be more impactful

than merely the next best language, not the next best, the best language they think for developing Apple apps. And so that's another good one where it's like, that was a huge decision. Cause think of how much money they had in the Swift, you know, just engineering hours. It was like five years of just Chris Latner working on it.

And then they brought a team in, and then like all this stuff, and then they got all this stuff rewritten in Swift, and so that's a huge investment that someone said, yeah, we're gonna go ahead and give it away to the world in order to accomplish our business goals. And I think that's totally fine, and it makes complete sense. Not everything is merely altruism. It's cool with Bloomberg that they have that

in their mission statement or whatever. Like philanthropy is one of our core incentives at Bloomberg. Not every business does that. But if you can find your why, then the details have to be figured out and managed, but they're just details. Correct.

I think you're putting it very well. There is different companies have different whys, and each company has different whys for different projects as a matter of fact. But locking that down, writing it down is super important because oftentimes it's brewing in your head. So usually when any leader comes to me that, okay, we want to open source this project, my first question is why? And there is corporate altruism, as want to open source this project. My first question is why? And there is

corporate altruism, as you said, you know, in some cases, more often than not, it's an enlightened self-interest. Okay, this is where it's going to serve me and in the process is going to serve the world as well. It's totally a fair gesture as a matter of fact. I mean, one of the efforts, I think, Adam, you were asking, Intel contributed, for example, one API, right? So we created this one API that's going to be a unified API across different accelerator architectures. So we created this for our benefit, but then over the period of time, we realized, hey, you know, this could benefit the world as well.

So over a couple of years ago, we created this thing called as UXL Foundation, Uniform Acceleration Foundation. That's the foundation that we created, brought a whole bunch of members together over there, and now that thing is taking a life of its own. In that sense, the whole idea was, if this is indeed an API, unified API, then everybody needs to partner in and everybody

needs an equal stake at the table so that they can define what the life of it's going to look like. Because if you want that collective engineering effort, there is no other way without going out in the open source and that the diversity of thoughts is what I really enjoy in in open source, of course, but how does this reflect into the other open source, aka, inner source? I was just leafing through the GitHub case study really quick while we're having this conversation. I was just looking at how essentially their inner source, you know, because I began as a social coding platform.

We all know GitHub. I don't need to tell you what that is. But their practice of intersource really became this sort of internal, like basically open source behind the firewall inside GitHub. How does that manifest in a lot of these companies? Like is that truly open source? What are they calling it?

Is it licensed? How do you manifest intersource? What begins that? Is it simply our software and you can contribute or is it, how does that manifest? I think the biggest reason that I've seen inner source happening are multifold. First is you want to avoid duplication of code. You know, how many loggers do you need in a word? Right. In a company, if everybody is writing a same ETL app,

there is no point doing that code duplication. How can I create that discipline where inside the company, when you're not within the firewall, you're not going outside, it was only engineers from the company that can contribute to it. Hopefully, you can be a bit more open. So in that sense, how do you publish that repo so that others in the company understand this ETL app is being built and we can all contribute to that?

Again, very much open source philosophy, that 80 percent of my task is already done with that one ETL app. I just need to put 20 percent more effort to customize it for my need. If I contribute it back upstream inside the InnerSource repo itself, that will do my job. So that's fun. The second part of it is, a lot of the companies have certain stricter requirements that what you can or cannot do in open source.

Inner source basically is bringing that open source practice inside the firewall. So that's really a good way by which you can coach your employees, train your employees on all the open source skills with much less risk. Oftentimes companies are under a trepidation that, oh, you know what, if this person wearing my company hoodie commits something out in the public,

it's gonna look really bad. That one person will define the whole company, which is generally not true at all. Everybody make mistake giving people a chance to recover from the mistake is exactly what defines them to be more successful, but it is what it is. So, InnerSource in that sense provides that learning opportunity platform where they can practice all of the open source practices inside the company. And GitHub definitely has a very excellent case study on that.

There is a case study by Inner Source Commons by Gail and Russ over there as well, because they really call out in terms of all the fun things that have happened within Inner Source Commons, because that provides common terminology. They run an Inner Source Commons gathering on a regular basis. They have lots of Inner Source case studies over there. So you can start looking at it on all the fun things that are happening in the inner source space. Then the third reason that I've seen it is,

you could see potentially inner source as a stepping stone, a stepping stone to going to open source. So for example, a project started, you want to see how the internal collaboration is going to look like, because oftentimes teams don't recognize, don't realize that, hey, I built a project before I release into open source, I don't know what level of support I would need. Do I need 30% more engineering if pull requests start coming in? How am I going to manage them? If people file issues, if they are not requests start coming in, how am I going to manage them? If people file issues, if they are not aligned with my roadmap, how does that work out?

So again, InnerSource kind of gives them that feeling as a stepping stone to going to open source that, okay, this looks like, okay, I understand my engineering efforts are not going up by 30% by only 10%. And maybe when I go to open source, they will double up to 20%. So it helps them with their resource planning and their roadmap and all of those things. by only 10%. And maybe when I go to open source, they will double up to 20%. So it helps them with their resource planning and their roadmap and all of those things. So in that sense, InnerSource is very, very effective. And Intel has a very large InnerSource practice.

We have hundreds and thousands of repos here, which are run on an internal platform, very nice nomenclature. So it kind of calls out, are you looking by a language? Are you looking by a technology? Are you looking by a business unit? So you can start filtering your repos and that really significantly improves the discoverability

of the entire element that we were talking about earlier. So I think in that sense, InnerSource is definitely a key factor that allows you to be on that open source journey in a much more constrained environment and giving executives that feeling that, yeah, nothing is lost here, it's all happening within the company. And most importantly, giving them a comfort feeling that when these people go out, they're trained on these tools very well.

It seems like almost like a proving ground for open source at large. It's like if you don't know what open source is, or jitter back to the question you asked before, like what are the hard questions, or what are the push backs you get from management? I feel like if you can prove this is how inner source works, now imagine how it works for the world. You know, like it's this, you know,

our safe world behind our firewall, controllable, you know, all those things It's still unclear to me though How you begin is it simply like a? Private repo on github is that is there a way to dashboard this stuff? How do you truly you know spark this it seems like it's bottom bottoms up like where it's I've got this thing I think this team or these other teams could use. I still don't understand how you manifest inner source.

Is it just, you know, behind authentication and authorization? Is that what it is? I'll give you two examples. One of them is from Apple. Like the IT team from there reached out that folks were recognizing the ETL example that I gave earlier, that there are recognizing the ETL example that I gave earlier,

that there are six different ETLs that are happening. It's a waste of resource, waste of time, and a waste of engineering resource. Now, how do we consolidate all of them together? So essentially what we did is, from ground up, we built up a inner source org, and we built up a nomenclature that, okay folks, as you are creating these new

projects, and even within the company, there could be sometimes firewall, right? Like, oh, IT team only want to collaborate among themselves, which is fine, whatever the structure is. So, we created an org, internal org on a GitHub platform or whatever your GitHub platform is. We created an internal org and said that, okay folks, before you create a new project, take a look at that org. There is some discoverability mechanism, there is some tagging mechanism.

You can start looking at dashboards in terms of how healthy the project is, how many other teams across the company have adopted it, what is the bug fixing rate, what is the pull request approval rate, because that's kind of shows the health of the project in that sense. Because if anybody is coming and looking at an open source project, that's what they would look at.

Why not adopt the exact same practice inside the company? So that's sort of how we started ground up. It took a while for us to gain traction. We ran an inner source event internally. Lot more curated people, because then they're coming to learn about inner source. And we had to intentionally and very deliberately build those relationships and connection.

So it took a time, but then the practice kicked off. I came to Intel. At Intel, there was already an effort that was happening on that. So we have 100,000 plus repos. Those were all put onto the platform. They were all on a wide range of CI CD systems, wide range of Git repos, wide range of orgs. So all of that was automatically then thought about that, okay, how do we bring this into inner source again, improve the discoverability, cut down the cost on running this wide variety of CID,

CD systems, cut down the cost by doing this wide range of orgs, etc. That really allowed us to minimize the cost and then also improve the engineering time that is required. I already found 70% of my work done and I'm just gonna contribute to that project and that really cuts down my engineering time. And now I'm also able to exchange that mind,

that knowledge with another engineering team who's having a similar issue. So in that sense, it continues to build that intellectual knowledge as opposed to intellectual property, you know, for your work and you continue to make progress. I think there is no no one right answer here. It really depends upon where you are in the journey and how you want to start about it. Yeah, I like that.

I mean, I like it seems like some of the key characteristics are, you know, organization, some sort of org that says, okay, we're gonna make this a thing. This is not a thing. We're making a thing. That's easy. You mentioned nomenclature. So how do we describe this stuff? And maybe each company is a little different with the way they describe it.

Maybe there's certain terms across all intersource organizations across different companies that just make sense. And there's some sort of shared knowledge or shared nomenclature. And then you've got sort of visibility. Okay, I don't wanna recreate the wheel. I don't wanna go out to the open source land because I can't play there. I gotta play in business user land,

not open source user land. And so where can I find that stuff? And then gauge my own desires. Like, are they maintaining well? Does it solve my true problems? Can I actually contribute all these different things that you would consider? I love though how this manifests to say,

these are the open source culture mechanisms you would care about. I love how that has the possibility, I suppose, of getting people to truly understand what open source at large works and how it works versus simply just how it works internally? I think one of the things that we don't talk often about is as new developers are getting on board,

they're coming fresh out of college. I mean, a lot of the developers understand open source really well, but for developers who don't understand open source well, who have that fear of failure that, oh, it's going to spoil my career. It may not look good on my career or whatever. One of the best keynotes I heard at KubeCon was this person said, hey, I burned down a 10,000 node Kubernetes cluster at Spotify.

And a week later, I did that again. And my manager said, go give this keynote and how you recovered from it. So I think InnerSource in that, I mean, it's a bold move. And I really love it. I admire it because that's how I am. But not everybody is like that, right? So in that sense, InnerSource really gives that safe space

for people to like, okay, I'm gonna refine my skills in my own comfortable environment, and I'm gonna try this out. I played with the CID system. I know how to get forked. I know how to get merged. I know how to rebase, and I'm learning those internal tools.

So that's from the engineer perspective. On the other side, from the inner source team, doing that advocacy, providing those tools, running those workshops, running those internal hackathons, you know that, okay, let's get together. Let's figure out what this project is. Let me guide you how this works. And that opens up the avenues and the opportunities

for the engineer that when I go out in the public, it's very much like that. It's just that the person on the other side is from a different company. That's cool. So you dedicate an entire chapter to internal events. You just mentioned a couple of things right there. And while we're talking inner,

it was a surprise to me to see a chapter on internal events because I'm not in the know, but apparently you are. And so tell us why that is like a whole chapter of your book and why that's so important inside organizations in order to foster this open source ethos. I think it's super important. And I'm again, looking at the chapters here,

the types of internal events that I talk about in that book is like workshops, where you are bringing people and teaching them that, okay, let me tell you how to be an effective Git user. Hackathons, where you bring a project and say, let's hack on this together. So now that you've learned the skill, let's apply this to a real-time project, because just a workshop and hackathons are just a very different nature. Bring those external guest speakers. These are luminaries across the industry

that you can bring them on. That way you get to hear their story, you feel inspired about it. Internal projects, where you may say that, okay, I'm just gonna run a hobby project, and on a daily basis I'm feeling the need that I need to do this again and again and again. So every knowledge that I've learned so far,

I'm gonna spin up an internal project, maybe an inner source as a matter of fact. Having those topical summits, I remember when we did the open ecosystem summit at Intel a couple of years ago, there were about 2,500 people that showed up. And a lot of internal discovery happened. They go, I did not know you were working on this project.

I did not know you were working on this effort. I did not know you were working on this effort. So that really allowed them to connect with each other and then join hands. Very detailed experience when we ran the first Kubernetes Summit at Apple. There were thousand plus people that showed up at Apple to that Kubernetes Summit. And Apple, as you understand the company culture,

is very walled across different BUs. But for the open source topic like Kubernetes, they were all able to share information and they recognize that the technical challenges are very similar because they know exactly how the Kubernetes is deployed, they know the internal terminology, the entire architecture, so they can talk

at a very much elevated level in that sense. And that essentially brings that internal community. There's a particular chapter dedicated on how do you organize the hackathons, and how do you go about doing those hackathons. So I think it's super important, the relevance of those internal events, because those internal events help you prepare

to be a better citizen out in the open source world. They help you bridge the gap, connect to the existing open source elements. So a lot of fun, I think it's very, very relevant. And I've seen the importance of these internal events all across, and in that chapter, there is case studies by BlackRock, Infosys, Intel, and SUSE in terms of how they have

leveraged these case studies, how they have leveraged internal events. Like I remember SUSE talks about something like Hack Week. So where they will have a week dedicated to hackathons. No work done during that time, but essentially bring a project in to hackathons. You know, no work done during that time, but essentially bring a project in, hack on it, and that incentive by the top management is really big time and encourages employees that it's okay to do that.

And that is what is fundamental. You mentioned the thousand people that showed up to that first Apple Kubernetes event. You reminded me of an old show he did with a late great Dan Cohn. One of my favorite episode titles ever, Adam, if you remember this one. We named it Kubernetes brings all the cloud natives

to the yard. Because we were just so surprised at how many, like the growth of KubeCon and just how excited people were for Kubernetes back in the late teens. Um, it was amazing. Like KubeCon doubled in size every year for the first five years or something crazy like that. And it was probably a surprise at the time that a thousand people showed up, but

probably shouldn't have been because man, people were just interested in Kubernetes for sure. Yeah, for sure. That was a good title, Jared. Good, good callback. Well, there's no shortage of AI tools out there, but I'm loving Notion and I'm loving Notion AI. I use Notion every day. I love Notion.

It helps me organize so much for myself and for others. I can make my own operating systems, my own processes and flows and things like that to just make it easy to do checklists, flows, etc. that are very complex and share those with my team and others externally from our organization. And Notion on top of it is just wow. It's so cool. I can search all of my stuff in Notion, all my docs, all of my things, all of my workflows, my projects, my workspaces. It's really astounding what they've done with Notion. And if you're new to Notion, Notion is your one place to connect

your teams, your tools, your knowledge, so that you're all empowered to do your most meaningful work. And unlike other specialized tools or legacy suites that have you bouncing from six different apps, Notion seamlessly integrates. It's infallibly flexible and it's also very beautiful and easy to use mobile desktop web shareable. It's just all there. And the fully integrated notion AI helps me and will help you to work faster, write better, think bigger, and do tasks that normally take you hours to do it minutes or even seconds. You can save time by writing faster, by letting notion AI

handle that first draft and give you some ideas to jumpstart a brainstorm or to turn your messy notes. I know my notes are sometimes messy into something polished. You can even automate tedious tasks like summarizing meeting notes or finding your next steps to do. Notion AI does all this and more, and it frees you up to do the deep work next steps to do. Notion AI does all this and more. And it frees you up to do the deep work you want to do. The work that really matters, the work that is really profitable for you

and your company. And of course, Notion is used by over half of Fortune 500 companies and teams that use Notion send less email. They cancel more meetings. They save time searching for their work and reduce spending on tools, which kind of helps everyone be on the same page. You can try Notion today for free when you go to Notion.com slash changelog. That's all lowercase letters. Notion.com slash changelog to try the powerful, easy to use Notion AI today.

And when you use our link, of course, you are supporting this show. And I think you like it because you're listening. So that's awesome. Again, notion.com slash change log. One thing that you were talking about hackathons, I was just leafing through that section of your book there. And I want to pull out this. If you your book there, and I wanna pull out this. If you don't mind, I wanna quote your words.

You said hackathons and coding sprints are like HIT. H-I-I, is that H-I-I-T? Yeah, it is. High Intensity Interval Training? That's right, High Intensity Interval Training. Okay, now we're gonna get the athlete to come out. That's right. Hackathons and coding sprints are like HIT.

Like HIT training for open source developers. They provide time boxed and concentrated bursts of engagement that push participants to deliver impactful contributions within short time frames. I think that's a great analogy because I've always struggled to understand like how you can do a hackathon at a company. I get it for, you know, hey, come, and it's sort of like, cause the most thing, the thing we struggle with as human beings, obviously we're human beings, right,

is that we desire and thrive in connection, right? You can't expect innovation or things to happen unless you connect with others. And I think this whole part here on like internal events is enabling me inside of a company to get to know somebody else. And even if I go and just meet one person or two people, now I've got more connection in the company. I've got a deeper, deeper roots, so to speak. So my, my, uh, I'm not

leaving anytime soon. If I feel connected, if I feel invited, and then you take a thing like a hackathon, which I was like, how do you do that well at a company? Well, you're just sort of taking the inner source you may already have spun up, and you're saying, go wild, have fun, meet people, do fun things, innovate. Correct, yeah. No, I think when I was writing that chapter, I was thinking in terms of, what do I do in my daily life?

And Jared, thank you for the reference. Like, I've been a long time athlete. And this morning, as a matter of fact, my workout was a hit workout. And I'm a lifetime runner, so I've been running for a very long time. But in order to maintain that running, you can't keep running every day

because that leads to a burnout. Some people do, which is great for them. But for me, I want to run, but then I want to also going to get equally strength trained so that I can be a more effective runner. If I bring that analogy essentially to open source, that's exactly what it is. In open source, new tools keep coming all the time.

In order to understand those tools, that high intensity interval training is what is required. Because what I'm doing is for one hour, I am all in, I've cut down all noises and distractions from my life. I just wanna learn this tool. I wanna fail in that tool again and again and again, so that I understand the way this works,

the way it doesn't work, and what are the boundary conditions, what are the normal happy path, all of that. So once, because once I understand that, then I can go back to my normal running. Because then I can say, aha, I'm stronger in this area, and I can apply that skill into my day-to-day life. So I think it's super important in that sense

on taking that intense exercise. It could be a workshop, it could be a hackathon, whatever it is. And in hackathon, again, Aram, as you called out, it's really a good way to engage with other people because no matter which business unit you are from, you are sitting together for a common purpose. And that pair programming concept is very extreme in that sense, right? Because you say, ah, I'm thinking it this way and that diversity of thought immediately comes on to you and then you are able to make progress on that together. Just the fact that how do I do a code review or if somebody has done a code review on me, how do I accept that feedback? Because,

don't take it personally, take it in the technical sense that, yeah, this is a really genuine feedback and accept it. One of the things I talk about often is conflict resolution, right? It's a big one in open source. So, often we get confused between personality conflict and task conflict. That, oh, this person has given a feedback, he lives in this part of the world and that's why he must be giving me this feedback. Keep that aside. It's not about personality conflict.

Take it as a task conflict, learn that element, and see how that makes you become an effective coder is what this is all should be about. I feel like we could have an analogy for the fitness junkies out there. Like you have Hit Class is like a hackathon, Pomodoro that's like Tabata, you know, coding bootcamp, well I guess that's just a bootcamp.

I don't know if that already has an analogy, but we could have a bunch of these. I like that. Well that's somebody coming in, educating them what to eat. There you go. Yeah, see, I mean, in the book, I'm looking through the chapters here. So for example, because I wrote this a while back,

the hackathons are like hit. The guest speakers are like the mentorship and coaching that athletes receive from seasoned experts. That's what guest speakers are. Athletes build muscle memory through repetitive training and hone their skills through simulated game scenarios in practice. That's your internal projects essentially.

Topical summits really dig deep into a particular topic. These are like-minded individuals, experts that get together. These are more like, you know, hey, I'm going to a bootcamp here. And all sitting together, really discussing that topic. So I think, yes, in that sense, you're right, Jared. Just very much.

Well, you beat me to it. I didn't know you already went through such a flushed out exercise, but yeah, good. Good metaphors for sure, for those interested in such things as fitness. That's good for you. That's good as fitness. That's good for you. That's good for you. That's good for you. Not for you, Adam?

Oh, I like fitness. I'm down with the fitness. So, Ruin, share more of your fitness bent. Like you said you run a lot. Give us some stats. How long have you been running? How far do you run? How fast do you run, etc.?

I've been running for 40 far do you run? How fast do you run, et cetera? I've been running for 40 years, for a long time. For a very long time. I've done 35 half and full marathons around the world. Wow. I think 2021 was my most running year. I ran 2000 plus miles that year, which is an average of five and a half mile every day. So that was the most extreme running year.

Now I'm on a much more easier scale. It's about 10K every four, five days a week, and the other two days are lifting. So I do work out every day. The days I don't work out, I feel very, I'm not very myself. So I work out every day. The days I don't work out, I feel very like I'm not very myself. So I work out every day. This morning I had a seven o'clock meeting. That means I got up at five, did my one hour workout. I have a full pull up cage in my garage. It was a full on 50

minute, 55 minute workout. I pushed to the limit, all sorts of stuff, you know. Box jumps, ball slams, bench press, pull up bars, all sorts of crazy stuff. So today was my running day because it was raining, but otherwise like yesterday was a 10K, the day before was a 10K, and all of those stats are available on my Strava. Oh, that's cool.

So you do that all by yourself, or do you have a partner in Crown? Sometimes for me, I get more motivated when I have an accountability partner or something. I'm all by myself. My schedules are been very early in the morning, and I gotta go drop my son to school, get the breakfast ready for family in the morning.

So I do really family in the morning. So I do like really early in the morning. Um, most of the days I'm getting up around five, five 15, you know, hit the road by five 30 or so do an hour workout and back in time for the first seven o'clock meeting. Very impressive. Yeah, very impressive. I find if I have, I like an accountability partner, Jared, but I find if I have to coordinate with somebody else, it slows me down.

You know, I can't. I gotta spend an extra half hour, or just some buffer in there to deal with the, hey, how you doing today? Let's get going. You almost need somebody who's like super strict. Don't talk to me, okay? Just don't even say my name. Just get to the work. Yeah, you want somebody who's like super strict. Don't talk to me, okay? Just don't even say my name.

Just get to the work. Yeah, you want somebody who's in the same mindset as you are, which is like, neither one of us wanna be here, but we know we should be. I can't find that person in my life. I can't find that person. That's what I'm trying to say.

I agree, but I can't find that person. For me, it's like, if I'm gonna get up early, I have to have something to where if I don't do it, I'm letting somebody else down. Cause I'm fine with disappointing myself. I do it all the time, you know? But to disappoint someone else is like, just harder on me.

So I'll get up for them, but not for me, you know? Apparently you're self motivated, I guess. Yeah, one of the very exciting things we did last year was we went, I took the entire family to Kilimanjaro and we all hiked the summit. So my younger son and I are big into fitness but I trained my older son and my wife but I'm really really grateful that we could actually summit Kilimanjaro and then literally in about couple of weeks we are again going on scattered trips,

but we're going to Patagonia. My son and my wife are going to Patagonia, and then I'll be joining my son on a beautiful expedition to Antarctica. And so all of those really require a high level of fitness. I'm grateful that we're able to do that. So provide a comparison for us, difficulty and pain of summiting Mount Kilimanjaro

or authoring a book. Oh, I think the book was easy. I think it was very really. Yeah. Yeah. Yeah. And my experience, see, frankly, in twenty twenty three December is when I did all of my writing. I pretty much did all of my writing within two weeks. You just cranked it out. Yeah, yeah, just two weeks.

Most people say that writing a book is like the hardest thing they've ever done. No. No. I mean, this was my seventh book too. So I think I've done that for a while. Oh, this is your seventh book, okay. Seventh book.

So you have some experience. I've been writing for a while, and particularly for this book, I've always been practicing this. So it was more about structuring my thought and putting it into a chapter format. A lot of the heavy lifting, I would say, was really working with those 40 plus companies,

40 plus case studies, getting their management approval, PR approval, helping them build their use case and all that, kind of refining their case studies, getting their management approval, PR approval, helping them build the use case and all that, kind of refining their case studies. That's where the biggest heavy lifting was. So that's where it spent a lot of our time. Kaleemajor was easy as well, as a matter of fact, because I run regularly, I lift heavily. What's hard for you? Tell us what's hard. I think I take things as they come

and just live in a peaceful, mindful manner. I would say the only hard part was the last day where they woke us up at 10 in the night and we hiked all night to reach the summit at seven in the morning and then come back the same night, come back the same day. So we started like 10 p.m., we hiked up, we came down, took an hour break for lunch,

and then hiked further down at a lower elevation. So it was about 5,000 feet up and about 6,000 feet down in the same day in a stretch of like about 16 odd hours. And that was tiring. We slept like a lot after that. Down sometimes is harder than up, isn't it? Down sometimes is actually, down is always hard,

you know, a lot more impact on your knees. And the grade is pretty intense. I think that took a bit of a toll on the body. I feel like the down is almost more dangerous than the up sometimes because you can correct you can there's a lot There's just you you almost have a faster pace because you're naturally being assisted by gravity Right, but then you're like, you know your knee buckles your ankle twists or like you do it You're sure footing may not slide down your butt Yeah, yeah

Yeah, and particularly because when we were going up, it was all during night, right? Because we started at 11, 10 PM we got up, 11 PM we started the hike and we didn't see sun until 6.37 in the morning. So it was all hike during the night. So with my headlamp, all I'm seeing is the person, the shoes in front of me and I'm just chugging along as they're going through switchbacks, whatever. So you just chug, chug, chug. Well, why did you start that?

Like, did you wanna see sunrise or? Oh, the whole idea was to see sunrise at the summit. That was one. And the second reason was, you don't wanna stay at the summit because Kilimanjaro is what, 19.3441 feet. So at that elevation, usually afternoons are a bit tricky.

The thunderstorms can appear. So they want you to get back from a higher elevation before noon kicks in. Gotcha. I think going back to the book, one of the elements that we missed talking about is the relevance of open source foundations. And that's pretty big actually.

You know, we kind of touched upon that topic earlier in the podcast. Open source foundations like Apache, Eclipse, Linux foundation of course is big. And I'm myself on the CNCF governing board and open SSF governing board and the chair for both the governing boards. It's very important that enterprises understand

the relevance of joining these foundations. And there are different tiers of membership. Because joining those foundations really helps you understand all the good things that are happening in the foundation, connects with similar minded leaders, and again, becomes a hiring magnet essentially. That okay, why Intel is joining over there. Intel really cares about the open source culture and other open source leaders get influence that, okay, I wanna work at Intel and I wanna build my open source career.

I remember when I joined Amazon, one of the first events we did, we got up on the reinvent stage and we says, hey, build your open source career at Amazon. And this was back in 2017. And that got a lot of applause because essentially Adrian Cockroft, my manager who hired me at that point of time, he was big into open source. I've always been big into open source as well. Bringing two large open source leaders that are credible in the open source community and saying, hey, we are joining this.

I wrote the six pager for Amazon to join Cloud Native Computing Foundation and bringing that credibility and saying, hey, we are joining in there, really goes a long way again, fostering that open source culture. I'm glad you mentioned that because I think the foundations are really important. It's always a grab bag of how you perceive membership

Right like you might say oh, this is Necessary because you got to support it and cost but then you think well is that pay-to-play? Dude does that get me a seat at the the board so to speak, you know Does that give me access no one else gets and the usual answer the obvious best answer is probably no Unless you're at the wrong foundation and that's just like a different foundation. But, you know, I think that's really important to bring that up, because I think that the foundations, they give the neutrality, right?

They give the neutrality, the formation, and gosh, what has happened with the Linux foundation over the last, you know, 15 years, I'd say, has just been tremendous. I feel like there's some angles where it could be good or it could be bad, like centralized control or centralized organizations, so to speak. But a large majority of the most important open source work is being done under the Linux Foundation.

And that could be seen as a good thing and potentially as a bad thing for centrality, you know, in terms of centralizing things. But I think it's mostly a good thing that we've got a worthy and organized body that can do that and have such great structure that they've proven to do it well over the many, many years. That is correct. You know, I mean, different foundations operate very differently. They play a very critical role in terms

of growing these open source projects. They provide this central functionality like CI, CD, security audits, legal support, marketing support, event support. So a lot of advantages of these open source foundations. Some foundations give you a seat at the governing board depending upon what tier of membership you take. Most of the foundations that I'm aware of,

they usually have their technical oversight committee or technical advisory committee. Those seats are all elected. Those are not pay to play at all. The maintainership again is again meritocracy, so doocracy, and how do you rise up to become a maintainer? In that sense, the administrative part and the technical parts are separate. I'm on the governing board, so we are responsible for the administrative, financial, legal aspect

of it, but we have zero say in terms of what the technical roadmap of the foundation is going to look like. I like that separation of concerns in that sense, but if the technical folks need some budget support, then for example, in open SSF, they come over to the board. But we're also trying to create swim lanes over there where a certain level of funding is not required to be seeking permission of board every time because we wanna create swim lanes

where people can go faster on their own. You tell us more about doocracy. You just said doocracy. What's this? Yeah, so think about the concept of you do things in open source and that really helps you rise up in open source. And it really could start with just being a lurker

on an open source project that, okay, I'm just observing what's going on in the open source project on an open source project that, okay, I'm just observing what's going on in the open source project. Then occasionally jumping in that, okay, hey, I'm participating in the working group and then I'm starting to participate in the conversation, or I'm jumping into the Slack channel. And first, maybe I'm asking my questions, but then slowly, as I gain more knowledge into the project, then I can start answering other questions. Then maybe I jump into sort of the overall aspect of looking at other people code, reviewing

people code. Then maybe I jump into the element of, hey, I'm going to start contributing code. And then I'm contributing more serious code. Maybe I'm contributing deeper sections. And that eventually, that duocracy is that whole contribution ladder where you rise up from being a user to a contributor, to a committer, to a maintainer,

and different projects at different hierarchy levels or different contribution ladder. But that duocracy is the more you do into the project, the more you are known into the project and the higher your chances of getting a leadership position is. It's not like, hey, Intel is part of the CNCF governing board

and Intel must have a maintainer into the project. No, it's purely purely duocracy. You do the work into the project to rise up to that level of maintainership. I like that. Duocracy. How does one begin? So we got a diverse listenership in our audience. I would say from individual contributor to leadership and everywhere in between, what

is a good on-ramp? I know you probably described some versions of this in your book but what are the best ways to begin this culture shift of inner source open source organization etc if it doesn't exist or if it maybe it's maybe it's been tried before but it hasn't been successful what are some ways to begin for our audience yeah one of the last chapters that sort of was looking at you know in the book is really about getting started on your culture change journey, right? A lot of the times, if you continue to do things

in a certain way that you've always done, and if you're not challenging the status quo, because change is the only constant, if you're not challenging the status quo, then that's the first thing you need to do, that how does open source work for you? You need to overcome your legacy mindset. That's an important element.

There's a chapter in the book that talks about that part of it. Then the book really gives you a 10-step framework on how you can jump onto that cultural journey. The diverse audience is great. Having a top-level executive sponsor, because you need that somebody either at the executive level, top executive level, they say, and it doesn't have to be at the ELT level or

the CEO must say that open source is our strategic direction. It could be like, hey, this is a group where a lot of the open source technologies happen and that executive stands up that, yes, this is how I'm gonna define the culture of my org and I'm gonna actively encourage, allow them to contribute to open source. This is what the incentive mechanism in the companies are.

Identify your stakeholders, not just within your team, but outside your team. If there are other business units that are doing similar work, if there are folks in marketing that care about, if there are folks in recruitment that cares about, because end of the day, they want to bring the top talent over there. So how you can start connecting with that? You need to have, I remember when I joined Apple, I think second or third day,

I was having a call with somebody and my God, that person was screaming at me, I submitted this pull request so many weeks ago, it has not been approved yet. It's been stuck into legal. What can I do to help? It was just a listening session, a venting session, essentially, that let that frustration come out. And it's very important to just listen with it. Again, we talked about task conflict, personality conflict. Think in terms of task conflict. What is a task not getting done?

Because that person has probably been trying really hard for many weeks, months, and is not getting through. Just understand the task, just get going on that. Identify sort of the non-core open source areas, or maybe the core open source areas where you want to make a traction. Define those walls within which you can do more open source or less open source. I think that's an important area. Create those working groups, for example. At Intel, we have several of those working groups where we teach on the best open source practices. Anybody want to go to an open source project, they can come for education enablement. Ospo does a good part of that, essentially.

Definitely having an open source program office goes a long way. So I don't want to give away all the tips from the book, so definitely encourage you to take a look at the last chapter of the book that gives you that entire framework on how you can get started with it. And there is a section in that chapter which talks about sort of my journey on how I went about building that exactly in these different companies. I was thinking as you were reading that, Arun will give all the goods away But at the same time, you know, will this be you know, will this be the book that gets handed to someone when they say? How does open source work? How can I make it work for my company? I hear about this thing called inner source What are the frameworks? I feel like you've in two weeks as you said you wrote this book it quickly in two weeks and a lot of the work was case studies and external work and whatnot but I feel like you've you've really

organized a lot of your wisdom and thoughts over your decades of experience to really give us The initial steps if not the full-on steps of what it takes to change the culture Inside the companies whether it's in a source or open source or whatever. And so I think you've done a tremendous job I can't wait to read the entire book personally. I've only leaped through the table of contents and some of the stuff with you along this conversation here in my morning here, but I think this is a great framework for what I can see.

I mean, I'm really proud of the work you've done here and I appreciate this being in the world to give that guidance, because I mean, crowdsourcing is the plain term but open source is the future innovation. I think actually if I can lead through quickly, page two, I want to read this if you don't mind. You might know what I'm not going to mention but on page two you mentioned Mark Andreessen's really famous phrase

when he said, software is eating the world. And then Jim Zemlin, the executive director and I believe the founder of the Linux Foundation, he said most of that software is open source. And then of course, our very own Arun Gupta says, here in 2024, open source culture sustains innovation. And I feel like what's happening in LL M's and and AI these models being open source like we're seeing a massive change in

Accessibility to software accessibility to models accessibility all these things and the innovation that we're seeing in our world I mean open source is one and that innovation you've given a great Blueprint and on ramp for so many organizations to say, how can we really be a part of this or put to work for our company or to truly understand what it is? So I really appreciate this work you've done here for the open source innovation that will come. Thank you. Thank you. Now I'm really excited about how the book came about to be. I really hope this book is a fire starter for people who wanna jump onto their journey,

kickstart their journey, or if you are far along in your journey, look at those case studies and see what other fun things you can find out. Anything left we have not asked you. I know that you've got a lot to share. Have you shared it all? What's left?

Well, we have shared it. You can even plug something if you wanted to. No, I think it's very good. I think in terms of everything around the book, we have talked about it. Open source culture is such an interesting topic and I've been working on this for such a long time that every time you talk, a new story comes out,

a new perspective comes out. And I would like people to think about, would you go to a potluck and not take a dish of your own? Would you go to a communal garden and just eat all the vegetables and not plant your own vegetable? So that's why open source is like a potluck or a communal garden. So contribute, make it sustain for yourself and for others. And that's the critical element. A perfect note to end on. Thanks, Arun. Thank you so much for having me here.

Well, those are wise words. Bring a side, plant some vegetables. Open source is for everyone everyone and it thrives when it includes everyone. And if you didn't know, this full length episode is now on YouTube. We're shipping all of our shows full length to YouTube so you can enjoy them.

Chapters, visuals, all the fun things. But let me ask you a question. The hypothetical question, of course. If the changelog wasn't here tomorrow, if you couldn't listen to any more episodes of this show ever again, how would you feel? What'd you mean? Sad, devastated, irate, happy?

You tell us. Email us at editors at changelog.com because we want to know. We're really curious to see if what we do here impacts your life so much that you would be sad forever or happy forever if we didn't produce any more shows.

Again just a hypothetical. Seriously it's just a question. But hey if you're a loyal fan someone who loves us dearly someone who enjoys this show consider joining change law plus plus you can go to change law dot com slash plus plus. It's better. loves us dearly, someone who enjoys this show, consider joining Change Law Plus Plus. You can go to changelaw.com slash plus plus. It's better.

It's better because there's no ads. You drop those. There's direct support of us and this show and those who help us make the show awesome. You get bonus content. You get extra stuff. You get a sticker pack in the mail in your inbox your literal IRL inbox and that's cool. Ten bucks a month. Hundred bucks a year.

change.com slash plus plus is better. Well a big thank you to our friends over at temporal temporal.io our friends at augment code augment code dot com and of course our friends over at Notion. Notion.com slash changelog. Love our sponsors. Give them some love. Check them out. And of course the Beat Freakin' Residence Brake Master Cylinder.

The beats. They're banging. So good. Okay this show's done. We'll see you on Friday. Music