Businesses can take hiring tips from Open Source

Dave Friedman and Doc Searls had an interesting discussion on the difference between "hiring" in open source and business. Doc railed against hiring based on flawed measures like academic degrees and IQ tests; Dave concluded that businesses and open source projects are so different that the same practices can't work in both. I think there's a better way.

Dave admits that academic degrees and IQ tests are imperfect, but businesses have to use them to evaluate potential employees because there's no other way to do it. The "anarchic world of open-source coding" doesn't use them, because there's no evaluation to be done: "any person can contribute to the code, at any time, regardless of qualification".

On the contrary, no serious Open Source project would ever think of letting Joe Random contribute changes at will. Sure, anyone can download the source and make their own changes, but "commit privileges"--the ability to make those changes to the official codebase--are tightly controlled. That's a big distinction.

Open Source contributors start by having to submit every change as a "patch" to the existing code, rather than changing the code directly. A current developer examines the patch, then either rejects it or commits it on the contributor's behalf. After slowly establishing a track record of both good patches and the ability to work with the rest of the team, the contributor may receive the ability to directly commit his own changes.

On most projects, even programmers with years of experience and spotless reputations have to go through this process. Some projects are so conservative with commit privileges that even valued, long-time contributors still have to submit patches.

So granting commit privileges to a contributor is the Open Source equivalent of hiring an employee. Both represent serious commitments--an incompetent contributor with commit privileges is as dangerous to the project as an incompetent employee is to a business. And revoking commit privileges carries the same political and psychological baggage as firing an employee.

Businesses try to predict whether a candidate will be a good employee, while Open Source projects say, "show us you're good by doing work at no risk to us, and then maybe we'll offer you a position." It's unlikely that the software industry can get away with this--the media and medical industries do, but only for entry-level positions. So what can we do?

I think the solution is to increase our use of true "contract-to-hire" positions. Contract-to-hire gives the company the ability to bring a candidate on at low risk, then hire the candidate or decline with no repercussions. It's also far better handling the unfortunate case of a competent employee that simply isn't a good fit for the company, because it limits the company's liability (both legal and emotional) while letting the employee avoid a resume-busting dismissal.

Yes, some companies abuse contract-to-hire. I know one programmer who was assured he would be "converted" in six months, only to spend two years in "headcount limbo" before being released with no warning. To be fair to both parties, the contract has to specify both the duration of the contract and a deadline for exercising or declining the option to hire.

The lack of benefits like health insurance for contractors is an issue, too, but it's hardly insurmountable. Contractors already command higher rates than they would get as full-time salary in order to pay for the missing benefits. When negotiating the contract terms, negotiate the proposed full-time salary (and thus the contractor's "benefit allowance") up front.

Fair and honest contract-to-hire is a win for both employers and individuals, and it's the only way I can see to achieve the hiring benefits Open Source projects enjoy. So what am I missing?