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!
Comments:
There are a number of projects that actually have a policy of giving commit privledges to anyone who provides a patch that is accepted (such as Rubinius). However, I think one of the big differences is that in open source anyone who shows up could be a bozo, in a corporate environment it's sort of assumed that you aren't a bozo by the time you show up on your first day (that's what the whole resume, interview, dance). Further, at a job you have meetings and strategy sessions and code reviews and a bunch of other formal systems for going through code. In open source the reality is that developers rarely have the time to invest in that type of synchronization, therefore one of the most important things is for the developers to be able to be operate autonomously, to a large extent.
Actually in our group we have a policy of requiring all new hire commits to be 'buddied' (full patch review and commit with both accounts tagged on the commit, one marked as the buddie) until they are proven. One person whom is no longer considered a new hire by any means still likes to get some of their more complex check-ins buddied. This is independent of the test framework and code reviews, paired programing, etc.
We expect it to take 6 to 18 months to get fully up to speed on the project.
We believe in convention over having hard coded workflows, so there is no 'committers bit'.
We've been doing this without giving much thought to it or with much structure around it for a long time. Everyone gets a copy of the code on the first day, but no one can commit code on their first day. Git makes it easy to have them work and even deploy their branches to sandbox servers while giving us an easy path to cherry-pick work that we've reviewed and would like to include.
I feel I should point out that you *have* tried this: I started at the Journal-World February 2006, and didn't get a commit bit on Ellington until May. During those first couple months you reviewed everything I wrote and committed it for me :)
(also, in fairness, my second commit was a bugfix for my first commit -- but back in the day we did it live!)
One project I worked on had no commit bit. Everyone had source code privileges, but all changes went through a review process, with a commit meeting where you had to defend your changes before promotion. It was incredibly heavy-weight, but it did keep quality up.
Congrats to us all on the 15th committer!
IMHO, You are comparing Apples and Oranges. While it's the same technology, an open source repository is also a project's distribution medium. The cost of a bad commit in an open repository is far greater than in a closed one and that's the reason you're so careful with commit privileges (lucky for us).
I wonder what's your take on the dvcs style of trust. Does dvcs really eliminate the class difference between committers and humans? and if it does, is it a good thing?
As the person who institute the Rubinius commit-bit-on-first-accepted-patch rule (which, btw, was taken from Audrey Tang's commit policy on Pugs), I can say it's been amazing.
For every developer that committed something silly and disappeared, there are 10 that committed something meaningful and continued to do so.
I can't even think of a single person who I've granted commit rights to that didn't understand the responsibility and trust that I had in them.
There are plenty of people who break something because they're not familiar with the code base, but probably 90% of those developers are quick to do another commit to fix the error.
Having that trust in them, bringing them into the community early is what drives them to want to come back, day after day.
Every developer, no matter how senior, breaks the build sometimes. It's how that developer and the rest of the team respond. Putting responsibility and trust in their hands means that they fix their own created problems.
A little bit off topic, but I thought you should know that I prefer reading your blog in a browser instead of a newsreader because I like your layout very much. The pony just makes me happy!
FYI, Google works this way. No one starts with commit access.
I just want to agree with Evan Phoenix. I work daily with the pugs repository (which holds a few different Perl 6 projects, including official test suite and specification), and I hand out one or two commit bits per week.
I haven't seen a single incident of vandalism, and got very positive feedback about the commit bit policy. In fact that's how I came to contribute in the first place: I reported a broken link, and got a commit bit and was told which file I could modify to fix it. I stayed :-)
Granted, it won't work for huge projects like the Linux kernel, but for small to medium size projects it does work very well.
Where I work, while we do get commit access on day one, all patches are put up on ReviewBoard before commit, and must get a ShipIt from at least one other person who knows the code before it can be checked in.
It has worked extremely well, and really helps with code quality AND with knowledge sharing.
Because it is part of the standard workflow, it doesn't really slow things down much.
I know of a few other companies that have a similar process, but most seem fairly gung-ho.
People seem to resist because of a few common issues: 1) the misconception that it will slow down development, and 2) that hubris makes it hard for some people to accept critique of their code.
@Michael Davidson: there is no commit bit at Google. *All* changes get reviewed, no matter who you are.
we have a completely open repository for writing books on open source. so far 1000 members, 50+ books, thousands of edits, no problems, and the quality of content continues to improve
Leave a comment: