 Well, welcome everybody to the third installment of OVE's open source policy series. My name is Steven Pech and I am OVE's research director and I'll be taking you through our event today. I hope everybody can hear me well. For those who don't know us, Openform Europe is a Brussels-based think tank working at the intersection of open technologies and public policy. So why did we decide to put together an event on open source and automotive? I think the general issue that prompted us needs really little introduction here. EU is behind on digitization of its industry and we all know the headlines and if you work in Brussels you will have seen those headlines on the cover of The Economist. We also all know the number of European companies leading digital is pretty small. Usually there's SAP, FI and then we're pretty fast done with the list. That is where policy comes in and the European Commission notes in their strategy documents Europe is a continent of industry. And there's few things that are more European industry than the car industry. So we felt this was a good case study to look at how open source software is touching industry. And as someone who never owned a car but lives in a city obsessed with cars, it's clear that cars aren't going anywhere and that the automotive industry is pivotal to European success. Today if you think about software, what is becoming important to people when they today if you think software is really important when you buy a car? So there's suddenly lots of questions here and let me be the first one today to say software is eating the world. Will my car drive automatically on the highway? Will it create the perfect route taking into account charging stops? And can I plug in my phone and use that on screen? And I haven't even mentioned all digitization that needs to happen outside the buyer's view when for example building a car. And so today we want to talk about what we see as one of the pieces in the puzzle to succeed in this transition. The aim of this event is to work out how open source is helping the automotive sector to digitize their business from their products to production processes and what the sector needs to accelerate the pace of digitalization. But first few words from the sponsor of the OVE Open Source Policy Series, the Eclipse Foundation. And we're thankful for the support enabling us to put this series of events on. After that we're going to kick off today's event with a keynote speech by MEP Maser Collager, Vice President of the European Parliament, before we seg into our panel of two experts from the software industry, the automotive industry and the in-between. We'll have a discussion between Debra Rind, CN director at Red Hat's Open Source Program Office, Dr. Katerina Marakke, associate professor at the Graduate School for Media and Governance at Cary University and strategic advisor at Ambition, which is Mercedes software development subsidiary, and Michael Plugger, who is Ecosystems Development Director at Eclipse. Just a bit of housekeeping before we get started. We want the policy series to be a space for open exchange. And we're very happy to take questions from the audience. If you'd like to ask a question, please write your question in the chat or use the Ask Question feature here in Crowdcast. Please also take a note that this event, like all OF activities, is covered by the OFE Community Participation Guidelines, which you can read on our website. And I saw that a colleague put a link into the chat and a reminder that this event is being recorded. And so now without further ado, Gael will come on, I think, in a second to speak about what the Eclipse Foundation is doing. There we are. So I will go off and you have the word. Thanks, Yvonne. So, well, I'm Gael Blondel. I'm VP Ecosystem Development at the Eclipse Foundation. And yeah, just a few words before we start today. So as you may know, the Eclipse Foundation has decided to move to Europe. And we finalized this move in early January. So maybe when you hear about Eclipse, you associate it with the development tools, but that's very important to understand that the Eclipse Foundation is one of the large umbrella open source foundations with more than 400 projects. And we cover all kinds of topics. And by the way, Automotive is one of our four pillars with IoT development tools and cloud native Java. And with our move to Europe, we also invest a lot in AI and cloud, for example. So we are very delighted to be a sponsor of the OFE open source policy series. We met with the OFE team some time ago and we really think that our activities complement each other very well. Also, we think that open source is very important for the automotive industry. And I mean that it's not only important for the design development tools or simulation tools. But also now for the platform for the future of automotive. And so our commitment is really to help automotive players strive in open source. And finally, before to keep it short and before giving the floor back to Sievan, I want to mention Katenaix, which is the B2B platform for the automotive delivery supply chain. And more specifically, Traktor 6. And Traktor 6 is the first open source project from Katenaix. And this project started very recently at the Eclipse Foundation. So I can tell you that we are very proud and very excited about hosting this project. And well, thanks for your attention. I'm very much looking forward to hearing the keynote and the panel today. So I won't be any longer. And have a good event. Thanks. Thank you, Gal. So now we're ready. And I'm glad that will be joined in a second by MEP Masal Koulaja, providing today's keynote. I think you'll come on also in a second to take it away. 10 seconds. I can see in the tool he's coming on. And there we are. Here we go. Great. Thank you. Take it away. Good afternoon, everyone. Thank you very much for organizing this event. And thank you very much for inviting me to deliver a keynote at the beginning of the event. I will want to give you a bit of a perspective from the policymaker, from a policymaker who has been interested in free and open source software and open technologies for, I would say, more than two decades now. And let me start with saying that free and open source software enables innovation and transparency. It strengthens cooperation and fosters a culture of exchange. And this can and should be used to the advantage of the automotive industry. I recognize that the infotainment in my car has an ample of bugs. I want to improve the behavior of the adaptive cruise control in my car, which also is a technology where users face bugs because every software contains bugs. I remember that one of my late colleagues said once that his car sometimes slams on brakes on a highway while driving on the adaptive cruise control, which apparently is a really dangerous bug. And if the software in the car is not open source, then users hardly can do anything about that. But enough of anecdotes. If you think about smart mobility, you could hardly come to a different conclusion than that software has become a crucial element of innovation, driving competitiveness on the market. And in order for this to work, we need a legislative framework that supports collaboration, transparency, and exchange of information. Unfortunately, the European Commission failed to realize the importance of open technologies in its various strategies. The EU's industrial strategy recognizes that digital technologies are changing the phase of industry and the way we do business. Then with its strategy on shaping Europe's digital future, the Commission set out its vision for how Europe can retain its technological and digital sovereignty and become a global leader. And this vision incorporates ambitious principles with which all of us can agree, I think. And let me quote from that. The Commission wants a European society powered by digital solutions that are strongly rooted in our common values and that enrich the lives of all of us. People must have the opportunity to develop personally, to choose freely and safely, to engage in society regardless of their age, gender, or professional background. Businesses need a framework that allows them to start up, scale up, pull and use data to innovate and compete or cooperate on fair terms. End of quote. Now, however, when it comes to concrete initiatives to make this happen, the strategy doesn't mention any action about free and open source technologies. Then the IPR action plan, deriving from the industrial strategy, goes the same direction. It talks about smart IP policies that can help companies to grow. However, it completely fails to recognize the difference in industries. It aims to encourage and assist companies with so-called intellectual property registration to improve competitiveness and resilience, but introduces no answer to the existing problem of excessive patent litigations and the issue of patent trolls, which is a huge problem for many innovators. These commission strategies came at a time when there are ample of lessons from the COVID-19 pandemic. Shortly after the global pandemic hit the world, researchers turned to free and open source research tools and open data platforms. The combined efforts of scientific researchers and free software developers have accelerated research on coronavirus to unprecedented speed. Medical professionals were working together to share information on how to repair vital equipment while others built open hardware alternatives. The pirates have been calling for policies supporting open collaborative innovation for years and at this point probably I should explain why I'm talking about the pirates. I'm a member of the Czech Pirate Party. If that message didn't come through in the introduction. And if Europe wants to be a technology leader, we need to support SMEs and the development of new technologies. We absolutely need to reform the patent system and supporting initiatives on open technologies, both hardware and software are totally necessary. And last but not least, the public money, public code principle needs to be adhered to. Public money has to result in public code. And today I am happy to announce that the European Parliament decided to step up efforts regarding open innovation. In reply to the SME strategy, members of the European Parliament in the internal market committee stressed the importance of open data and knowledge sharing via open technologies. In the shaping Europe's digital strategy, the same committee pointed out that economic actors can benefit from free and open source software and this could even contribute to achieving European strategic autonomy in digital. And we went even further. The regulation on the biggest fund under the recovery plan, which will distribute about 670 billion for the green and digital transitions explicitly mentions that investment in digital technologies should promote the use of open source solutions. So let me conclude that there is a political momentum to make change happen in Europe. And with that, I would like to thank you again for the invitation and I pass the floor back so that you can enjoy the rest of the event. Thank you very much. I think we're really touching on quite a few of those points and I fully agree that there really is a momentum right now regarding open innovation, open technologies and digitization of the European society really. Yeah, and I think we'll really touch also in addition to that on quite a few points that you mentioned there. So I'll be joined in a few seconds by our panel. I think so that means that Katharina and Michael will become on and so that we can kick off the conversation. I'll just wait one second. I can see our first panelist is here. Michael is here. Deb is here and I assume that Katharina will also show up in a second. I actually did want to start with Katharina. But you know what, we can turn it around. How about I start with Deb? It would be great to get from you to just start things off. 90 second answer. Just kind of understanding a bit from the perspective of a software company because we will hear in a second more about the car perspective, the automotive perspective. What is open source bringing to the automotive sector in terms of sectors and yeah, what is open source bringing to the sector? Happy to. So open source is a collaborative software development model has transformed a number of industries in recent years. We've seen this, for example, in telecommunications where software is now literally redefining networks. These are companies that were not known as software companies before that have become so. These also involves companies who would otherwise be considered competitors that are working together for a mutual benefit. So I think this kind of transformation opportunity has arrived for the automotive industry as they consider digital transformation. Development models and open source can include transparency, open licensing, the kind of open culture collaboration that we've seen in other sectors. And these things are huge force multipliers with regard to open innovation, which is a key goal for the initiatives we're talking about. Open source provides a foundation for developing shared technologies, and then the participants can build upon that and improve to their own ends. I guess my final comment would be that open source and more currently open source hybrid cloud technology today and edge ecosystems provide a huge opportunity for automotive to innovate faster, more safely, and with greater regard for end customers. Great. Thank you very much. Now to kind of hone in on the automotive perspective specifically. Katharina, well, for me Mercedes-Benz stable cars and last I checked that that is hardware. So why did Mercedes create ambition, an organization dedicated to software development? And would you say that Mercedes now is a software company? Well, thanks for bringing up this question. Yes, you're right. So Mercedes builds hardware. So we build cars. And I think it's important to notice what's happened is already pointed out. Open source has transformed a lot of other industries, and it's about to transform also the automotive or the car industry. So, yes, Mercedes will always deliver hardware, but we are in the transformation to become a software company. And this is where ambition comes into the game. So ambition really is Daimler's in-house startup company, and it was set up with two main goals in mind. So the first one is of course to develop software in-house that was previously bought or purchased somewhere. And then there's another very important aspect made that's even more important, that's the cultural aspect. So we need a cultural shift within the company, a shift of the mindset, a shift of the way of working, a shift in the structure and the priorities and so on and so forth. So in a sense ambition is the in-house troublemaker to build from the bottom up, build the right mindset to become a software company. I'm trying to find the mute button. Great, thank you, Katharina. And now something that I called now before sort of the in-between between software and automotive going to Michael. I mean, Gell told us just now about Eclipse's move to Europe and also emphasized kind of Eclipse's commitment in automotive. But I was wondering since I know that you've been spending a lot of time in different companies in the automotive sector and automotive industry in different roles also, if you could kind of give us an intro to how an automotive company is impacted by the increasing use of open source, but also in some sense open innovation and collaboration. Yeah, you're sure. Thanks a lot, Stephen. Yeah, so I started to work on automotive software 20 years ago. It was not related to open source software. It was very much close software development. But what I would like to point out, if we talk about automotive industry, it's not the automotive industry, it's not the automotive company dealing with open source software. So I usually try to separate this in three different layers I would call. On the first layer, what I see is in-cast software plus connected back-end software, software which is experienceable by the end user, by the customer, the car manufacturer. If you just heard from the anecdote, something failed, the in-vehicle entertainment system doesn't work well. But we also talk about software which is end customer relevant. I think, let's say, software and breaking system, software and steering system, which is not directly visible to the end customer, but yeah, gives safety to the end customer. That seems work, that cars are more reliable, that the value of cars is much higher than it was in the past. The interesting stuff here is that this kind of feature, this kind of software is directly impacting, let's say, the top line, the revenue of an automotive company. So it's the features which can be experienced by the customer. So a customer buys a car because he sees perhaps a certain feature in the drive assistance area or a feature in the infotainment domain. And open source of this area is seen for ecosystem development. So we see that the automotive companies see huge pressure from new entrants, which comes from the platform software domain. I think I don't have to name them, you know who they are. Open source is still used for cost saving. I think that's a quite important aspect, even with open source. Open source is something which is nice, but there's a huge cost pressure in automotive. So having open source for cost saving is for sure a better aspect of open source. Open source for interoperability that mainly comes with standards. So it doesn't make sense. You cannot compete on standards. So why not putting things together on interoperability standards? And finally, although software for mastering of complexity, right, so things getting more and more complex, where we see 90 different issues in the past, things are now combined in one big high performance computer in the car. So complexity is rising and inventing everything from scratch over and over doesn't make sense. So having an open source approach, we share this kind of cost is different. Participant of the ecosystem makes sense. The second area I'm referring to is let's say OT or shock floor in comparison to IT, right? That means all the things. We saw a couple of announcements by the OM in the past, cooperating with hyperscalers on their production sites, for example, bringing their legacy production sites into the cloud, using data for predictive maintenance for AI use cases, improving the process efficiencies, stuff like this. And all these kind of things are more, let's say, impacting the bottom line, the cost structure of automotive companies, right? And here the competition is not so much the new companies from the platform software industry, but these are more competition among the automotive companies. The third area I see usually is the, let's say, general IT area. Although there's a lot of stuff which can be done on open source, starting from web servers for the marketing and sales teams, but this is more like it's not automotive specific. That's a kind of software or a kind of area which impacts all companies of a similar size and how they could leverage the benefits of open source, but I would not focus here on that's not automotive specific. There again with the microphone button. Perfect. I think we'll touch on a lot of those aspects. And I think maybe kind of moving from this, I was wondering if Katarina, you could maybe talk a little bit about kind of the specific business needs, you know, now that we have this kind of intro on the different layers on the specific business needs that has really driven this shift to open collaboration in the automotive industry, skills, innovation, IP and these kind of aspects. Yeah, of course, I think you already touched upon most of them, right? So the first most important aspect is a time to market, right? So don't reinvent the wheel, use whatever has already been proven to be right in your product to the extent that's possible. The second one is to attract talent. I think if you're serious about becoming a software company and you really need the talent for development, then there's no way around open source, right? So that's kind of required almost everyone wants to work in an open source company wants to be able to contribute to be part of the community as part of their, you know, job. And so that's a that's a no if you don't offer that opportunity. And then I think on top of that, there's probably also the big picture perspective that open source enables you as the company to be part of the, you know, new perspective, to bring new perspective into your own, you know, a smallish, you know, way of looking at things if I may put like this. So when you work on time pressure and you know, the automotive industry, you work with deadlines, the car lines and so on and so forth, you tend to be tied into the operational duties. And by working in open source, you force yourself, you force your team to expose yourself to new ideas to innovation that's happening around your product that you may otherwise always see you. So I think there are many different aspects that really puts a business need on companies in the automotive sector to really get into open source. Yeah. Very interesting. I just wondering now a little bit if we go to depth, because I know that you lead the open source program office at Red Hat. And of course, at the end of the day, an open source program office is a lot on the one hand, maybe about the IP, but I would imagine that Red Hat a lot about organizing collaboration about collaborating with other companies. I'm just wondering if you have any thoughts on how this maybe would be applied in the automotive sector. And I'm also wondering maybe this is the follow up question to Katarina, does Mercedes and Ambition, do you have an open source program office? Do you want to go first? Or was that directly to me? Yes. Well, sure. I thought you were following up with you first. You go first. So do you have an open source program office? General Mercedes will answer that question. No worries. So we are in the process of setting that up, right? So we are in the process of Mercedes Benz or the Daimler families and the process of setting that up. So you can see it as of course, we are already using open source components. So there's the whole question about compliance, how to deal with that responsibilities, and so on and so forth, and trying to move to becoming really a player in the open source community. So along that way, we are somewhere in the middle. And that also includes of setting up an open source program office, whether we call it an open source program office, whether it's tailored exactly around the common understanding of what we may define as an open source program office. That's, I think, still in discussion. So there are many ways of tackling the responsibilities and setting up the right processes. And each of these processes, I think, are uniquely or need to be uniquely tailored to the already existing development processes. So it doesn't really make sense to set up something in theory that you have learned in some of these forums and discussions and conferences, if it doesn't really match with your already existing development cycle and the processes that Mercedes has already set up. So yes, we are going there, whether it's an open source program office or not, that's debated. So thank you for that. So I would agree that the form of something should always follow its function. You'll find that open source program offices that are formally created often vary in their functionality and scope. We know that Red Hat Ars is considerably different because engineering happens elsewhere. So to address your question about what our experience would be to offer or where we might encourage collaboration or CEC collaboration in the automotive industry, we've certainly had a lot of experience in gathering community. It is a huge undertaking, but the results are so beneficial. It's worth the time in figuring how to get there. I think with automotive, the best way to inspire that community, and like Michael, I probably refer to as the ecosystem rather the industry, is to address the concerns of the stakeholders directly. In our case, we would focus on delivering Linux into traditional embedded use cases. Those requirements are evolving, so you need to have an active conversation with companies that will be interested in participating and engaging. It means you have to have a consistent platform, a way to develop and deploy together all in the context of security and functional safety in particular, because it's one of the unique features for the automotive industry. It isn't so much about building a single code platform as creating an environment where we may have multiple platforms that coexist and collaborate, but most important is to understand what the goals are and have people who participate, companies who participate, come transparently to the table with their own motivations. That's how you start to create a successful project. Michael, here maybe it's a good opportunity for you to come in, since what a foundation does is to facilitate collaboration between companies as OFE and Fraunhofer we're conducting the study for the European Commission. One of the things on open source, you can make impact for open source. Of course, we look at the automotive sector and one of the things that we look in there is the factor of differentiating products that collaboration is happening on non-differentiating products. I'm wondering a little bit if you could talk about why this sharing of development in the automotive sector has become more important and where do you see the potential for common goals? In the automotive sector and the development of the software area? Maybe before I answer that later part of the question I would like to focus a little bit on things coming into my mind is if we talk about open source, it's not clear to everyone open source means that different flavors, let me call that one of open source, right? And I think it's some of the standards expectation to open source that there's a certain kind of openness and transparency, but just uploading something to one of the coding platforms is also open and transparent, but usually it's not enough to force the collaboration and partnership between different partners. What we see in the automotive industry that there's a certain expectation when it comes to governance structures starting from antitrust, but also have a clear understanding how I can work together. What are the rules? What is the level playing field? And that's something which usually a foundation can provide quite well. On top of this is all what is quite important is vendor neutrality. That means we're talking about products which are on the market for 10 to 15 years. And if there is a control of an open source component by a single vendor that single vendor decides not to go ahead and be similar, it's a problem, right? It's not a smartphone. You change perhaps every two or perhaps every four to five years. We talk about products which are in the market 15 years or even more. So that's something you have to consider. And I think what is interesting, I think you mentioned that open source does not mean that everything is leveled. There are no differences. I think people think if you do open source you cannot differentiate any longer. And I think that's not true. I think there's areas where you can cooperate on, I call it the underworld, but we talked about mentioned before, interoperability. But there should be, and that's at least from a tips foundation, always a point which we think is very important, there is place for differentiation. So you need to differentiate because you don't want to have the product look like each other, right? So product from company A should be different from product from company B. You need to define your areas where you can cooperate. Let's say a vehicle to X communication. Let's talk about other areas in the drive assistant domain. If you talk about global optimized route planning, so that not everyone is taking the same stuff like this, real-time traffic information, all these kinds of things that's something where you may not really can differentiate, you can cooperate. At the same time, if you talk about the level of autonomy, what kind of levels for autonomous driving, you would like to offer level two, level three, perhaps later years, later four, later five, that's something where you also can differentiate, right? And the idea is to, from a presentation perspective, especially in automotive, where a lot of things comes initially from the compliance perspective, right? So when I started to be engaged with open source in automotive, the first question was, there's a list, a wide-listed software which can be used. And all discussion was about compliance. You are not allowed to use open software initially. And now it's opening up, people see the value, the positive aspects of open source, but still you need for this kind of big cooperates with high liabilities, you need a framework, how these organizations can cooperate. And foundations can provide these kind of frameworks. And now with the move to Europe, I think the Eclipse Foundation can provide this even with a pure European setup. Yeah, you mentioned now antitrust, you mentioned governance and vehicle-to-vehicle communication or vehicle-to-infrastructure communication. And then I see there was a question on standards, on open standards in automotive, and I think all of these topics are very much connected. So I wonder maybe we should go a little bit into the standardization question, because I know this is a very important topic within the automotive sector standardization. I'm just wondering if anybody wants to jump in on the role of standards, also maybe the role of open standards, and how this interaction with standardization and open source is evolving, since standardization I think traditionally is a very important factor in automotive, and now open source is complementing it. Anybody want to jump in on this question? So I'm not the standards expert in my organization, but I will tell you for many years of history and other sectors as well, that I cannot overemphasize the importance of open standards. There is no open source software for that open standards, and interoperability is key. There will always be legacy systems and other software. So open standards creates an opportunity. Open source is going to be a critical element of the work ahead in the industry. I've observed this in the public sector, where we adopted open standards to make sure that things were interoperable many years ago, and some of our biggest public failings were when we did not. And when we had a proprietary standard, fail-less, like the 9-11 tower horrible event where radios couldn't talk to each other, because we had standards, we just had multiple standards. So I cannot emphasize the importance of open standards and any policy work with technology development. And I'm sure Michael can speak to this as well, because Eclipse is deeply involved in standards making. What I see interesting, I think what you see, if you look at the software development process of the automotive industry, you see more and more an agile approach to developing software. And agile developing does not necessarily fit, let's say, to standardization. So what I have the feeling right now is that there's more and more code first or code and specification and prevalence. In the past, we had the classical V-Model, right? So let's say specification for head units or navigation system, which has 19,000 requirements, different requirements. So there was a team of people working for two or three years just on the requirements document, and then there was an implementation phase. That specification is, like, it's not a standard, but it has a similar approach as a standardization, right? And then there was the implementation, furthermore, stress and integration phase, just according to the classical demo. What we see right now, more and more companies talk about customer stories, they have HR developments, two-week sprints, four-week sprints, and that does not necessarily fit into the world of standardization. So what I see right now is that more and more companies, perhaps not necessarily an open source, but they start really having that agile approach to feature development. And this is perhaps not 100% compatible with the old way, or the traditional way, not all the traditional way of doing standards. And I think it would be interesting to see how this will develop in the future, because if you all look into software companies, they just, time to market was one of the things Katarina mentioned, right? Time to market and standards is something which may not fit all the time well together. Yeah, yeah. And I think, I mean, it's clear that we're seeing these questions pop up, not only in the automotive sector, it's very clear, the question around time to market for standardization and how that, how that measures with open source, I think it's becoming really important in a lot of different sectors. I'm thinking we're kind of maybe in a very specific topic, and I think maybe we could hone in on some of the really practical kind of technical examples where projects are making a difference in terms of reusing of components in terms of kind of the broader open innovation potential. I'm wondering, Katarina, if there's any examples that you have from your work at Ambition, from your work at Mercedes, here where you can talk about how open source is really changing the way an automotive company is approaching a project, a product, compared to maybe five, 10 years ago. Yeah, maybe also one follow up comment on the discussion on standard, because I think it's the general theme that we can see in the automotive industry, which is they are clearly lacking behind. Let's face it. So in the whole context of becoming open source companies become software companies, and then becoming open source software companies, they are not very much advanced. So most of them, all of them, I would say, use open source components, and probably all of them have figured out how to use them in a compliant way more or less. But I think very few companies have really made a step towards what we would call open innovation, innovate together with competitors in open platforms. And I think the same is true for standards. I think the standards still need to be built in that sector. So even whether it's open standards or just generally speaking technical standards, I think the automotive sector is still in the beginning of building that and setting that up. So with regards to open source projects that really make an impact, I think they still need to be developed. So we are really at an early stage. It's not that you can say like in the embedded world, we see everything as Linux-based. And of course, there's Linux and automotive products. But I think the real benefit of open innovation of using open source in the sense of being an open source player, being able to maintain, contribute, facilitate a community, that step still needs to be done. So I really see, we would need to give the automotive sector a little more time and maybe help them push them a little bit into the right direction, because this whole idea is completely new. So they were set up to, we do it in-house, we do it differently, and we do it better. And for a long time, that was successful. But now, you know, there really needs to be a shift in the mindset, as I said earlier. Yeah. Do you, or this question, I think, could go to everybody really. Do you see any areas where there's a specific need really to go down this route? I'm thinking maybe automotive, autonomous driving, thinking about, can one company do this on their own? Is that maybe too much to ask in terms of capacity, the production, something that I assume to some degree is a similar process across different companies? Any thoughts maybe on where really the need or maybe the benefit would be the highest? I mean, I can start and others may have different perspectives. I see the need on all different levels, whether we talk about autonomous driving, ADOS. I mean, for sure, it would be beneficial for the, you know, advancing the technology if the companies would be working together and use standardized, you know, platforms which share innovation and then build on top, what would then be the differentiating part. But the same is true for, you know, infotainment and stuff, right? So you, when you go into navigation, you will see that many companies are using open data already. But this is really just a very small point tip of the iceberg, right? So there's so much potential on all different levels. And I think I'm kind of repeating myself. But my feeling is that, you know, the cultural shift, the way of seeing things differently still has to happen is not there yet completely. So in each of the automotive companies, you will find people who have that mindset already and who really want to change things. But you will also see a lot of, you know, management people who, as you said earlier, who have grown all the way in the hardware cycle and who have, you know, successfully delivered great cars over the past 40 years. And it's very hard to explain that, you know, innovation in terms of software can work differently in certain areas. So it's a lot of explanation, education, I would even say, right? Especially let's put, frankly, middle management. Okay. Yeah, Michel, I would say another question. I congratulate this to the comment just popping up in the chat window. I think we treat the automotive software guys a little bit unfair, right? Because I think the quality expectation for automotive software is different. So especially we talk about, let's say the traditional software parts like braking, steering system, power shift, powertrain software, that comes quite often with financial safety requirement, ASLB and ASLD. And an ASLD software is a complete different story than an app for mobile operating system, right? Functional safety is a topic. And I think here also, I think there have been still concerns in preparation of the panel today. I read an article, I think it was on the Economist for two years ago, which stated open source and ISO 26262 is not compatible. There will be no open source projects which will achieve an ASLD certification, for example, according to the safety element out of contact, which is not true because, and that's why I think by our race set point, we just did, not we, but it's the company we just did it for now from the software stack, which is based on open source, namely on the RS2, which just received that safety element out of contact certification, ASLD level for an open source, for a software component which all the consist of includes open source components. And I think that's a major step because having this functional safety requirement is hard work for automotive software developers, but having now the proof point that this is all the possible in open source, I think that's all the big step for open source, for the acceptance of open source in the domain of automotive software. And I would follow and echo that. I think the cultural changes that Katrina has pointed out are really essential because we're, with the opportunity and the challenge is going to be is to change the way we're thinking about how we design cars, right? So rather than developing these components in isolation, which historically didn't talk to each other, we're now ultimately going to treat the car like an edge device and put it on the internet. So the long vision is smart cities and interconnectedness. And so you have the seamless experience. The challenge is going to be to take advantage of the open source model, not just functionally from the development point of view to really change the way we're thinking about how we do design together, where the standards come in and how we can shift that thinking. I think it's an incredible opportunity. And I see some comments in the chat that reflect that some of our audience actually understand that, that yes, we think about having a higher standard. I believe last year when I was at the European Commission's 2020 road map session, someone there, their public testimony was that open source would never meet safety standards on those requirements. I think we're starting to shift our thinking. And I see some of our audience understand that, but I'm excited about the notion that we can change together to change the way we're thinking about designing cars. I don't think it's impossible that maybe even Jonas, who I see has made a comment now, has said that because I think it was 2019, what a beautiful world that was, looking at 2020 ahead event, the Commission had. I'm just wondering, I have to say also culture is one of the things that in the study that we're conducting also very much has stuck out as extremely important level. I'm just wondering a depth to maybe bring it back to you as probably the biggest open source company in the world. Do you have any tips for convincing your management of open innovation of open source? Because I assume you have to do this work sometimes with companies that you work with, that you collaborate with. Absolutely. Actually, I think that's probably the most advice I've ever been asked over the last 15 years or so in any sector I've worked in is how do I convince my manager? And there are different tips. One is that we have found that leadership is most comfortable gaining confidence from their peers. So it's really helpful to find other companies who have already done similar work before and get those people talking to each other. It's also helpful to find out where some of the pitfalls are. And so with all respect to my colleague who is an attorney, often attorneys and companies are the first barrier to participating in open source communities. And we have secret weapons of red hat. Their names are Richard Fontana and Scott Peterson. And we're grateful that they will go out and talk to attorneys directly about some of their concerns because those things are manageable. But the advice is, you know, find people in other companies that are doing similar work. So you have use cases. You know, ask people for help. Red Hat has a library of use cases that may be from an industry that can be helpful. And look for organizations, larger organizations like the Clips Foundation, that have that kind of experience where they can introduce you to others that have tried to hoe that role before. Perfect. Maybe let's stay on the theme of challenges. And this one I think goes to maybe Michael, but as always, everybody who wants to jump in. I'm just wondering maybe then about the challenges. And I know you've worked on the kind of the supplier level before. So I think you're probably very well placed to answer this. What are kind of the challenges from the OEM perspective, from the supply perspective for enabling a cooperating system? And maybe Katarina, there's something for you to jump in, because I know that in the past, lots of software or firmware was provided by suppliers of the different tiers. But this might get more centralized today. So I'm wondering maybe if you also have a reflection on this development. Two questions. If you don't mind, I would start. So I see two different areas. One is what I would say the internal challenges. And the other one is the external challenges. So from the internal challenges, if you look in a modern car, which hit the road at three to five years before, I think it had been 80 to 90 small little computers inside, right? And each computer acted more or less in people. For sure they were community hitting each other. But it was mainly the task of the automotive company was system integration. The computer and the software and the computers, based on technologies like OSEC or Autos, there was development that you wanted to supply. So the one supplier that had the software integration capability and the OEM had the system integration capability. What we see right now driven by staff like, like, like, with your media systems, navigation system, but all the driver system systems was a tendency to replace 90 small ease used by three or four big high performance computers. And suddenly the system integration capabilities of the OEMs is not any longer or it's not as long required as much as previously. So some of the OEM has to have software integration capabilities. Because what happens here is if something goes wrong, the first question is always who is responsible? Five years, 10 years ago, that was easy. Just look into the direction of the Q1 supplier. Today it's difficult because if the software, if we have 10, 15, 20 functions and one ECU and one high performance computing ECU, it's not clear who is responsible if something goes wrong, if timing is incorrect, if something crashes and similar. So that means, and that was, although as you can see from the development of the software capabilities within the car manufacturers, they changed from being, let's say, doing specifications and being project leads into being software developers. I think Ambition is the best example for that one, right? 10 years ago, there was nothing like an Ambition. I would claim that it was hardly anyone was in diamond organization was able to write software and this completely changed because these capabilities are needed. And that's coming back to the challenges for the car operating system being able to that kind of software integration, integrate different functions in one high performance computer in the car. I think that's exactly the challenge which has to be solved by the OEMs. On top of that, we see things like, again, functional safety requirements, ISO 26262, we have the long-term support and I think the key enabler for doing this is what I would call over the air updates. I think if you look, I don't really want to mention Tesla, but honestly, I think the innovation of Tesla is not the electric car, it's not the electric drive. Innovation by Tesla is over the air updateability. They don't have to care if a software is error free because they can replace it over the night. And that's something that's a capability which German or European OEMs all of them are able to roll out, but they missed it and they have a five years gap, let's say, to other competitors over the air updates. As soon as this is available, I think it's much easier to develop software and all the especially car OS software. Coming to the external requirements, it's difficult. It's a tough market. You have Android Auto on the other side. You have companies like QNX which have a track record on operating systems, platforms. And the question here is it's not only that they're a technical advantage, but if we talk about car OS, if we talk ecosystem, if we talk platform, they all usually have platforms of a certain size in place. If you look at Volkswagen, I see 10 million cars a year. That's a five million cars equipped with a head unit which can provide connectivity services. It's five million, right? If you look into services like Facebook or similar, they talk about billions of people into the ecosystem. The question here, if you build an environment incorporating system just by yourself, how can you scale in a way that you are also attractive for software suppliers, app service providers or similar? And that's something which I would call the external challenge. You have to compete with well-attached companies which only have the software capabilities, but all the sometimes already platform of a certain size in place. Yeah, many, many topics that I could potentially address. Maybe a starter over the first one. You mentioned Tesla. Of course, Tesla is five years ahead of all of the European car makers. That's absolutely right. It's not only in terms of electricity. It's also connectivity. So what they are doing with the Starlink now, there's a real gap. On the other hand, they don't have the legacy. And numbers prove that connectivity and electricity is not the only thing that the customer cares for. So it's a very complex topic. I think the discussion about Tesla, as much as I would love to continue on this. I wanted to make one final comment on the functional safety and security requirements. Because I think this is quite often, it's being put as an obstacle. And I see Jonas already posted in the chat. Hi Jonas. I think he can probably speak much better on this than I can do. But I've seen this in different industries that there's always this argument of, we can't do this because we have special requirements. Talk to the banking industry. Talk to the credit card payment systems. Talk to the healthcare sector. They all have to deal with very special requirements, ISO standards. Now in the automotive sector, we have this new land regulation on security, which is not even talking about functional safety. It's just security, how you make sure that everything's protected from outside attacks and so on. So there are always arguments. But as Jonas has already put, we can deal with that. So there are projects. I mean, maybe the Lisa project should be mentioned here, which deals with Linux and the context of functional safety. There are probably new projects coming to the Eclipse Europe, because this is a great host for these kind of topics that many players can openly discuss and find a solution. So I wouldn't really let that count as an argument. We need to deal with that. And we need to find a way to make open source software being compliant somehow, if I may use this term with these requirements. All right. Maybe I just realized, maybe you can just say what the distinction between a tier one and tier two suppliers is. Yeah, if you work for 20 years. So when I call OEM, and that's interestingly the opposite meaning from other industry, the OEM is a car manufacturer, right? Like a Daimler, that's an OEM, right? Then the tier ones, I use the companies like Conti, Boris, Denso provides a complete system for the car. And then you have a tier two or tier three supplier which provides part of the system. Could be hardware parts, but could be all the software parts, right? Let's say just my previous company called Electrobit delivered navigation software to another company that company integrated the navigation software into the head unit and then delivered the final head unit to a company like BW for example. So it's a tiered approach in the past. And that's all interesting. If we talk about it, it's a strong hierarchy. So automotive, complete automotive industry is driven by strong hierarchies, right? So the business foundation, if you look at how many end customers from an industry perspective you have, so how many car manufacturers are still there out there? 15, perhaps 20. So everything at the end of the day, all the projects, all the work ends up in 15 or 20 companies. Now with open source, suddenly this hierarchical tiered industry and the way how the things work together, suddenly is a tier three is perhaps at the same level as the OEM. And this is something which all that has to be learned by the OEMs. OEMs are used to control. And open source environment, usually at least a consolidation meritocracy. So everyone has the same voting rates from OEM perspective, perhaps worst case scenario, right? And having this kind of level playing field for all participants of the system is something that the complete industry is not used to. I'm not saying that they cannot get used to it, but at the moment all the structures, let's say from the purchasing department and similar, is still focused on this pyramid of the hierarchy. It is almost something philosophical in a sense because you were speaking before about integration between the suppliers and the OEM integrates all of these disparate pieces. And then open source, of course, a big part is integrating lots of different open source components. And here I'm wondering a little bit, and this is the lawyer's perspective, we talked about functional safety now, but I'm wondering this goes to Katarina, because I know that you are a lawyer. When integrating open source component, what is the liability situation when Mercedes has their first automated car and the negative scenario, let's say, happens and it crashes? Who then is liable, the original supplier of the open source software or maybe even some community person, some poor community person who's supporting a piece in there in the web of software that's being used? So I'm just wondering if you could expand a bit on that. Yeah, I think it goes also back to what I just said. I think in the past, or maybe that's still the current framework in the automotive industry, being used to this hierarchy of different tier suppliers, the automotive industry really likes to push the liability by contract to the tier one, tier two, whatever. In the contract, you clearly have that section that who's responsible, who's liable for what and that whole setting is currently changing and frankly speaking, that is the real challenge. Especially, I mean, I don't want to go too much into the details here, but when we look at open source components and the common open source licenses that we all know by the open source definition, most of them have a disclaimer in there. You get rid of all the liability that unfortunately, in the German context, is not valid. And I'm pretty sure in most other jurisdictions, we have a similar legal system, so you can't really get rid of the full liability. You will always be liable for what we would call gross negligence. So you cannot say I'm completely out of the game, I waive everything. And this makes it tricky. And I see certain concerns, especially when it comes to allowing people in the company to contribute to open source projects. There's always the question, so if you work upstream and someone else implements that system, that project, whatever, in the car, and then the car crashes as you have just said, who is responsible? Will we as a contributing company be eventually be responsible or liable for that? And on top of that, we also have the product liability law in the European context, which is translated into the German context, or the Produkthaftosgesetz, which is a nasty being that explicitly says that the supplier is liable. And eventually, if you break down, then that would go to the original software developer. But this is all, I think, in the process. And I would be a little bit provocative here, because this is also a policy event. I think we need clarity. I think we need a clear framework on who is liable for what in the end. And that should be, that kind of framework should be done with all the players around the table. So it should not be done by people who have legal expertise, but don't know how automotive works. And I think the automotive industry has to be invited and has to be around the table to see what's feasible. But there's definitely a need for policy makers to help provide clarity on how this can be handled. Yeah, thank you. I'm thinking about, because you now speak about kind of the collaboration between the suppliers and industry. And I'm wondering maybe, Deb, if you could talk a little bit about what is necessary to achieve a good community, a sustainable community in some sense, maybe around a project. One would assume that this often includes the OEM, let's say, in the automotive sector, the OEM and then the different suppliers. What is necessary to put in place to have a good community, a good collaboration to achieve kind of the common goals? Well, so what I answered in two parts, one is that the work we're relatively new in creating these kind of communities inside the automotive ecosystem. And Michael highlighted, and so Katrina highlighted some of the challenges in terms of the way OEMs have thought about how they relate to the software or car or how they're in the supply chain. So that's going to be a very interesting conversation in the ecosystem, but will ultimately be centered around projects that are launched and how those organizations and commercial concerns enter the ecosystem. What makes it successful or what makes it successful? One is really starting with a very clear understanding of the problems you hope to solve together. This goes for most things in business. If you don't have a really clear definition that everyone looks at and understands what you're trying to solve to, you're not off to a very good start. So a very important feature of a community is agreement on the problems they want to solve together. And also an acknowledgement, because that community is going to include both technical and business people and understanding where you probably most likely differentiate on the product side, on your secret sauce, on your special sparkle you're putting in a project. So I'd say it starts with clear understanding. It also should include really broad calls for all stakeholders. You'll have large companies, you'll have SMEs that will participate in this kind of ecosystem. So people feeling that they have an opportunity to be included in the front end is really important. They're more likely to be engaging or decide not to engage but not throw stones at your idea a long way if they've been insulted early on. And there's a couple of ideas for early strong starts. In terms of the sustainability of the community, a well-defined governance model that's a right fit for the project is important. Not all projects need to be in a foundation. Some really do. The more complex, the more industry participation, sometimes you need to have that very formal project structure. And then just along the way, all the best practices that you see in open source go for healthy and sustained communities, good communication, transparency and all the other technical best practices going on. Okay, thank you. I want to go because you mentioned now SMEs and I think this is something that's really on the top of mind for European policymakers. If we look at the numbers, don't quote me on this, I think it was 80 to 90 percent of European companies are SMEs. So this is extremely important and I'm wondering Michael, I would assume, please correct me if this is wrong, that from the supply perspective SMEs, German Mittelstand now maybe we talk about that is relatively important in the automotive sector. I guess maybe Katarina is also interesting for you. So I'm wondering kind of what is being done to include SMEs at Eclipse, maybe specifically. And what are the challenges because what we often hear, this is from the standardization world actually, is that it's difficult to include SMEs in standardization activities because they don't have the time for it. But I'm wondering, is that similar to an open source or different? Honestly, I think that's different. My feeling is that projects open transparent so each one in a vendor neutral way can contribute. There is no difference. So a Daimler don't have more power in one of our projects than a small and mid-price enterprise organization has in the project. And I think that the things which are developed there are directly tangible. It's not like a standard, which is just one step to the final product, but the software is already a big step into the final product. What I see more is a challenge is, you know, we get all these regulations starting from GDPR. I would say that this is bad, but we have the regulations GDPR. Now there's this new AI regulations, which has been published last week, something like that. And for large organizations, it's much easier to deal in a compliant way than for small organizations. And I think that's a big issue. But Daimler has an organization, perhaps for 30 people, dealing with this AI regulations, make sure that the company behaves in a compliant way. That's not a real cost factor, right? But if you have a small and mid-price enterprise with 500 people, you would have to have the same size of a team, it would be not, you cannot finance this kind of things, right? So I think what is different, what is all the dangerous for small and mid-price enterprises, when we talk about policies, that smaller mid-price enterprises need to be able to afford to be policy compliant. And I think the bigger the organization, the easier it is. Because if you look at the overall cost structure, the part for the share for the compliance work is less and less on this. The bigger the organization will be, or is. But for small companies, being compliant with these kind of regulations can be a real challenge. Yeah. Maybe something that I also have a very strong personal interest in. It reminded me a bit when there was a text around NVIDIA here. So this goes to chips and hardware. We are seeing, I think, the news has been around that automotive companies, car companies, not producing sort of right now at the speed that they could, because there's a shortage in chips. Now it's clear from that that there is maybe not so much control and relatively much dependence on companies around the world, mostly in Taiwan and I think in Asia specifically, that produce those chips that are needed to produce cars. This question was supposed to go to Katharina, so I do hope she returns in a second. There she is. Fantastic. Yeah, we're gone for one second. Open source software, that provides control for companies over the software that they use, because everybody can use it and so nobody can take it away from you in some sense. So I'm wondering in terms of chips and hardware, if there are any considerations on the level of Mercedes to do something in the space, I'm also thinking when we think about electrical mobility, we see that lots of companies are now investing in capacity for batteries. Apparently, Taboo Tesla word comes to mind. I know it's building a big factory in Berlin, but I know that also some European car companies, I think, are organized in Norfolk. One of the suites in the chat will surely let me know if that's not correct. So there's investments happening in hardware in this kind of strategically important area. Any considerations regarding chips specifically, with there being much more kind of development now in the open hardware front? Yeah, I can kick off the discussion. I see that risk five should be mentioned here and I'm very much interested. I mean, it still needs to prove if it really kicks off. So if it really will be successful in the end, but I think this is one approach towards some level of openness on the hardware front, if I may say so. Whether or not the automotive industry and considering Daimler is one of the even more traditional ones, I would say in that industry will jump on that. That's not my turn to comment on or to say I wish they would do because I feel this is something that everyone should engage in. Otherwise, it will not be successful. But my current observation is that there's enough work to do still on the software front. Then back to the second question, which I think is a little bit separate from that too. To what extent we need more investment on the European ground? Absolutely. Whether it makes sense to support international companies to build something in Europe, I would question that. So I would rather see something coming from within Europe and innovation happening really among the European players. Let's face reality, we all know that it's difficult to compete against the big US and of course also the Chinese players. And to me, as always, one way to leverage that is to find ways to collaborate instead of building something equivalent and then trying to compete from scratch, which might be difficult. I think we need to find a way to collaborate with the big guys. Yeah. I think, well, in some sense, I guess the takeaways from open source software also apply to hardware in that sense, the need for collaboration. And I guess then the commission proposal to invest what can be maybe colloquially called a lot of money into a European chip facilities. I think I saw something, 145 billion euros. Yeah, clearly sounds like you in support of that. I'm thinking maybe, and you could kick off discussion almost before if we talk a little bit about the policy context. And I'm wondering, Michael, if you have any thoughts, because now we're seeing what Katarina has now a few times said is something that is now slowly being created in the automotive sector, open source software collaboration. It's now happening slowly in the automotive sector. Is there something that you see or where Eclipse is involved in kind of speaking to governments, to policymakers, to make sure and educate, on this change that is happening and to make sure that this is being taken into account in policymaking? Yes. So, one good example is being part of that panel here today, right? I think it's not so much about automotive. We talk a lot about, let's say, open source in general, open source for GAFTAG, for public sector, open source, for example. But I think the arguments are not too much different. So, I think what we talked about openness, transparency and similar, these apply in a similar way all throughout the automotive. So, with this in regards, we talk about open source in general, that's not too much different from other things we are talking with. It's either we are the industry associations, we are members, so just to name it for Germany, we are the Eclipse relations member of the Bitcoin, of the ECO and so these kind of things. For automotive specifics, I'm not aware, but that may all the change in the future. So, I mentioned that we have this first financial safety related stuff here. We talked about, Katarina mentioned that there may be new and updated policies in the future. And based on the technical expertise we have, our members have, I think we are quite interesting to facilitate discussion with the policymakers. They would need technical or input or feedback from experienced people in that area. Yeah. Anybody else want to come in on this? Otherwise, I have a question maybe on the upcoming industrial strategy. This was supposed to, I mean, well, the EU industrial strategy that already came out last year in, I think, March 2020, but timing. And now that we have a year of COVID, they decided they need to update this. And I think it really happened also in the kind of under the impression of dependencies that have been identified through what we see with COVID. I think, you know, there's clear dependencies that we see now today. So, that is a thing that the new industrial strategy we hear will end is coming out tomorrow. Apparently, we'll focus on a lot. So, I'm wondering, is dependencies something that, I think this question goes out to everybody, is dependency something that the EU should focus on with industrial policy? Or are there other areas that you think make much more sense to focus on? No takers? No, I just, so, you know, there's, there's this, there was just, I think, the paper about the German IT rat on digital serenity. And I think there are three goals which are like, I think the one is having the ability to change. That means having more than one supplier for certain stuff, right? The second one is the ability from a policymaking perspective to shape and to create something. And the third one is more to influence what I would say is a traditional way by, by, by regulations, by political steering, but especially that point, shape and create. That means being active part of that ecosystem and not only regulating, not only being at the sideline and watching what's happening on the playing field, but being perhaps more active partner here. Sorry, we talked about this for the, for the hardware now, but in general, being more active partner in, in supporting stuff like open source, which all then enables this kind of, of getting rid of dependencies or controlling dependency, I think that's the quite interesting approach, not only coming via regulations, but all the playing an active part in overcoming dependencies. And I mean, maybe a reflection, reflection from my side with open source, I think I've mentioned this, I think it's being seen as, as a way to overcome dependencies, but of course, at the same time, it is not a protectionist way of, of attacking, let's say that problem, because of course, at the end of the day with open source, it's still available to everybody. So I think that's, well, that's maybe quite interesting. I'm wondering before, before we go, before we go kind of into the final rounds, I'm wondering, and this goes, goes to Katharina now regarding the more the kind of the practicalities, I guess, of building software or building software for a car has, has Mercedes to does Mercedes has its own operating system like Tesla? Or is it something where there's a lot of integration happening? So this is something that you are centralizing more? Yeah. I think I'm not in the position to talk, you know, in detail about what the operating system will look like and what it will be. I think it brings us back to the point where we were, what we talked about in the beginning, right? So Mercedes or you can call the whole Daimler family is in the transition of, you know, doing more stuff in house. And while we are transitioning from, you know, hardware and purchasing the software to be built into the car, what Michael has, you know, outlined earlier as a fully, fully prepared system, of course, the goal is to ultimately control what I would call crown jewel, right? So there is a certain desire of having something that is proprietary and that is then the unique user experience that differentiates the Mercedes car from the Tesla, from BMW, from the Volkswagen, whatever. And I think that is a natural, you know, evolving process. And in the middle of that process, of course, there's the question about the operating system to what extent that will be fully in house to what extent there might be open source layers involved. I think this is all in the making, in the baking. And, you know, that's probably the most interesting part for all the automotive players, right? So it's not only Mercedes, you could go and ask the same question to BMW, you will probably get a very similar answer. We are in the process of designing that and finding out what makes the BMW different from the Mercedes, right? And I think this is only, this is only natural, because as much as we all want to collaborate in the end of the day, they are still competitors. And that's good, right? So there should be, the customer should have the choice in the car they want to buy and where they want to invest. Well, I've seen the announcement, I guess, for the new S class. No, it's not, it's not called the S class anymore. It's the EQS, I remember this, which I've seen is essentially one huge screen inside, or many screens, screens galore really. So I assume, at least to sound you agree, there has been some work on the Mercedes side, but I understand. You know what, maybe one final question on that. So to me, what is not really important is the question whether there's one big screen or two screens, or we can move them around and, you know, whatever. What really counts is in this way of transforming to become a software company, the most important cultural aspect that needs to be tackled is the customer centricity. So what counts is not if our designers like it this way better, or that way better, or I like it this way better. What really counts is, will we be able in the future to listen to our customers and implement that feedback quickly? Because that's all that counts, right? So, and you know, let's go back to Tesla because that's the elephant in the room, right? So someone tweets to Elon, I'd like to have that feature. Two days later, it's in, right? So now this is not possible to the screen design, but I think, you know, that kind of mindset, let the customers decide. And you know, the customer in China is completely different from the customer in Europe and from the customer in the US. And Mercedes and all the other car makers want eventually to deliver cars all over the world. So you need to be able to really quickly react to what your customer wants as a product. And you know, right now it might be fancy to have a big screen. Okay, fine. But frankly speaking, as long as the car is not fully autonomous driving, is that really helpful at all? I mean, it's interesting. And I will, this is my only contribution to the elephant in the room Tesla conversation, was on the phone with a colleague in Berlin on Friday. And we, I asked what he was doing in the weekend, he said, I'm spending the weekend deciding which car to have my company lease me. And he said, I'm down to two choices. He said, I love Tesla software, they have great software, they have a terrible car. I love Daniel's cars, they have wonderful cars, they have terrible software. And he was actually laboring over this decision. I mean, maybe it's just, you know, my generation, but I think, you know, I want a car that's a great car. Why would he care about software? Well, you know, to a country at this point, the customers are going to drive what is really important and it's something to pay attention to. Yeah. Yeah, that's, that's, I think, a really great summary of the situation maybe that the European car industry is in. Okay, maybe let's go to the final questions. And this one, you know, let's see if we can make it a little bit policy focused. So I was wondering if there is now one kind of particular concern or maybe a proposed solution that you kind of want to leave in the, in the laps of the EU policy makers that they should, that they should go to thinking of maybe standards, licensing, reuse, cybersecurity, digital sovereignty or digital autonomy. And maybe let's just go through one by one that maybe you want to start, we'll just do it alphabetically. Sure, locating even. Yes, so I would say one thing I've heard I have a concern with that I would encourage policy makers to clarify is that when we talk about digital sovereignty and data sovereignty, sometimes the idea of open source software and open data get conflated. So we just need to be very clear that open source software is software and it may be the database where Danga is and it may run the networks where the data moves on and it may be living in a data center or a cloud that's driven by open source, but it has a different model for development and it has its own governance and open data, which is incredibly enabled by open source and has really exponentially accelerated our ability to find and use and deploy open data has its own governance. And so for legislators, when they think about digital sovereignty and what we should just know that open source provides an opportunity to collaborate beyond borders and all benefit from the same benefits, the same features and functions of the software, but open data has its own governance structure and shouldn't be conflated. So just encourage them to take care as a consider policy maker, making not to pure open source because it has something to do with what or the data lives in how it's handled. Perfect. Thank you. And Katarina, by last name, I realize alphabetically by last name. I would actually have two points to raise. So the first one I think we touched upon earlier is about the question of liability and clarity or an easy to understand framework so that action items can be taken in that framework. I think that is something that needs to be thought through. And then the second one basically touches upon what Deborah said, but goes maybe a little bit further. I think the data flow is important. So as much as I love the GDPR and how protective it is in the European context, the industrial context, and especially when collaborating across borders, you know, across continents, it can be an obstacle. So I'm wondering if and that's not for the EU itself. It's more like collaborate with the US and the Asian, Japanese, Chinese counterparts to enable a more accurate flow for data. I think that would be helpful. Fantastic. Well, I guess we should also focus in another time on the data questions becomes clear now. Michael, do you want to take the last one? We do not hear you unless... Sorry, my fault. I think I made my point already, right? I think what I would like to see is that there's a little playing field, although for small and mid-sized companies. So in Europe, we are driven by the so-called hidden champions. There's a lot of innovation potential within the small and mid-sized companies and don't overrun them by policies like GDPR which they cannot figure and hinder innovation by this. I'm not saying that we don't need this one, but maybe we can have an active approach, right? Find best practices, support them with guidance that even small and mid-sized enterprises can fulfill this kind of regulations, maybe on data, maybe on AI, maybe on other things so that they are able to compete when it comes to innovation, when it comes to features, but the big corporate. Okay, thank you. Well, then I think we're wrapping things up here. A few minutes over the time now, but I think still okay. Thank you to all the speakers, so to Michael Depp and Katarina, but also to Gael and to MEP Maserculator for providing an intro. I really, I took a page full of notes. This is very interesting, very, very helpful. I think for me, maybe one of the points that really stuck out was the point of culture and the kind of the evolving awareness that is happening now in the sector and how much work there is still to be done. And I think this culture aspect might be really this, I think that's what you said, the culture aspect really the key enabler of getting to all the other benefits that come further down the line. So for me, there's only one other thing to say is that we will have a next policy series event on the 20th of May on the European Commission Open Source Economic Impact Study, where we will talk about the results from there on policy recommendations and check out our website for that. I think it will also be very interesting and thanks everybody for taking part and for asking some questions and have a good evening. Bye-bye.