Test & Code

Welcome to Test and Code. We have a couple of special guests from Intel, Joe Kerley and Arun Gupta, and I wanted to have them on to talk about Intel's involvement is with open source. Let's do a quick introduction, for each of you. Let's start with Arun. Can you introduce yourself?

Absolutely. Brian, I'm very happy to be here. Thanks for having us. Yeah. My name is Arun Gupta.

I joined Intel over a year ago. I lead the open ecosystem team here at Intel. But I've been, in the open source world for over 2 decades now. I've taken companies prior to Intel, I've taken companies like Apple, Amazon, Sun Microsystems to systemic changes to bring those people process tool changes or to bring that open source culture in the company. You know, usually, the CEOs or the some top executive will have a strategy, but until you have that culture in the company, the strategy doesn't manifest itself.

So that's the part that really excites me, and I'm super happy here how Pat talks about open ecosystem, and it is thrilling to be at Intel.

Oh, awesome. And, Joe, can you introduce yourself also?

Yeah. Arun's kind of the, perpetual hard act to follow, but I'm Joe Curley. I'm, I handle Intel software developer products and a lot of our ecosystem development for that. I've been at Intel for, oh, heavens, about 15 years. But, I have an oddity of having been an ecosystem partner of Intel's for over a decade and then a customer of Intel's for over a decade before joining Intel.

So I have a real passion for the work that's done in enabling and building out ecosystems and and the 3 very, very different views on on on the importance of what role Intel can and should be playing in an open ecosystem.

It so I'm really curious because I I didn't know any of this was going on. I mean, I think of Intel as just the the Intel inside. You guys make the chips to make, most of the possible, along with couple other hardware companies, of course. But, this is so I guess I don't know where to get started, but how does how does let's start with the open ecosystem. What is that?

I've never heard that term. I don't think.

Yeah. No. I I can talk about it. Pat, went on a sabbatical, a long sabbatical. I know he was at Intel for 30 years.

He went on a sabbatical as he claims it, to a different company. Then he came back. This is it, what he considers the real job as. And when he joined Intel back, about 9 months after joining, he wrote a letter on LinkedIn, which is open letter to the open ecosystem. And in that, he explained why Intel believes in open ecosystem.

Why he believe that that is the way all the innovations in the world has happened. And by open ecosystem, what I really mean is when you think of open ecosystem, it's a more encompassing term than open source. Open source is a big element of open ecosystem, but then we think of open API, open spec, open hardware, open data, all of those become part of open ecosystem. And as you said rightly, Intel is a silicon company primarily. And also all of those pieces are super important to us.

And are we like, in certain places, there could be open spec, you know, where we are all collaborating on the spec, and then the implementations is completely different. Or open hardware like RISC V. You know, those are the places where we can really do it well. Open source, certainly, by all means, is the biggest, portion of it. But all of those other pieces, layers, so to say, are very relevant.

And you said Pat. So that's, Pat Gelsinger?

Pat Gelsinger, our CEO.

Okay.

Well, we use Pat, like, as if, like, he's our very close friend. He is. But, yeah, Pat Gelsinger, our CEO.

Okay. I had to look that up. I'm like, who's Pat? So how how I guess it it does seem counterintuitive, actually. I've I've worked with hardware companies a long time, and the hardware company well, so Intel's kind of a bridge.

It's not I guess, there aren't very many only hardware companies anymore. They're all software companies also. But, like, our work companies are more, like, keeping their secrets. So doesn't isn't it dangerous for you guys to be involved with the open?

Before before we we get to the the concept of the open, which I'll let you, you know, take that's right in your wheelhouse, and then, I'll come I may pile on. But one of the things about Intel is that Intel is a little more complicated a company than than, you know, the chime for Intel inside. Most of the benefit that people may recognize is from the the server or or notebook that they, you know, any cloud or or on their desktop they're using. But one of the reasons, ironically, that I joined Intel 15 years ago was is that I was looking at trying to do a pretty cool and innovative product, a product that would kind of create a whole new level of energy efficiency. But the key to getting that to work was having great software on top of it.

