Why should large financial/insurance companies use git and/or github

Question

I work for a large enterprise (30K employees) in the financial/insurance industry. While "IT" isn't our main focus, let's be honest, these are information driven industries and the companies with the better technological advantage seem to get ahead faster.

There are many software development teams at my company. They are all over the map with version control, let alone languages/frameworks used. Some don't use any (I know), some use PVCS, some use VSS, and the most enlightened use SVN.

I want to bring git to my enterprise. More specifically, I want to bring GitHub (private repositories). I know the right people to talk to about this, but let's be honest again, drastic moves like this usually get shot down in the large enterprise setting because of vague security concerns or the fact that none of our competitors are using it (and I can only cite jQuery, Ruby on Rails, Facebook, etc as references).

So my question is this. What are the most compelling reasons of why a large enterprise should slowly and deliberately make the switch from PVCS/VSS/SVN to a hosted git solution like GitHub (private repo). Of course, part of my plan involves a POC for a non-essential development project.

Answer 1

There's a few things I might be concerned with, as a disinterested third party. So let me toss some questions at you that you'd better be prepared to answer (to your IT department):

• Any version control is better than none. We have plenty to choose from, what's wrong with those?
• Distributed version control? What's that? How do we control that?
• What does it cost? Not just the software, but the servers, licenses, maintenance, etc.
• I don't trust GitHub, or any outsourced hosting. We need to do everything in-house. Why can't we set up our own server?
• Can we run it on Windows? We have to keep it on our current baseline, you know.
• How do we secure the thing? SVN we get, but this scares me.

These are the very first questions that will come up. As to VSS and PVCS you can probably come up with a bunch of reasonably good arguments (like VSS corrupting version history). SVN will be a bit more difficult. I highly recommend focusing on the merge capabilities of GIT, and also recommend keeping an open mind about Mercurial. Every argument for GIT is also an argument for Mercurial--and Mercurial has more mature Windows support.

Security is of paramount importance to financial and government institutions. They will be extremely resistant to externally hosted resources. From a risk management perspective, consider what could happen if someone hacked GitHub and stole the source code, or discovered the security vulnerability documented in the issue tracker. That would be devastating to the company. From a pure management perspective, if the company is legally required to pay you for every hour you work, how can they monitor whether you are working from home when the resources are outside their VPN network? On another note, how can they prevent you from performing some corporate espionage when all the resources are available from outside the company? These are the IT and management arguments against outsourcing the hosting. A large company has to look at things this way. For a small company, you look at the bottom line and how much it would cost to put all those services in place.

It's actually cheaper for the large company to do it in house. They already have the IT resources, they just need to shuffle the responsibilities a bit. And if the solution largely takes care of itself with only periodic maintenance needed (backups and user management), all the more reason to keep it inside corporate doors.

As to Windows hosting, that's an organization by organization issue. Several companies have swallowed the Windows koolaid. Others have swallowed the Linux koolaid. Others consider it on a case by case basis. You'll have to play by the rules the IT department has set for your organization. As long as your solution can be hosted on either, you are golden.

Finally, in such a large organization there are guaranteed to be fiefs all wanting to do things their way. They all have convincing arguments why they chose VSS, PVCS, SVN, or what have you. To IT they are all the same. The only way to consolidate within an organization that large is to have the order come by fiat from above. Such orders are always met with resistance, and it is probably not something your company wants to do unless there are obvious Total Cost of Ownership (TCO) benefits to having a standardized version control system.

Answer 2

