Navigating the open road: Building sustainable open source contributions

This talk focuses on the significance of open source in the automotive industry, exploring its motivations and implications. The speaker, involved with the Open Source Program Office at Bosch, examines the evolution from closed, proprietary development to collaborative open source solutions. They emphasize the importance of understanding the diverse drivers behind open source contributions and the challenges faced in creating sustainable, collaborative ecosystems. Through personal observations and industry anecdotes, the speaker highlights the necessity for clear communication, governance, and discoverability in open source projects. The session urges attendees to reflect on their roles as contributors and maintainers while addressing the need for a positive mission and feedback mechanisms to foster community engagement.

[music] Thanks a lot for having me and warm welcome from my side also from the introduction. Um maybe a few words about myself. I'm part of the OSPO or the open source program office in Bosch these days. So I have the privilege or the chance to look on open source from a bit more abstract way. So obviously a lot of automotive stuff but also from other domains.

I've been working with Eclipse IoT in the past but also with the Eclipse ST we so I was one of the people in the very beginning of the Eclipse S3 working group involved and from all these different conversations that we had on there I also had the idea or some feeling that it might make sense to maybe take one step back and talk about okay why do

we actually do open source and how does it inflict here second disclaimer if this sounds very similar to what to the previous talk we thought about okay how can we combine these things but the idea was okay with the first talk we talk about more like how is open source done in the Eclipse Foundation so why are these things in the Eclipse Foundation like they are while

here the intention is to be a bit more generic abroad I need to start with a disclaimer because this is more personal observation um as you know maybe from some of the ads this talk is based on personal observations and collective best practices it is not in any way intended to expose anyone or to claim that there's only one way of doing things in the open. For

any further risk questions, risks or side effects, ask your local OSU to-do group ambassador or your neighbor in this group. And this is what I also encourage you to have this discussion about some of the um yeah pointers that I will get to. So looking at the automotive industry and I think this is not unique to automotive. We've seen this in a lot of hardware industries. networking

for instance we started by having really this manual controlled systems what got over to more specialized hardware to really go from the physical to the hardware world I think what we currently see is a lot of the mixing hard and software so we have more general purpose hardware but use software on that and the goal that at least the people in the ACV working group and also

across the industry are aiming for is these software defined vehicles so really be software defined and have overarching software system getting there and really being on the software side we got I've also seen it in other industries is that we get to a point where open source comes into question or comes into play that people want to do open source and my feeling is especially also in

automotive that we see a lot of people saying yeah open source was pretty pretty well we do open source now as too because it proved to be good or to put it in other words um what do you think about open source. So people say, "Yeah, it's cool. It's or it's just a bunch of nerds in the corner. We will do it seriously afterwards because we the

engineers so it will never work." But there's also people saying, "Yeah, you can make a billions." Heck, IBM bought companies like Red Hat or um Hashi Corp and it obviously also transforms a lot of industries. So the question is what is open source actually? It's a bit like everyone is talking about it. We just did a whole uh talk explaining what open source is. What what is

it? And here I need some of your engagement because I would like to get a humming or clapping game. So I see I will tell you a couple of potential answers to the question what is open source at least answers that I have heard in the past. I would like to see whether you agree that this is open source or not. So first of all open source

is only about the license. Who agrees with that? I can't see you because there's so much light, but I could hear you if you would make a noise. Okay, interesting. Open source is a working model. See a bit of nodding. Okay, so interesting that this is more agreement for the working model than for the license. It's open source about saving cost. Okay, shaking hands. Serenity. Yeah, one

or two hands raised. Funny story, if you listen to, let's say, politicians or high level managers, I think in the last half year, we heard serenity a lot, but the open source term was not used so often in that regard. Is open source a business model. Okay, I hear laughing. Okay. Is it a compliance risk? So, is it just a problem? Okay, I see a bit of

nodding innovation or just marketing. We just do it and then once there's an actual customer, we just we redo it in a proper proprietary internal way. Okay. Or is it just for fun? I guess that's why some of the people also are drawn to open source. point is and you cannot really say okay this is open source and then the other side has exactly the same meaning

for that. I mean there is the definition by the open source initiative and personally I always try to get back to that which is basically saying yeah your software needs to be under a particular license which allows you to have a free distribution source code available for inspection and I guess you kind of have seen it already. So license should also not specific to any product or

