At a Glance:
- Involved in open source since: 2016
- Works for: Omnifish
- Eclipse Foundation contributor since: 2019
- Involved in: Jakarta Batch, Eclipse GlassFish, Jakarta Config, Jakarta Messaging, Jakarta EE TCK, Eclipse Piranha Cloud, Eclipse JNoSQL
- Eclipse Foundation committer since: 2020
What’s your background as a developer?
I started out as a typical Java back-end developer. Over time, I realised that I enjoy learning best practices and understanding how things work, which led me to start lecturing and mentoring my colleagues as well as professionals in other companies. I see myself as a mentor and an active member of the community. I regularly attend conferences, contribute to the open source community, and lead the Java User Group here in Prague. So my career evolved from being a typical Java developer to becoming someone more involved with the community, sharing knowledge, connecting with people, and teaching others.
Academically, I earned my Magister, which is equivalent to a Master’s degree, in Computer Science at Charles University in Prague. Most of my career was in the financial sector, working with banks and insurance companies, before joining Payara in 2015 to work on their open source server. I was already familiar with the original GlassFish server, having used it in several projects, and I appreciated the technology. I had been working extensively with Java EE, using application servers and Java EE itself directly, not Spring Boot or other derivatives, so Payara’s continuation of the GlassFish server and its core APIs was a natural fit. I stayed with Payara for seven years.
In 2022, I co-founded Omnifish with some other fellow GlassFish experts, where I now serve as CEO. We are a team of five, working remotely but intensively and closely together. Not all of us work for OmniFish full-time, but we are planning to grow. Building a company takes time, but it is an exciting journey.
How did you get involved in open source?
I began using open source tools at a very young age. I first installed Linux on my desktop computer while I was still in high school, and I continued using Linux for most of my programming work afterwards. My first real experience of contributing to open source came at the university, when I was working on a project with a friend who was a year or two ahead of me and more experienced. We encountered a bug in one of the open source tools we were using. He suggested that we look into the code and try to fix it, reassuring me that it wasn’t too complicated. We found a straightforward way to debug the code and submitted a change request, back then it was in the form of a diff.
That experience completely changed how I viewed open source. Until then, I had thought it was all built by clever masterminds on the internet, and I definitely suffered from imposter syndrome. But then I realised that I could do the same sort of things myself. I didn’t contribute much at the time, but I did start reading open source code. For example, when I was working with the Hibernate library, I ran into an issue and decided to explore Hibernate’s source code. I was able to understand what was happening and how to work around it. That taught me not to be afraid of looking into the code to understand how things work on the inside, instead of just relying on how they appear from the outside.
How did you become a committer at the Eclipse Foundation?
At first, I wasn’t really connected to the Eclipse Foundation itself. I had used the Eclipse IDE in the past, but later I also worked with other IDEs. I knew that the Eclipse Foundation was involved in other areas such as IoT, but those weren’t directly related to my work. Things became more relevant when Oracle decided to contribute Java EE to the Eclipse Foundation [in 2017]. At the time, I was working for Payara, which was involved in the process, so it was straightforward for me to become a committer.
I found the Eclipse Foundation, and the people working there, to be very supportive. They provided a lot of guidance compared to other open source foundations. I also appreciate the structure and governance, particularly the Working Group model. It can sometimes be a little complicated, but I can always find the information I need, either on the website or simply by asking people. Overall, it’s a very pleasant foundation to work with.
What are the biggest challenges as a committer?
As a committer, one of the biggest challenges is simply finding the time for everything, because the role carries a lot of responsibility. If someone contributes code or reports an issue, I feel obliged to at least respond and provide some guidance. When someone submits an improvement or a bug fix, it is important that a committer reviews it, since contributors cannot merge into the main repository themselves. Reviewing, approving, and merging can sometimes take time if committers are busy with other priorities.
From the perspective of a contributor, it can also be challenging. You need a committer to review your request, and while some projects have very active committers, in others it can be harder to reach someone. Building a strong community around an open source project is essential, because you can’t achieve much on your own. I also know of projects where not all committers are aligned, which can lead to disputes without resolution. That’s often due to the involvement of many different parties, each with their own goals and strong opinions. Reaching consensus can therefore take longer. This is why communication is both the greatest challenge and, ultimately, the key to finding solutions.
What are some highlights of being a committer so far?
The biggest highlight for me is the community. You meet so many people online. Often you don’t know them personally, but you quickly see how clever they are, with productive discussions taking place and excellent ideas being implemented in the code. Sometimes I even get the chance to meet some of them at conferences or other events. I learn from them, and they also learn from me. That exchange is a great experience – not only the social side, but also the opportunity to learn from other people’s code.
By interacting with others, you gain insights that aren’t always obvious from the code alone. If you want to improve your coding style, open source offers plenty of examples of best practice, especially when you know the people behind the code, as they are very skilled at what they do. You can often reach out to them and ask questions, and I would encourage everyone to do so. Many of these people are very open to discussions, so it’s usually easier to approach them for advice or pointers than to try to figure everything out on your own. If you have questions, just ask! The answer might arrive in a minute or in three months, but it very often does come, and when it does, you learn a lot from it.
Any advice for someone new to open source?
The best advice I can give is: ask. That’s the real strength of open source. The source code is open, of course, but what many people don’t realise is that the community is open as well. Most projects at the Eclipse Foundation provide communication channels to contact the team, whether that’s a mailing list, a website like jakarta.ee, Slack, or a forum you can join to ask questions. If your questions show genuine interest, people will respond, because they identify strongly with their projects.
What committers don’t appreciate quite as much are requests that demand immediate features, or complaints about what’s missing. Open source is free, so if you want specific features developed quickly, the right approach is to ask a company or consultancy to implement them. What is helpful, however, is when people raise issues in a constructive and respectful way. On the open source side, I see a great deal of respect for users, and I expect the same in return, because users receive the software for free and are not in a position to complain.
Open source is ultimately about people, not just code. Even in the age of AI, there is no substitute for talking to people. With their help, you can begin contributing, which is a rewarding experience for both sides: users gain a deeper understanding of the project, and contributors get the satisfaction of helping others make use of their software.
Another piece of advice is to look beyond the projects themselves and get involved with local communities. For example, I lead the Java User Group in Prague, and there are many similar groups worldwide. These communities are often centred around open source, because most of the topics involve open source tools, but they are equally about learning and sharing experiences. They are just as open as the source code itself, and I would encourage everyone to keep an open mind – not just sticking to what they know, but learning from others.