At a Glance:
- Involved in open source since: 2004
- Works for: Red Hat Inc.
Eclipse Foundation contributor since: 2006 - Involved in: Eclipse Project, Eclipse Technology, Eclipse Science, Eclipse Tools Project
- Committer to: All of the above, and many other downstream projects
- Eclipse Foundation committer since: 2008
Can you tell us a bit about your background as a developer?
I got my first paid job back in 2002, translating old Cobol-based systems into Java-based ones. It was a wild mixture of 40-year-old technology and what was, at the time, state-of-the-art. It was quite interesting.
We were using a lot of open source technologies, including Eclipse IDE version 1.0, which was not that stable yet. The company had a very strong policy of using open source whenever possible.
Within two years of starting as a developer, I was involved in packaging issues in various distributions. Open source back then was not that stable and reliable, so if you wanted to use it, you had to get involved with it too.
How did you first get involved with the Eclipse Foundation?
At one point I had my own company, and we were working with financial companies. As a startup we heavily relied on open source projects. That led me to become a contributor to the Mandriva (Mandrake back in the days) Linux, which shared its Java stack with the Fedora Linux distribution via the JPackage project. That got me involved with many of the underlying dependencies of the Eclipse IDE, such as the Apache Ant, Apache/Jakarta Commons, Objectweb ASM, etc., as well as deep diving in the various build systems.
After I started working at Red Hat, I ended up becoming the maintainer of Red Hat-built Eclipse IDE distribution. That led to involvement with Eclipse Platform (Releng and SWT initially), and things spread from there quite quickly.
I’m still active in the Eclipse Platform development, though I am looking to hand off some of the daily duties in order to focus on actual enhancements.
When did you first become a committer?
Back in 2008. I had been contributing to a few open source projects, particularly the RPM tooling plug-in for the Eclipse IDE, as I was an active user. After sending in a good chunk of patches, the project lead of the Linux Tools project, Andrew Overholt, asked if I planned to continue. I said yes, and he nominated me to be a committer.
How have you found that experience?
It can be very rewarding. Part of that is somewhat selfish: you’re capable of driving the change you want to see. Another big reward is when you’re able to help others get their ideas in and watch a project grow. This is particularly true for small projects. With big projects, there’s a bit of a trade-off. One person can’t make as much of a difference, but on the other hand, when you do make a change, you can see thousands of people benefit from your work.
But there are also challenges. Working on an open source project means working with many people with a lot of different priorities, which don’t always overlap. Finding the balance between someone trying to support the latest and greatest versions to hit the market and someone trying to maintain what might be a 15- or 20-year-old system can be quite challenging.
It can also mean working with many different cultures, which have different norms about what sort of feedback on your work is acceptable. You don’t necessarily know how your criticisms or comments are going to be received.
Any advice for someone considering becoming a committer?
I’ve been asked this a few times, and every time I say just go for it. There’s nothing to lose: if it’s not working out or you can’t keep up with the work, you can just stop. There’s no long-term commitment. But you stand to gain a lot. You can learn a lot, really help a project with even a few months of hard work and then be available to answer questions. Plus, you can get a lot of good connections and networking opportunities, whether that’s professionally or just some nice people to have a beer with.
How about someone who’s new to open source in general?
That’s a tough one, because there is still this misconception out there that open source really just means low-quality freeware. Even when they get past that, some people shy away from the amount of work involved. But the reality is that project outputs depend on the inputs of the people involved, and many projects are primarily driven by a few people. If you get involved — and really involved — you can make a big impact.
Any other thoughts?
It’s really interesting being involved with the Eclipse Foundation, particularly how I have been, with the Architecture and Planning Councils and so on. It’s quite different from other organizations, in that you have these very interesting conversations between people with very different backgrounds trying to shape what are ultimately largely unrelated projects in similar directions. You don’t see so much of this inter-project communication elsewhere.