At a glance:
- Involved in open source since: 2009
- Works for: IBM
- Eclipse Foundation contributor since: 2024
- Involved in: Eclipse Yasson, Jakarta RESTful Web Services (Project Lead), Jakarta EE Platform
- Eclipse Foundation committer since: 2024
What’s your background as a developer?
I was working in a warehouse in shipping and realised that the shipping software we used could do things much better. So I started teaching myself RPG programming for IBM i systems.
Over time, I moved into the purchasing department at the same company and started doing IT work on the side. Eventually, I began learning Java so I could help update the company’s customer website and related systems.
In 2008, I became a full-time developer with a consulting company. I was still working with RPG, but I was also doing much more Java development and spending a lot of time learning Java EE. Around that time, I worked on getting JBoss Application Server [AS] running on IBM i, which ultimately led me to join Red Hat in 2011 to work on WildFly, which was JBoss AS at the time.
As of July 2025, our team moved from Red Hat to IBM, where I continue working on WildFly. I’m also the Project Lead for RESTEasy, which is a Jakarta REST implementation.
How did you get involved in open source?
Like many people, I first got involved in open source simply by using it. Around 2004, while working at the company I mentioned earlier, I installed Fedora Core 2 on an internal server and built an internal website for the company.
A few years later, around 2009 or 2010, I started interacting online with people working on JBoss projects. Twitter was in its prime, and it became a place where developers connected and collaborated.
I gradually started contributing to JBoss projects, and by the end of 2010, I was fully participating in the community. That involvement eventually led to my role at Red Hat in 2011.
How did you become a committer at the Eclipse Foundation?
I first encountered the Eclipse Foundation through the Eclipse IDE many years ago. Later, when Java EE transitioned to Jakarta EE under the Eclipse Foundation, I started participating more actively.
In 2024, I became a committer on the Jakarta REST specification project [Jakarta EE RESTful Web Services]. About a year later, I began contributing heavily to the Jakarta EE Platform TCK and became the Jakarta EE 12 Platform Co-Coordinator.
At the beginning of this year, I became co-lead of the Jakarta REST specification project [Jakarta EE RESTful Web Services] and also became a committer on Eclipse Yasson, the Jakarta JSON Binding implementation.
What are the biggest challenges as a committer and project lead?
One of the biggest challenges is making sure you truly understand the problem you’re trying to solve. I tend to be a perfectionist, and when you’re working on projects that are widely used, it’s important to get things right.
You need to understand both the issue itself and the broader problem space because other people will maintain that code in the future. Today, that code may even end up training an AI model, so there’s even more importance in producing high-quality code.
Another challenge is working with people from different cultures, communication styles, and technical backgrounds. Still, it’s a challenge I genuinely appreciate.
Another major challenge is contributor time. Many people in open source have demanding day jobs and limited free time, which makes long-term participation difficult. I’m fortunate that contributing to open source is part of my daily work, so I don’t have that time constraint.
What have been the highlights of being a committer?
One of the best parts of being a committer is getting to work with people from many different backgrounds and experiences. You constantly encounter people who think differently than you do, and that opens your eyes and your mind to different possibilities. It teaches you that just because you think something should work a certain way doesn’t mean it’s the only or best approach. That exposure to different viewpoints ultimately makes you a better developer and collaborator.
Another highlight is hearing positive feedback from users. When someone tells you that your work made their job easier or that they’re excited about a new feature you contributed, it’s incredibly rewarding.
Any advice for someone new to open source?
Start with a project you already use or care deeply about. If you use a technology in your day job, contributing to it gives you a clear purpose and helps you better understand the tools you rely on.
You can also choose a personal project you feel passionate about. Passion is important. Open source projects can absolutely feel overwhelming at first. There are so many projects now, and many of them are massive. But if you care about the project, you’ll eventually learn how to navigate it.
Patience is also extremely important. Today, people are used to instant communication and immediate responses, but many open source maintainers contribute in their spare time.
Not every project can respond immediately to questions or pull requests, and that’s okay. Contributors have jobs, families, and other responsibilities.
It’s also important not to take feedback personally. Communication in open source is often text-based, and language barriers or differing communication styles can sometimes make messages come across more harshly than intended. In most cases, though, it’s not personal.
Any recommendations for companies relying on open source?
My biggest recommendation to organisations is simple: give back.
Open source gives a lot to the world. It provides enormous value to companies and the wider technology ecosystem, so organisations should contribute back whenever possible.
That doesn’t necessarily mean assigning full-time teams to every project. Even small contributions matter. Companies can allow employees to spend a few hours contributing fixes, filing issues, improving documentation, or participating in discussions.
Sometimes even reporting a bug instead of forking and fixing it internally can help the entire community.
Contributing back strengthens not only the projects themselves, but also the companies and developers who rely on them.