Open source basics for automotive - How to be a good open source citizen in the automotive world

This talk focuses on the integration of open source principles within the automotive industry, highlighting the journey from traditional development practices to a more collaborative, open source environment. The speakers, Harald Mackamul from Bosch and Andy Rick Singer from Schwarz Digital Cloud, discuss the differences in mindset between closed and open development, emphasizing the importance of transparency, meritocracy, and community contribution. They outline the critical role of the Eclipse Foundation in supporting automotive projects and the challenges faced by organizations in embracing open source culture. Key topics include project management, collaboration across companies, and overcoming anti-patterns that hinder effective open source participation. The session aims to encourage attendees to adopt open source best practices while fostering trust and collaboration in the automotive sector.

Good morning. Hi. I hope that you started a very good morning and you've had your coffees. Um I would like to thank you all for attending and please be seated. They're closing the door so that like you know the ambience noise is not coming in. Um I would like to introduce our moderator on stage Mr. Mario Drussi, a researcher at Virtual Vehicle Research GmbH. Please. I would

like to hand it over to him to introduce our speakers and moderate the panel. Thank you. Talk. So hello and welcome to the second day of this OCX Automotive track. So I'm happy to announce our first talk today. It has the title Open Source Basics for Automotive, How to Be a Good Open Source Citizen in the Automotive World. And for that I'm Please welcome our speakers on

the stage. So it's Harald Mackamul, senior expert at Robert Bosch. And Andy Rick Singer from Schwarz Digits Cloud GmbH and Kuka AG. Former also Robert Bosch. >> Okay. So good morning everyone. So we would like to present today the Open Source Basics for the Automotive World as we experienced some how to say it a little bit of difficulties within that. So therefore it was for us a

real not a challenge but a mission to talk a little bit about that. So we want to We are You already heard my name Harald Macamull. I'm working at Bosch Central Research and in the Eclipse world I'm project lead of App for MC and also part of the automotive project management committee and we will talk about that later. That is the background of our inspiration for this

talk. Yeah, and my name is Andy. So I was with Bosch for about 28 years. Now I'm an open source advisor at Schwarz Digital Cloud. Also member of the automotive PMC and co-project lead for two Eclipse project. One is Eclipse Autoworks and one is Velocitas. And also committed for other projects like the SDV landscape I presented yesterday. So right now we see two worlds are colliding. Means

automotive the automotive world with a real long history. It's about 140 years starting with just hardware, no software meets now the open source world. And you can really imagine it's a real different DNA where we come from. but we have the same future. So we are all here. It's an open source conference. It's about a software defined vehicle. We have all the interest in open source to

bring that further to overcome some hurdles to enable collaboration talk with each other, bring things forward. But what is the automotive reality? Who is in the automotive world in an automotive company? Okay, more or less all here. So you you know about the hierarchy within the automotive world. You have supervisors, you have CTOs, CEOs. Everyone want to tell you how to do your work. Often you have

the closed development because it's all IP protected. You have some patterns of stuff. So, therefore, oh, it's it's mine. I need that. And I do everything better than the others. So, therefore, yeah. No one have to see what I am doing. Just only in the product later on. We have their long release cycles. So, you see new car, when does it come? It takes some years to

the next one. We have an Intel internal ownership of all that stuff. Also within the companies, yeah, I can do it better than the okay, there's a solution out there fulfills, yeah, let's say 90 or 80 to 90% of my requirements, but not 100% what I'm doing right now. Okay, then I will make it by my own I'm the best one. But how looks the open-source reality?

So, there's everything about meritocracy. Means you have to earn your status. You have to show what you are doing. The others can assess what you are doing. Therefore, transparency is really, really necessary. Everyone, yeah, can see what you are doing. It's a kind of a business card what developers do. So, what I saw also in the automotive industry, it's also a kind of software quality asset if

you in the open, if you be transparent. Because the developer see, the software goes open. Everyone can see what I did. I have to do this, this, this, and this. I have to rework. Oh. And the at the end the solution will not be 80% it will be 125% at the end. Also, the continuous collaboration what what I learned so so it was a really great experience

