Thursday, May 29, 2025 - 07:00
  • Share this article:

At a Glance:

  • Involved in open source since: 2017
  • Works for: ETAS GmbH
  • Eclipse Foundation contributor since: 2020
  • Involved in: Eclipse KuksaEclipse Velocitas
  • Committer to: Eclipse Kuksa
  • Eclipse Foundation committer since: 2022

What’s your background with open source?

I first got involved with open source more or less in my last year of high school in 2017. I ended up doing an internship at Bosch in the corporate research department while I was studying hardware and software. I had made use of open source libraries and created some issues before then, but I’d never made any contributions to an open source project. But Bosch was involved with the Eclipse Foundation, specifically the Eclipse Kuksa project, and I ended up working on that.

My first contribution to the project was an experimental addition, a re-implementation of the vehicle abstraction layer, in 2020. I moved away from the project for a few years but ended up coming back in 2022. That was when I first became a committer to the project. 

Why did you want to become a committer?

This is around the time I feel I really got to know what open source really means, and what the benefits are. Before then, I mostly just benefited from open source, which is great in itself. It’s nice to simply be able to access useful code when you need to, but until I got involved as a committer, I didn’t really appreciate the amount of work involved in maintaining the codebase. But I also didn’t realise how much fun it can be to contribute. 

Eclipse Kuksa, in particular, is a very innovative and new project. It relies on the Rust programming language, which was very new at that point. As a new developer, I was really interested in getting in on the ground floor of some interesting and innovative work happening in software. 

What do you like most about being a committer?

One of my favourite things about open source is simply the fact that everyone can see what you’re doing. As a young developer, one of the most important things for me is to get feedback on my code, so that I can improve. Working in open source means that all your work happens in front of a huge audience, bigger than pretty much any other. 

Plus, working in closed source environments, it can be hard to collaborate in a cross-disciplinary way. If you’re working at a company, you’re ultimately working with people who are in the same industry as you. But in open source, you work with people from all kinds of different industries and backgrounds, and you’ll see suggestions and pull requests you never expected or considered. 

It's also been great being a committer at the Eclipse Foundation. It is of course a lot of extra responsibility, but the nice thing about the framework that the Foundation provides is that you don’t have the responsibility of figuring out how to be an effective committer. It’s all laid out for you, and you can simply focus on your contributions, your code reviews, and so on.

What’s been your biggest challenge as a committer? 

Time is the biggest challenge. You have to keep track of all the different pull requests and feature requests, and maintaining your codebase takes a lot of time. Plus, you try to give fast feedback when someone does make a pull request because nobody wants to wait. 

There’s also a bit of a delicate balance to be maintained between encouraging contributions to the project and maintaining the project direction. Open source is, of course, open. So, all kinds of feature requests come into the project. As a committer, someone who’s trying to maintain a goal and direction for the project, you don’t want to simply tell people no, because we don’t want to discourage people from getting involved and committing. But at the same time, not every feature makes sense in the context of what the project is trying to achieve. 

What are your goals as a committer and community member?

I would definitely like to make Eclipse Kuksa even better, with more features. There’s been a lot of work done recently in the project to quantify its performance, so a really exciting potential next step is to get it running on some real hardware, in an example car. It, along with many other projects in the SDV Working Group, are in a state now where you could take at least some components and see how they work in a real car, but the automotive industry is, understandably, very conservative. So, it’s quite challenging to convince the industry that this is ready. 

Any advice for someone new to open source? 

I would say that the whole open source process is iterative. That is, we start with an idea and we iterate on it over time until it’s ready to be used. 

I see a lot of requests come in from people who seem shy. They say this is something they’d perhaps like to see or would be nice to have. But open source is, well, open. It’s predicated on that idea that anyone can contribute. Nobody’s expecting your contribution to be perfect from the get-go, nor is there a secret inner circle of developers who will turn their nose up at community contributions. 

We want new things. If you have an idea, go ahead and contribute it. You can iterate on it later.