Fostering open source culture

We are back with Arun Gupta. It’s good to see you, Arun. It’s been a couple 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… I 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’d 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.

Okay. Gotcha. I like the way you say it in your book, of course, too. The book I’m talking about is “Fostering Ope 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 this is a book for anybody really trying to do what you’ve done in your career, which is jumpstart and prime, 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 is my fifth or sixth company where I built that kind of open source culture. My experience really goes back to Sun Microsystems… Gosh, 2003, 2004. 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. Let’s send 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 bringing that open source cultural change, and I recognize that pretty much the recipe is rinse and repeat, in that sense.

And as I was moving across these companies, I recognized – I kept doing the same things again and again… 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 why 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 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’ sake… Because hey, you’ve got to have white papers, and somebody on your page, or whatever. But 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. So for the open source culture part of it, the open source program office was part of my team. My team had the DevRel folks, my team would sponsor the open source foundations, my team would sponsor these open source events…

[00:08:08.24] 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, or the chop wood/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 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 the Linux Kernel. We are one of the top contributors to Kubernetes, OpenJDK. We are 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, to use your guys’ Intel Inside…

[laughs]

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 advocating - not just “We should use open source because it’s great for our business”, but then taking that next step of “Let’s not just be users of open source. Let’s participate, let’s contribute, let’s support etc.” 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 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. 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 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 to win an NBA game by standing on the sideline. You’ve got to get into the field, 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’s 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. And then, of course, once you become a maintainer or you hire a maintainer, then you don’t put them into dark; you’re only going to 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.

[00:12:24.10] 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 to me seems like the obvious one. Like, that’s probably the most impact you can have. 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 - you know, 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, the 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 an 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. She said, “Okay, what do you need?” So 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 kind of 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 at the end of the day, we humans are always looking for incentives. So creating those incentive 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 “I don’t know why you’re contributing to this open source.” 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 complexity, that kind of engineering expertise from just one company. 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.”

[00:16:33.21] 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 [unintelligible 00:17:13.12] that I’ve seen across these companies is just purely lack of awareness. 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 were 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 this was purely lack of awareness.

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 heavylifting for you. And if we make that work better, that only runs our infrastructure in that much more scalable a 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 in 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. And I would say the 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? You know, Newton’s law of motion is always kick in; that thing is moving in a certain direction, you’re trying to change the direction, it’s like “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, 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…” So 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.

[00:20:01.28] 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. And 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. 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 re:Invent 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 – I mean, 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 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 that say “Yo, we can’t do that. This is our competitive advantage.” What do you say when people say “This is what we sell. Let’s not give it away”, for instance?

Yeah. 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.” So I think there are several reasons. And if I go through the book, essentially… You know, this is the book that we were talking about. There are several Why that we talk about. Is it a faster innovation? Is it a more sustainable codebase? Because then, essentially, you’re not just reliant upon your engineering teams. 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.

[00:24:04.14] 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 etc. 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, 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+ 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, whatever 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 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 on why you want to do that.

Break: [00:25:50.18]

You mentioned having some case studies… I don’t know if you have any case studies around this, but the question really is is aside from Kubernetes - that’s a good example of Google open-sourcing it, not holding onto 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; not even so much a corporation. But what are some other examples beyond Kubernetes?

Yeah, I think the book has about 40+ 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 “Okay, hey, we’re going to contribute dollars to an 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 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 studies. 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, it’s like “A-ha! 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 readers to go through the book and say “Which vertical do you align with?” Oh, maybe I’m 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 the 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.

[00:32:18.01] 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 into Swift. And if they just wanted an awesome language for iOS or Apple platform engineers, they probably didn’t need to open-source it. 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. So that was their why. It’s like “We want this to be more impactful than merely the next best language…” Not the next best. THE best language that they think, for developing Apple apps. And so that’s another good one where it’s like, that was a huge decision. Because think of how much money they had in the Swift just engineering hours. It was like five years of just Chris Lattner 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… So that’s a huge investment that someone said “Yeah, we’re going to go ahead and give it away to the world, in order to accomplish our business goals.” And I think that’s totally fine. 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. No, I think you’re putting it very well. Different companies have different Why’s, and each company has different Why’s 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 you said, in some cases; more often than not, it’s an enlightened self-interest, that “A-ha. Okay, this is where it’s going to serve me, and in the process it’s going to serve the world as well.” It’s totally a fair gesture, as a matter of fact.

I think, Adam, you were asking… Intel contributed, for example, oneAPI. So we created this oneAPI 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, this could benefit the world as well.” So a couple of years ago, we created this thing called as UXL Foundation. Uniform Acceleration Foundation. So that’s the foundation that we created, and brought a whole bunch of members together over there, and now that thing is taking a life of its own.