I also work at a financial/insurance enterprise (though not as large as the one you're currently working for). We also have multiple development teams, and while the enterprise has chosen specifically microsoft products to develop in there is still no master architecture, language or source control. We are all using .Net, but we have multiple projects in different versions of the framework and in different languages. Some projects use VSS others TFS. We have a new higher level architect as QA manager now and he has spear-headed a more enterprise transition from our hodge-podge bug tracking, source control, framework usage to a more universal implementation of TFS for all of it. This is only made possible by the fact that he is a) extremely experienced in the nature of the software, b) highly placed within the company and capable of influence through both guile and position, and c) not directly affiliated with one particular software team.

In addressing this within your own organization, you have to consider some things first:

1. Why are you so enamored with GitHub as the answer? Are you looking for common source control or are you looking for a reason to implement something you are comfortable with? I don't know the answer (and frankly don't care), but this is a question that will come up when you start nosing around in other people's business.
2. Are you currently affiliated with one of these software teams? If yes, you may need to find an unaffiliated, well-positioned individual to champion the concept. Otherwise other development teams may just feel you are attempting to imprint your thinking on them. This will make them even more resistant to the concept since they already have something that works (in their opinion).
3. Have you made any outreach to individuals on other teams to gain buy-in to the concept? Are other developers having similar opinions or concerns? Another avenue to getting it accomplished is to build a critical mass following among the people who perform the work. As more people begin to demand common source repository, management will have to take notice.
4. Are you familiar enough with the code/processes/requirements of the other teams enough to say that GitHub will (or won't) work for them?

As for your final (or actual?) question, the only true compelling reason in the long run from the perspective of the business managers is that it saves money. These savings could be in the form of reduced downtime, increased code security, increased developer productivity, increased code-base redundancy (for backup), etc, et al. What you will ultimately need to do is convince the individuals who write checks for all of this that the time, effort and money spent transitioning to such a model will be well worth it in the end as a return on their investment. You will also need to show that the future support for that same model will be there when "slowly and deliberately" finally happen. What happens when support for the software is no longer available (for whatever reason) or in a hosted model what happens if the company goes belly up and shutters its doors?

There is a lot that goes into such an enterprise change in doctrine, so it will take a lot of grassroots style enthusiasm and you'll definitely need someone at the VP level to champion the concept. A manager might work, but an executive will have a lot more authority to imprint concepts on other groups.

Answer 3

Such companies will want to have their repositories centralized. SVN, VSS ad PVCS have one thing in common -- they are all client-server architecture. Git is designed as distributed VCS, and by nature is decentralized.

GitHub -- even more problematic. It's an external service. Source code in external service is something that management will most likely never accept.

There is however solution that could keep both sides satisfied. Git has git-svn command. Basically you'd have SVN repository, but some of developers may choose to have their own local GIT repo, and synchronize it with the centralized SVN repo. Good alternative to private branches or sending around uncommited patches. Good how-to for git-svn integration.

Answer 4

Several of these answers are significantly out of date in regards to comments about GitHub and security because of changes at GitHub since they were posted.

• GitHub does not force you to be externally hosted
• The FREE version of GitHub is what puts this restriction in place.
• There is an Enterprise Version of GitHub available for for internal hosting. https://enterprise.github.com/home . It is not free and costs $ of course

The company I work at just started using it and we had the EXACT same concerns because our code is a trade secret, we are in the finance sector. That aside there are other ways to use GIT that dont involve GitHub that are similar, redmine, gitosis, etc...

Regarding the "who's using it" question: PayPal, Etsy, rackspace, vimeo, SAP, NASA's JPL, Linux Kernel

Compelling technical reasons are too many to list. The only thing worth focusing on here is the high level bigger enterprise issues which the other answers point out. The biggest one I can think of is consistency, uniformity, clear auditing, simplicity of auditing. Though solving a treasure trove of problems with many of these other VCS systems is a big one.

There are reductions in duplicated effort to all of those departments that have to write different wacky scripts to integrate between the different systems, to audit them and report on them and control them.

• Everytime I've had to use SVN in a paranoid environment like a trading firm, the absurd 'compliance' and 'security' hooks were so extremely detrimental to performance.

Since I glossed over the technical usage issues from a dev prospective, I'll say this. With 15+ years of total usage I've used CVS, SVN, CMVC, clearcase, perforce, and other systems in a professional setting along with GIT. If someone wanted me to use something other than GIT ( with the exception perhaps of bzr, mercurial, perforce and clearcase ( depending on the setup of the last two ) ) I would immediately know my time is better spent elsewhere. I was nearly at that conclusion ( albeit extending a slight allowance to CVS and SVN ) back in 2009. I was so fed up with the short falls of how SVN was used at my workplace I started using GIT as my SVN client in early 2010 before helping to convince us to change over to GIT.