discriminate against um specific fields or persons or groups or fields of endeavor. Um point is and that's also why I had the slideshow in the beginning is obviously this is just a very basic basic definition. When people talk about open source it's not so much they only talk about the license they talk about all the other things that come with Um maybe another motivation I think what

what why automotive and also other industries like to engage also in open source or open collaboration as you could say it. So classical model that we've seen was this close development or even close collaboration and there it might take you don't see anything from the outside. You wait a year you don't see anything at all and after two years you see maybe an 80% solution and then

all the other people that have not been involved before we're like yeah this does not really fit our use case or we should add this or that. That's maybe the classical proprietary way. In the open way it's a bit different because you already see results quite quite in the process. So I think that's also what sometimes is why open source is seen in in a bad way

is in the very beginning it might seem even worse than doing nothing because it's completely confusing and a lot of different ideas because these discussions now happen in the open and not behind closed doors which where you also lose some of your control. However, since you are able to involve more perspectives, more more yeah views on that after two or two and a half years just don't

call me on the years exactly but after some time you might end up with a better and more proven and use solution compared to the close development. So how is the state of collaboration in the Eclipse STV community? And I think that's kind of the same motivator also for um the PMC to talk here. I did a small analysis of the project. So I found 31 distinct

projects in GitHub. So first disclaimer, I didn't look into the data for the GitLab projects. So some of the projects are hosted in the GitLab instance by the Eclipse Foundation. And these projects they have four around 400 repositories and almost oh more than thousand distinct authors. So these are these usernames that committed to one of the projects. I cannot claim that these are individual people because I

know multiple people that use different accounts but that's maybe beyond the scope here. However, and I think this is quite striking is and um only 88 people actually contributed to more than one project. So if we really think about the Eclipse as the working group as a group of people working together, I think there's room for more inter collaboration especially if you look into the first eight

accounts which um have the most project that they contributed to, they all somehow associated to the Eclipse Foundation. So the infamous Autodoc for instance is like one committer working with a lot of these projects. Um what I think was even worse and shout out to the found uh to the working group they I know they work on that is in the last eight weeks seven out of

these 31 projects didn't had any commits so stopped working and another seven they had less than 10 commits so I would also say it's like really gradually fading out potentially so that's kind of the motivation why I wanted also to have [clears throat] this impulse this talk or this or because um my feeling is there's often a lot of good intentions or motivations to start the project

but we see have a tendency that it will stop because there's also a bit sustainability or potentially long-term funding or motivation to do these kind of activities missing missing so the question is how do we reach our goals through open source and it's kind of taking turning it around it's not like you do open source because you want to do open source it's more like I have

a goal and I do open source to reach that goal and this is already where it becomes complicated because you need to pick your driver like what actually drives you to do the open to do this open and just as a um example I think this can be quite diverse in a sense and depending on your driver you also have conflicts coming up with people that might

have a completely different driver it can also be aligned so for instance for some people it's really because they want to volunteer it's maybe too much a case in STV but in general in the open source active system we see this a lot people just wanted to do it for the public benefit but at the same time you might strive for zero licensing cost it's really hard

business that you um follow here or transparency and this also gives you another observation about the maturity in an open source project so thanks to this um guide which is called in principles of industrial open source so you see there's already the company perspective in there. There's kind of a ladder or staircase that you follow. So many organizations they go more for an accidental open source. It's

like a boss telling the engineer, "Hey, come up with a cool solution for that problem and they are back like in instantly because they searched the internet and found someone else who already solved the problem. But it's not really driven. It's more accidental. can do this in a more repetitive form and then even get to the point of prevailing and really controlling or um being a leader

or taking a leadership role in that The point is since this is a staircase, I see many organizations that try to do the prevailing and leadership at the very beginning without building any of these foundations or getting some insights or experience on how to actually work on the say lower layers here which is part of the reasons why things like the PMC and the Eclipse Foundation struggling

a bit because they are used to these um way of people walking through the ladder or through the staircase where people like say hey I want to step jump set I just want to get to the to the top. Um you can put another layer on on there because to me I think there's like two different sides of driving these uh activities. So one is the engineering

driven side. So it's again the engineer having a problem in solving it together with other engineers and here the thing is you kind of have a hidden return before the invest. So you it feels like you get the uh project for free but obviously once you depend on the project you also have to take care of the uh maintenance or at least that it is maintained. So

this is the invest you have to do afterwards. On the other side we have the businessdriven open source where people say okay yeah this is really supports our business case we are willing to do this invest because it creates a lot of value for us and we are also happy to maybe share of that some of that. So here the invest is before the expected return and

