Obviously your search should start with a resume.
Resumes are funny things. In a single page they are meant to convey several things to the hiring professional:
- This individual is competent.
- The candidate has some experience or sufficient education to fulfill the needs of the position.
- He/she has worked with the technologies that you are trying to utilize to fulfill your mission.
The best resumes, from an Open Source development standpoint however, actually must possess several additional traits:
- Evidence that the individual has worked on or is working on Open Source projects.
- References* that can attest to accomplishments on Open Source projects.
- Examples of code that are publicly viewable.
* - Do not accept actual references here. Almost all Open Source projects have a contacts page where one can find a list of the project leads. You'll want to use those instead of some e-mail or phone number when it comes to Open Source.
Mix Depends on Needs
Oddly enough someone with ALL Open Source development experience might not be a great candidate to take with you to conferences and end-user training sessions. Here you need to focus in on the mix of business experience and pure Open Source development. Look for evidence that the candidate has participated in some kind of customer-facing activities like demos, training, conferences, and the like. If that is not present in the resume you'll need to do a phone conference or an interview. Pretend that you are an individual who is brand new to using a software package they are familiar with and ask them to describe its advantages in terms that you can understand.
If the individual fails miserably at the previous tasks it is fine. You simply have to remember that not everyone is good at explaining technology. It is a skill, one that must be honed, and oftentimes most IT professionals get very little practice.
The best candidates have already worked with the system you are hiring for (or a related one) and can tell you where it lacks features. They have some familiarity with deploying it in different environments (different industries, computing environments) and can list its capabilities, strengths, and problems it solves. The last part is the most important. As a solution provider everyone, even developers, must have a clear understanding of the types of problems that the system proposes to solve. Without this the application scope can go wildly out of control. Your team will try to deliver too much with too few resources. It is a recipe for disaster. Weeding out this problem early can start at the hiring phase.
Where to Place People
Not everyone is a developer and your Open Source initiative is going to need people that are NOT developers. Yes, you read that correctly. An individual that can train end users, discuss business benefits of technology, gather requirements, sell solutions, and write code is a rare person indeed. Often these capabilities will only exist in a set of individuals. Prioritize your needs at the various phases of your product's development. If you find yourself fielding lots of questions from end-users you might need to hire someone with experience documenting Open Source applications and communicating with end-users in a support/training/software testing capacity. If you are finding that you are building the wrong solutions you might need someone good at gathering requirements and working with your development framework to help steer your project down a better path.Go Back
Citation: Interviewing for Open Source. (2015). Retrieved Mon May 1 02:09:48 2017, from http://www.limsexpert.com/cgi-bin/bixchange/bixchange.cgi?pom=limsexpert3;iid=readMore;go=1420210664