And so in doing my own background and research, what amazed me was the tremendous amount of competency that Intel has in software. And, you know, there are things that are intuitive, like device drivers that come with the hardware. Okay. That's software for hardware or work that we've done in, you know, getting biases and building a stable platform upon which everyone else can start to innovate and do their own their own creation. So they profit from bringing their software on top of our platform, and we build a great platform that works with the software in the ecosystem.

It knows is is healthy from that. But, you know, the Intel C compiler has been an industry standard if you really want to have, you know, performant piece of of code that's really efficient. People knew to go and get Intel software developer tools or math kernel libraries or other tools that we've been building for decades. On top of that, and there's some really exciting things that are coming up in software that we may maybe we can talk about as we get there. But it it's exposing it's exposing the value of unique hardware out through through developer tools of our own, through open standards, and through community that and that really has helped Intel prosper over, you know, 3 or 4 decades, as a computing company.

So you know us for the hardware, but actually, there's a substantial number of software developers here. The number was thrown around earlier around 19,000 software developers inside Intel alone, today. And so it's a, you know, so it's a little more complex than just a company that you buy on hardware from. But, Arun, I think you can talk about the cool question of how we, of the I'm sorry. What, you had the cool question of if if is open or closed, really the right way to go?

Well, I I guess I wanna pause that a little bit longer because Yeah. You said 19,000 ish software developers. How does that compare with the hardware? I mean, is there more software people than hardware people? Or

Oh, I've you know, there's all kinds of things. If you Intel's if you kind of pull Intel apart, we we're a state of the art semiconductor fab, and we are a logistics company, a supply chain company. We have sales, we have engineering. So I don't know how to break down the org chart on all of these things. I think that the most important thing to take away from that large number is that software is incredibly important to Yeah.

To Intel's ecosystem and customers, and that we've been heavily invested in it for decades. And that we have a capability to be able to help help the ecosystem by providing software into the ecosystem in a way that's, you know, that supports the hardware investment, however many folks we have working on it.

Let me let me address that question specifically. You know? And as Joe said rightly, I think the key part really here is, you know, as you were saying, when I came to Intel, like, when Greg Lavender, who's our CTO, who reports to Pat, he reached out to me and he said, Arun, we would like you to build a open ecosystem team. Either way, Intel and software like what does that mean? And Yeah.

I was like and then he started telling me that okay that is exactly the problem we wanna fix.

Okay.

Because Intel has been invested into software for multiple decades. You know, we have been doing open source. We were the founding members of Linux Foundation, which is where you see all of these cool open source work happening. We have been the top leading contributor to Linux kernel, top corporate contributor to Linux kernel for 15 plus years. We are the top 10 contributor to Kubernetes.

We are one of the top 10 contributors to open JDK. We are one of the top contributors to PyTorch. And the reason we contribute to is exactly what is tied to our core business. Yes. Intel is a Silicon company, but the way our customers consume this silicon is by using these open source project.

When they are using our silicon private cloud, public cloud, data center, client desktop, PIC, no, edge, wherever they are running it, They expect that when they are running Chrome, when they're getting a freshly minted Windows laptop, Chrome is gonna operate at the maximum best capacity over there. That's why after Google, Intel is the largest contributor to Chromium. You I know they when they are running the Red Hat open shift out of the box and they're running on a Intel data center, they expect it to run at the maximum path. When they are running PyTorch, which is what everybody is using it for AI these days, they expect that the default algorithms are gonna kick in. And if I'm running on Intel, it's gonna be the most comfortable manner.

And if you think about open JDK, same thing. We contribute to open JDK upstream, and the reason we contribute upstream to the main branch because then it is distributed downstream in all the distros, whether it's Oracle JDK, Amazon, Corretto, Eclipse, Adaptium, all of those distributions. All of our optimizations are available in that. Now me as a customer, I bought a brand new Mac, a brand new Windows laptop. I'm not gonna go for open JDK.

