At a Glance:
- Involved in open source since: 2015
- Works for: ETAS/Bosch
- Eclipse Foundation contributor since: 2015
- Involved in: Eclipse Leda, Eclipse Kanto, Eclipse Kuksa, Eclipse Velocitas
- Committer to: Eclipse Leda
- Eclipse Foundation committer since: 2022
What was your first experience with open source?
I used to work as a Java developer for a German company in the financial sector, on a visual modeling tool for business logic based on the Eclipse Rich Client Platform.
That was my first real encounter with open source, via the Eclipse open source community. I joined technical discussions on Bugzilla and forums and prepared code contributions like bug fixes or enhancements. The contributions mostly originated from our commercial product, making the UX better or minimizing maintenance by pushing contributions upstream.
How did that lead to more involvement with the Eclipse Foundation?
Around 2015, Bosch strategically decided to invest more into open source. Our experience with the existing Eclipse ecosystem suggested it was a good match for what we were looking for. The methodologies, processes, and especially the open-minded people seemed compatible. We started to contribute our core components and core protocols as Eclipse projects.
What has that experience been like?
Witnessing the opening of a pretty large corporation to become a considerable open source contributor is a really fascinating story to me, especially considering that the root of the company was a rather closed space of software development. The Eclipse Foundation provides just enough structure to allow developers to collaborate freely on code-first projects while also helping the more risk-averse roles in the organization adapt to the idea of open source.
How have you found the experience of being a committer and working in open source?
It feels like a huge relief. In a closed source organization there is a lot of approval and permission and access management stuff. A software developer in the automotive sector has to do a lot of non-development tasks to be able to push out code. There’s a lot of bureaucracy and replication of work. With the open source approach, it’s much easier and it feels like I can just focus on producing code, not creating requests and waiting for weeks for approvals. It’s liberating.
Any thoughts on the impact of open source development on the automotive sector?
With the foundation of the Eclipse Software Defined Vehicle (SDV) Working Group, I’m very excited about what we as a community are going to achieve for the next generation of vehicle software.
It’s definitely a long-term process for the automotive industry to open up even more. Sure, there is already a lot of collaboration between partners, especially on open tooling and open specifications. But the more interesting part, from a general application developer point of view, is the “runtime” — the in-vehicle software platform.
As soon as we reach the point where we can deploy a generic third-party application to any kind of vehicle, across brands and models, without in any way sacrificing human safety, then that’s the point it gets really interesting.
What’s so exciting to you about these changes?
It’s the idea that it will become much easier to get to the point where the actual companies involved with automotive software can start cooperating on this base layer instead of duplicating it.
That gives the whole industry a way of focusing on the next generation of features and advancement.
Any advice for someone wanting to get more involved with open source?
Just start. Why not? Coming from a risk-averse industry, we’ve been lectured so much about risks and compliance that it may sound a bit scary to do something in the open.
But once you start, it becomes easier. You may need some additional patience, especially with departments that are used to working with closed source only, but it’s worth it to go that route. Software development should be a global, collaborative endeavor. Why write duplicate code which already exists somewhere?