Reasons against using "Git" in the enterprise.

Question

I was recently using a commercial centrally controlled version control system in a large company with about 100 different subsystems written in different operating systems and languages, and I have noticed that several developers use either git or mercurial on their pet projects, but not for their work systems. I personally am more familiar with git but was wondering what reasons are their to "Not" use Git in the enterprise, apart from the fact that the choice has already been made (we have many problems with our centrally controlled version system, so I can't say it is brilliant).

Answer 1

If I had to guess, I'd say it's because enterprise has always been wary about using "free" things. Mostly because they lack a stable support system (generally, support comes in the form of StackOverflow.com or forums when it comes to open-source), but there's also a pervasive mentality of "you get what you pay for." They figure if it doesn't cost them a buttload in licensing fees, it must be worth as much in terms of real usability.

Of course, we, as tech experts, know that's a load.

Answer 2

From my experience it is the fear of change. Source code management is a central piece of infrastructure and affects all developers. If the current system doen't hurt too much enterprise IT will actually fight change.

Another reason I've heard quite often is that IDE integration has not yet reached the quality of e.g. CVS or Subversion. Though the argument is true it is becoming increasingly lees an issue.

Answer 3

Some of the many reasons:

• Inertia: There's an enormous number of people out there familiar with centralized systems. You don't have to "retrain" developers if you just don't change.

• Interactions with other tools: Corporate environments are of course big on extra tools like continuous integration, IDEs, fancy issue trackers, and so on. Naturally, there's more support for the established centralized VCSs with those than with the relatively new git and hg.

• Support: When you buy a commercial VCS product, you're not just buying the program, you're buying peace of mind.

Of course, I'm not saying these are good reasons; they're just convincing to people in the position to make this decision. I think it's worth overcoming inertia - it takes work now, but it pays off later. I think the external tools are getting better at supporting git, particularly the open-source ones - they just need plugins. And as for support, we all know there's plenty of less formal support out there on the internet.

Really, there's a common thought in all of these - the free software philosophy just isn't the way corporations do business. Buying a product is established and easy. You pay your money, you get what you need. Management doesn't have to worry. Using a free software product... well, it may be much better, but it's more complex to deal with. It doesn't come in a box.

A clarification: I use the word "free" in the same way those in the free software world do - free as in freedom not as in beer. Hopefully this phrase will get drilled into everyone's heads eventually. Note that I never dealt with the issue of cost here - though I do think that in the case of git, in general it will be ultimately be cheaper than a purchased solution despite the costs of bringing everyone up to speed on it and making sure it fits in with the rest of your process. This isn't a cut-and-dry issue though, and since I think git comes out ahead, there's no sense putting it among the bullets.

Answer 4

This same question can be asked about switching any large infrastructure service with something else. When there are hundreds or thousands of people using something, it had better be broken or the new thing had better offer some compelling features.

Think about switching email systems. Someone is going to have to train all the users, transfer all of the messages, make the switch with minimal downtime and without losing data, and then convince management it isn't going to cause a major disruption to business operations.

In your specific example, converting the source control system for 100 subsystems while retaining history and retraining all of the developers, testers and release engineers, and not impacting their daily productivity, is a huge task. The existing system will have to be really broken.

Answer 5

Git is a version control system with an attitude of collaboration and sharing. There is practically no way you can enforce a specific pattern of access and sharing. If the people who're using git don't want to follow your rules, the tool is not going to help you much.

Although I personally think this kind of organizational behaviour is stupid, I'm sure somewhere someone thinks it's a good idea. Maybe you're concerned that your unruly employees work on the wrong projects, or you're desperate to keep changes out of the code.

Answer 6

I have to disagree with the ideas that Enterprises are afraid of free or that they are slow to change. These may be true, but to dismiss the slow git adoption rate for the Enterprise space to them misses the point of what Enterprise means. Besides, SVN is pretty popular and it's free.

Enterprise is about centralization. You want all your developers to follow the same procedure, get the same code, etc.

Eric Sink is more eloquent on this subject than I could be: http://www.ericsink.com/articles/vcs_trends.html

Answer 7

"Apart from the fact that the choice has already been made"

That part of the statement is actually too important to disregard, because it ties in with the learning curve of any particular tool. Learning, for example, SVN takes a while, and the learning process costs money in the form of developer time. Learning git, in my experience, takes more time, and is made more complex in the absence of simplified interfaces (gittortoise's ongoing development not withstanding). Plus Git has so many tools that it's learning curve could actually be considered more of a learning slope.

The payoff after getting over the curve is great, but the initial requirement is a barrier to adoption.

Answer 8

A significant practical barrier to enterprise adoption, apart from lack of central control and integration as mentioned by Eric, is "ease of use".

If you are used to Subversion, or similar tools such as PVCS, then Git (and DVCS in general) represents a significant learning hill to climb -- both at the conceptual level and the daily workflow. In my (somewhat jaded) experience many enterprise developers are often unwilling to invest the effort in learning a new tool or concepts; and I fear will scupper any attempt to introduce DVCS.

Please prove me wrong