I'm gonna go to right? Yeah. I I might, but more likely than not, I might end up downloading downloading Oracle JDK or Amazon Corretto. Or if I'm running on a data center like the AWS, then I might use Amazon Corretto. That's where the optimizations are already available.

And that's really what drives us. And that's the part I was mentioning earlier. There is a strategy, but there is a very significant cultural element within Intel. That why we contribute to open source because our customers care about it. This is a true customer obsession and as a matter of fact, Intel contributes to 300 plus community managed projects.

What I gave you is just a slew of very few examples of where we contribute to. Yeah. And We're not it's not

and it's not a charity for what for what it's worth. I mean, it's in every it's in everybody's interest. Right? The one of the if if we build out an innovative piece of hardware, let's say that we we we add additional cores to a CPU or we we put something called a SIMD instruction inside a CPU that allows you to get, you know, 8 to 16 times faster operation than something. It delivers more value and causes people to consume more of our our products.

We could we could build that and hope that people write software for it. Or you can go and you can you can start working with the communities and enable the communities to get the most out of out of that technology, you know, from as early as possible. So, you know, when you you have hardware innovation, but the open ecosystem is a great way to expose that and create the thing that really matters, which is user value and user preference. So there's great synergy.

Right. And add that add to that, for example, send the instructions. I was literally talking to the team that is contributing to WebAssembly. And the reason they're contributing to WebAssembly is they wanna make sure the code that you know, whatever Rust, Java, whatever code you're converting to WebAssembly, end of the day you wanna run it in a browser in the most optimal manner. And because of the SIMD instructions that are in the hardware, that's where the WebAssembly SIMD marriage has to happen so so that it runs in the most optimal manner.

So in a short phrase, you know, which is what Pat and Greg talks about all the time is is software defined, hardware enabled. And hardware without the software being enabled on top of it is a bug. So that's sort of the mentality, that's sort of the thinking across the company, whether it's a Intel managed or Intel owned product where we have given it to the community and we are the leading maintainers, or community managed projects like PyTorch or Kubernetes or OpenJDK, where somebody else has contributed and one we are one of the leading maintainers over there. Both ways, the idea is to do this in an open ecosystem because that open ecosystem really allows everybody to participate. It gives a choice to the customer.

No. You're not locking in into a walled garden. And as Linus' Law says, all eyes given many eyes or makes all bugs shallow. It really builds trust in the solution. So really that open choice and trust are sort of the founding pillars of our open ecosystem.

There's, one of the things you you mentioned, that is interesting to me is is in a lot of the ways that, all these products that you're talking about, they they still are a lull tons of software developers care about this, but the end user of the stuff doesn't really see these things. Like, the user of a website doesn't know that it's using Kubernetes or PyTorch or something. PyTorch is probably more visible because you had data scientists using it. But the, in which we we love because primarily a lot of our listeners are Python based, and so we we're familiar with the PyTorch and Kubernetes and stuff. JDK, maybe not so much, but, but that's it.

Oh, except for we use also use, JetBrains tools, and JetBrains are built on Java. So so, yeah, we're there too. But the the interest one of the things that we've seen a lot in the open source world lately, and I'm curious how Intel's thoughts are on this, is there is this this weird thing going on with a lot of open source projects is you've got people from other companies or even individuals that are contributing their volunteering time. And then you have, people like Microsoft and Intel and Google, participating in these communities, but they've got corporate interest. So you've got, like, these corporate expectations along with just some people just doing it in their free time.

Are there is there a friction there that Intel sees at all? Or

No. Not at all actually. And we love that part as a matter as a matter of fact. You know, I mean, yes, there are people whose job it is to enable the latest Intel hardware, Intel features, you know, Intel instruction sets up there. But there and the fact that we have lots and lots of people who do chop wood, carry water work.