from my point of view. So, it was it's about just 7 years ago where I met Rex. Uh Rex also a former um automotive guy or still automotive guy from a competitor company. So, and therefore typically without open source it was not possible to talk to each other. And now we had the chance to talk about open source stuff. And that was the start of a real

cool collaboration and not only collaboration in the meantime it's also friendship. And and therefore And therefore I I like that really. And what is also hard for managers it's a community own- ownership. As mentioned before in the automotive world you have your supervisors. They want to tell you what to do. But now they have the challenge that others are deciding what to do. How an open source

project evolves, what comes in, what not. The discussion in the open. And that's from my point of view even if I'm a long time automotive guy but I learned to love open source and this is really really necessary. But what's the real problem when automotive meets open source? It's not about the tooling. Because I will look at the portfolio within the Eclipse Foundation there are a lot

of project in in there. It's more than 400 project. A lot of tooling is there. It's also not about the processes. You have in the open processes. You have a lot of processes within the companies. Sometimes over regulated. But at the end, it's really the mindset. Thanks. So, in our title was how to be a good citizen. So, what is good in the open source and Eclipse

sense? Uh we already said it. Work in the open. And that also means not only present your results, but also discussions, steps to the solution. And all this helps to have a better documentation and also better understanding of your software. This public collaboration, as we mentioned it here, is one essential part with competitors, with others. So, there should be no limitation. And especially trust is earned through

your collaboration. So, it's really a personal achievement you have that is also untypical in the automotive industry. So, if you leave your employee, you take your roles with you. That is sometimes critical or was seen critical by the management. So, how does Eclipse define this? So, the rules of engagement are very clear here. First part, the openness in the sense of who can collaborate. So, you should

not have any boundaries. So, the same opportunity for all participants. And also everyone participates under the same rules. So, no special leader of the team. are not allowed that anybody is excluded. So, that's typically a first question if somebody starts a new project, would you allow your competitor to work with you? Or is it something you want to have for your own? Transparency we already mentioned. And

especially all the project artifacts, if possible, should be open. That means discussions, road maps, not only code, code documentation, whatever you have. I know that's not possible all the time, but the more you provide, the easier it is for others to join the project or to understand the project. And the last point I already mentioned, this meritocracy means the more you contribute, the more responsibility you can

take, and the more influence you to the projects you are working with. And merit-based means not only programming. You can answer questions in the mailing lists, you can do documentation. This is all very valuable work in an open source project. if others want to join the project as a committer, that is also important because that is part of our work in the PMC then. Uh there will

be an election, and the other committers can decide if this people person have contributed enough, has shown enough knowledge and commitment to this to be part of that as a committer. In all that, um governance matters because um there are rules also in open source, and the Eclipse Foundation is so-called top-level projects. These are umbrella projects for a specific topic, specific product, whatever. And each top-level project

has a number of projects below. And there is also this so-called project management committee that should help to do the project help the projects to do the work, also as a mentor sometimes, and also sometimes as somebody who has uh look that the rules are followed. Typical top-level projects, I mentioned a few here. So, uh I see that will not work. There is another line in but

as you can already see, Adoptium is a typical example of a product. So, Eclipse Runtime is a very clear area. Then we have the big automotive. We have smaller things like digital twins. But all these projects have something in common, and it should help the projects in this top-level project to work together, to communicate, and to have a common basis. And now, this should be one below

in the automotive part. So, we are one of the bigger top-level Um these 28 active member companies and 47 projects have rapidly growing in the last 2 years at least. So, even strong focus on software-defined vehicle, for example. And with the more than 2,000 commits typically in 1 month, that's a clear sign of very good activity. A little bit more in detail, um you can read the

names. We have car manufacturers, suppliers, technology providers. Really a good number of very good partners here that can contribute specific content and also a large number of projects. And on the right side you see the number of projects that have STV in the name. So that was one of the biggest growing parts in the past. This only to show you, as I already said, typically we have

more than 2,000 commits or you have more than 2,000 commits. We are only the top level project here. And it's also a good diversity regarding individuals and also companies who contribute. So it's not a show that is done by one company or a few companies. It's really a collaboration Now to this project management committee. And this is really the message we are here to help. So of

