Leveraging Open Source Experience in Your Job Hunt

  September 20, 2012

Working in open source brings many kinds of rewards. Open source participation helps get the software created that you need, and it brings a sense of accomplishment to help others with the work you do. If you’ve been involved in an open source community, you probably also have discovered that it’s a way to gain new technical skills.

There's also the benefit that your work in open source can have when it's time to look for a job. Your experience in working in open source is just that - work experience. Even if you're not paid for your contributions, it is still valuable experience that belongs on your resume, and the contacts you make in the community can help you find jobs.

Open source colleagues as leads

The first place to use your Free Open Source Software, or FOSS, background is in the toughest part of job hunting: Finding the good jobs. When companies look to fill positions, they look inside the company first, and outside the company, most jobs are filled by referrals. Companies find this to be the safe, most efficient way to fill a job. Networking and personal contacts are the most productive source of leads in your job search.

Many people (especially techies) cringe at the word "networking," but consider the hiring manager's focus. She wants to fill the position as quickly as possible. She would rather have people she knows give her resumes rather than sift through dozens or hundreds of resumes sent in cold. It's not that friends of friends automatically get the good jobs, but they are the easiest for the hiring manager to find, and the implicit recommendation of someone passing along a resume is that this candidate, at least, is reasonably competent.

Given the value of personal contacts in the job hunt, how do you make use of your personal network? Don't think of your contacts as “people who can give you a job.” Instead, see them as people who can help point you in the right direction to another job.

Never ask someone, "Do you know where I can get a job?" It's presumptuous and puts too much burden on your contact. Instead, describe your situation. Ask for ideas that your contact might have in helping along your job search. It's more open-ended, and it lets him offer assistance even if it's not exactly what you want. If he knows of a job opening, he'll certainly mention it.

When networking, don't focus on finding the endpoint. Think about how you can broaden your search to increase the chances of finding the endpoint. The more people you talk to, the better. Best of all is finding more people you can talk to that are outside of your normal circle.

Don't announce your availability too soon

If you've been let go from a job, or you finally decided to quit your current job, it's tempting to run out and tell everyone right away. Don't.

All too often I see postings on the jobs subreddit, or even my Facebook wall, where someone posts, "Help! I need a job!" That approach is 100% wrong. It tells nothing about you that is interesting to a potential employer. It tells only what is most interesting to you: the fact that you need a job.

The first thing that someone who wants to help you will ask is, "Do you have a resume I can send to someone?" If you don't have one, you have to answer "Well, no, but I'll have one in a few days!" You will have squandered the initial burst of attention from your contact. Wait until you have a coherent message to share, a story to tell, and a resume to which you can point people.

This isn’t just a matter of having a resume ready to go. Some of your open source colleagues may know you in one context (contributing on a project you work on together) but be unaware of your other skills and experience. They might know you only by the persona in IRC, and could be wholly unaware of your experience in other realms. Instead of telling her manager, “I know someone who’s looking for a job, and wow he knows a lot about this project,” your acquaintance can discover the other things you’ve accomplished and brag to the hiring manager about them, too.

If someone is to help you find your next great job, she has to know about you. She has to know what you can offer your next employer. It's not enough to know you want a job.

Don't mass mail your contacts

People don't like getting spammed. You're far more likely to get attention from a contact if you spend a few minutes writing a personal e-mail that explains your situation, what you have to offer, and why you consider her a valuable contact. Don't assume that your contact knows everything about you. Spell out your main areas of expertise. With luck, she will forward your message to someone she knows along with a personal recommendation. Do your best to make it easy for her to do so.


As you may have heard, my position with Yoyodyne is being eliminated, so I'm in the market for a new job. I have 25 years of software experience, and lately I've been focused on Perl, PostgreSQL, and jQuery. I remember talking to you once about your experience in the widget industry, and I thought you might be able to suggest contacts that might be helpful in my search.

My resume and portfolio are at http://example.com/resume. Thanks for reading this, and I hope to see you at the Open Source Bridge conference again next year.

Don't give in to the temptation to write one of those and just cut and paste it to each contact. The five minutes you spend making a personal appeal to your contact could be the difference between getting help and getting ignored. The job hunt is not where you want to start prematurely optimizing your time.

Make any public postings skimmable

If you do decide to post publicly about your job search, such as on your blog or to a user group or project mailing list, remember that you must explain who you are, even more than you do to your contacts. Do not post something with a subject like “Programmer needs job ASAP!”

Sell yourself from the start, with a subject line like: NW Chicago suburbs: 25+ yr programmer available, Perl, PostgreSQL, jQuery, etc.

In the body of the posting, include a summary of your resume. If you have a 3-5 bullet summary section at the top of your resume, instead of a vague fluffy objective, use that. Don't post the entire resume, because 99% of people won't care, and you want it easy for the interested 1% to see what you're about.

After the summary of your resume, include a pointer to your full resume online, as well as your email address and your phone number. Explicitly include your email address in the body of the mail; you don't know how the text of the mail will be forwarded.

Putting open source on your resume

The time you spend working on FOSS projects is work experience. The people you work with on FOSS projects are leads and references. Just because you aren’t paid to work on them doesn't mean they don't belong on your resume, or can't fit into your job search. An employer wants to know that you have experience with a technology or process. The employer wants to know what you accomplished. How much you were paid (or whether you were) isn’t part of that equation.