For example, there is Krog who is on the open SSF, technical advisory council, and a chair. No code, but lots of deep technical work. There is Marlo Weston, who is a cochair of TNCF TAG Sustainability Group. No code, but lots of deep technical work to take the foundation forward. Chop would carry water.

Kathy Zhang, who is on the technical oversight committee for CNCF. I am on the open SSF governing board. I am also on the CNCF governing board and the chair of the governing board. So all of those things are truly, truly taking, and that's really our legacy, honestly. That's what we have been doing, you know, for all these years.

And that job would carry water work, effort is very well respected within Intel. As a matter of fact, couple of months ago, we ran our open ecosystems summit inside Intel. And this was really if we would have run it externally, you know, think of it as an any external event, but we have 2,500 plus people that were inside Intel. We're doing all open ecosystem work. And this was very exciting to bring the people together, talk about what they're doing, create that synergy.

And then from there, we are sort of curating who could potentially be external speaker, what kind of content we can generate. It's a very taking that multichannel strategy where, yes, coding is a big element of it. Coding is the glorious world, but the non glorious world, how do you run meetups? How do you do conference talks? For example, the NCF is organizing WASM Con, the first web assembly conference.

And there are people from Intel who are on the program committee reviewing those talks. Non code, but deeply technical work. So that is very well rewarded inside Intel.

The word community is actually a pretty important, it it it it's pretty important in the framing of your question because communities are, you know, they build standards, they self govern, whether you're a corporate contributor or an individual contributor, what you're bringing has to fit into what the community needs and wants and desires. And I think you're absolutely correct in another assertion you made earlier, which is by and large, you know, the the the more abstracted the developer is away from the hardware, the less they care about what's in the hardware. I mean, honestly, kids in my family who program don't really care about ABX instructions. They never will. What they do care about is did the job get done?

And, when they did the job, could they get n of those jobs, you know, on and off their company server in time and, you know, so that the the the nobody yelled at them. It worked. And so, you know, you get you get a performance benefit or you get more, you know, more virtual machines into a, you know, into a server. So all that work the benefit to the to the developer at the top is it just worked. As you get further down into the stack, when you're writing PyTorch or when you're, you know, when you're involved in Kubernetes, you start to care a lot more.

But, ultimately, you you work at a community to you have standards. You have things you're trying to accomplish. Everybody contributes, self govern, and you make it easy for the developer at the top just as you asserted.

So I I get the okay. So there's a whole bunch of, like, ecosystems that that benefit Intel if they're if they're running smoothly, software ecosystems. But there's also some software projects that, like, I'm I'm sure some of the Intel employees care about that Intel itself doesn't really. So, I guess, is there a this might be a tangent, but is there a philosophy around that? Are you do you allow Intel employees to contribute to open source projects in their free time that are not related to these open initiatives?

Absolutely.

Absolutely. You know, I mean, I I was literally following that process myself. I've been I've started to play with web assembly. How could I take, for example, a Java application and, package it up as a web assembly to run-in a browser? And then similarly take a Rust application, package it as a web assembly, and, run it as a microservice, and then connect the 2 together.

And then I just get get my hands a little bit wet in that technology. So there is a process. As a matter of fact, the open source program office is part of my team. You know? So, as part of that open source program office, we have our own time process by which you can say, hey.

You can contribute to any project that you care about. And I'll just fill up this form, get your manager's approval, and roll with it. And that is encouraging. You know, on time means you can use your own time, own resources, but you can contribute to those. And believe me, you know, over the last 3 years, what we have learned is, I was not here, but the last 3 years, people had so much spare time to do things.

And as software developers, you know, this is what sparks their innovation. This is what sparks their energy. Yeah. And that's very important.

Yeah. And you never know what

bleeds over into actually useful for work later. So Yeah.

Well, that's exactly where I was gonna go with the follow-up. And I think it was it's a perfect it's a perfect segue. That there so there's the stuff you do at home. There's also things that you suspect might have might be interesting. But before you go rolling a huge investment in trying to build up a product, you know, you you can do a lot of work out in the open and see what the what the community will do with that.

