14

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?

Mark McDonald
  • 241
  • 1
  • 4
  • 4
    Why would you want to keep it from them? – Marjan Venema Feb 14 '12 at 07:49
  • Keeping code "secret" from the rest of the organization may be illegal. It's often a "capital asset" and as such doesn't belong to the developers in any sense of the word. Keeping it obscure, or controlled or hidden may not be feasible. As intellectual property, it's subject to copyright and trade secret protection and often **must** be disclosed internally. How can you suggest otherwise? – S.Lott Feb 14 '12 at 10:45
  • 1
    Can you cite law to back that up? – Blrfl Feb 14 '12 at 11:25
  • On point 1, even if you remove the password then a user with read access to the repository can still get the prior revision number of that file, at least it works that way in Subversion. – maple_shaft Feb 14 '12 at 11:56
  • 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 Feb 14 '12 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 Feb 14 '12 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 Feb 14 '12 at 13:24
  • 1
    @JanHudec: "Should we open up our code for our non-development staff to be able to read?" sure sounds like developers making the decision. It calls out for clarification and explanation. It may be clear to you what's going on, but it's not clear to me why this question is asked in this way. Which is why I'm simply asking for clarification. – S.Lott Feb 14 '12 at 13:35
  • @Birfl: Generally Accepted Accounting Practices have the force of law. Capital budgets spent on software development create capital assets. How else can it work? – S.Lott Feb 14 '12 at 15:00
  • I am a development manager and I have set up our repository to be open to the whole business - the counter-argument is usually around security concerns, though in our specific case we do not have anything we'd consider a "competitive advantage" in our code IP. We still have sensible barriers preventing write access & bulk extraction but it's a very good point that it's not a decision for developers. The catch is that the words "risk" or "security" elicit a defensive reaction unless you understand the scope - which only developers can do. – Mark McDonald Feb 15 '12 at 01:07

4 Answers4

8

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.

Péter Török
  • 46,427
  • 16
  • 160
  • 185
5

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...

sleske
  • 10,095
  • 3
  • 29
  • 44
4

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

MalsR
  • 390
  • 4
  • 12
3

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!

Dipan Mehta
  • 10,542
  • 2
  • 33
  • 67
  • 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? – Péter Török Feb 14 '12 at 08: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 Feb 14 '12 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. – Péter Török Feb 14 '12 at 15:16