Strong opinions, weakly held

Commit access on work projects

Jacob Kaplan-Moss on who you let commit code to your projects:

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.

I can think of good reasons for the difference, but I’m going to think about this one for awhile.


  1. Well, presumably a company has hired you because you passed some interviews and they think you aren’t a dumbass. In the opensource world, you’re just some dude on the Internet. At my current company, I think it took a little while for me to get commit access on the code base I work on, though I can’t recall if that was because our sysadmins were slow, or because they wanted to review my stuff first. In my previous place of employment, there was a whole team in charge of ‘change control’, and you couldn’t check in code that hadn’t been signed (literally, on paper) by another developer and your manager. So I don’t think the opensource/commercial world is so different. There are all sorts of work places and projects out there.

  2. I don’t think it’s unheard of for commit access to be mysteriously “delayed” for new hires… not that I’d ever do that, of course…

  3. I don’t think there are any impracticalities if the shop has a review mechanism in place. Part of the logistical issue is identifying a maintainer for a given component (official, not de-facto). Many companies tend to think of developers as interchangeable, regardless of actual practice.

    Without a culture that reviews code, this proposal won’t work. I suspect a lot of corporate development don’t have that reviewing culture vs. OSS projects with any development community.

  4. With subversion I give new corporate developers read only access for the first week or so. The ramp up period of a new hire is more reading code and learning the work environment than producing anything. This in some ways approximates the OSS model, as any potential developer can read the code but not commit to the project. The difference is that the switch from r to rw is predetermined and guaranteed in the corporate world, very much not the case in the OSS community.

Leave a Reply

Your email address will not be published.


© 2023 rc3.org

Theme by Anders NorenUp ↑