What considerations go in when a company decides to restrict codebase access to respective teams? I cannot see any code another team is working on. How common is this practice? What can one gauge about the company culture if this is the case?
Ask HN: Is your company's code open to all employees
1–9 of 9 posts
Re: Ask HN: Is your company's code open to all employees
#2Where I am at now we can see all the repos for all projects in the company regardless of team. The only pre-req is to be added to the company's github organization. We have a lot of cross team work, though, and I have worked on a few services that aren't related to my team and it would be a pain to have to request access.
At my last job, however, everything was locked down and you had to request access to just about every repo. It was a pain in the ass and there was no real valid reason to do so.
Re: Ask HN: Is your company's code open to all employees
#3Where I am at now we can see all the repos for all projects in the company regardless of team. The only pre-req is to be added to the company's github organization. We have a lot of cross team work, though, and I have worked on a few services that aren't related to my team and it would be a pain to have to request access. At my last job, however, everything was locked down and you had to request access to just about…
> no real valid reason to do so
I'm struggling to find a reason within my org as well.
Re: Ask HN: Is your company's code open to all employees
#4My experience:
Went to work at a startup transitioning to the next stage. When hired I was told everything is available to all employees, 'there are no secrets here'.
I quickly found that most was locked away...and then noticed the same in many places. That and what comes with it led to my leaving.
When I left I went back for a pseudo-exit interview with the CEO and he actually told me he had been screwing my team for the past year.
In essence what I found was mostly lies. The lies began in interview (everything open to everyone) and continued until I left (continuing to hire based on things that don't exist at the company...like HR).
My take: if you are told one thing and find it different, look around at more things.
Re: Ask HN: Is your company's code open to all employees
#5Where I am at now we can see all the repos for all projects in the company regardless of team. The only pre-req is to be added to the company's github organization. We have a lot of cross team work, though, and I have worked on a few services that aren't related to my team and it would be a pain to have to request access. At my last job, however, everything was locked down and you had to request access to just about…
> no real valid reason to do so I'm struggling to find a reason within my org as well.
IP theft would be one reason. If a computer is stolen which has source code that could be a problem. That said, most companies just deal with that risk or their business is not so dependent on source code but services and support instead.
Re: Ask HN: Is your company's code open to all employees
#6Where I am at now we can see all the repos for all projects in the company regardless of team. The only pre-req is to be added to the company's github organization. We have a lot of cross team work, though, and I have worked on a few services that aren't related to my team and it would be a pain to have to request access. At my last job, however, everything was locked down and you had to request access to just about…
Source code is important intellectual property and trade secret.
In general it is simply good practice to only make this sort of information available to employees who need it to carry out their jobs. It is not a problem because there is usually no reason to study the code of another product/module/team/whatever, and if there is a reason then access can be granted, and is granted.
If your side needs to interact with another team's code and you cannot see their source code it at least forces everyone to have properly documented APIs.
Re: Ask HN: Is your company's code open to all employees
#7Earlier quoted context omitted.
> no real valid reason to do so I'm struggling to find a reason within my org as well.
IP theft would be one reason. If a computer is stolen which has source code that could be a problem. That said, most companies just deal with that risk or their business is not so dependent on source code but services and support instead.
> That said, most companies just deal with that risk
They actually don't, sadly. Most companies limit the risk using non-competes.
It's very hard to secure code. If someone wants to steal it, they can usually figure it out.
It's much easier to limit their legal ability to profit from stolen code. Most companies don't have IP that's very valuable on the black market. If you stole Zoom's compression algo, for example, it would be hard to profit without openly starting a new company and violating your non-compete.
Re: Ask HN: Is your company's code open to all employees
#8Where I am at now we can see all the repos for all projects in the company regardless of team. The only pre-req is to be added to the company's github organization. We have a lot of cross team work, though, and I have worked on a few services that aren't related to my team and it would be a pain to have to request access. At my last job, however, everything was locked down and you had to request access to just about…
Source code is important intellectual property and trade secret. In general it is simply good practice to only make this sort of information available to employees who need it to carry out their jobs. It is not a problem because there is usually no reason to study the code of another product/module/team/whatever, and if there is a reason then access can be granted, and is granted. If your side needs to interact with…
Assuming your developers have malicious intent is a bit strange for me personally. But I get that some companies may have this structure in place.
Re: Ask HN: Is your company's code open to all employees
#9Earlier quoted context omitted.
Source code is important intellectual property and trade secret. In general it is simply good practice to only make this sort of information available to employees who need it to carry out their jobs. It is not a problem because there is usually no reason to study the code of another product/module/team/whatever, and if there is a reason then access can be granted, and is granted. If your side needs to interact with…
Assuming your developers have malicious intent is a bit strange for me personally. But I get that some companies may have this structure in place.
This does not assume anything. That's the point.