Is it advisable to ask employees to create 'work' GitHub accounts?

Question

I've moved all our company Git repositories to GitHub and now I want to add employees to the projects. Since most employees already have personal GitHub accounts, I'm wondering whether I should ask them to create a work GitHub account. The reason that I'm thinking of doing this is to decrease the chances of unauthorized access to our code base since their personal accounts may be well publicized through their personal activity on the site, increasing chances of targeted attacks. Furthermore, if their personal account is ever compromised it won't mean the whole company code is accessible to the hijacker. Since this will bring the burden of maintaining two accounts for the employees I'm wondering whether it is the correct approach and whether it even makes sense. I would love to hear your opinions on this.

Update Thanks for all the useful insights. I won't set an answer as accepted because of the subjective nature of the question/answers and since I took the best points from several different answers.

I have decided to go forward this way: I will remind employees that work-related GitHub e-mail notifications will have to be sent to their work e-mail accounts for practical reasons. Therefore it would make more sense to create work GitHub accounts. If they are willing to use their personal GitHub accounts and connect it to their work e-mail accounts then that's fine. In any case, employees will have to agree in written form to a number of conditions tied to using GitHub. These are related to account security: choosing a secure password using a secure random password generator that is not used with any other account, not accessing GitHub through computers not owned or administered by them, etc. At the end of the day employees will have to decide themselves whether a work account makes more sense for them or not.

Answer 1

If there was a benefit, it would merely be painful. But nothing sucks worse than painful and pointless. Just have the single personal account. Two reasons:

• Github has incredibly good access control in their organizations. If an employee leaves, you can instantly remove their access. If they had a company account, you'd have to reclaim the account somehow to get the stated benefits. In practice, you'd probably just remove the account access, same as if they had a personal account.

• Having more than one account is painful. Logging in and logging out between accounts hurts, and adding comments, following, and all the social stuff when you use different accounts.

References: I make a CI server that has GitHub integration, so I have about a lot of test accounts, and I've talked to customers with all sorts of weird configurations, including separate work accounts and personal accounts. It always leads to trouble.

Answer 2

Is your company's code in public or private repositories? If they (or at least some) are public, and you allowed your employees to use their own GitHub accounts, then it would be an incentive for them to write good code. Their name would literally be attached to it, publicly. However, I'll assume that all of your repositories are private.

Overall, it sounds like you would prefer that your employee's accounts to not be publicly visible throughout GitHub. Unfortunately, they make money by selling GitHub Enterprise so I imagine that's one reason why they don't allow you to create private accounts for organizations. In either case, having (essentially) locked-down work accounts would be really counter-intuitive after choosing a very social site to host your repositories.

Lets imagine that you did set up work accounts for your employees. Would you enforce any restrictions on how they can use those accounts? Would you allow them to contribute code to non-work projects for work purposes? If so, then their accounts would become publicly visible, bringing you back to your initial concern. You could just allow them to make the contributions with their personal accounts, but then you're creating a logistical pain point for them. Personally, I would encourage my employees to contribute code to other projects as themselves. This not only gives them a confidence boost, it is allowing them to gain valuable experience and to build their credibility.

In any case, I don't think it's worth the effort to have work accounts. The GitHub interface allows you to easily control who has access to what, so removing access is simple either way. I also don't think that having separate accounts really "draws a line" between personal and work projects anymore than the GitHub interface already does.

Also, keep in mind how you plan on dealing with this as your company grows. Are the policies you set in place now going to be scalable from a management stand point? Managing 5 accounts right now might be fine, but what happens when you grow to 20 or 50? But once you get to that point, maybe GitHub Enterprise will be an approachable solution. In that case I would consider figuring out if GitHub accounts can be migrated to GitHub Enterprise installs. If so, I can see that being a one positive reason to have work accounts.

Answer 3

Not out of the question, and actually a pretty good idea.

Regrettable as it may be, you need to plan on your employees leaving the organization at some point in the company's life. How are you going to extricate their personal accounts from the company's repository at that point in time?

What are you going to do if the employee leaves on bad terms? In an ideal world, everything will remain professional and there won't be any animosity between the firm and the ex-employee. You would be prudent to plan for less-than-ideal circumstances.

While maintaining two accounts is a pain, your employees should welcome the opportunity. It provides a cleaner line between what is theirs and what is the company's.

Edit: Of concern here is providing a clear separation between the employee's personal contributions to projects X, Y, Z, etc... and their paid work on your company's product. Using a separate work account helps provide the delineation necessary to identify who owns what intellectual property and associated copyright.