So in that sense, the whole idea was, if this is indeed an API, a 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 diversity of thoughts is what I really enjoy in the open source journey.

[00:35:42.03] We’re steeped in open source, of course, but how does this reflect into the other open source, a.k.a. inner source? I was just leafing through the GitHub case study really quick while we were having this conversation. I was just looking at how essentially their inner source – GitHub began as a social coding platform… We all know GitHub, I don’t need to tell you what that is. But their practice of inner source really became this sort of internal – basically, open source behind the firewall inside GitHub. How does that manifest in a lot of these companies? Is that truly open source? What are they calling it? Is it licensed? How do you manifest inner source? What begins that? Is it just simply “Our software and you can contribute”, or is it – how does that manifest?

I think the biggest reasons that I’ve seen inner source happening are multifold. First is you want to avoid duplication of code. How many loggers do you need in a world, right? In a company, if everybody is writing a same ETL app, there is no point doing that code duplication. So how can I create that discipline where inside the company, when you’re not within the firewall, you’re not going outside, it’s only engineers from the company that can contribute to it, so 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% of my task is already done with that one ETL app. I just need to put 20% more effort to customize it for my need. And if I contribute it back upstream inside the inner source repo itself, that’ll do my job. So that’s one.

The second part of it is - you know, a lot of the companies have certain stricter requirements, 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 going to look really bad. That one person will define the whole company”, which is generally not true at all. Everybody makes 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 inner source 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 InnerSource Commons [unintelligible 00:38:46.19] 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.

And 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. 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’ve 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 aligned with my roadmap, how does that work out?” So again, inner source 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.

[00:40:10.09] So in that sense, inner source is very, very effective. And Intel has a very large inner source practice. We have hundreds and thousands of repos here, which are run on an internal platform… A 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, inner source 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.

Yeah, it seems almost like a proving ground for open source at large. It’s like, if you don’t know what open source is, or - Jerod, back to the question you asked before, like what are the hard questions or what are the pushbacks 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.”

Our safe world, behind our firewall, controllable, all those things… It’s still unclear to me though how you begin. Is it simply like a private repo on GitHub? Is there a way to dashboard this stuff? How do you truly spark this? It seems like it’s bottoms up, 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 behind authentication and authorization? Is that what it is?

I’ll give you two examples. One of them is from Apple. The IT team from there reached out that folks were 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? Essentially, what we did is from ground up we built up an 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 a firewall, right? Like, oh, IT team only want to collaborate among themselves. Which is fine. Whatever the structure is. So we created an internal org on a GitHub platform, or whatever your Git 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 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. A 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.

[00:43:45.21] 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 CI/CD systems, cut down the cost by doing this wide range of orgs etc.?” So 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 going to contribute to that project, and that really cuts on 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 for your work, and you continue to make progress. So I think there is 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, it seems like some of the key characteristics are organization, some sort of org that says, “Okay, we’re going to make this a thing. This is not a thing… We’re making it a thing.” That’s easy. You mentioned nomenclatures… 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 inner source organizations, across different companies, so it just makes sense. And there’s some sort of shared knowledge or shared nomenclature.

And then you’ve got sort of visibility. I don’t want to recreate the wheel… I don’t want to go out to the open source land, because I can’t play there. I’ve got to 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 it? 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 inner source 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. So in that sense, inner source really gives that safe space for people to like “Okay, I’m going to refine my skills in my own comfortable environment, and I’m going to try this out. I played with the CI/CD system, I know how to git fork it, I know how to git merge it, I know how to rebase, and I’m learning internal tools…” So that’s from the engineering perspective. On the other side, from the inner source team, doing that advocacy, providing those tools, running those workshops, running those internal hackathons, 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.

Mm-hm. 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 of organizations in order to foster this open source ethos.

[00:48:12.29] 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 the workshop and hackathons - 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 and you feel inspired about it.

Internal projects, where you may say that “Okay, I’m just going to 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 going to spin up an internal project. Maybe in 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. Like, “Oh, I did not know you were working on this project. 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 ditto experience when we ran the first Kubernetes Summit at Apple. There were 1,000 plus people that showed up at Apple to that Kubernetes summit. And Apple, as you understand the company culture, it’s very walled across different views. But for the open source topic like Kubernetes, they were all able to share information, and they recognized 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. 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.

I remember SUSE talks about something like Hack Week, where they will have a week dedicated to hackathons. 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 it 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 remind me of an old show we did with a late great Dan Kohn. 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.”

