Commit bits

What’d you do the day you started your job? Got a little tour. Found your desk. Some HR paperwork. Figured out the network. Set up your new company machine. Got your VPN credentials.

And got your commit access to the company’s source control.

Normal first day procedure, I know. And yet, that day-one-commit-bit is one of the starkest differences between the corporate and the open source development model.

Django’s open source debut was in the summer of 2005. At that point, we had three full and one partial committer. Since then we’ve had major contributions from hundreds of developers, bug fixes and patches from thousands, and input and engagement from tens of thousands. Yet last week we added only our fifteenth full committer.

Granted, Django’s very conservative when it comes to granting that commit bit, but I’m not aware of a single open source project under the sun that’d give out a commit bit on a contributor’s first day. I’ve seen developers who’ve been hired to work full time on open source work for months without commit access to the project they’re paid to develop!

There are obvious practical reasons why software companies would give developers commit bits on day one. Those reasons are so obvious I’m not even going to bother enumerating them.

But imagine a company that withheld commit from new hires. New developers would have to file patches, get them reviewed, and have their code committed by an existing committer. Only after new employees proved they measure up to the requirements would they be granted commit.

I’d argue that the level of quality this process would ensure would more than outweigh the downsides. But that’s just a gut feeling – I don’t know that this model’s ever been tried outside of open source.

I can tell you one thing, though: I’d love to work for a company that operated this way!