At a glance:
- Involved in open source since: 2000
- Works for: Johannes Kepler University Linz, Austria
- Eclipse Foundation contributor since: 2015
- Involved in: Eclipse 4diac, Eclipse SimRel, Eclipse GEF Classic
- Eclipse Foundation committer since: 2015
What’s your background as a developer?
I would describe myself as a researcher-developer. Most of my work has focused on building research prototypes and tools. I began my career as an embedded systems developer, working with small microcontrollers. Over time, however, I gradually shifted towards tool development because I realised how essential good tools are for conducting effective research.
The Eclipse Platform became a natural foundation for this work. It offered exactly the kind of extensible infrastructure we needed, although it also required significant effort and contribution. These days, most of my development work is in Java, building on top of the Eclipse Platform and contributing to projects such as Eclipse 4diac.
How did you get involved in open source?
I first encountered open source during my studies in electrical engineering at the Technical University of Vienna. A fellow student in my dorm introduced me to Linux, and I was immediately hooked. The freedom and possibilities it offered were inspiring.
Like many people, I began as a consumer of open source software. Eventually, I started building my own projects. At one point, I even experimented with creating something similar to my own version of Blender, which is still available on SourceForge.
Later, with what is now Eclipse 4diac, we made a conscious decision to publish our research results as open source. We wanted other researchers and industry partners to experiment with and build upon our work. From that point onwards, I got feedback from different projects that we used or that we collaborated with.
How did you become a committer at the Eclipse Foundation?
In 2015, we decided to bring our main project, now Eclipse 4diac, to the Eclipse Foundation. Until then, we had been operating as a typical grassroots open source project: we had code online (at the time on SourceForge), and we managed it in a rather ad hoc manner.
After five or six years, we realised we needed a more professional structure for governance and long-term sustainability. Through contacts with the Eclipse Foundation, particularly via Ralph Müller and the Eclipse DemoCamps [now Open Community Meetups], we gained a much better understanding of the Eclipse Foundation processes and community. When I brought the project to the Foundation, I became both a committer and the project lead. It felt like a natural fit, especially as a large part of our codebase was already built on the Eclipse Platform. I'm very thankful to Ralph, who introduced me to this process. It was really helpful, and I learned a lot during that time.
What are the biggest challenges as a committer?
One of the biggest challenges is time. When your day job competes with your open source responsibilities, it can be difficult to find space for everything. This is particularly true for projects that may not be as visible or prominent as they deserve to be. Deciding how to prioritise and finding time for the “right” tasks remains an ongoing challenge.
Any particular challenges as a project lead?
I would say learning and getting accustomed to the process. Becoming part of the Eclipse Foundation brought enormous benefits, particularly the structured development and governance process. However, adapting to that process was a challenge in itself.
Previously, we simply did what was necessary, when it was necessary. At Eclipse Foundation, you must follow a clearly defined process. Learning how to do that properly, and setting everything up correctly, required effort.
That said, I consider this a positive challenge. The structure improves quality and credibility. For example, even project leads do not commit without review. This strengthens both the codebase and the community’s trust in it.
What have been the highlights of being a committer?
There have been several highlights. One significant milestone was participating in Google Summer of Code, which would not have been possible without being part of the Eclipse Foundation. Even as a professor working with students regularly, engaging with Google Summer of Code students offers a different and rewarding experience.
Another major highlight has been deeper involvement with the wider Eclipse Foundation community. Previously, we were primarily consumers of other projects. Over time, we became more engaged with sister projects. Collaborating more closely, understanding how others solve problems, and identifying ways to support one another has been extremely valuable.
Community meetings, such as the Eclipse IDE developer meeting and EclipseCon [now OCX], are also consistently inspiring and informative. Face-to-face meetings, even in today’s remote-first world, still matter greatly. Establishing personal connections at the beginning of a collaboration makes long-term online cooperation far more effective.
Any advice for someone new to open source?
Patience is essential. Joining an established open source community can feel intimidating. My advice would be: help us help you. Reach out, ask questions, join mailing lists, participate in forums, and attend meetups. Open source is as much about people and culture as it is about code. Early in my own journey, I was too shy to engage actively, and that held me back. I encourage newcomers to be proactive and to build connections.
How would you encourage companies to use and contribute to open source?
That topic could be an interview on its own. In a nutshell, many companies underestimate how much of their software stack is already built on open source. Engaging actively with the communities behind those projects ultimately makes products better and more cost-effective.
By interacting with upstream projects, for example, contributing to Eclipse GEF, we have significantly improved Eclipse 4diac. The result was not just incremental improvement, but substantial gains in quality, usability and development efficiency.
In short, contributing to open source makes your product cheaper, easier to build, and more valuable to your customers.