Open source projects always need extra minds. Does your hiring process contribute to open source? It could, and it's easy to do.
Part of our hiring process is a day-long visit that includes a lot of pair programming. To make the day valuable for all involved, we want to work on interesting problems. Open source is made to order:
We also do whiteboard sessions, where interviewees and Relevance folk work together to solve design problems. In the past, I haven't made a specific effort to find open source projects for these sessions. This morning I was reading about a Guice/Wicket integration issue, and it occurred to me that open source issue trackers are a goldmine of interview opportunities.
The next time you encounter a complex issue in an open source project, file it away for your next job interview. If you make interesting progress, contribute it back. It doesn't have to be code! Good analysis and documentation can be a huge help to the next developer on a project.
Oh, and if you are interviewing at Relevance in the next few months, be ready for this interview question:
There is an interesting Wicket/Guice integration pitfall documented on the Wicket wiki and as issue WICKET-1130. If you were free to change anything (e.g. Wicket, Guice, Java, the value of Pi) how would you solve this problem? How would your answer differ if you could change only Wicket?