If you're trying to hire developers who have open source experience, you have a big advantage compared to hiring other kinds of developers. Most of the résumé of an open source developer is public — it's everything they've ever done in every open source project they've ever worked on, because all of that activity is publicly archived.[55] But you shouldn't need to go searching for all of it. When you put out a job posting, tell prospective candidates directly that the résumé they send in should include references to their open source profile. This means their committer accounts on the projects where they've been active (or their account names at the overall project hosting sites where they're been active, e.g., their GitHub.com username), the email addresses or usernames they have used when posting in discussion forums, documentation they have written, and anything else that would lead you to places where you can see their open source project activity.
The kind of activity to look for is not only their direct technical activity, but also their relations with the other developers in the project. So look at the candidates commits, but look also at the frequency with which they reviewed others' commits, and at their reaction to reviews of their own commits. In the project's issue tracker, how often did the candidate respond constructively to incoming bug reports or contribute useful information to a bug ticket? Visit a threaded view of the project's discussion forums and see how often the candidate's posts were responded to, and what the general tone of the responses was. Someone who consistently causes negative reactions from others in the project may have social problems as a collaborator, which is important to know independently of the candidate's raw technical ability.
If candidate is applying for a position that would involve working on an open source project, but seems to have little or no open source experience themselves, this is not necessarily a showstopper, but it's a sign that you should ask some probing questions, and that you should expect some ramp-up time if you hire them. If the candidate is young and inexperienced in general, then lack of participation in open source is easy to understand. However, if the candidate has been a programmer for a while, and especially if they already have experience as a user of some of the open source software you'd be hiring them to work on, and yet they have never participated much in that project except to download and use it, then you should ask them questions about why. There is nothing wrong with being uninvolved as a participant in software that one uses. However, if you're hiring someone to be a participant in a project, and they already had a chance to be and chose not to, that implies a lack of intrinsic motivation to participate and may indicate that this person's temperament is not what you're looking for. Or there may be other reasons — for example, the candidate's prior management forbade them from participating. Whatever the reasons are, you should make sure you find out.
[55] Brian Fitzpatrick has written about the usefulness of having an open source résumé in two articles, The Virtual Referral (onlamp.com/pub/a/onlamp/2005/07/14/osdevelopers.html) and The Virtual Internship (onlamp.com/pub/a/onlamp/2005/08/01/opensourcedevelopers.html).