I love that.

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. 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 it probably shouldn’t have been, because man, people were just interested in Kubernetes, for sure.

Yeah, for sure. That was a good title, Jerod. Good callback.

Break: [00:52:05.05]

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 don’t mind, I want to quote your words. You said “Hackathons and coding sprints are like HIIT.” Is that HIIT? Yeah, it is.

High Intensity Interval Training.

That’s right, High Intensity Interval Training.

Okay, now we’re going to get the athlete to come out…

[laughs]

That’s right.

Arun the athlete.

“Hackathons and coding sprints are like HIIT training for open source developers. They provide time-boxed and concentrated bursts of engagement that push participants to deliver impactful contributions within short timeframes.” I think that’s a great analogy, because I’ve always struggled to understand how you can do a hackathon at a company. I get it for, “Hey, come” and it’s sort of like – because the thing we struggle with as human beings (obviously, we’re human beings, right?) is that we desire and thrive in connection. 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 deeper roots, so to speak. So 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 out, have fun. Meet people. Do fun things. Innovate.”

Correct. When I was writing that chapter, I was thinking in terms of “What do I do in my daily life? “And Jerod, thank you for the reference. I’ve been a long time athlete, and this morning, as a matter of fact, my workout was a HIIT workout. I’m a lifetime runner, so I’ve been running for a very long time… But in order to maintain that running – you know, 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 get equally strength-trained, so that I can be a more effective runner. And if we bring that analogy essentially to open source, that’s exactly what it is. In open source, new tools keep coming all the time. And 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’m all in; I’ve cut down all noises and distractions from my life. I just want to learn this tool. I want to 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 I understand that, then I can go back to my normal running, because then I can say “A-ha, 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, Adam, 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 “A-ha, 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. 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. Think of it as a task conflict, learn that element, and see how that makes you become an effective coder, is what this all should be about.

Yeah, I feel like we could have an analogy for the fitness junkies out there. Like, you have HIIT classes like a hackathon, Pomodoro, that’s like Tabata… Coding bootcamp… Well, I guess that’s just a bootcamp. That already has an analogy. But we could have a bunch of these. I like that.

Well, that’s somebody coming in and 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 HIIT. The guest speakers are like the mentorship and coaching that athletes receive from seasoned experts.

Okay. Yeah, sure.

[01:00:04.04] 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. And topical summits really dig deep into a particular topic. And these are like-minded individuals, experts that get together. And these are more like “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, Jerod.

[laughs] Well, you beat me to it. I didn’t know you already went through such a fleshed out exercise. But yeah, good metaphors, for sure, for those interested in such things as fitness.

That’s good for you. It’s good for you.

Not for you, Adam.

Oh, I like fitness. I’m down with the fitness.

[laughs] So Arun, share more of your fitness bent. 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 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 or 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 – 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 55-minute workout. I pushed to the limit, all sorts of stuff. 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 it was 10K, the day before it 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 crime? Sometimes for me I get more motivated when I have an accountability partner, or something.

I’m all by myself. My schedules are very early in the morning, and I’ve got to go drop my son to school, get the breakfast ready for the whole family in the morning… So I do like really early in the morning.

Nice.

Most of the days I’m getting up around 5, 5.15, I hit the road by 5.30 or so, do an hour workout, and back in time for the first seven o’clock meeting.

Very impressive. Very impressive.

Yeah. I find if I have – I like an accountability partner, Jerod, but I find if I have to coordinate with somebody else, it slows me down. I can’t – I’ve got to spend an extra half hour, or just some buffer in there to deal with the “Hey, how you doing today? Let’s get going.”

Exactly.

You almost need somebody who’s like super-strict. Don’t talk to me… 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 want to be here, but we know we should be.”

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 going to get up early, I have to have something to where if I don’t do it, I’m letting somebody else down… Because I’m fine with disappointing myself. I do it all the time. But to disappoint someone else is like just harder on me… So I’ll get up for them. But not for me. Arun, apparently you’re self-motivated, I guess.

[01:03:58.19] [laughs] 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 a couple of weeks we are again going on scattered trips, but we are going to Patagonia. Well, my son and my wife are going to Patagonia, and then I’ll be joining my son on a beautiful expedition to Antarctica.

Wow.

So all of those really require a high level of fitness. I’m grateful that we’re able to do that.

Absolutely.

So provide a comparison for us… Difficulty and pain of summiting Mount Kilimanjaro, or authoring a book.

Oh, authoring a book was easy. Authoring was very easy.

Really?

Yeah. And my experience – see, frankly, in 2023 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.

