At a Glance:
- Involved in open source since: 2012
- Works for: Red Hat Inc.
- Eclipse Foundation contributor since: 2019
- Involved in: Jakarta Contexts and Dependency Injection (CDI), and MicroProfile
- Committer to: Both of the above projects
- Eclipse Foundation committer since: 2019
Tell me a bit about your background in software.
I’ve been toying around with computers since I was 10 years old or so, and it didn’t take long after that for me to get interested in programming. I toyed around with open source in the late 1990s, experimenting with various Linux distributions. When I started university in 2001, studying software engineering, I obviously was using open source software, including the Eclipse IDE. From day one of my professional career, Linux has been my daily driver: everyone around me was using it, I’d already done some looking into it myself, and I got some excellent mentorship from a colleague of mine.
When did you make your first contribution to open source?
It was when I started with Red Hat in August of 2012. I actually recently celebrated a decade there. I started as part of a Quality Engineering team: writing and executing tests, investigating results, and communicating with developers, as well as a bit of documentation and a few contributions here and there.
Those contributions were mainly to components of the WildFly project, since I was on the Quality Engineering team for the JBoss Enterprise Application Platform, which is the product version of WildFly.
And how did that lead to being involved with the Eclipse Foundation?
When I moved from quality engineering to engineering, it was to contribute to WildFly Swarm, which was trying to develop WildFly for microservices. The idea there was to make it so you could take whatever pieces of WildFly you wanted and add them into a single jar with your application. That project was later renamed to Thorntail, and Ken Finnigan and John Clingan from that team were among the founding members of the MicroProfile project. MicroProfile later became an Eclipse Foundation project. So MicroProfile ended up being my introduction to the Eclipse Foundation.
How did you find that introduction?
To be honest, the first thing I noticed, as a software engineer, was that things slowed down a bit. There were a lot more processes happening than when we were running wild, so to speak. And I understand that there are reasons for that: intellectual property laws are complex and there needs to be a lot of processes around them to do things properly, so I get it.
But it was great that I got the opportunity to work with all the diverse groups of people that are working together to achieve a common goal. That itself is really one of the things that feels so great about open source.
How about becoming a committer?
I started as a contributor by doing a few features and fixing a few bugs for MicroProfile Fault Tolerance and its TCK. I ended up becoming a committer even though I hadn’t contributed anything hugely significant. I think my biggest contributions were after the fact. And the community was very welcoming. In general, I found it works the way you’d expect any open source project to work: you join, you do the work, you interact with the community, and at some point you become a committer. It was very lightweight and pleasant: the MicroProfile community is very open-minded, and there’s very little hierarchy.
Do you have any particular goals as a committer?
I’m a lot more active these days in Jakarta Contexts and Dependency Injection (CDI), and that’s really where I want to focus my time. I want to make CDI more amenable to build-time processing, so that it can be implemented by more architectures than was previously possible. I’ll continue to work on CDI so that cloud-native frameworks, such as Quarkus, can become compliant with the specification and can therefore be easily used by people that are familiar with it.
Any advice for someone considering becoming a committer?
I’d definitely recommend it. What’s nice about being a committer is that you get to do really interesting work with knowledgeable people, and it makes a difference. Not only do you directly affect the specification, but by extension, you have an impact on all the different implementations that people out there are using for their work.
Just show up, do the work, and you’ll be a committer before you know it.