And and there's one one project that, Arun and I both have had something to do with in open federated learning, where working with universities, academics, and hospitals, whatever else. It's not Intel product, but but it's something that we we knew a lot about. And we had well, we were working on concepts of how you could do secure transfer of patient records anonymously across different bodies. That's a really it's a really hard distributed and federated problem, and you can learn a great deal. And so if you can find a community of 6 or 7 different major groups that have a similar interest, you can you can use open source development to really pioneer Pathfind and and find ways to to to solve hard problems together as a community and then decide what what that ends up meaning for your products later.

Yeah. And that particular project, you know, Brian, OpenFL was created out of a customer need. We created that project. Ultimately, we contributed that to LFAI and data. And just to kinda close the loop on that as well, Intel is part of 700 plus standards organization.

You know, Linux Foundation, W3C, all of these. So you were talking about, you know, is non code work encouraged? Very much so. Because we believe, you know, we need to be in those driving positions. We need to be in those governing boards and the technical oversight committees to drive it for our customers.

And projects like OpenFL that Joe just quoted is a stunning example where we work with, UPenn, and other partners, and we created a credible solution. And we said, hey. This is really cool. I know we're gonna test the waters and this makes sense. People are liking it.

Let's give it out to the community and truly, like, open up the door. So I think there are personal examples. There are corporate examples. There are commitment to the standard bodies and foundations all over the place that is highly encouraged at Intel.

Nice. I think

the strategy, as I said, I'm gonna go back to that point again and again. Strategy is just one element of it, but the culture is just mind blowing.

Okay. So how does that, what do you mean by that? What does the culture changes? Do the cult does the open open source idea culture change anything else other than people contributing to more projects?

I'll I'll tell you why. My previous gig before coming here was Apple. There is neither a strategy nor a culture to be open source centric. Working well for the company, there is no need to change that. And I've given a talk, why, you need to create a open source culture in the company because no matter what your strategy is, if the culture is not there, culture is gonna eat strategy for breakfast.

And it's a famous Peter Drucker's quote. So the having that culture is super important. Something like inner source. We have a massive inner source movement inside the company. And inner source is basically bringing those best open source practices inside the company.

So we have a unified code base. We have one CICD where it's unified across the company, and that allows you to improve the security posture. We take a look at things like open SSF scorecard and see how we can integrate that to into our projects and practices. We need to create SBOMs. So you using that unified CICD, we can create those kind of things.

So really enabling those teams, having open source program office, having those open source advocates, having those, BU specific open source teams, which are really guiding them and advising them on how open source needs to be done correctly. You know, having that deep inner source practice where on a monthly cadence, we are generating a report that, hey, here is a health card of your open source into or inner source project. Those all things really add to the culture because as they say, willpower is overrated. You all need those mechanisms and tools in place to make sure you're making progress.

Now inner source, I'm just I wanna, like, poke at that a little bit. That's I wanna make sure I understand that. That's like I've got a little tool that helps me in part of my job or something, and I'm gonna make it available to other people in the company. Is that what that is?

That's right. That's right. Well, it starts with that. But then, you know, at a company of Intel scale, you know, when there are hundreds of employees contributing to that scale, the challenge is, yes, here's a tool that I created. I'm gonna make it available to other employees.

But if other employees wanna contribute to it, how does that work? Do I what is my governance model? Everything that we do in open source. What is my contribution ladder? Do I accept their pull request?

Who reviews the pull request? Do I allow them to be a maintainer? And more importantly, if 6 employees in the company have a similar need, are they all creating similar tool? How how am I improving the discoverability aspect of it? So all of

those Discoverability.

Are gonna be dig into our inner source practice. And we are really creating that developer productivity platform inside the company that truly, truly brings that culture and the open ecosystem from it. So doing those we did a internal open source hackathon a couple of months ago. And there were project maintainers who were waiting to bring in new committers, guiding them. Let me tell you how to send a first GitHub pull request.