No. Weaklings.

It’s too easy.

I mean, this was my seventh book too, right? So I’ve done that for a while.

Oh, this is your seventh book. Okay, 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 a use case, and all that; kind of refining their case studies. That’s where the biggest heavy lifting was. So that’s where we spent a lot of our time. Kilimanjaro was easy as well, as a matter of fact, because I run regularly, I lift heavily…

What’s hard for you? Tell us something 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 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 log after that.

Down sometimes is harder than up, isn’t it?

Down sometimes is actually – down is always hard. A lot more impact on your knees. And the grade is pretty intense, so 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 – you almost have a faster pace because you’re naturally being assisted by gravity. But then your knee buckles, your ankle twists, your sure footing may not be sure footing…

You slide down on your butt…

Yeah.

Yeah, yeah. And particularly because when we were going up, it was all during night. Because 10 p.m we got up, 11 p.m. we started the hike, and we didn’t see sun until 6:30, 7 in the morning. So it was all hike during the night. So with my headlamp, all I’m seeing is the shoes in front of me, and I’m just chugging along as they’re going through [unintelligible 01:07:39.29] whatever. So you just chug, chug, chug.

Well, why did you start that late? Did you want to 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 want to stay at the summit, because Kilimanjaro is 19.3441 feet… So at that elevation, usually afternoons are a bit tricky; the thunderstorms can appear. So they wanted you to get back from a higher elevation before noon kicks in.

Gotcha.

[01:08:13.23] 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. 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 OpenSSF 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, it becomes a hiring magnet, essentially. Why Intel is joining over there? Intel really cares about the open source culture, and other open source leaders get influenced that “Okay, I want to work at Intel and I want to build my open source career.”

I remember when I joined Amazon, one of the first events we did, we got up on the re:Invent stage and we said “Hey, build your open source career at Amazon.” And this was back in 2017, and that got a lot of applause, because essentially, Adrian Cockcroft, 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’re 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 in, again, fostering that open source culture.

I’m glad you mentioned that, because I think 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’ve got to support it in cost”, but then you think “Well, is that pay to play? Does that get me a seat at the board, so to speak? 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…

Correct.

But I think that’s really important to bring 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 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 organization, 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, 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. They’ve proven to do it well over the many, many years.

That is correct. 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 is, again, meritocracy, so douocracy, and how do you rise up to become a maintainer. So in that sense, the administrative part and the technical parts are separate. Like, 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…

[01:12:23.13] And I like that separation of concerns in that sense. But if the technical folks need some budget support, for example in OpenSSF, 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 want to create swim lanes where people can go faster on their own.

Can you tell us more about douocracy? You just said douocracy. 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.” 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 eventually, that douocracy 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 ladders. But that douocracy 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 douocracy. You do the work into the project to rise up to that level of maintainership.

I like that, douocracy.

How does one begin? So we’ve 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 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’s what I was looking at, in the book… It’s really about getting started on your culture change journey. 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. How does open source work for you? You need to overcome your legacy mindsets. That’s an important element, and there’s a chapter in the book that talks about that part of it. And then the book really gives you like a 10-step framework on how you can jump onto that cultural journey. I mean, the diverse audience is great. Having a top-level executive sponsor - because you need that somebody either at the executive level, top executive level, that says… 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 going to define the culture of my org, and I’m going to actively encourage, allow them to contribute to open source. This is what the incentive mechanism in the companies are.”

[01:16:22.00] 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 at the 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?”

Very calmly, yeah.

It was just a listening session, a venting session, essentially… 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 attraction. 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.

I don’t want to give away all the tips from the book, so I 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, don’t give all the goods away”, but at the same time, will this be – 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 quickly, in two weeks. And a lot of the work was case studies and external work and whatnot. But I feel like 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 of companies, whether it’s inner source, or open source, or whatever.

[01:19:03.04] So I think you’ve done a tremendous job. I can’t wait to read the entire book, personally. I’ve only leafed 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 from 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 crowdsourcing is the plain term, but open source is the future innovation. I think, actually, if I can leaf through it 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 LLMs, and AI, these models being open source… We’re seeing a massive change in accessibility to software, accessibility to models, accessibility to all these things… And the innovation that we’re seeing in our world. I mean, open source has won. 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 it 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. I’m really excited about how the book came about to be. I really hope this book is a fire starter for people who want to 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 at all? What’s left? You can even plug something if you wanted to.

No, I think it’s real 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 sustained, for yourself and for others, and that’s the critical element.

A perfect note to end on. Thanks, Arun.

Thank you, Arun.

Thank you so much for having me here