At some point in every firm’s journey with source control, there comes a time to decide on who should and who should not have access to read and modify different sections of the code base. In our opinion, if confronted with this question, you should save yourself the trouble of agonizing over the choices and instead follow one simple rule that typically requires no work to implement:
Give all your employees full access to all your code.
That’s all employees, not just all developers, full access, not read-only access, and all code, not just the code each person needs to work with to do his or her job.
Why take such a laissez-faire approach?
Permissions create busy work and impede progress.
When starting up a new project, most developers are excited to get right to the design and coding work. No developer that I know gets excited about the bureaucratic aspects of setting up a new project – such as ensuring that everyone has the necessary permissions to work with the code. Eliminating that step gets everyone doing real work faster.
Permissions are artificial barriers that encourage silos and hamper collaboration.
DevOps is all about cross-team collaboration, so if you are trying to “do DevOps”, make sure your company policy on source control permissions is not actively hostile to collaboration. How do you expect development and operations to collaborate if they aren’t allowed to view or modify each other’s code?
Permissions create a culture of mistrust.
By telling your employees that they aren’t allowed to modify (or even see) your company’s source code, you tell them that they aren’t good enough, qualified enough, or trustworthy enough to do so. A “need to know” policy indicates exactly what you think of those who don’t “need to know”. Beyond simply creating silos, permissions can create an artificial hierarchy and breed jealousy on a team that doesn’t “need to know” that much.
Before we conclude, let’s look at some situations where the evil of permissions can be necessary. If it is truly the case that the continued profitability of your company (or the security of your country) would be jeopardized if certain source code were leaked to the general public, you may want to lock access down to a subset of your firm. Using permissions to protect such secrets becomes more necessary as the organization grows. In a company of 50, it is likely that everyone knows each other and all are known to be trustworthy; in a company of 50,000, not so much. I once worked for a medium-sized financial firm that closely guarded their economic “signal” algorithms that determined how the company would trade based on market conditions. Clearly, if this code were leaked to a competitor, it would have been disastrous, so permissions were logical in that case.
Some firms fall into implementing source control permissions in order to prevent employees from screwing something up accidentally. However, we believe that preventing bad check-ins isn’t worth the trouble of using permissions, because the great thing about source control is that you can always revert a bad check-in. At one firm, a new employee managed to delete a sizable chunk of our subversion repository on his first day of work. After a little bit of panic on my part, we quickly identified the issue and reverted the change. No harm was done, and that new employee learned a valuable lesson about the difference between deleting files from a working copy and deleting them from the server.
In conclusion, we feel that it is important that your default stance regarding source control permissions should be “just say no”. The “need to know” model of bestowing permissions only when there is a demonstrated need is harmful because it hampers collaboration and efficiency while breeding distrust. If you believe permissions are necessary, make sure the code you wish to protect really is critical and would compromise your organization if someone outside got hold of it. As always, it is critical to weigh the cost against the benefit.