Let me tell you what it takes to be a maintainer. Let me help you walk through building the project. Those simple things, you know, the thumb becomes a lot bigger than a hole, and that's what brings a cultural element.

Yeah. That the those are interesting, and I I I love to talk to more people about how they're, managing their inner source stuff because, there's a there's weird stuff that happens. Like, this this person in this other project is using our little tool, but and they have a bug, and they need it fixed, but we don't care about it. So do I how do I how do I justify spending time on it? I mean, it'll help the company, but right now, I can't.

You know, those sorts of weird negotiations with inner in inner politics.

It is absolutely no different than in an external project. You know, it's like, is it if it's not your priority and if this scratches somebody's itch, do you allow them to become a maintainer? You know, do you Yeah. Recruit other people to be the reviewers of that pull request? Do you even allow that kind of a thing?

And, you know, it takes a village to really build that community. So I think that effort is super important.

You know, you said something interesting a couple of minutes ago about, culture and strategy of Quentin Trucker's famous quote. I think what things are where things really align well is when your culture and your strategy actually all align. And then, you know, we we talked about Pat Gelsinger earlier. And one of the things that Pat, when he came back to Intel a couple of years ago, reminded us of is that through its history, Intel as a company does best in thriving, you know, open ecosystems and systems without walled gardens and systems where, you know, we're all we are we are, organically, ending up competing. And so it the two things actually feed very well on top of each other.

You'll have more developer if you're more open and you're more accessible, you have more developers who are working on top of your platform, who want more consumption of your hardware, who it all comes together. The alternative to that is trying to figure out if you can build a wall or garden, walk everybody in and say, hey, I'm gonna give you maybe the best user experience. I know how to, but I'm gonna control absolutely everything. And that works for some companies. Historically, our strategy has actually aligned very much more to the open platform.

And then it gets into you start building then you know, the the business alignment and the culture alignment all come together, and then you get things like you naturally work through internal and external projects where how do you handle customers? How do you handle for for our install base, when someone finds a bug in a, you know, in a compiler, we have them. You know? How how does it pop up? How do we how do we end up treating that?

How do we get it up into the mainstream? You know, you upstream. And so, you know, whether it's internal or external, it's just it's an input. And and, you know, just all part of how we do things.

I, I imagine so I met one of I've got a lot of questions, but one of the things that interest me is you said, like, a bug in a filer. I mean, it it happens. However, I'm I imagine the testing is pretty good because, I'm I'm gonna assume it if I see a problem, I'm gonna assume it's me. I'm not gonna assume that it's the Intel compiler.

So it depends. Sometimes the error message that gets thrown tells you it is. So, yeah, I mean, obviously, we try to build really high quality products and high quality contributions. The developer tools are insanely complex if you think of everything we have to end up supporting. And in the open source world where we're supporting potentially people's platforms that aren't our own, it gets even more complex.

And so, yeah, you you gotta be good at what you do. You have to have a good architecture, a great design, a good implementation, great test system, great Arun mentioned CICD. You know, you wanna be a great software company and have to have to have all those practices. We try.

I I'm just refreshed because, I mean, it makes sense. I but I didn't real I guess I hadn't really stopped to think about it that that Intel really cared about a this this this sort of open open source support and and getting involved. But you also said that, like, Pat came with this idea a couple years ago. That's not that long ago.

Did you actually it's so I think I hope, like, the way I said it, I you know, we'll go back and listen to the podcast later, is that he reminded us.

Okay.

I mean, it's it's something it's something that we've been doing for 40 years. But you you mentioned earlier, there's always a discussion of what we're a for profit company. We we build products. We we want our products just, you know, to have to be unique and position them in the marketplace. And so there's always a as you point out, there's always a tension that says, you know, is can I do this?