course sometimes we have to say this is not good enough, but in the essence we want to help the projects to do good work, provide guidance, ensure some quality. And as it says in the second row, not control is the focus, but enablement and mentoring here. To describe you what we do in in general, we have some tasks to review, for example, the elections. That was one

reason why we said we should talk about So people who want to contribute and want to be committed have to fulfill something. So we have to approve or in some cases also to veto these elections. And that only means not now, you can do it later. Show that you provide something and then come again. I think that's it and Andy will take over. Thank you. As we

are here to help, so we we thought about what can we do to help you. So, therefore, of course, we need a website. Therefore, we have started to create the automotive website. It's still under construction. It's not everything in there we want to have, but it's a a first good step and you can start with that. So, you have currently necessary links there. Um you will get

the information about how a good nomination uh should look like and so on and of course the contact data of Therefore, it's it's a real real good starting point and if you think there's something missing in there, yeah, let's do an issue. Um talk with us, come to us, tell us what do you need, especially for nominations, for your project setup, how to start a project and

so on. One of the real real necessary things and we are all here organized more or less in in one working group, the STVI working group, um is is one element which helps us. So, it's a safe legal space for collab- So, for example, I would like to stress the example with Rex one once again. Um if we do not had these legal stuff around that, as

I mentioned, it was not Yeah, it was not possible in the past to talk with a direct competitor of the your company. And therefore, this is really helping. It provides you a neutral ground to talk with others. Um you can align with your and you can bridge the industries together with with open source software. So, open source is really open for everyone. So, this means yeah, let's

talk with your competitors, I can just Yeah, do cannot say it enough. Yeah, it's it's really really worth to do that. So, currently we have three working groups within the automotive area. Of course, ASAM. I guess all of you know them, right? Or is anyone struggling with ASAM? No? Great. Then we have open mobility. For open mobility, we have here also a representative, Robert here. If you

want to talk about traffic simulation, so please correct me if I'm saying now some wrong stuff. Yeah, get in contact with Robert. He has the ownership, I would say, over the famous project SUMO. Stands for simulation of urban Oh, now. Yeah, sorry. Then we have OpenPASS. They started with I would say a kind of accident simulation. they are managing software platform for traffic scenarios, as well, and

they predict the real world effectiveness for driver assistance, which is also more or less relevant for an ASAM system at the end. But what is going wrong right now? As mentioned before, the project does not fail because of the technique, because the technique is there. So, you are I guess you are all technicians. Some of you will be software developer, some of you maybe hardware developer, but

most of you are Yeah, tech afficionado will say um and within the uh the technique. It fails because of the behaviors. So, as mentioned before, it's a kind of So, you have your to adopt yourself to the open source principles. And what we see as automotive PMC, what we call for today the anti-pattern, yeah, let's come to that right now. Keep the the button. So, uh we

have four anti-pattern we decided to present and we do it uh one after the other. So, a broken handover is a typical thing that happens not only in open source project. So, good documentation and onboarding material is essential for any product, of course, or any project because uh knowledge locked in people who will leave the project will not help Uh what is specific now in our case

is that in a company it's typical to say, "Oh, I have a new job and this is my successor who is responsible from now on." And especially this is not possible in open source. So, if you want to have somebody who replaces another um employee of a company, that person has to contribute amount of time to show that there is enough knowledge and enough um visibility to

others that the other committers can decide, "Okay, we want to have this person as another committer in our round." Because committers all have the same rights in general. So, they have access rights to repositories right possibilities right access. So, this is really a responsible task and it's a task that is really given to a person. So, this the leaving person cannot hand over to another one. That

was number one. Number two, what we see as as PMZ a wide range of nomination. So, as Harald mentioned to become committer to become a project lead, you have to fulfill some stuff. You have to undergo the nomination process. Sometimes we have nominations just a template. The template shows you with some brackets what to fill in. Some of them did not fill it out. So, it's just

a template and we thought what shall we do with that? So, next one is yeah, he did a good work. Let's call him a committer. Okay, and how to prove his merits? No answer. And then we have also some real good examples. Some Some are providing also more stuff than we are able to prove. So, with the list of 100 links to pull requests to discussions to