For example, if an employee uses their personal account and contributes to both the company and Project X, how do you identify what role the employee was in at those points in time? Was the contribution to X on behalf of your company or their own personal discretion? Does the employee or the company own the copyright to that work given to X? For that matter, if you allow outside contributions to your company's work, how do you distinguish if the employee was an employee or if it was a voluntary contribution?

In a broader sense, say you have an employee who builds up a reputation acting on the company's behalf by contributing to other projects. When that employee leaves, how do you indicate that the personal user account is no longer associated with your firm? Serious brand issues can occur without clean delineation of what a particular account is for.

It's pretty easy to fall down a rabbit trail of ownership, brand, and copyright concerns when you start thinking through the potential scenarios. Using separate work accounts helps remove some of this ambiguity. The company needs to be able to lay claim to contributions made in its name.

It's not about the technical aspects of separating the user account out, it's the legal questions that can trip you up.

Note that this may be a moot point if your company's products are all released as open source under permissive licensing and / or you're not worried at all about potential branding issues.
(Hat tip to Paul Biggar for requesting this edit)

Answer 4

Since everyone seems to agree on the lack of employer’s need to separate both, here is my short experience having tried using my personal account on professional projects and open-source contributions made in the context of work.

Just to make the context complete: I was not asked anything regarding accounts, actually GitHub is unknown to most people at my workplace. I simply was able to get green lights to open-source the project I will be working on, and went with the least amount of work, i.e. using my personal account.

From an employee’s point of view, one thing I really hate: getting notifications on my personal email for work stuff.

From that observation, I went to realize it’s a blatant breaking of the professional / personal barrier: if I want to contribute to a project during my off time, I still get all updates from my work projects… And it can bring confusion for external contributors, who might contact you without knowing you’re off that project.

Then of course, there’s a balance to find with the fact that your personal reputation can gain from your work contributions. But then again, it might the opposite if your name gets associated with a poor project…

In the end, as the question is asked from the employer’s point of view, and considering all other answers: I would say there’s probably not much point in enforcing using work-dedicated accounts. But you shouldn't forbid it, so that employees who prefer to raise the personal barrier may do so, and perhaps hint about those risks…?

---

As a side note, regarding security, since there seems to be some easy dismissal in other answers:

Of course, a “work” account would not be any more or less secure than a “personal” account regarding passwords. But when you're using GitHub, you're allowed to push with an SSH key. And that key usually lies in one’s session… So, the personal account can compromise all work repositories with a simple personal computer steal (without password knowledge), whereas a dedicated work account would probably have its key lie only on the work machine, making it more physically secure (hopefully).

Answer 5

I'd vote "No". It's quite a bit of hassle for your developers and gives you security through obscurity: if someone's actively targeting your developers there's plenty of other attack vectors for someone to get your code.

Plus, as a startup unless you have a lot of magical secret-sauce-type algorithms at play someone getting your code would be embarrassing, and terrible, and obnoxious, but shouldn't result in a significant competitive advantage (who could legally use your code?) or cause you to go out of business.

Such a low order probability vs. developer productivity? I'd take developer productivity, but that's my calculus. :)

Answer 6

I would say that should be a choice left up to the employee. One thing I would say is do not force them to use their personal github account if they don't want to. I was at a company that used GitHub and while it was not a requirement, I personally wanted to create a separate account. The main reason was to protect my person projects. I didn't want the company to try to say one of my personal projects was their's because it was under the same github account used for their comapny projects (not sure if that would ever hold up in court however I don't have much faith in the legal system when it comes to things like this). I think having that clean separate can be a good thing.

Answer 7

We are doing it in our company. I don't want to start a discussion "what is safer, github or a server under your table that everyone has root access, not sure if the backup is working, etc". Our approach was:

• every developer, must create a new account, unrelated with his personal github account
• it should use the company email.
• It should be compliant with our security rules (login name and password requirement).
• They cannot show/have any public activity.
• It's company property. Not his/her account.
• All accounts are connected with a company, random name as well. No public activity as well.

Answer 8

I recognize this Q&A is a few years old, so maybe this wasn't available before, but they specifically state in Differences between user and organization accounts that:

It may be tempting to have more than one user account, such as for personal use and business use, but you only need one account.

GitHub has built good tools to turn on/off notifications by repository and more so it seems that combining the personal/work makes the most sense.

Answer 9

People are yet to trust the cloud based source servers. Github boasts lot of new age web companies signed up with them but the real fact is that, most people has their own servers for maintaining the source code. In my experience, most of them uses either Clear-case or SVN. Git is is yet to be adapted in an enterprise environment. Even the corporate mail servers aren't really appreciated outside the company's premises.