Would I want to? And so what Pat reminded us was, this is easy. In general, Intel wins in open ecosystems. Make that your make that your make that your make that your center of gravity. And, so we we we try to figure out how to, you know, how to work collaboratively to build the most robust and and healthiest ecosystem for computing out there.

I think Brent, the honestly, when I wrote read that letter a few months before I joined, and I'll drop a link to that letter, it said, you know, I I fundamentally believe in open source bias. And he quoted several examples over the history of Intel. Things like USB, things like UFE where we have completely driven these standards out in the open. So this is not something new. No.

We have been doing this for multiple decades. Somebody asked me, Arun, what's your job? I said my job is only chief storytelling officer. Joe and his team are doing a fantastic job building the products. We just need to tell the story more and more.

And I really wanna pivot, and I know we have about 10 minutes left now. But I really wanna talk deeply about one API on what we are doing over there and why we are all doing over there because that's again a classic example why we believe in opening system.

Okay.

Yeah. Yes. So maybe maybe I think we we have to start off. Before you can get into one API, there there you have to start with a a basic problem that's going on in the industry. And if you read Henderson Patterson's watershed paper from a few years ago, you you hear that there's a Cambrian explosion coming of computer architectures.

And you can it's a great paper. We could we could put a link to it. But ultimately, it says that the need of specialized computing, things like artificial intelligence, which we've certainly seen in the last 6 months, are are driving novel novel accelerated hardware into designs specifically built to solve specific problems, which is really cool, and it's happening. The fundamental problem was the thing you talked about earlier, which is, you know, the the developer, by and large, is completely unaware of the cool hardware at the bottom and actually really doesn't wanna know that much about it. They just want the result.

And so how do you program all of these individual devices that are really cool that that could do something really, really well, whether it's using a GPU or whether it's using, you know, a blockchain accelerator, whatever it is you're trying to get done. And so the historical problem we have is that everybody writing a building a piece of hardware builds a bespoke stack of software that it's really optimal. It works really well with that one thing. But what's the problem? Well, if you if you invest in writing the code for that one widget, you either have to rewrite everything to get to the next widget.

Uh-oh. You know? Or or you're stuck on that person's widget forever, which has its own set of uh-oh. Uh-ohs involved in it. In it.

So accelerated computing is happening, but you have lots of individual proprietary tool chains that that make it hard for people to to sustainably take advantage of them. OneAPI is a really simple concept. It's an open programming model targeting all of those different kinds of accelerators that allow people productively to write code for all the different architectures that might get deployed on, whether it's a CPU or GPU, an FPGA, an AI accelerator, a blockchain. So whatever it is, you can write code and you can deploy it down to that hardware, and uncouple it. And if you're a hardware developer, equally, if you endorse the standard, what you can do is take advantage of all the software that's been written up at the top, and it will fall down to you.

So it's just an it's an open, an open programming model for accelerators. And that breaks that breaks a chain of years years years of very pry proprietary bespoke codes.

Now is is this a a is this a Intel driven thing then? Is one API an Intel?

Yeah. So it's community driven. And in fact, it's community governed today. But when you when you start something like this, Arun mentioned USB hardware stuff, USB, Compute Express, PCI PCI Express, all of these hardware standards that exist. A lot of the IP in that came from Intel.

But at some point, you have to open that IP up to the community if it's if it's beneficial and allow others to contribute. And then eventually go to an open standards body and have the open the open body, manage all of that. So we started oneAPI community driven, actually working with academics, competitors, all kinds of people and saying, what you know, if we were to do this, how would we do it? And we we had a small cultivation phase where we proved the concept, which started up until, you know, from, like, late 2018 to early 2020. And then we went we've always been open spec, open development.

Most of back most of our products in it are backed by open source repos. And then in last November, we actually went to open community governance, where today there's an open governing body. And there's even work going on that says, you know, should we have other mechanisms for maintaining this because it's so important? Should we have even more formal governance around it? But, yes, it's it's open.