Don't get hung up on the size of the contributions you make, or how exactly you participate. Whether you've written code for core functionality in Firefox, wrote documentation for MySQL, spoke at your local Ruby user group, or organized a meeting, it's all participation and it should be included on your resume.

Distinguish between paid and unpaid

Even though both paid and unpaid experience are valuable, you do need to differentiate between the two on your resume. If you say on your resume that you've worked on Apache Tomcat from 2010-2012, make it clear that it was unpaid. Otherwise, a resume reader might think that you are trying to make it sound like a paying job, which implies (if nothing else) 40 hours per week. You don't want the reader to have any reason to distrust you.

Guide the reader through your best work

The hiring manager's challenge in the hiring process is trying to determine if the candidate really knows what he claims on his resume, or if he's just talking a good game during the interview.

You can't just say "Here's a link to my GitHub page" and assume that the hiring manager knows what to look at. She needs a guided tour of your work. What if you contribute to a huge project like PostgreSQL? You can't expect that she's going to understand what you've done based on having a forked repo on your account. She probably won't even look, and even if she did, she won't be able to tell the role you played. Don't leave it to chance.

Here are some examples of what I would include in my resume, or in a portfolio of my work:





Ack is a text searching tool, written in Perl, optimized for searching large trees of source code. I created it in 2006 and have driven development with community help.




WWW::Mechanize is a Perl module that allows easy navigation of websites, acting as a web browser in an object. Created as a fork of WWW::Automate in 2002, I maintained Mech until 2012 when it became part of the standard libwww-perl library.




Parrot is a virtual machine, written in C, for running modern dynamic languages like Perl 6. Since 2007, I have worked to increase stability of the code by increasing the number of compiler warnings checked, running static analysis tools like splint, and instrumenting the code.



This site is a collection of information to help novice programmers understand how to properly use parametrized SQL queries to prevent SQL injection attacks. While I created the site in 2008, it is now based on community content. Source for the site is kept on GitHub, with contributions coming in just like patches to a code-based project.

Use synonyms to increase understanding and findability

Include synonyms and related words in descriptions of your work. If you've contributed to Solr, a document search engine built on top of the Lucene indexing package, make sure you mention both "Solr" and "Lucene" on your resume. Someone reading the resume (or searching through resumes on sites like Dice) might be looking for someone with Lucene experience and not realize that Solr is closely related.

This is the same principle as making sure that if you put "Oracle" on your resume, include the word "SQL" as well. I suggest a section at the bottom of your resume titled "Technologies" or even "Buzzwords."

Open source colleagues as references

After you get a job interview, and you're at the point in the process where your future employer is asking for references, don't overlook the value of using your colleagues in open source. These people won't be your primary references, but they are good as supplements to your past employers and colleagues at paid jobs. Even if you've never met the person, or only see him once a year at a conference, the reference is still valuable.

When employers speak with references, they ask what it is like to work with you, and your open source co-workers can speak to that. They can also confirm the technical abilities that you've discussed in interviews.  Even if you've never met your colleague in person, or only see him once a year at a conference, the reference is still valuable.

Make sure that you contact your potential reference to make sure that it is OK to use him as a reference. You don't want him to be blindsided by a reference request, and you want to make sure that he knows about the job you're working toward. You might send off an email like this:

Ricardo, I've been interviewing with Amalgamated Widgets, and I'd like to use you as a reference, based on working together on Dist::Zilla. Would you be comfortable talking with someone from Amalgamated about the work we've done? What would be the best way for them to contact you?

When you list your contact in your references that you give to the company, explain your relationship as you would for any other contact. Instead of a standard reference listing for a former boss, like this:

Bob Smith, IT Manager

Yoyodyne Industries

[email protected]



Add a little explanation:

Ricardo Signes

[email protected]


Ricardo is currently the Perl 5 Pumpking, or the release manager. We worked together extensively between 2009-2010 on my Module::Starter tool, which then morphed into his Dist::Zilla.

Note that in this case, Ricardo is a luminary in the Perl community with important responsibilities, so explain that role. Don't assume that the hiring manager has the same understanding of the community as you do.

Further reading

Jeff Atwood of Coding Horror wrote about some of the troubles in using open source in the job hunt. He points out that "any company not even willing to take a cursory look at your portfolio before interviewing you is already suspect," and that the choice of projects you work on may matter as much as the code you generate. Just as employers look at the work you've done on the job, they also look at what type of work you were doing. The analysis of your open source work is no different.

If you're not yet involved in open source, and you're interested in getting started, even if only for the benefits to your career, check out my article here, 14 Ways to Contribute to Open Source Without Being a Programming Genius.

An ironic postscript

I've been working on this article for a long time ("Too long!" my editor would say). In a bit of irony that even Alanis Morrisette would appreciate, a few days before I submitted it for publication, my company announced that my division would be sold and I would lose my job in 60 days. Everything that I'd been writing about is now about to be put to the test, assembled in my resume+portfolio website, http://andylester.org/.

Andy Lester has been writing software professionally since the mid-80s, and working in open source since the mid-90s. Andy’s experiences hiring programmers led him to write Land the Tech Job You Love (Pragmatic Bookshelf, 2009), and he blogs about programming, careers and work life.

See also: