Should we be hosting code online?

Question

We're looking for a good source control and project management solution at my workplace and I've suggested creating a GitHub organization and private repositories. I love GitHub for many reasons, but this isn't about GitHub (in fact my colleagues are going to present points in favor of competing platforms) - it's about storing our private code online.

I'm trying to understand whether this is a good idea or not. It definitely seems advantageous because it removes need for server costs (at least directly) and also makes it easier to search code (everything is online).

However our team is undecided and leads me to my question, what should we be considering in order to make this decision?

Answer 1

As a pro,

If your company's office burns down, the code is still on the server.

If your company's office doesn't burn down, but the server on which your git repository is located DOES, then you still have a local copy.

If you host your repository on your server in your company's office building (like you would with a Network shared drive...?), then if the company's office burns down, you lose both.

Of course, you still need backups as usual...

Feel free to replace "burns down" with "gets infected with ransomware".

Basically, availability is up.

As a con,

You'd have to share your files with the 3rd party that will host your code. If you've got really big company secrets, this might not be allowed. For instance, if you have a database containing personal info from european citizens, you might not be allowed to host your code on a third party from the USA - because they'd be subject to US law and thus couldn't be relied upon to uphold EU privacy laws. Even if it is not a legal issue, you should be aware that the third party could be bribed into giving your private files away. This would likely be really bad for the third party (huge reputation penalty), but it could happen.

Basically, confidentiality is down.

---

If you are okay with trading confidentiality for availability, then hosting your private code online with a third party is a good idea. Otherwise, don't. You could explain the trade-offs to allow your boss to make an intelligent decision - but you might hear "no". That's what can happen if you give someone a decision. If your boss says no, then that's that. I don't think forcibly convincing your boss is a very good idea.

Answer 2

Obviously its a question of trust in the provider and how much you value your source code.

However, I thinks its clear that, at least in the past, people over valued their source code.

• For 'business process automation' products; where an in house team creates websites and other software specifically for the needs of the business. The value of that software to other people is generally very low.

• For saleable software; it's the binary you are selling, and that can be copied and hacked without access to the source code.

Secondly: You should also consider whether storing.your code with a third party actually increase your exposure above its current level. In many cases it will not

• For example; if your product is a website with no backend code, your code is already public.
• If your compiled code is distributed it can be decompiled.
• If your code is a website or service and you are hosting it with a third party. Then the third party can decompile your code.
• If you store your backups with a third party, they have access to your code.

In short, most modern businesses will trust a variety of third parties with their day to day business; even things which are vital and unique to them.

Answer 3

A part of this decision process could be a little testing, trial and error. Take a small project and have a few members try out some of the different sites. This should cover the usability by the team, but there are other considerations.

1. Current Infrastructure - Some companies already have servers, internet connections, VPN, and people on staff with the skills to host servers, so some of the costs and concerns can be absorbed much more easily. A startup may be more inclined to use something like Github because they don't have to make these types of investments and can get up and running sooner.
2. Budget - Many aspects of #1 will fall under here, but there can be other solutions with a hefty price tag. Some companies can justify the costs. Obviously with a low budget, many options are eliminated.
3. Team Distribution - When everyone works out of the same office during the same hours, you may not need github. If your file server isn't too burdened, just put Git on it.
4. Security - You can probably find many sites that are secure, but perceptions of security for some clients are more important. Having your own ironclad network may be the right thing to gain their confidence. Security badges, retinal scanners and armed guards just screams security to some clients.
5. Training - There's more to it than just how to use the app, there are the rules and procedures that your company/team wants to put in place. Having an idea of how you want to do things can drive what tools to use. Attracting additional team members gets a little easier if they like the way you do things.

Start working through the entire process of coding and delivering. The more people that are involved in this process the better. You don't want to adopt a source control platform based on certain criteria only to have someone in management change everything. "This distributed agile thing isn't working, so we'll need everyone to start working from the office at 8-7 starting Monday, Okay."

Answer 4

I'm not necessarily saying you shouldn't host your company's repository in the cloud, but I've personally experienced some disadvantages and pain with cloud hosting.

How fast and reliable is your internet connection?

To me, that is the single biggest consideration. For example, my company is located in a pretty rural area. While our intra-net speeds are blazing fast, our inter-net speeds are slow at best, downright flakey at worst.

Depending on which VCS you're using, some of the pain can be mitigated. Distributed version control systems, like Git, aren't so bad because you can still work locally. You can even init a new repo on a network drive if you really need to share some code with a co-worker. In comparison, you can't really do either of those things with Team Foundation (despite the whole local workspace thing).

But that's just the code. There's a whole lot more to your cloud hosted repository than just the code. What about your work items (features/bug list)? What about your documentation (wiki)? What about your continuous integration build? All of these things will likely also be hosted in the cloud along side your code. If your internet connection goes down, how will you work without these things?

Gitlab provides a free on premise version that will likely provide more than your team needs. I highly recommend an on premise installation. It will reduce risks considerably.

Answer 5

What should we be considering in order to make this decision?

You should be considering the downsides. I (along with others) successfully encouraged my current employer to stop hosting the company's crown intellectual property jewels on a private github repo. Don't take me wrong; github is fantastic for open source software.

In the case of closed source software, have you had github.com (or some alternative) sign a nondisclosure agreement (NDA) not to release your source code to the world? Good luck with that!

In my opinion, its outright crazy to disclose ones crown intellectual property jewels to some other entity until that other entity has signed an NDA with you. You are planning on using a service such as github that does not sign NDAs with their clients. They instead offer a vague promise in the form of a very long EULA (end user license agreement).

Github themselves realizes that this can be a significant issue, and as a result they offer Github Enterprise as a mechanism for hosting source code (and other private stuff) on ones own server.