this sometimes makes it quite hard to argue for that or to convince people of doing this invest but once you actually achieve more this businessdriven side it also becomes a bit easier to have it in a sustainable way. [gasps] So for the business-driven open source obviously you also need a business model and I completely subscribe to the notion that open source itself is not the business model.

It's more about okay how do I set up my business so that contributing to the open source projects or also contributions from others are actually helping that. So we have the classic ones like support and maintenance or packaging professional services but it's also more that you own a platform and then work on monetizing out of that platform or do a licensing. I won't go too much into

details about this due to time and also because I think it's um well written out in other places for instance and this is a commercial break and one of the reasons I'm here with you and let's see who knows German television because then you're accustomed to that is there's another activity um in the to-do group which is a yeah combination or loose community of opos open source

program offices which It's exactly looking into the business sides of convincing to do open source. Um, but the caveat here is it's not so much about the classical startup or smaller business doing open source and trying to build a business around creating that project. I see a lot of phones. It's nice. It's more about how do larger organizations that are not necessarily relying on software as a

core business model um approach open source. So you already see one of the main contributor is Cornelius Schumah from Deutsche Barnan. And this is a really good example because at least from my perspective you choose Deutschean or the railway company in Germany not because they have the best software but because they provide you a solution to another problem but they also need a lot of software to

do that. Um another contributor was Emily Amir so far who was also one of the founders for the open source founders summit. So more these yeah startups relying on open source as a core. So I'm really looking for input or ideas here. To put it in another way, when I pitched this idea to um colleague from another company, he was like, "Hey, we all have this small

slide deck in our desk or in our drawer to convince management why we want to do open source or why we would need an open source program office." And let's just combine all these slides and see how we find a common agumentation line. And with that, it's already the end of the commercial break. But if you're wondering where these business models and all the drivers came from,

it's exactly from that document. now we talked a lot about okay there are different drivers there's you we just had the talk before telling you hey you have to do this you have to do this but is there only one way to do I mean if I ask a question obviously obviously not again it depends because and bear with me it's a bit uh I I just

came up with that idea if you're into distributed systems or computer engineering, you might come across this cup theorem where you say if you want to have a distributed system which has to be consistent partition tolerant and should be available, it's really hard to achieve all or almost impossible to optimize on all of three of these dimensions. So it's bit depending on your requirements whether you need

to the partition tolerance or the consistency for instance. [sighs and gasps] I try to adapt this to the open source or open collaboration model and I would argue and I'm really looking for your opinions here is that um here the theorem would be you cannot have cohesion and control a large ecosystem and pace at the same time. So for the pace it's more the petition tolerance. So

are people or teams able to um work independently from each other? For the cohesion or control it's is it really consistent road map? So is it like a really completely clear UX journey for from an outside perspective and also how available are you for contributions and usable artifacts. Um another way to look at this um and thanks to the Mozilla Foundation for funding that is the so-called

arch types. So there are different open source projects arch for how to do these projects and the reason I'm putting them in here is it's quite relevant to me to actually be aware that there's not the one and only open source project. So people might build a multi- vendor infrastructure and I think that's also what we're doing in Eclipse SUV mostly is that you build a common

layer on which you can create your own solutions on top of that. So these multi- vendor infrastructures like kubernetus or openstack they tend to have um more like loosely coupled modules that join together become more or less a defacto standard because a lot of people in the industry use that and you also have a more formal governance with really formal tech committees membership driven um and also

more large organization contributing to that. On the contrary to that, we also have the single maintainer house plant and I think that's also where a lot of frustration comes in because the single maintainer house prints and curl is just one of the striking examples. There's one or two guys that are really really deeply looking into particular problem which is then adopted by uh many people in the

industries. And if you now collide these worlds of multi- vendor infrastructure, we have to be this more governance-driven thing compared to a single maintainer who's like just driving their project in a way. You already see there's there's room for conflict or miscommunication same with specialty libraries. Um here the idea is more we have a really specialized group of people that work together. Um so FFmpact or SSL

are examples. So it's again used across the industry in a wide form but at the same time you need a lot of domain knowhow or knowledge to actually do meaningful contributions. So these projects might not super urgently looking for new contributors because it takes a lot of time to actually onboard them into the the domain which also gives them other needs compared to let's say a trusted

vendor like um one would be or graphana which basically have a product and a whole productization strategy and um use open source more as a tool to um yeah get through the market and still try to maintain a lot of control. So for instance, I would be really surprised to see a trusted vendor project in the Eclipse Foundation, but maybe they are because putting it in the

