Where I work, we have a lot of developers and an awful lot of code running our proprietary applications used by staff & customers alike.

We also have a lot of smart support staff that like to understand the inner workings of our systems to better support our customers, and perhaps even submit a patch from time to time.

Should we open up our code for our non-development staff to be able to read? What factors should we take into account when making this decision? I have come across a bunch of arguments and counter-arguments each way & would like to make a decision based on the experience of others as well as well-understood risks.

Some arguments thus far:

  • Passwords in VCS are exposed (solution: get rid of the passwords - they shouldn't be there to begin with)
  • Code is open to white-box security attacks (counter-argument: this only keeps out the honest/lazy attackers)
  • Support staff can ask developers "how" things work (counter: teach a man to fish, etc)

Does anyone open their code to staff at their organisation? Has it caused any problems?

  • 4
    Why would you want to keep it from them? Commented Feb 14, 2012 at 7:49
  • 1
    Can you cite law to back that up?
    – Blrfl
    Commented Feb 14, 2012 at 11:25
  • 3
    @S.Lott: It is a "capital asset" and as such the company has right to control which employees may and may not access it. Usually the company will want to limit the number of employees who have the access to limit the number of people who can be bribed or forced to give the asset away or abuse the asset when they get in disagreement with the company. So in most cases it must not be disclosed internally (to everybody; it must be disclosed to management).
    – Jan Hudec
    Commented Feb 14, 2012 at 12:53
  • 1
    @JanHudec: "must be disclosed to management"; "the company has right to control which employees may and may not access it." Perfect. It's not up to developers to make these decisions. Hence my request for clarification. How can this question come up? Why are developers making this decision?
    – S.Lott
    Commented Feb 14, 2012 at 12:55
  • 1
    @S.Lott: I don't see the question imply that it's developers who are making this decision. Management has the last word, but somebody has to gather arguments for them.
    – Jan Hudec
    Commented Feb 14, 2012 at 13:24

4 Answers 4


I don't think there is a general answer to this. Organisations differ wildly in their size, geographical spread, company culture, copyright policies, kind of software being developed, etc. etc. etc.

E.g. for a company developing commodity / infrastructure type of software, it may be easy to open up the source code, even to open source it, as Cisco did some years ago with their printer driver software (IIRC).

For a company developing some rare proprietary software, potentially including special algorithms or stuff which gives them competitive advantage over their competition, I can very well understand if they are striving to keep their code secret. E.g. AFAIK Google very strictly limits the number of people who are granted access their core search algorithm implementation.

Also a multinational organisation is nowadays spread over many countries, time zones and cultures, and for security reasons, they probably segment their intranet and use firewalls to control traffic between different segments / domains. So making an SCM repo accssible to "the whole company" may in fact require a lot of extra work for sysadmins, and extra security risk. While it doesn't usually bring any benefit in general, as employers working on a different continent on totally different stuff probably don't even know about our project over here, much less to contribute to it positively.

So if it makes sense within your department, and/or for people associated with the project in some way, why not. But in general, just for the sake of "openness", I am not quite sure it is worth it.

One final note: even when support people are smart and eager to contribute patches, I would say their contributions should always be reviewed by a developer before getting integrated into the system.


In most organizations I have worked in, the code repository was open to all developers.

In some it was also used to store documents (such as specs and requirements) to version them alongside the software. In that case most other employees also had access. Where the repo was only used for code, non-devs usually did not have access - but I never heard anyone complain, so it was probably no big deal either way.

I would recommmend as much openness as possible - so if people want access, give it to them unless there is an obvious problem. But that really a question of the culture of the organization...


I do share a general/pragmatic view on this and may also depend on the nature of work/organisation as well. But I do believe that the code base should be open to all (will also show openess and trust within the organisation also).

I also work in a similar setup as you mentioned where we have a suppor/helpdesk team which deals with customer requests. However certain complex areas of the system they require addtional help. In my case the code base is open to all we have not encountered any problems.

  • I think by opening up the code base other support team members who are keen can also checkout the code base and get familiar with the business rules/area they are interested in or need to find answers (and possibly improve their technical understanding and looking at something different than the monotonous routine if time permits ;) ). This might also prove useful when support team members get customer issues and logs and would be able to point/assist on possible areas of the code where this happens by looking at the stacktrace e.g. (obviously will depend on the problem etc). This will also save time with the developer but depending on the problem of course.

Also having an up to date documentation/wiki of the product which contains all the business rules/decisions will also help. But of course you need to make sure that the wiki is constantly updated to relfect new enhancements and/or bug fixes (where behaviour changes). My honest thoughts


In general, from the organization point of view - people come and go; the project (or product) needs to continue to evolve. Hence, in most organization, there is usually an Open to all repositories for maintaining code.

Usually there are access rights etc. to prevent unnoticed unauthorized access (to prevent code theft etc.) but most higher ups are not really barred on this. Within an organization, one must trust people (enough) that you can trust them with code. Hiding code from employees (or colleague) is a great de-motivating factor.

In our organization, even when people don't really contribute to code - they have direct access to code that helps because they attempt to fight/fix the problems at field (with ownership) rather than dump things back to developer and go to sleep!

  • 3
    "in most organization, there is usually an Open to all repositories for maintaining code." - I have my doubts about it. Can you quote any data to back this claim? Also, how is not being able to access project Foo's repo supposed to demotivate me? Commented Feb 14, 2012 at 8:24
  • @PéterTörök - I suspect that what Dipan means is that most organisations he/she has experience of, code is open to all. That would concur with my own experience over 20 years in various sizes of organisation. Even while working in the defence industry there was surprisingly little code which was only on the secure network.
    – Mark Booth
    Commented Feb 14, 2012 at 11:56
  • @Mark, in that sense I agree. In most of my workplaces so far, I haven't seen much effort put into devising an access policy for SCM repos, so quite often they are de facto accessible to anyone who happens to come by. But this is the result of neglect, not of anyone's conscious decision. Commented Feb 14, 2012 at 15:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.