At a glance:
- Involved in open source since: 2023
- Works for: Vector Informatik
- Eclipse Foundation contributor since: 2023
- Involved in: Eclipse PDE, Eclipse Platform, Eclipse SimRel
-
Eclipse Foundation committer since: 2023
What’s your background as a developer?
Probably like many others, I started coding as a teenager. My first touchpoint was programming little games, because that was quite fun at the time, using languages such as BlitzBasic. I also started using C++ then.
I moved on to more serious work, developing extensions for AutoCAD construction engineering with Visual Basic and C#. Shortly afterwards, when I began studying computer science in 2010, I moved into the Java and Eclipse ecosystem. My university used Java and Eclipse as the IDE.
From then on, I was deeply involved in that ecosystem: first during my studies, and then while working for around six years as a researcher in software engineering. I used Java and Eclipse throughout, focusing on software engineering methodology and model-driven engineering. I also led a research prototype project based on Eclipse modelling technology.
About four years ago, I moved to Vector, my current company, where I work as an engineer developing a large Eclipse-based product. I am now responsible for developing and integrating the Eclipse dependencies in our product, as well as the IDE we use to develop it.
How did you get involved in open source?
I had been using open source for quite a while. I have used the Eclipse IDE and modelling tools for around 15 years, including for all the research I did. For most of that time, though, I was simply a user. I made only a few contributions and, honestly, did not really understand the relevance of open source then.
That changed when I moved to Vector. I initially joined as an ordinary developer working on one of our products. Soon afterwards, I was asked whether I wanted to drive our Eclipse development and help sustain the technological basis of the product. At that time, the Eclipse Platform project was at risk: there were not many contributions, and there was not much funding for essential work such as release engineering.
My manager was deeply involved in the newly founded Eclipse IDE Working Group, which had been set up to address risks that many companies faced. He asked me to drive the work on the technical side and took me directly to the next in-person meeting. There, I met the people involved, including Ed Merks. I had known Ed for years because of my work in modelling, so meeting him in person was awesome.
That was really where I became involved in open source development: through the Eclipse IDE Working Group and then through the technical development and maintenance of the Eclipse Platform. That was around three and a half years ago.
How did you then become a committer at the Eclipse Foundation?
I started contributing to the Eclipse Platform because it was the foundation on which our product depended. It was not easy to enter the project because it is large and has a complex set-up. You need to find the right place to begin.
I looked at reported issues to find something I could solve. That was quite difficult because the project had only recently moved to GitHub, while many issues were still in the old Bugzilla tracker. However, the move also meant that there were many flaky tests in the new GitHub Actions infrastructure. I decided to start by fixing tests so that I could learn the codebase, explore different areas of the project, and do something valuable, because reliable tests are important.
That was a very good decision. I learnt a great deal about the different parts of the codebase, and the existing committers really appreciated the work because it was valuable but cumbersome, particularly before AI tools were available.
I believe it was Lars Vogel, who has been deeply involved in the project for a long time, who nominated me as a committer. He said that because I was doing such valuable work on the tests, I should be able to merge my fixes myself rather than depend on someone else. It happened quite quickly: after around three or four months and quite a few test fixes, I was nominated as a committer on the Eclipse Platform project.
What are the biggest challenges as a committer?
One challenge is finding the time. Like many other committers and contributors, I have an ordinary job at a company. The open source work often supports the company’s work, but you still have to balance daily business against the needs of the open source project. The more responsibilities you take on, such as being a project lead or holding other roles in the development process, the harder that becomes. Time management is a challenge I face constantly.
Another emerging challenge is AI. On the one hand, AI assistance is very useful. For a project such as the Eclipse Platform, which no longer has so many contributors, agents can help us make a lot of progress. On the other hand, it is becoming difficult to track everything that is happening and assess the risks arising from the growing volume of contributions.
Compatibility is another major challenge, particularly for the Eclipse Platform, because so many people and projects consume it. In our company’s own product, we can largely decide what to do with our code and APIs. In an open source project, we have to maintain compatibility so that consumers do not need to adapt constantly, or at least know precisely when something will break. That teaches you a great deal about stability and good engineering, but ensuring it all the time is difficult.
Bringing in new contributors can also be hard. The projects are complex, and maintainers do not always have the resources to review contributions and support newcomers. You must decide whether to spend limited time helping a new contributor or on another urgent priority, knowing that without support the person may not remain involved. For more than a year, the Eclipse IDE Working Group funded two community mentors to support onboarding, improve set-up material, and streamline release engineering. The developer community call every two weeks also gives newcomers a place to discuss what they want to work on and ask questions. The community call was initiated by one of the community mentors, Hannes Wellmann, who is also a well respected Eclipse Foundation committer. These measures improve the experience, but finding and supporting new contributors remains difficult.
Sometimes it is also difficult simply to stop working, because working in this environment is so much fun.
What have been the highlights of being a committer?
One highlight is the people and the community. I enjoy meeting people, and coming to OCX is always a highlight because you can feel their energy. People have different personal and professional backgrounds and different opinions. That can sometimes be difficult, but once you understand how valuable those perspectives are, you learn a great deal from the discussions.
A personal technical highlight was the first large feature we implemented in the Eclipse Platform. We worked with Yatta for around two years on monitor-specific UI scaling for Windows. It allows an application window to be moved between monitors and rescaled. That sounds simple, but implementing it in a backwards-compatible way – so products built on the platform do not need to adapt, or need only small changes – is very difficult. It was awesome when we saw it working in the Eclipse IDE and later integrated it into our own product. Vector released the product with the feature this year, and seeing something we had developed for so long reach users was a great moment.
The methodology was also rewarding. We implemented the feature in production code behind different states of a feature toggle, so people could activate it, try it, and deactivate it if it did not work. The opt-in and opt-out process worked smoothly. Feedback was generally very good, and people now enjoy having a clean UI on whichever monitors they use. Achieving that together with another company made it even more special.
Any advice for someone new to open source?
First, be patient. Many open source projects are large. It takes time to find your way around, and it is completely fine if you cannot make a big contribution on your first day.
A good strategy is to show commitment by doing work that nobody else has time to do: cleaning things up, fixing tests, improving infrastructure, or migrating to new frameworks. This is not only a way to earn the trust that may eventually lead to committer status; it also helps you learn the codebase, release engineering and continuous integration through small tasks that are genuinely valuable. Tests are a particularly good starting point because the work is local and the risk of breaking something is limited.
Second, get to know the people involved. Meeting people in person was very valuable for me, but regular online meetings are useful too. It is completely different from communicating only through GitHub – and nowadays you may not even know whether you are writing to a person or an AI agent. The Eclipse Foundation developer community call, held every two weeks, is a good example of a place where newcomers can talk about what they want to work on and ask questions. You can find the call, held every other Thursday, and its joining details in the Eclipse IDE Community Agenda.
Finally, be open to different opinions. Open source projects bring together people with very different perspectives. Discussions may be controversial, but those varied opinions usually contain something valuable. If you work constructively with them, you can learn a great deal and reach better solutions.
Any recommendations for companies relying on open source?
First, companies should understand their open source dependencies, their criticality, and the risks attached to them. We often hear that 80 or 90 per cent of a product consists of open source components, yet many companies do not assess those dependencies properly. The Eclipse Platform, for example, is mission-critical for many products built on top of it, but not every manufacturer appears to understand the scale of that dependency or the associated risk.
That does not mean every user has to contribute to every project; that would not be realistic. Companies should, however, understand the health of the projects they depend on and assess the risks. Where working groups exist, joining them is one way to stay informed about what is happening.
Companies also need to understand that simply freezing the last available version is not a sustainable plan if a project stops being developed. The Eclipse IDE depends on operating systems that continue to evolve, so an old version can easily break if it is not adapted. We have seen this repeatedly with macOS compatibility. The Cyber Resilience Act makes the idea of pinning an old version even more problematic because that version may contain vulnerabilities. You need to be able to move forward.
There are also direct benefits to contributing. Before becoming involved, we were simply consumers of the Eclipse Platform and IDE. Once we started contributing, we could fix our own issues, get rid of patches, and address performance problems in the IDE. We could make a change and benefit from better productivity the next day. Getting involved in open source can therefore reduce risk and create immediate value for a company.