Eclipse Foundation also gives away some of the control towards the foundation. Not in the sense that the foundation is controlling the project, but in the sense that they ensure a fair and governance on the project. So you cannot just say hey I this guy is becoming a maintainer because I want that. you have these structures that try to really also ensure the um the communitydriven approach. So

there are even more art types of apps. So I think even by the names you can already see there's quite a difference. So one of my favorites is rocket ship to Mars which sounds like super crazy. It's like really few people coming together and having a crazy vision to do that. often these also evolves and maybe to um to to um a wide open project for instance

or you also have these upstream dependencies that we also talk a lot when it comes about security and supply chains. So these are very small projects no one knows the name of but they almost in there a lot of other software projects because they do such meaningful things like logging for instance. with this with that out of out of the way, let's shift a bit the perspective

because so far it was more an observation of let's say the ecosystem or the market and now let's shift the perspective to hey I'm a maintainer so I want to do a project I want to collaborate on that or I have maybe other reasons why I do it in the open. So, how do I actually become interesting to contribute to? And um this is almost a marketing

activity to be to be honest I've seen people that that put a project out and said, "Yeah, the community will solve that." Like, where's your community? Yeah, they will come because they're the open source people. They they will solve everything. And obviously, this is not the case and it's part of the reason we have also this talk. First thing is discovery like really make the project discoverable

and make it clear what you do there. Um I put in stars here which is one indicator of the relevance for some people but it has there's some caveat to it. So people start buying stars so they can get to their venture capital um providers and say hey my product is successful I have so many stars and these stars actually coming from somewhere else but that's just

side story but is it really actively maintained is also a really good first impression. So, do we really know what it's what it's doing? What who is it for? Why should I care about this project? How easy is it actually to get started? Because remember the staircase, it starts with the usage. People tend to use a project tend to find it useful and then they actually have

a larger motivation to also contribute to the maintenance of the project compared to yeah, I don't even need that. then also the maintainer perspective again really be aware that um there's also this journey from okay people are using the project become a contributor add some contribution and then be uh end up being a maintainer that's sometimes forgotten when people say hey I have this cool open source

project but no one wants to be a co-maintainer here I I do all the things on my own and then you ask them like how easy is it is to contribute and they're like yeah you should have to have to fulfill this this and this and that rule and also you have to be a seasoned C++ programmer for the last 20 years otherwise I won't accept your

pull request and you're like hm there's maybe a bit where the problem is coming from how open are you also to support or mentor people in this um um maybe some motivators why it also makes sense to be as a m maintainer to open that up so it really opens multip multiplies the workforce here gives you more the long-term investment. So classical motivations also for [sighs] doing

mentorship resource that I really recommend to you is uh a book called social architecture by uh Peter Hintians. He was um a maintainer of one of large project which had a lot of um contributions Q. Yeah, that he was also involved there or >> zero. >> Yeah, zero Q. That's that's what I at least that's why I know him mostly from and he postulated or not postulated

but has this nice way of um giving you some hints on how to act or react uh if you maintain such a project. And this is a disclaimer if you're interested in growing a community because again if your driver is different, you might not need a community, but in most cases this helps um to reach your goals. Um one thing is you really should get your fundamentals

right. So have a strong mission and um really why does this group exist? And uh what he also says and I strongly subscribe to that is this mission should be based on positivity. It's so driven by positive goals in the sense if you ask someone why you are in that community. It should be because I like I want to achieve this and that and that and not

because the people on the other side are bad. I don't I don't want to talk to them or because I want to have something bad for the other side. It's really more the positive goals here. It sounds kind of obvious but at the same time um yeah I've seen I think in business we kind of used to having it's us against them um thinking at some point

which might get in the way if you want to really collaborate in the open. Um the other thing is participation. So how easy is it actually to join and uh to get started with the whole process to actually have a smooth learning. So that's why people tend to say you need documentation because obviously this enables you smooth learning and remember people use contribute and then maybe become

a maintainer if it's impossible to use your product because no one knows how to do that difficult story to actually grow it. Um another thing and that's might be a bit controversial from a commercial standpoint is free contributors. um is what he's saying is it's way worse to have a person who is on out of their own motivation or maybe the motivation of their employer to put

it more on the commercial side is contributing to the project compared to hey I just pay this guy or this this lady to contribute now and because the moment this money is gone also the person working on that is gone. So with free cont with contributors that actually have their own way of being motivated um you also have higher engagement here. Another thing thing is uh governance.