talks and so on. This is also a bit too much. So, we good ones. So, what do you think is what you did to earn your merits. Because it's it's really the only chance we can see if the people are doing the right stuff and not under hidden um yeah, company borders, I would say. Yeah, just one addition to the last point. So, even if you provide

the GitHub user, that helps. Or a link to to a possibility to see the commits of some person. It's not always obvious, and people are very creative with their Okay, next one is then the hidden development. That is very typical if you have some kind of product that is mainly done by one So, very often an initial commit is of course something that is already valuable. But,

after that the work should not go on in a closed with some new releases every few months or even longer time, but really work in the public repository and avoid these big drops of code because legally you are also have to do some snippet scans and other things if your company did not sign this agreement So, that is an an additional hurdle to to do it, but

in general, if you do work in a closed environment with a closed ticket system, worst case, and unknown requirements, it's hard for others to join. And that means in the end there is no collaboration. It's simply a component you provide for an open source environment, and that can be better from our point of view. And last but not least, the fourth antipattern, it's the corporate behavior. Let

me try to make an example what really happened. So, we had also committee election or nomination. Um, and the colleague asked me, "How can overcome this hurdle because I did that that and that but behind the doors. He did also some talks in the open but this was the only thing we can prove. So and after some discussions ongoing there the next step was he escalated internally

and his boss came to me. What could be the next step? How we can we overcome this hurdle? Then the same discussion. Then what I also experienced so they have also a colleague with within the Eclipse Foundation not not contracted from the Eclipse Foundation but also very very active in there and he contacted Harald and asked how can we solve that? So and this is what we

mean here with hierarchy over merit. So they try to transport the internal structures to the open source and that does not work. It's also with the decisions they made. For example, okay, I'm I'm leaving the company or I take over a new assignment within the company but in another department. my successor will be hm hm here's the baton I handed over and please make him a committer

or project lead. So but this is not how it works. But let's be honest maybe you experienced this as well. This is how companies I guess it's not only automotive also in some other company you will see see the same behaviors. Yeah, but we are working on that to overcome exactly that. And honestly spoken, this is not open source. So, we will say if it is not

public, if you have it not in the open, then it didn't happen because we cannot happens behind the doors. Even if they say, "Ah, we are open source. We are working also in open source projects." But if the development still happens behind the doors, then it don't really happen. Good. We We tried to summarize some things, but if there are any questions regarding how Eclipse projects typically

work, the project handbook with the link on this slide is a good example. So, you will find all what is necessary from the application as an Eclipse project, what you have to do to find a community, what is necessary to provide as an initial commitment or commit and whatever is necessary regarding governance, how to deal with changes in a project, how to do reviews, how to do

releases, and so on. So, all is there. It's a long document, but if you have specific questions, it's really a good source for that. Next one is and we can only offer support. The PMC is the idea to have people who have experience in projects they already did and also some overview in the area they are working in. Use the mailing lists. We will respond to that

and ask early. Don't try to do it in a strange way in some way, Um, we really try to help. We will do it on the mailing list uh mainly because we also had some experiences if we start to have additional mail contacts, that's not really helpful. So, we try to be as open and honest as possible and we will do it on the mailing list. Just

to add, we are not here to slow you down, to bother you. We are trying to enable you to help you really. So, some of the key takeaways what you should have in mind when you the session later on. Transparency is not optional if you are in an open source project. Everyone should know what you are doing, what your ideas are behind that. How you come to

the next decision, how the project will evolve. Sometimes you some of the projects uses also within GitHub the the road map features. Issues, discussions, pull requests, Be active in there. Meritocracy wins and we cannot negotiate it. So, it's it's really one of the fundamentals of So, if you have no merit that's I guess it's a hard message now, then you did nothing in the open at the

but try to to be to make that good. And uh your behavior defines at the end the success. So, if you are open enough, if you are transparent, if you show your then your project, your activities will be successful and you can reach the next state as a contributor, I would say. So, means to all of you please be a good open source citizen build trust in

