Real World Job Skills the Open Source Way

For this presentation, I expanded the subject to include all of open source, not just free software. That distinction is subtle, but important. I also expanded considerably on the list of skills one can gain from working with open source software.

I focused on three major benefits from participating in one or more open source projects: core competencies, other technical skills, and non-technical skills.

The prevalence of open source also means that it’s so easy to try, with little risk. Whether you dabble on your own hardware, or you use a hosted provider somewhere, there’s really no excuse not to be learning something open source.

When I think of open source, I think of the big projects that demonstrate the success of the development model: the Linux kernel, the Apache httpd, various development languages like PHP, Python and Ruby, and all of the open source database systems. These are the big ticket technologies with which one can gain real technical skill. Linux admins and MongoDB admins and Ruby developers are all in demand these days, so by participating in open source projects (of all kinds) you can build demonstrable skill in these technologies.

And beyond the big ticket items listed above, open source will help you learn things like version control, virtualization, configuration management, development frameworks, and a whole lot more. All of these are used by employers, so you’re only making yourself more appealing to current or potential employers by gaining expertise through open source participation.

There’s also things like writing unit tests. More and more open source projects are demanding that contributions include tests to verify the patch you may be submitting. Writing tests demonstrates that you have a commitment to the success of the project as much as the success of your specific patch. It’s a commitment to quality.

Building packages for existing open source projects is an important – and oft-overlooked – technical skill. Packaged installations are a primary component of automation, and are critical at bigger employers.

Owen suggested to me that UX – user experience – is another technical skill to be gained from open source. At first I scoffed at this, thinking it was too niche of an example, but after some discussion on the matter I realized how important this actually is. UX is far more than just responsive web design or mobile application interfaces. I asked the attendees of my presentation how many of them enjoyed using SELinux, and no hands went up. I then asked how many people simply turned SELinux off, and almost every hand went up. That’s because, I pointed out, the user experience of SELinux is pretty poor. The same can be said for Sendmail M4 configurations, and a host of other things. UX is about the experience of the user of your product or project: that may be a sysadmin writing SELinux policies.

Problem solving is, I think, one of the biggest non-technical skills. The reason I claim this isn’t a technical skill is because problem solving involves looking at the bigger picture. You don’t need to know how to fix something to correctly identify that it’s broken. The staggering quantity of open source projects means that if you have trouble with Project X, you might find success with Project Y. So you can’t get Apache to do what you want? Maybe you’ll succeed with nginx or Lighttpd. Maybe Fedora will work where Debian has stymied you.

This kind of lateral thinking is important to employers because it helps them identify alternate solutions. It also helps influence discussions of “build vs. buy.” If you don’t know what options exist in the open source world, you’re pretty much at the mercy of vendors to sell you what they have. If, however, you have open source experience and expertise, you have a real shot at building the best solution for your situation.

Communication and teamwork are two other non-technical skills you’ll develop through open source. Communication is absolutely a skill, and it gets better through iterative use. Open source is, essentially, all about communication: whether it’s mailing list discussions, or back-and-forth on a bug tracker, or actual code contributions, you’re communicating with the other members of your community. You’ll need to learn to be precise, unambiguous, and (mostly) tactful.

Similarly, teamwork is something that many people think “just happens,” when in fact its a skill that develops over time. The larger, more successful open source projects have successful teams distributing the effort of writing code, writing documentation, shepherding bugs, and more. Smaller projects with fewer participants may struggle to handle all of the responsibilities successfully.

Professional networking is the final non-technical skill that I highlighted as a benefit from open source involvement. You’ll meet a lot of interesting people, and these people will be able to help you out in surprising ways. When I have problems at my day job, I often contact one or more of my peers in the open source community to brainstorm or bounce ideas off of them. In my experience, the people I know often know what I need to succeed. And speaking more broadly, open source participation introduces you to people and cultures from all over the world, making you a more interesting person to know.

To this I responded that the lack of original material in your account is ancillary to the public history of your participation in open source projects. Sure, you could fork projects in which you’re interested, but your GitHub account should also document the bugs you’ve reported, the improvements to documentation that you’ve submitted, and generally enumerate your specific interests by the projects you star. All of this will help potential employers evaluate your skills and interests.

I did point out that open source skills are easier to highlight when applying for a new job. The question of how to advertise your open source experience to an existing employer is a little trickier. It depends greatly on the kind of employer, the relationship you have with your peers and superiors, and a lot more. It’s certainly not impossible to leverage open source expertise into an improved situation at your existing employer, but it takes a little more effort – and probably a little more savvy – to succeed.

One young man asked me what I thought of certifications. I equivocated a little, saying that they’re not a bad thing to have, but neither are they sufficient in my mind. A cert essentially says “I was able to pass this test,” but doesn’t really impart the same information as reviewing someone’s GitHub history. Someone else in the audience astutely observed that hiring managers and HR folks are unlikely to go look at your GitHub account, whereas they are likely to immediately understand the relative benefit of a certification.

This was a great observation and caught me by surprise. My first response was “Well, let’s change that together!” which got some chuckles. It’s true that a certificate is a decent proxy for experience. A trusted third party says “Scott knows this” and that makes it an easy baseline for HR folks and hiring managers. This highlights the importance of the cover letter when applying for a job, because you can provide more explication for your open source experience.

A young man in the front row asked about the relative benefits of generalization versus specialization, specifically inquiring whether there were situations in which generalization might be a professional detriment. This started a great conversation between several others in the audience, and was probably my favorite part of the session. A lot of good points were raised. I wrapped things up by comparing professional skills development to university education: Your major program of study doesn’t mean that you ignore other subjects altogether. Universities want their graduates to have a well-rounded, general baseline of education upon which their major focus builds.

One man shared that he volunteers with high school students, and wanted to know if I could identify the one or two most important skills to develop prior to specific professional experience. I suggested that communication and teamwork were probably the best choices. Being able to communicate effectively online isn’t a skill being taught by many schools, so real guidance in this regard would go a long way. Even many adults with established open source careers still have a hard time saying “Your code sucks” in a way that doesn’t also imply “You suck.” This generated a lot of nodding heads in the audience.

To my surprise, this question was followed up by an actual high school student asking my advice whether he should apply his time and effort developing something new of his own, or if he should instead spend his energies by contributing in smaller ways to established projects. In my mind, the two are not mutually exclusive. Participation in other projects is sure to yield benefits to his own efforts in unexpected ways, so why would he not do that?

I hope I get the opportunity to give this presentation again!