So especially when projects grow you see a lot of problems which come because there's not these strong protocols in place. It's like people like hey we always talk to each other in a closed room and then at some point people come or add there or added to the group and then problems might occur here but at the same time you also need a fair authority. It's not

about hey we have this big law or this rules you should follow that and now we kick you out because you made a small mistake and you misinterpreted the second paragraph here. I mean again it should be driven about positivity. um also regular structures. So how predictable is the overall project? How predictable is it actually to find your resources and transparency? So if you're wondering why the

Eclipse project handbook exists or why it is written that way, I would say it's mostly to ensure this governance to ensure that there's a fair authority to ensure that there are strong protocols that you can point to in case of conflict or different opinions. But also I think what the Eclipse Foundation is doing in a way is this regular structure. So you have this project pages where

you get an overview who is involved. You get a idea where the repositories are. The repositories are organized in similar way. So if you know one of the projects you have a easy time to find your way around all the other projects talking about regular another point is the uh autonomy like how um autonomous can the members of your community work together. So is it really a

self-organization or do we need like a dictator telling everyone you do that you do that you do that which does not really scale. So that's why we have this self organization also these free workspaces. Um so how easy is it maybe to create a sub project in your project and um how easy is it actually to branch out and combine things and this brings me to I

think a very important topic which is sometimes seems easy on on on paper but it's really hard in in reality is this full remixability because I think one of the caveats or the benefits of open source is actually you build something and you have a particular use case in mind and then someone else is buildings something else and out of coincidence the piece of software that you've

written exactly matches their use case even though they're doing something completely different. So I expect that some of the stuff that is done in the Eclipse SDV working group or in the automotive domain will be applicable to other domains as well but we not even fully aware yet because we're not so deep in that domains. Think about robotics, think about trains, think about ships, airplanes and structuring

the project in a way that it becomes um remixable in somewhere else like having the software architected in a way that um you can actually use this without having the whole stack which for which the project was initially built like with common APIs for instance can be very helpful also for adoption or growing beyond your initial scope. >> [sighs] >> Um, another thing which is also easy

to put on slides but really needs to be lived is uh the culture. So how easy does a group embrace conflict? So conflict can happen but it should not be a problem that you just split because there's a quick conflict. Obviously forking is always an option but at the same time if you cannot embrace this conflict you might have um a problem and also to have this

measurable success and high scoring. So really rewards the participation of people joining the projects because often they might have their own motivations but also rewarding them in some way is helpful compared to Yeah. Yeah. saying hey I expected you to do this contribution now and this is also a two-way street where I think a lot of people can learn in the sense that um it's also rewarding

the contributors that they did this contribution it's not like okay now please do that and that and that even though they do it maybe in their free time or because they have other motivations where your requirements do not match there so it's also part of this high scoring um last but not least um we have the sane funding which I thought also particularly interesting in in this

regard is um make sure that the project um is maybe not overfunded because then people are more there for the money and not because they're so much interested in the project but at the same time if it's not enough money in the project or enough not enough funding you also starve out the people and get into also emotional problems. Um with that I'm looking forward to your

questions or opinions. Um and again as I said before uh if this is somehow interesting to you and also to have this conversations okay how does open source play in um beyond directly connected business models. I happily invite you to continue the realization around this business guide. So thanks. Thank you very much. [applause] So, any questions from the audience? >> Some hands raised. >> Comments. >> Uh,

thank you for your talk. Uh what I would like to to add is some kind of comment for the funding because I think um if you have a new project or newer project that you want to grow the community for example you are on GitHub uh and we have that for a project which is not on in the Eclipse Foundation um we give out some GitHub sponsorship

for example for the best committer once a month like $50 or something nothing big but this is something that I have the feeling is really working well because from time to time you can you can more or less uh give an incentive to the to the most active members to continue contributing to your project no matter where they sit and you get an invoice and everything is

fine for your business. >> Yeah, thanks completely agreed. I mean this is I guess is this somewhere between saint funding and high scoring because I mean it already shows you also some appreciation and rewarding even though it's obvious that maybe in that case you cannot cover the full cost of that person but still you you show the appreciation there other questions so if not then I have

maybe one you have talked about this business models so we had a lot of discussions in this SDV research project area how to contribute especially to this S core so because we have at the past we have the value chains where you have let's say tiers software vendors and they developed let's say this classically autosar stacks and they sell and resell that year after year so we