everything what you do, collaborate with each other, enable the collaboration. So, we are all here. So, I guess you are all interested in building trust and collaboration. And if you have so I yesterday with the STV landscape I had a picture with the box of Lego bricks. Um all that once, then you have your your blueprint, you have your your stuff to build something new, to drive

innovation, to bring the automotive further, to overcome the gap between the traditional behavior and the open source behavior I would say. open source is behavior. Try not to adapt the open source to your company. Do it vice versa. Use the open source behavior and bring things forward. Otherwise, you will just publish code. You need a picture. So, thank you very much for this great presentation. Uh there

is space for questions. >> not better? Yeah? So, for the picture or So, ready for questions? Yeah, of course. We have enough time. Fantastic talk. I really loved it. The only thing which I was a little bit missing this had to be an open discussion because there are so many points where I'm the project leader of Eclipse Iserix, a project, and I'm really affected by this what

you mentioned here. And I think in the Eclipse community the ideas are great, but we have problems. People which violate them consciously. It's not about let's say teaching them the values. I would say the handbook is very well written. It's was presented to us when we started the project and I would guess that all the others read or had at least the opportunity to read them. So,

the first thing I wanted to ask, how to enforce the rules? What happens if someone gatekeeps consciously? Examples we encountered is for instance where decisions were made, we do not use Eclipse Iceoryx and the result was just let's copy out the code of this. It's completely legal, but the problem is it's compete with each other, not complete each other. So, therefore it's like against the open source

mindset, especially if it's in the same Eclipse Foundation for projects in the same project as let's say in the same project house for instance. The other thing is also gatekeeping in the sense that you say, "Yes, you can contribute, but my internal CI has to run." I said, "I have no idea idea or access to your internal CI." Or you have to buy a license of QNX

which costs a massive amount of money. I said, "No, and how do you enforce this? And how what is your plan enforcing this? Because in the past when we mentioned these things yeah, it was like we have to teach them more open source and thing and this is say, "Yeah, okay, we're still teaching them and it's still happening." So, what is here the process? What is let's

say the things that Eclipse Foundation learned to enforce values and not just say it's a recommendation. Mhm. Often that's uh it's a small path between the words I would say. Uh QNX for me is a is a real good example because we we have also project where QNX has at the first step is forced into that because the company not behind QNX, behind the the the open

source project says, "Okay, it costs me much more to retrain the people than to pay the licenses." So, therefore it's about the behavior. It's adapting open source to the company, not vice And enforcing, yeah, we can just talk, we can go to them, start a discussion, but at the we cannot prevent that right now. We have we have some, but very few possibilities to reject elections. For

example, if we see really no reason for that, no public reason. Uh all other cases are EMOs or Eclipse Management Organization or Wayne Beaton should be the right person to address. But you can also use the automotive PMC mailing list to start a discussion right now. I really like to motivate you for that and um looking forward. Any questions? Yeah, so Harald and Candy, thanks for the

very interesting presentation. It's not a question, it's more I'd like to start a debate, and maybe I'm wrong and then you correct me, yeah, but you asked for this one, yeah. It's about the principles that you have shown, and I would say they apply for Eclipse because there are other open source initiatives that have other rules, even they call themselves open source, but now coming even to

Eclipse, yeah. You say meritocracy is the basic fundament, yeah. Mhm. But now, there are equals and there maybe a little bit more equals cuz there are different levels of memberships, yeah. So, there are strategic members, there are contributing and there are supporting members, and at least to my knowledge, and correct me if I'm wrong, if you're a strategic member, you automatically become also a committer, yeah. So,

you don't have to go and maybe I'm wrong, yeah. That's That's my interpretation, so help me to understand this better. So, you don't have to undergo means at the end if you have the money, there's also an Eclipse way around it. So, perhaps let's let's start with the strategic membership. If you are talking about the Eclipse Foundation, that's definitely not true. So, if you are strategic member,

you get a seat in the board of directors. Yes, you have some possibility to talk about strategic decisions of the Eclipse Foundation, but that's it. You do not get any committer rights to projects automatically. And regarding STV, there is also a strategic membership because Yeah, but But the same principles apply there. The only difference is if you start a new project. Therefore, you are able to come

