Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
2  
I am in that same process (large financial company, 100K employees...): see stackoverflow.com/questions/3597747/… –  VonC Mar 23 '11 at 12:32
3  
You can start with having an internal git repository. You might convince that git is nice, but never, ever get allowed to put code "outside". –  user1249 Mar 23 '11 at 12:47
    
@VonC: thanks for the other question. Others: Thanks for all the great answers/comments so far. I'd like to stick with the question though, specifically around GitHub because I think it's such a great UI and takes some of the "technical pain" away from git –  macca1 Mar 23 '11 at 17:35
1  
GitHub now offers GitHub Enterprise which allows you to host GitHub on your private network, but be prepared to shell out some dough. –  M. Dudley Sep 19 '12 at 12:39

3 Answers 3

up vote 16 down vote accepted

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.

share|improve this answer
1  
+1: Even if the arguments posited here weren't valid, I'd +1 it for creative usage of the word "fief". –  Joel Etherton Mar 23 '11 at 13:35
1  
I just wanted to present the way large corporations see things. No-one pretends they are all valid, but you'll have to have an answer for them. –  Berin Loritsch Mar 23 '11 at 13:48
1  
I don't disagree on any of these points. They may not be all valid for every organization, but they're each is valid for many organizations. –  Joel Etherton Mar 23 '11 at 15:10

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.

share|improve this answer

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.

share|improve this answer
    
Agree on centralized repository preference. As to Git-SVN interop: GitHub now provides SVN access to Git repository; and company-hosted repositories may benefit from tools like SubGit. –  vadishev Dec 19 '12 at 23:19

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.