Open Source software has had a major role to play in the growth of Java. Apache and in particular the Jakarta project has been the birth place of several top Java components like Struts, Ant and Tomcat. In this interview, we speak to Henri Yandell, the current chair of the Jakarta project.

Henri speaks about open source software and its contribution to Java. He also shares his thoughts on why one should contribute to open source and his views on open sourcing Java itself. He also tells us about projects he thinks have a lot to offer to Java developers and which projects hold promise for the future.

IndicThreads >> Hello Henri. We are glad to have you on IndicThreads. Could you introduce yourself to IndicThreads readers?

Henri Yandell >> I'm an English Java developer, proud father of a recently born son and barely average football player. To hide how abysmally average I am at football, I moved to the US where I write code to monitor the US and European power grids for Genscape Inc.

"I commit to various Jakarta subprojects,
mostly to Jakarta Commons,
and am the current chair of Jakarta..."

 The other major component of my life is being involved with the Apache Software Foundation. I commit to various Jakarta subprojects, mostly to Jakarta Commons, and am the current chair of Jakarta.

IndicThreads >> Considering your long association with Java Open Source, you are in a good position to tell our readers why they should contribute to open source projects?

Henri Yandell >> The best reason is because we all have itches, and open-source lets us satisfy those itches. I recently installed an mp3 server in the basement so my wife could play music upstairs (computer attached to the dvd speakers) and soothe the baby. The server had bugs with play-lists and the apostrophe character, and because it was open-source I was able to dig into it and fix it. You hear this kind of story again and again: "Use open-source products, scratch the itches, join the conversation by offering your fixes/ideas."

"The Internet is good at creating larger communities,
and open-source projects are very good at using the Internet..."

So that's the first reason; the bait on the hook that lures you in.

After that things snowball. Contributing to open-source projects is a great way to learn from other developers. Most of us don't work in environments in which large numbers of developers regularly interact. It may be because there are only a handful of developers at your workplace, you live in a non-major city (Louisville, Kentucky for me), or just that you're divided into small teams at a large employer. The Internet is good at creating larger communities, and open-source projects are very good at using the Internet. Another situation might be that you're finding yourself in a non-programming role for a short period, being involved with a community project is a great way to keep yourself 'coding fit'.

"Being involved with a community project
is a great way to keep yourself 'coding fit'..."

The fix a problem itch I initially mentioned is a very good lesson. I don't usually code in PHP, which this server was implemented in, and so it was a good code exercise for my PHP abilities.

IndicThreads >> Right. However developers often say that they are indebted to open source projects and wish they could contribute. However very few manage to contribute. What do you think are the reasons and how does one overcome those issues? How did you start contributing to open source?

Henri Yandell >> Online gaming at University gave me an awareness of open-source communities, but my first contribution was when I bought Psion's superb netBook PDA in late 1999. It was really a mini-laptop, slightly cheaper than a laptop, and had a JRE 1.1 environment on it. I quickly wanted to code Java on it and found the JPE (Java Psion Editor) project from Daniel Ockeloen, a very minimalist IDE. That Christmas I found myself with a) frustration at the lack of search and replace and b) time. 10 days or so of hacking around with the code led to a list of new features and I emailed Daniel to let him know. He'd grown frustrated with Psion's lack of support/future for the netBook and had quit the platform, but gave me his blessing to release my enhancements, which I did as a replacement jar/patch.

"Online gaming at University gave me
an awareness of open-source communities..."

There were quite a few hurdles to overcome here, and they are many of the ones that face us all when looking to contribute to open-source.

1. Itch:
   I had to get frustrated enough to want to do something. In this case there were no other options to switch to, so the only way to allay my frustration was to look at the code. This is the hardest hurdle to overcome, often you can just choose a different product or process and avoid having to look at the code.
2. Time:
   I had to find time to scratch my itch. Fortunately I had a 2 week vacation just starting and was just planning to laze around with my family. This is less a problem for open-source and more a problem for our lives in general. Initially my open-source time was just a part of my general personal education time. Reading books, articles, websites and playing with code.
3. Community:
   Once I'd made my changes then found that the existing project was not as active as I'd like. Although I made a couple more releases of my patch, I ended up growing as disheartened as Daniel with Psion's lack of direction for the PDA. Dead, inactive and dormant projects can be very frustrating to deal with, especially when you're feeling your way in the general open-source world. The thing to remember is that in a non-open source world, you'd have never even have heard of the project, or it would have been a site with an unanswered phone number. SourceForge is excellent in that regard, even when the project dies/sleeps it's still there to be resumed or reworked someday. I think this is the least of the hurdles, but can feel like a big one.
   Around the same time, I had various bits of code from home that I wanted to use at work. Sadly my then company did not want to enter the confusion of using code at work that I owned, so I hit the 4th in my list of issues:
4. Day-job:
   What's the impact on coding outside of work, and can you use that code in your work without problems? This can be the biggest hindrance once you have built up momentum in open-source; legal-crap.
   This issue is also the reason why I tend towards the BSD style licences and not the GPL licences. If I GPL a utility library at home, it involves much more in the way of legalities to use it at work. So I go for the simplest possible.