Okay. I actually think I know that the competition is real when money is involved, But one of the things I'd love to see happen is for companies one of the things that happens in a open source is to try to not think about competitors or competition even though there is. Like, for instance, in the Python ecosystem, there's fast API that's that's going along, and there's, you know, Flask and and Django, all web frameworks. And they don't and we could think and some of the people might argue about it, but the people actually at the at the head root of those, they're not angry at each other. They don't they're building off each other.

They're they're some ideas flow back and forth. And I really would love the more of that anti competitive philosophy of of open source to seep into companies more. So we don't think of competition really too much that, yes, some you'd want you people to buy my product versus theirs, but having both companies get better is always better.

You're you're you're you're absolutely right. And, you know, the, you know, I think that the the spirit has to be where we have common problems, we embrace common solutions. Differentiate, specialize, take your unique position, find some way to enhance the platform and deliver extra value. Yeah. Absolutely.

But, if the alternative to that, if you don't all agree on trying to solve the same problems together as you end up with 6 or 7 walled gardens, and then, you know Yeah. A lot of not good things happen there.

I wish we had more time, but I know we have a hard clip.

Well, that is a true spirit of open source, as Joe calls out. You know, the coopetition is a common philosophy in open source. Yeah. Yes. One API, you know, is a common API, but there is enough I know once is this, you know, you know, multiple tides rise all boats.

Yes. That's sort of the element here. So I think that's very important because you as I said, the open source really needs to be tied to your core business and it needs to benefit your business. If it doesn't, it's gonna stay on the fringe. So that's where, you know, efforts like oneAPI truly benefits where we are bringing multiple partners and lifting everybody up.

Hey.

Moving it from the abstract to kind of an anecdote is one just just to just to emphasize the way we feel we all feel about that point. I wanna hit the cultural aspect for a second. I was at a conference, and the head of one of Japanese Japan's largest computing projects came up to me and said, we just broke the MLPerf record. We just we just shattered, machine learning perf. And and it's, oh, that's great.

He goes, we did it using your code. I said, oh, really? You say, yeah. Yeah. Yeah.

Yeah. Yeah. It's sickle code on top of on top of 1 DNN from 1 API. We took that it only took us about six and a half weeks. We were able to get that up and running.

It's on our ARM based processor and look you know? And and and and I went, great. Great. Yeah. Great.

That's exactly what we're here for. We want we want to be you've just given us, you know, an absolute brilliant proof of, you know, why we're why we're building an open ecosystem so that people can innovate underneath it and build hardware and and have a better development platform so that it'll attract more developers. That's great. It was like, oh, you know, and and then their people started attending our technical advisory boards and continuing to contribute to the the standard because we all recognize that it's that that's exactly what we're trying to do. We're trying to build an open, an open accelerated ecosystem.

Cool. Any, any final thoughts that you guys wanna get out before you need to leave?

I think I would add, you know, I would really encourage people to take a look at open.intel.com. That is our primary website where we talk about all of our open ecosystem efforts, why we do, what we do, which events we're gonna be talk to us. We have, open at Intel podcast where we feature regular guests. So if any one of you open invitation. If you wanna come join us, be there, they would love it.

We also have open at Intel Twitter handle where we tweet regularly about our presence, etcetera. So those are sort of the usual channels by which you can reach out and talk to us.

If you're if you're intrigued about accelerated computing and and and, you could spend a full podcast of an hour on that alone, and it would be really cool. Not at intel, but at oneAPI dot io, a third party site that we administrate. But but it but it's contributed through it's a community site with community repos. You you shouldn't find any intel up there. That that's where you can learn more about what the one API specifications are.

You can get access to all the repos, and you can take a look at all the technical advisory board and community minutes that are done in the open, which you'd expect from an from from open community development. So and chat with people there. We can we're we're always looking for, you know, more aligned people to to chase the goal.

Nice. Well, thanks, so much for your time today, and we'll talk to you guys later.

Brian, thank you so much for having us.