Author: Robin 'Roblimo' Miller
MySQL also has several email lists. The one Brian watches most closely is the internal one that “deals with the guts of the server.” If someone has posted intelligently on that list, and has contributed patches, sooner or later Brian is likely to ask, “Hey, dude, would you like a job with us?”
To Brian, familiarity with MySQL is obviously an important hiring criterion. Beyond that knowledge, he says, “I’m looking for people with pure system skills, not just somebody who took Java for four years in a college class.”
What makes an open source developer?
Brian says one of the major differences between proprietary and open source developers is that open source developers “tend not to want to reimplement everything themselves. They have familiarity with other projects, and know what bits of code from elswehere can be incorporated into what they’re working on — a skill you don’t find in most commercial developers.”
Another major difference he sees is that open source people tend to need less tech support. He says he’s talked to commercial developers “who sit in their office and program but don’t know how their computers work, while most open source people know how to set up a compiler (and sometimes build their own computers and set up their own networks). There’s a lot less handholding needed.”
“The best way to get a job is to do something”
It can be participation in an existing open source project or starting your own. Or writing documentation, especially for new grads trying to get started in the field. Brian says, “If somebody’s trying to get a break, there are open source jobs besides being a developer. Documentation is not a bad starting place.” He notes that most open source project leaders tend to be good communicators, and that writing documentation is a good way to show off your communications skills. “And then you get the publishers coming around wanting you to write books, too,” he says, “and that’s nice.”
Another method of worming your way into an open source company’s good graces is offering to do a project on spec. That is, if you see a feature lacking in one of its products, offer to write it and accept pay only if it works out. Many of Brian’s most successful hires have started with a trial project. He notes that this is not common practice in the U.S. but is normal in many other countries, which may give an edge to non-U.S. applicants in some situations not because of exchange rates or cost of living differences, but because “try before you buy” testing of prospective employees is more common elsewhere.
(MySQL AB is headquarted in Sweden. Brian Aker lives in Seattle, Washington, USA, so technically he’s an “offshore” employee. The staff he supervises is scattered all over the world, with a majority of MySQL staff developers working from their homes, connected to the company via email, IM, IRC, and telephone.)
Of course, the “something” you do if you’re aiming for an open source job doesn’t specifically have to be with the hiring company’s code. One of the great advantages a manager has when evaluating an applicant with open source experience, says Brian, is that “the code (he or she has written) is out there. It’s immediately available to look at.”
Brian says, “In a typical white board interview I might ask 100 questions the applicants learned all the answers to in college. I still don’t get a good feeling for them out of that. But if they’ve implemented open source code, I can go read it and see what they did.”
Where are the open source jobs?
Brian says, “At this point ask yourself, ‘How many open source companies are out there?’ It’s a trick question. Is Google an open source company? The answer is yes.”
And Google is only one of thousands of companies competing for top open source developers. Brian says, “I can’t go around hiring leaders from big-name open source projects. They’re all hired. If they don’t have day jobs it’s because they don’t need them.”
Often, as with MySQL, companies that use open source heavily will give a job prospect a trial project to work on, although sometimes they’ll only do this if the applicant mentions the idea. “Ask for the opportunity,” Brian says, “and follow up on it.”
He also notes, “You can go to Microsoft and say, ‘I’ll implement this wonderful feature in Windows,’ and they have no way for you to do this. But someone can look at MySQL’s code, say the same thing, and we can say, ‘Go right ahead.'”
Even companies that aren’t committed to open source can often be talked into allowing programmers to work on open source projects as part of their jobs. “I think if you say, ‘I want so much of my work to be open source,’ you can often get what you ask for,” says Brian. He warns that such requests should be gentle, not couched in radical political terms or as a good vs. evil choice, because “companies don’t like militancy.” But, he adds, “If you really believe in yourself, you can get away with a lot more than if you don’t.”
Indeed, Brian suggests that finding a job where you can write open source software at least part of the time is a good career move even if you expect to spend most of your working life writing proprietary code. The reason for this is not idealism, but pure, pragmatic self-interest.
“When you go to the next company,” he says, “you can actually point to lines in a program and say, ‘This is what I’ve done.'”