with the initial committers. Maybe this is what you are talking about. Maybe. But if the project started, then you have to undergo the election process Thank you. Any further questions? Yes. If not, and ah, okay. Yeah, maybe like with the about this initial committer group. Um I mean, those can be strategically chosen within like company hierarchy of like the company who starts the project. Um and then

also majority's kept strategically because the people who are voting are the ones who who were initially strategically chosen. And the question is like how can the project like break out of this? Is it Is it a common common issue, or is it like It's It's almost impossible for us to check that this at the beginning. Because we as a top-level project were asked, "Do you want to

support this project and have it under your umbrella?" But uh if we have a number of people and it was not visible before, we cannot decide who is really developing, contributing to this project and who is perhaps the the boss or somebody who wants to also be in this role. Yeah, I I I I saw this as well in in one project um set up um I

saw the the list of project leads and the list of committers and I thought Okay, I know this guy, this guy, this guy, this guy. I never expect from them any comment in there. Uh so, this is what you mentioned. So, this is the automotive behavior, I will say. So, the fear of um having nothing under control anymore. So, therefore, bring in So, this I guess that

was the intention, bring in the management people as project lead that we have still a kind of control. But, that that um this doesn't work in in that context. But, we cannot >> No, there's no good solution to that, to be honest. Yes. I commented it in the project proposal, but um no chance. Sorry? I read your comment. There was further question. Hi. Um hello. Can you

hear me? Yeah. Okay. Um as I understand it, the auto market is is a lot supplier relationships, etc. And now you have people like Tesla or Rivian coming in and I understand that they're much more vertically integrated. Uh with like less interfaces, right? Does that change the way you operate in the Eclipse Foundation and at the project? Sorry, I did not not get everything as uh the

door was a little bit open. Sorry. >> you have people like Tesla or so which control the whole stack and there's much less inter- like integration interfaces, right? Supplier and and customer. So, does that change anything for you in how you run your stuff here? That's a That's a good question. I I I guess not. The because um within the Eclipse Foundation, um we try to be

vendor neutral. If you um if I come back to the the example with Tesla. So, Tesla is opening or publishing the code under their own arc um GitHub arc, and therefore you see, okay, typically it's a project with one maintainer under the control of one company. And um Eclipse do it better, okay? Often in the start you have also a project with one company, but that evolves

and it's vendor neutral because it's not the GitHub arc, Tesla, Bosch, Continental, whatever. If this answers your question. The That was It was more >> Perhaps one one more sentence. The existence of Tesla forces some of the current companies to to think about the models. And I think projects like um ASCOT or these STV in general uh is a direction to do more together and to have

a a common basis and a fewer parts that are distinguishing things for a company, but it's a beginning Thank you. Further questions? If not, then the last one from my side. So, very impressive what you showed Uh so, you have given us an introduction what is needed to be a good, let say, contributor, committer? Uh and you have this project handbook. To be honest, I haven't read

it. And you also mentioned that there is a mindset change needed. So, from this closed source development which you have in our companies and this open source, let's say, Uh is there also something like a training or to onboard new guys to this or is it only to read this book and then jump in or There are there also the so-called committer hours. Um so, you can

can join them, ask your questions. Then there are also a lot of training videos uh there you can Yeah. Have a look on. So, like Nadia in the morning um said learn, learn, be curious, um try to find that Um and yes. And you see it also in the automotive world. So, so my my example typically is go about 10 years back. If you talk about open

source in the automotive, they say, "Hey, go out of this room. We do not do open source." And now to the things are changing. Everyone has to learn. It's a learning journey. And therefore, the change do not happen from today to tomorrow. So, it needs time and therefore, we are in the middle of that. It's it's a long process. >> Yeah. We we also started with tooling

that was non-differentiating and step by step it was more common and there is more internal clearness how to do open source. That's a progress I see the last years. if you want to learn a little bit more about open source, open source contribution, stay here in the room. Sven Eric will tell you a little bit, but I hope I did crash your announcement. Thank you very much

for this great introduction.