In this RedMonk conversation, Kate Holterhoff speaks with Ansgar Lindwedel, Director of Software Defined Vehicle (SDV) Ecosystem Development at the Eclipse Foundation. They discuss the concept of Software Defined Vehicles, the evolution of software in the automotive industry, and the challenges faced by developers. Ansgar explains the importance of the Eclipse SDV working group, the trade-offs of proprietary operating systems, and the role of open source in building competencies. They also touch on safety in open source software development, the ecosystem of Eclipse SDV, the impact of AI on automotive development, and the future roadmap for the community.
This RedMonk Conversation is sponsored by the Eclipse Foundation.
Links
Transcript
Kate Holterhoff (00:04)
and welcome to this Redmonk Conversation. My name is Kate Holterhoff. I’m a senior analyst at Redmonk. And with me today, I have Ansgar. He’s the director of Software-Defined Vehicle Ecosystem Development at the Eclipse Foundation. Ansgar, thanks so much for joining me on the MonkCast.
Ansgar Lindwedel (00:19)
Thanks for having me, Kate. I’m happy to be here.
Kate Holterhoff (00:21)
All right, so let’s start with some of the basics. What is a software defined vehicle and what makes the Eclipse SDV so important?
Ansgar Lindwedel (00:29)
So interesting one. I I try to or I’m getting this question quite regularly sometimes also from people who are not even from automotive and they ask me what are you doing and when I’d say like I’m looking on software defined vehicles they are like what and Pretty much you can if you try to look at it super abstract in the past usually a New car was designed coming from a hardware perspective like okay
how much horsepower should the engine have? How do we want the suspension to be? How do we want the driving experience, et cetera? And then to enable all these, also in the meantime, very electronic components in the car, which are still hardware, to enable them doing what they need to do, you needed software. So software pretty much was the, yeah, we need that to let the hardware do what the hardware needs to do. And the software-defined vehicle is pretty much flip-siding that entire
attempt of how to design the product. So you start from software first in terms of, okay, how do we want the software experience in the car? So what is the software experience the customer desires? What do they want from features, etc.? Then you design the entire software experience of the car and then you derive the hardware needs from what the software requires, which pretty much for automotive product engineering is the exact opposite of what the past 120 years look
Kate Holterhoff (01:53)
All right, that’s helpful. So I suspect many of our listeners don’t know a ton about the history of software in vehicles. So can you give us a brief overview of when and why software really entered into the automobile industry? And maybe as part of that, can you talk about where we are today?
Ansgar Lindwedel (02:09)
Yeah, sure. So maybe following my own professional career, so I’ve been pretty much working in the automotive industry as a software engineer by studies since all of my professional life. I started working after university in 2005. Software at that time was exactly how I described it before. So it was the thing which you needed to put to hardware like any sensors or whatever.
to enable the sensors to do what they do. So if you have an ultrasonic sensor at your car, who helps in parking your car and figuring out where’s the next thing I don’t want to bump into, it needed software to do that. And that was where software was, and often software still is. What is maybe interesting to people who are not in automotive embedded engineering is that
All of these different hardware have their own little computers attached to it. We call them ECUs, electronic control units. And these ECUs, they run the pieces of software which then helps the hardware doing what the hardware needs to do. Sensing something, recording something, whatever. Or the most prominent software you can experience in a car as an end user is most likely your HMI, your navigation, your I have apps, I have my whatever.
Google or Apple integration to have my favorite apps running on my car etc. so software in cars is often still super decentralized. So that means a modern super electronic car, so not electric but electronic, is having maybe a hundred of those ECUs. And it could also be that the software which is developed for these different hundred ECUs
is completely independent from each other. There’s interfaces for sure, but there’s different approaches how to develop that software, how that software is going to be on those ECUs. And I think what happened over the course of the last
years is that the electronic architecture of a car, so these ECUs, but then also the software accordingly got more more centralized. So that means instead of 100 different small ECUs in a car,
you have more and more what the car industry is calling high-performance computer. If you talk to a cloud engineer at Google or Microsoft, they would smile and laugh about the high-performance compute. for cars, it’s high-performance computers. Instead of having 100 different small ECUs, you integrate the functionality to maybe five, six big ECUs in a car and run the software more centralized, which then also comes with different software architectures working on those ECUs.
Kate Holterhoff (05:02)
Okay, yeah, that helps me out. So I want to hear a little bit more about the Eclipse SDV working group and how is that currently structured?
Ansgar Lindwedel (05:11)
So if you look at what I’ve just described, how hardware was enabled by software and now more and more we are getting into the software defined vehicle, this also comes with challenges how to, so that changes the architecture, that changes also the way you develop the software. And that also has requirements on what kind of tools do you use for that, et cetera. And many of the software building blocks for modern software defined vehicles,
That is software which you can say is not differentiating a BMW from a GM or from a Ford car, but it’s what I call a foundational software. So every of these ECUs or high-performance computers needs an operating system running on it. It needs middleware technologies which helps you abstracting between the underlying hardware and the software applications running on top of it. You want to decouple that.
Kate Holterhoff (05:58)
Mm-hmm.
Ansgar Lindwedel (06:09)
You would also love to have one of these software platforms, which is not something you develop for each and every new car from the scratch, but something you evolve as a software technology. You’re carrying over if you’re manufacturing cars from the first generation of the vehicle to the second, to the third, and you evolve this instead of every time you build a new car, you develop all the new software. Once that is out of market, you throw everything away and develop something new for the next generation.
of that car. And since many of these pieces are what I call non-differentiating, there’s no meaning in what the industry did, let’s say, if you look five or six years back, every car manufacturer, every big supplier worked on their own, they called it OS, even though it’s not an operating system, but VW was doing a VW OS, Mercedes was doing an MB OS, all the others did pretty much the same, had some other names for it.
And what they’ve been investing into is building this foundation layer of software Which in the end is not really giving your brand and your product a differentiating feature But you need that software to build the application software on top which then is differentiating your car So everybody was investing a whole lot of resources a whole lot of money also in building that foundation level To not really have something differentiating for oneself afterwards
So that was also the idea in 2021. I’ve been still working with Bosch those days to create an open source initiative saying like, okay, it’s just insane what we doing here. Why shall we all build that non-differentiating stack everybody for themselves? Let’s just integrate those efforts and make that collaborative. And that is pretty much what Eclipse SCV is doing. So let’s see.
To build this non differentiating stack together, everybody can run that into the cars, the big suppliers can run that onto these use they are supplying to the car manufacturers, et cetera. We develop that once, we maintain that once instead of so many different times, which is reducing cost, which is making you quicker building that and maintaining that. That’s pretty much what Eclipse SDV is all about.
Kate Holterhoff (08:29)
And so let’s pivot to talk about developer experience now. So help me to understand why current automotive development tools are disappointing modern developers and what specific improvements in the developer experience the SDV.Dev and SDV.Ops pillars, what they’re delivering.
Ansgar Lindwedel (08:49)
So if you’re an automotive engineer, you’re used to circumstances which for a cloud native engineer just maybe even sound insane. looking back at that 100 ECUs I’ve been mentioning, it could be that those 100 ECUs are developed each by each with different tools.
Kate Holterhoff (09:00)
Yeah.
Yeah.
Ansgar Lindwedel (09:11)
with different kind of what demands I have to develop that software. Obviously, since cars are a functional safety relevant product, it has a lot to do with functional safety. So you want your braking system to operate every time, 100%. So you cannot live. So if, I don’t know, an app on your smartphone breaks and not operates and you cannot, I don’t know, play your Angry Birds one day, nobody’s going to die, right?
If your braking system in car is not operating because software has a failure, that’s a severe issue. So the kind of three, as well as other industries who build products, are having demands on functional safety, invests a lot into making sure that software is always up and running and making what they want the software to do.
Also comes with that for these 100 ECUs, different context, different software which is running on it, it could be that an automotive engineer developing software for those ECUs is having maybe not 100, but a whole bunch of different tool sets, a whole bunch of different processes who needs to follow to develop that software. Also, these tools are not what a Linux developer from maybe a cloud native world is used to.
So they are not CI native, it’s very fragmented. Often you also have standards which are proprietary, so that means you also need proprietary tools. That also means that if there is something wrong at the tool chain and you would like to fix that, you cannot even do that because you would need to ask the provider of that tool chain to do that in their proprietary product.
You don’t have really an interoperable tool chain over the entire software in the car, but it’s really a fragmented thing. And usually if you ask automotive engineers if they love or hate that, they obviously hate that because that is a lot of complexity dependencies you’re having you don’t want.
how do we fix that? I think to say like in the future we only have or in five years down the road we only have one tool set and one way of producing software for cars that’s maybe too ambitious. But streamlining that, defragmenting this massive fragmentation we are currently having and trying to be closer to what a cloud native tool chain and also
the cloud-native way of developing software and releasing software is. That is what the community is working on if you look into SDV.Dev in particular.
Kate Holterhoff (11:55)
OK, that helps. So let’s go back to some of the things that you have mentioned earlier about this sort of traditional approach to foundational automotive software. And so you’ve characterized how many companies, they’re building their own operating systems. And that is just fundamentally an inefficient process, right? Can you explain the trade-off of that choice? I mean, there’s got to be a reason why folks choose that, right? So what is the final d-?
I guess turning point that has convinced major companies, so some of the automotive companies that you’ve already mentioned, right, BMW, Mercedes, to embrace sharing this open source platform like the Eclipse SDV.
Ansgar Lindwedel (12:34)
Yeah, so thanks. That’s an excellent question from my point of view and it’s also a personal perspective, right? So maybe I’m not hitting everything and every aspect of what people have at their minds. My personal perspective on that question is that everybody was pretty much going through a learning curve. So if you look back 20 years and that also comes from that fact, what I’ve been describing at the very beginning, software wasn’t a product in the past. Software was something you needed.
to make your product ready. And that means that many of the car manufacturers, the traditional car manufacturers, didn’t even develop any piece of software themselves. So usually they carved all of these ECUs and hardware parts out to suppliers. So you saw the big Bosch’s, Denso’s, Continental’s, whatever in this world. And they’ve been building ECUs, including the software for the car manufacturers.
So that means, let’s say 20 years down the road, there has not been a software engineer working at an OEM. Maybe despite the ones working in IT making that every laptop works for their employees. But nobody who was developing software for the car because that was carved out to supply us. So then if you look back maybe 10 years, the OEM started saying like, software is getting more and more important. So we need to have the competency of software, which obviously is true.
So if you realize that software is the dominating factor in how your product is experienced by the end customer, how you can also deliver new features into your product, you want to own the competency for sure. What from my point of view has been often the gut feeling and first choice of how to do that is we need to install software by a hundred percent. We need to do that all by ourselves. We cannot do that with suppliers.
Because if we do it with suppliers, we don’t have the competency. And I can understand this reflex to say like, okay, I need to own it to have the competency. But then we’ve been seeing big car manufacturers building sometimes even huge new organizations within their companies to deal with software. They hired a lot of talents from the market, started building their software themselves.
Obviously, they needed to start at the foundational level. So they’ve been working on OS, on middleware, on all of these things we’ve been discussing about. And then realizing that A, it’s not the easiest thing to do. And B, also you’re grounding a lot of resources into things which in the end are not differentiating. And from my point of view, open source is giving you exactly that kind of sweet spot and that trade off.
That means you are still working in those projects. So you have own staff who are also building the competencies because they contribute to the project, et cetera. But you don’t need to own that by 100%. What you want to own is the application software level above all this foundation level. the, I don’t know, parking pilot, which is making your, and just randomly picking any brands, making your GM performing better than a Ford or a BMW.
not judging, just an example here. But you want to own those software competencies where you can influence how good your product is performing, where the product is perceived by your end customer. But all the things which are below, you want to have the competencies because you want to also have an independency from somebody else. You want to be able to help yourself, but it doesn’t mean you need to own everything. And that is exactly what open source enables you to do. So you don’t need to have all the depth which is coming with zoning technology, but you still have the opportunity to gain the competence.
Kate Holterhoff (16:30)
All right, I love that explanation of what open source is really successful at achieving, right? Okay, so I want to dig in a little bit deeper into, I guess, how the developers are encountering the Eclipse SDV. So can you help me to understand from the perspective of an enterprise IT or cloud native technology perspective, what is the fundamental difference between writing software
for the hardware-defined vehicle of the past versus this software-defined vehicle that you’ve been describing, which is the future, right? And how does the Eclipse SDV project change the day-to-day of these automotive engineers?
Ansgar Lindwedel (17:12)
So from my point of view that is something which is not going to happen by just switching one switch and then from one day to the other it’s going to be longer than we had it in the past and only how we want to have that in the future so that is also going to be an iterative kind of process but pretty much it goes back to what I’ve been already describing about the tools you require etc. So in the past pretty much you had
one kind of tool set, one kind of way of working per one of these 100 ECUs. Extreme example, not super accurate, but many different kind of ways, many proprietary standards you needed to follow, proprietary tools you needed to use, which are from one domain to the other you’re developing software for, not interoperable. If you look at how a cloud native engineer is developing any applications for running in a cloud,
etc., then usually this landscape of tools he or she is using, the way of how to develop, how to release, how to deploy the software is always the same. So it’s more homogeneous than what the automotive engineers are used to nowadays. And pretty much the way it should work in the future is more the cloud native way of doing it. It’s going to be
different to the cloud-native because automotive will still have their specific needs etc. But to take the paradigms and the way cloud-native engineering is working and make that part of the automotive engineering world, that’s pretty much how the future should look like.
Kate Holterhoff (18:58)
So I want to pivot now to discussing safety. So the successful ASIL D safety assessment of the Eclipse Trustable Software Framework is a huge milestone. How does developing safety critical open source software for projects like S-Core differ from traditional open source? And what does this assessment truly prove about the viability of open source in these critical systems?
Ansgar Lindwedel (19:22)
Yeah, so you’re touching on one very important point I’ve been mentioning before already, what makes automotive embedded engineering different to cloud native engineering. And that is the example I’ve been giving early on. If your Angry Birds app on your smartphone crashes, you pretty much don’t care. It’s a little bit of frustration. But if a safety-relevant feature in your car isn’t working, that’s severe thing. So that means also in the future, it’s going to be different
the way you are developing functional safety relevant software in comparison to non-functional safety relevant software. What is special for open source is, since you have mentioned ASIL D. So ASIL D is pretty much a rating which comes from an ISO standard. That ISO standard in the automotive world which is applied is the so-called ISO 26262. That’s a functional safety standard. And pretty much what that standard is describing is like,
Hey, if you develop software and you want to develop a software for a functional safe context, like for example the software running on a raking ECU, then you need to do it like this. So it asks you to specify your requirements properly before you even start developing software. Then you should derive test cases proving that the requirements are implemented well once you test your software. Then…
You implement your software, you also make a traceability between requirements, test cases, the software, so that in the end, once you’ve done your integration test, system test, etc., you prove that what you’ve been specified in the very beginning is implemented in the software, it does what it needs to do, and it is not having any bugs. That’s pretty much an abstract way describing how this standard is working.
And then you also need to work processes in the development according to this requirements. If you look in open source projects, very rarely you find open source projects. And if I say very rarely, I’d say never. Where people start writing down requirements before they code. Because usually open source projects starts with code, which also is an advantage of open source because usually
You can innovate quicker because usually people start at code and implementations, see what it does, make it better afterwards, do iterations, etc. So how can you ever do functional safe code and produce functional safe code if you do it in open source following that paradigm? Most likely natural. And that is exactly where a trustful software framework also comes in because trustful software framework is pretty much an approach.
how to deal with functional safety. Not only functional safety, it also covers things like cyber security, standards, et cetera, but pretty much a new approach of how do you make sure that the software you’ve been developing is doing what it needs to do, is bug free, and therefore you can still prove that it’s functional safe. And that still goes with you need to collect artifacts, which is proving that you’ve done
or the needful things to ensure that you’re functional, safe, et cetera. But it’s a different attempt, like in the past, processes were implemented on this ISO 26262. And by following these processes, you pretty much proved that you’re functional and safe. And by getting that attestation, that trustable software can and applying that methodology and also tools which coming with it.
This attestation says like if you do that, that is also a viable way of getting a functional safety certification to your software code. And this is a game changer for open source communities overall. That is not only something for Eclipse SDV, that is also true for many other open source communities because they always lack this functional safety thing.
So any open source project which is working towards a product which is relevant in a context of functional safety benefits from this because now you have a methodology and an approach how to deal with functional safety in an open source developer project.
Kate Holterhoff (23:48)
All right, thanks for that. Yeah, I mean, I don’t think we can put too much emphasis on the safety part of the SDV, right? I think one of the things that interests me the most about the Eclipse software-defined vehicle is the ecosystem. And so what I mean by that is that there’s an open source structure and community, there’s events, it functions as a sort of innovation incubator.
Can you talk to me a little bit more about what the ecosystem looks like, maybe the roadmap? Why is the ecosystem such a pivotal part of Eclipse SDV?
Ansgar Lindwedel (24:22)
So the super simple answer to that is that obviously if you agree to what I’ve been saying before, if you’re an OEM, T or whatever, that it does not make sense to work on non-differentiating software alone, but you would like to do that in a collaborative manner with others, obviously you need others. So you need an ecosystem, right? And I like one.
One quote from our first steering committee chair we had, which was a gentleman from Microsoft who helped us building the first meetings and committees. And he always used to say, like, there is no ecosystem beside the one you’re building, right? So doing something in open source and doing it by just going somewhere on a public GitHub repo and dump a code base.
doesn’t build ecosystem because most likely either nobody’s finding what you’re doing or nobody’s interested in what you’re doing. So it’s an effort to build that ecosystem to make that collaboration even work. How does that work in the Eclipse SDV? In the very beginning, 2022, when we founded the initiative, there has been 11 companies founding this initiative. That was the initiators were Bosch and Microsoft and then we…
Quickly for the launch we acquired nine different other companies Continental was involved, ZF was involved So now I started calling names and I’m definitely going to be unpolite to someone I’m forgetting members were
Kate Holterhoff (26:02)
they’ll forgive you.
Ansgar Lindwedel (26:02)
but 11 industry members were saying this is a meaningful endeavor we should do that Interesting point was that day none of the OEMs have been yet part of the
initiative. So that means there was a solid base of 11 big companies, very European, very German centric, starting this initiative. Then in the first year we’ve been able to also attract two of the big OEMs, with VW and Mercedes into it. The year after we also attracted BMW into it. And that also was a pivotal moment for the community because obviously
all that software everybody is working on, in the end needs to be adopted by OEMs, right? So none of the tiers, none of the software companies who are part of the ecosystem can decide what software to put into cars. In the end, that’s a decision by an OEM. So the ecosystem needed OEMs. It also needs suppliers and software companies because that’s the knowledge, that’s the background they are having. They need to also build that into their ECUs, et cetera.
So you need a diverse ecosystem. You need the ones who can contribute. You need the ones who also finally adopt the software, etc. And that has been all the time the balance trying to build or get members into the ecosystem from all the different perspectives. And then what has been the fact for the first three years until I’d say last year or even the beginning of this year is that
We had a critical mass of OEMs, tiers, software companies on board. They were very European-centric. So we always had members around the globe. But if you looked at our member structure, then it was very European and in Europe even very German-centric. And that is something which we’ve been working on over the course of the last one one and a half years. At the beginning of this year, we had an announcement also during…
CES where we’ve been able to show that OEMs, tiers, software companies from around the world are now also contributing and also committing to use this software in future cars. So we’ve been able to grow the community in the US, in Korea. We are currently heavily investing also into the Japanese auto market because in the end
If Germany or if Europe is solving these issues, that would already be helpful, obviously. But it would be even more helpful if that is not something where the European auto industry is developing their standard and then a Japanese auto industry is developing their but a different standard. And then maybe the Northern American one is doing it exactly a third time, because then you have three standards around the world. What’s the meaning in that?
So if we all agree that this is non-differentiating stuff, we should do that worldwide. This is what we’ve been achieving over course of the last year, that this is not only a German initiative, but a worldwide collaboration.
Kate Holterhoff (29:18)
Yes. Okay. I think having that global representation is going to be so important to the success of the project. So I appreciate you laying that you’re thinking about right now. And yeah, helps me to sort of formulate what it is that you folks are doing.
Okay. So the community has seen a surge in interest in Asia and the US. I’m curious, what would you say is the key value proposition or unique challenge that Eclipse SDV is solving for the developers in these diverse regions? So we’ve got South Korea, Japan, a lot of these you mentioned earlier. And how do they compare with the initial momentum from Europe and Germany specifically?
Ansgar Lindwedel (30:01)
the same things, right? So all of these challenges which the German car industry or the European car industry is having, it’s the same challenge what is there for the Japanese and for the American car industry, right? So this idea of saying, okay, I need this foundational software to be able to develop cars in a software defined vehicle manner, what we’ve been talking before, everybody is having that challenge. And everybody is again also having the challenge that
Kate Holterhoff (30:14)
Right.
Ansgar Lindwedel (30:30)
using resources for something which is in the end not differentiating your product in the market probably doesn’t make sense. So everybody is benefiting in the same way from such a collaborative effort. And that’s from my point of view why the people are also interested in participating in international meetings we are doing, becoming part of the community. It’s not an easy decision all the time because it has to do something with you need to
realized that maybe you need to do something different to what you’ve been doing up to until today, which always is a kind of pivot in strategy. And also there is many different kind of standardization efforts in the industry as well. So it’s also a decision about, which one are the ones which I pick and invest into? I also understand that.
But I’m pretty confident that we do have, like I’ve been mentioning it before, do have a critical mass of members now from the different kind of roads active in the community. They are working on software which is going to be releasable software by the end of 2026 to then base the serious development which they need to do with their products upon that. So we are on a good way and…
Hopefully we can catch as many of the companies around the world to be part of that initiative.
Kate Holterhoff (32:00)
So, we’ve gotten this far in the conversation without bringing up AI, and I’m afraid that I can’t let you get away with it much longer. So let’s talk about the AI Special Interest Group here.
You’ve got projects like the Eclipse LMOs. What are some of these initiatives, and at a higher level, what would you say is the biggest long-term disruption that you are seeing from AI, the automotive development lifecycle?
Ansgar Lindwedel (32:24)
Yeah, so I understand you cannot have a conversation about tech today without talking about AI It’s always a little bit of stretch between Talking about meaningful stuff and just feeding the bus So from my point of view AI definitely will have and already have an impact on automotive engineering
Kate Holterhoff (32:31)
It’s true.
Ansgar Lindwedel (32:47)
which from my point of view is on the one hand side obviously in how developers work. So you see that in the enterprise IT world, AI is already doing parts of the coding job. That is obviously also true for automotive engineering. So the automotive industry is expecting that they have developer efficiency increases by leveraging AI, vibe coding, et cetera.
If you talk to developers, sometimes they say, like, OK, it’s even increasing my workload because I need to review that bytecode and code and make it work again. But we can argue about it from my point of view. In the end, there’s going to be opportunities to leverage AI to increase developer efficiency for sure. And it’s already happening today. What adds to that from my point of view from an AI perspective is that
Kate Holterhoff (33:22)
Yeah.
Ansgar Lindwedel (33:40)
everything what you see about agentic AI and how those AI agents can also add value in products by being implemented into products is definitely a total different angle here. And I’m getting to an age where I can say, like, I’m not even sure if I want that, but I bet we are going to see cars in the future where a lot of AI agents are in who are trying to make your
your life easier. Maybe sometimes they won’t, but that’s definitely a technology which is giving a huge potential of innovation. Think about how end customers like you and me driving around with a car could benefit from these technologies and how to deal with your car. Imagine like you’ve been able to mutually discuss with your car, influence your calendar.
whatever and your car becomes more or less your digital assistance instead of just a device which is bringing you from A to B. So another aspect of AI in automotive is also dealing with all these pain points I’ve been discussing before. So different tools, different processes, processes to follow. So AI can also play a pivotal role from my point of view in making the use of these tools and the use of how to develop software for
automotive system, AI can help relieving the pain which is coming from following these processes or dealing with different tools and make the developer life easier by pretty much putting that work and effort a developer has nowadays into the responsibility of an AI to do that. And that’s also something which is
in the scope of this AI special interest groups, especially the question of how can AI help making the tool landscape, which is there today, better and more convenient for developers.
Kate Holterhoff (35:43)
Okay, yeah. Well, I appreciate you addressing the buzz here. I think that’s, you know, it’s useful. It’s certainly top of mind for many of the folks who we talk to at RedMonk. So yeah, it’s helpful to least bring it up, right?
So we’re about out of time. I’m going to end us here on one last question. And that’s about your roadmap here. So you have stated that 2026 is going to be a big leap for the community. And that includes the launch of Eclipse S-Core 1.0. And so beyond this technical milestone, I’m interested in what would you say is the single most transformative experience or industry? that the Eclipse SDV will enable in say, you know, the next year, maybe 18 months.
Ansgar Lindwedel (36:29)
So that’s an interesting one. So what is the most transformative thing? So from my point of view, even though that you asked me about something beyond Eclipse S-Core, I need to mention Eclipse S-Core because developing
and collaborative middleware stack, which then could be used abroad across the industry in just two years would be super transformative. If you look at how long these kind of endeavors took in the past, if they’ve been successful at all, then that took longer time. Or you’ve also seen many of the attempts failing because in the end it wasn’t done to the final stage.
Kate Holterhoff (37:06)
Mm-hmm.
Ansgar Lindwedel (37:18)
Then having a joint software stack which the entire industry can use and we already see a lot of OEMs lining up saying like, yeah, we intend to use that also in our series production. You will see that hope. So from my point of view, the best thing which is going to happen is that every OEM then can refocus their priorities away from that middleware sync and focus their engineering capacities on
building software application for the cars, which is then differentiating them. So you will see a lot of more, as the end user of a car, you’ll see a lot of more new software features in your car coming to your car, coming also super frequently to your car, because the OEMs have time and money to invest into that instead of doing that foundation. And most likely,
And that is going to be an interactive thing. Also, the developer experience for the developer of car software will then step-by-step change and we will see a lot of more adoption of open source technologies in modern cars.
Kate Holterhoff (38:30)
Excellent. Okay. This has been such a great conversation I’ve really enjoyed speaking with you Ansgar. Again, my name is Kate Holterhoff. I’m a senior analyst at RedMonk. If you enjoyed this conversation, please like, subscribe, and review the MonkCast on your podcast platform of choice. If you’re watching us on RedMonk’s YouTube channel, please like, subscribe, and engage with us in the comments.