say hardware and software on top now if there is this let's say open source solution for this middleware so which is non-competing or competing. So that depends on which uh which which you talk. But uh if I look at that so is there a business model your company sees because you are one of the main contributors because some companies are struggling they say if we contribute now

to this escore so maybe then the feature is in so we get paid for that maintenance fees maybe for this feature but before that so we have developed this whole stack in our company and what's with the other things now is there some business model or business case you can derive for that. So which fits for this whole value chain or does this open source mean so

that the cake is go pieces of cakes are going smaller let's >> I would like to avoid to conflict uh comment on a particular project so in this case escore >> um what I can say I think in general is even though you might have the same work on the same open source projects you might have completely different drivers here and different motivators. So um many of

these al if you also look into these business models uh many of these models are driven by the fact that people somehow use your software with knowing or without knowing that. So you kind of did these pre-invest of um having the technology openly available and then build services or additional things on top of that. So integrating your project in a in another project might also be seen

as a way to um get the exposure or the the adoption of that pro of your project in this larger context and uh then create these one of these models there really depends on the particular situation of your project and also the the the product that you contribute to. Um so maybe another example is um what we've seen quite a lot in the CNCF I would say

is you have this basic platform with Kubernetes and you have a lot of smaller businesses that somehow strive on the fact that they quite easy to integrate with Kubernetes. So if an uh adopter now has Kubernetes, they know okay I can use that and that and that software and might also be willing to uh pay for some of these softwares because I already know it's quite working

very well with this open source tech which uh I already rely on and then you you get in this field of you can do support and m maintenance you can um have full respit other things that you provide like um tooling or completely integration becomes easier to to adopt because um the people do not have to work completely with your problem or with your solution. So that's

a very abstract way I know but that's maybe that's what I would like to comment on that. So it's really okay. How do you shape the ecosystem and position yourself so that yeah you become relevant if you if you will. >> Okay. Thank you. One more question here. >> Hi. Um Eclipse is not the first opensource project in the automotive world. There have been some before, right?

>> Yeah. >> Most of them that I know actually failed or were not that successful or some of them. Have you been involved in one of those that were not so successful? And what are your three key learnings mapped to the values that you presented that we don't repeat with Eclipse for uh SDV? >> Um it's cool. >> Let me start it differently. So I think the

main question is what is success for an open source project? Yeah, [laughter] fair point >> because I think that's where automotive also has a is a bit special in the sense that it not all of these um principles might not apply directly in the sense that if your project is used by two OEMs technically you have two adopters but this is a huge success for the project.

Um while if you develop a it's a bad example login library if you only have two adopters it's maybe not a big success. So >> if your model is really about growing ecosystem then um that's one that's a different story than being driven by one of the adopters. Um key takeaways um let me put it the other way. We I was also involved in an IoT business.

Well, there we built an IT back end. And I would say this is just my personal opinion. Forget about the logo in the in the in the corner. Is again how easy is it actually to use that software like um maybe the where does it fit? So this um yeah smooth learning and also ease of joining is um if you need a whole data center to set

up your solution or need a full vehicle it's it's really hard for people to actually play around with this uh technology. Um one problem that we also had with I think with the um in automotive is the tendency that people take out have a whole stack or whole internal stack in their mind and then they feel like hm this small piece I want to collaborate on that

and then they pick out this piece and the rest of the world or the outside world is like what is this doing like where should I put it but what is up what is down like how do I turn it around because they're missing the whole context of the internal system but for obvious these reasons the internal system is not public. So it's really hard to map

that and that's also why these to meat fields sometimes more like picnic. So people just bring something and then the task is how do we make a meal out of that is that that is the ambition then it's really hard task. If it's more about okay we agree that this is a particular problem for us and we kind of are willing to shape our internal stack so

that it matches comp matches there um then that could be learning um maybe one example a project that we are involved in is eclipse cooxer it's an abstraction layer for automotive so basically the idea is to decouple all the applications from the internal data or the can stacks in the the vehicles honestly coming up with such a data model is not a super hard task. But what

the problem is to actually agree on this data model and adopt it. And there's have this tendency also maybe a bit in this tribalism if you really want to say it in a in a in a bad way that okay we already have the solution we already have um this data model it's hard for us to adopt and this adoption to actually move a bit to a

common solution is maybe another learning because otherwise it will be hard for people to maintain >> Thank you. >> Thank you very much. further questions? If not, then thank you again, Sen. >> [music]