I noticed from various SO questions that some shops ban the usage of open source software, like Subversion for example. What are the reasons for doing this?
EDIT: Just to be sure: I'm not asking about linking to open source libraries but the usage of compiled open source tools, like Subversion, Mozilla or OpenOffice. Something which normally shouldn't be affected by license incompatibilities.
The (government) shop I work at is required to have support contracts for any products that are used.
Open Source isn't banned as a whole, but it is a lot harder to get an Open Source project approved than it is a proprietary product.
Lack of knowledge, fear in a lack of support, ...
OS software is as good or better than any commercial software, it's simply following different business lines and some people is not comfortable with them :(
Definitely lack of customer support. Also, it's harder to blame the tool developer if it crashes, i.e., harder to justify failure.
I share the opinion that it's a wrong line of thinking to ban OS. Sometimes it's by far the best alternative in so many ways.
The GNU licence can give lots of problems, as it is not clear (without expensive legal advice) when a using open source “product” will put all your own source code into the public domain.
It is bad enough for us developers to understand what “linking” etc is – think of the problems a none tactical manager will have. He will lose his job if he gets it wrong, you will get the pain if he always says no to open source.
Hence a blanket ban on Open Source usage is sometimes seen to be less risky.
(I am not saying I agree with the above, but I have had the argument in the past and lost because of the above)
Fear of licenses which, under some circumstances, require that the company ship its own source ("viral licenses"). I've worked at several companies where the OSS licenses had to go through the Legal department first, and others where the answer was simply "no way".
Certain companies restrict the usage of Open-Source to protect it's intellectual property. This is not just limited to GPL licenses but any open source license. If a company uses a specific open-source product and releases a similar, but not connected product and charges for it... it looks somewhat suspicious.
The purchasing manager doesn't get a free lunch when choosing open source.
Many companies also like to have someone to sue when things go bang.
It's not great for us techies, but commercial considerations often bear little resemblance to technical ones.
Things I have seen:
Lack of paid support.
Uneasyness over licensing. AKA - Is it really free for us?
Might not be free tomorrow. Yes, sounds a little interesting....
Whomever is writing it may not be here tomorrow. There's a sense it's easier to walk away from and the company has no recourse.
Waryness over who's to blaim or where to turn when an issue does arise. Aligned with support but I target this thought at the managers and higher, not the technical people. Although, this can be the case even for technical.
It's a foreign idea / model (how can it be free?) which produces for some a trust issue or at least a lack of understanding that makes them uneasy. Even if it's subconscious.
Lack of a track record. No salesman's pitch, etc... to tell them about all their amazingly happy customers.
Lack of Training.
These are some of the things I have seen that can cause agencies to not consider Open Source as an option.
EDIT: My answer is how I have seen people react in Org's. It Doesn't mean these thoughts are factual or well founded.
EDIT #2:
I think this SO question adds a nice angle for our discussion:
http://stackoverflow.com/questions/1396191/what-should-every-developer-know-about-legal-matters.
It think this illustrates an example of #2. AKA - Is it really free? Or can I really use it this way or that way. Yes, I know this is in regards to how someone was using something in code but I think it helps illustrate why some companies run away from OS.
I hate to say so.. but kruczkowski is right. Plus, executives don't get to publicize all the money they've spent at national and international conferences on things like MySQL, Apache, and Subversion. They love to go spout and tout that "We have Oracle, WebLogic and Perforce!"
I've been working with the above open source technologies and others for years, and they've never let me down. Of course, I read the documentation and learned how to use them before I started using them.
I think you may need to differentiate between using open source tools in house versus including open source libraries in shipping code.
Banning use of open source libraries in shipping code is almost always due to legal/license concerns.
The only reason I can think of for banning use of open source tools internally is for quality/support concerns. I've worked for a lot of places, and I've never seen a ban on using open source tools internally. A lot of places are careful about what you're allowed to install, but I've never seen a complete ban. I just can't imagine some place banning tools such as Notepad++ or Paint.NET.
It depends on how your shop would use the open source software as to the reasons, but I have personally seen the following:
(1) Anyone can modify many types of open source software. That is both a strength and a weakness. It is very possible for someone to insert malicious code into an open source project. Sure, it would probably get caught eventually, but depending on the code it could only take seconds for it to do damage or steal information.
(2) Some people do not like the viral nature of some of the open source licenses (GPL) and don't use open source under these licenses because they don't agree with what they represent.
(3) Many open source projects are only backed by the community and not a company. A company has a vested interest in fixing and developing software products that it sells because they depend on it for revenue. I have seen tons of open source projects lose steam and die. Sure, you could get the source and work on it yourself, but who really wants to do that? Personally, I have plenty of work to do without taking that task on.
(4) If your company produces a commercial product similar to the open source, then it could open them up to allegations of using the open source software in that product in a way the open source license does not allow. Even if they aren't true it would be a huge hassle at best for the company.
Its an interesting question, and one I can't think of an easy answer to.
Firstly, lets assume the ban is on OSS tools, not libraries. We all know of the perils of using the GPL if you're not prepared to pay the price laid down in the licence. That's fine, a company can decide to be really cautious if it wants.
So, just considering OSS tools. I had a similar issue at my place of work, the problem is not a total ban but a total mistrust from my boss. I suggested we migrate from VSS (which was significantly letting us down, corrupting data) to Subversion. Immediately my boss decided we had to trial commerical alternatives that he would try to get budget for. He just didn't like the concept of the free software solution, and admitted as such.
Now, I can understand trying to get the "best of breed" solution for our needs, and using something as important as source control means we really need to get it right, but the problem wasn't one of evaluating several suppliers and choosing one, it was 'pick one of the commercial ones'.
I think he was too cautious about it mainly because he doesn't understand it. Free software to him suggests kids in the back bedroom tinkering with software and producing ill-tested, poorly-designed, unsupported toys. (hmm, reminds me of the stuff we sell :) ). So the issue is one of ignorance, and a little mistrust when I came to him to say OSS is good, he dismissed that argument because it came from a techy who didn't explain the issue in good business-speak, ie, I came from a position where I was naturally advocating my preferences, not coming up with an impartial suggestion (that's not the case, but this 'favouritism' position is far too common in the software industry)
In the end, we evaluted a SCM, then found out the total cost (!) and went with subverison after all, and we're all happy with it, and I got an honourable mention in my review due to it.
So, the problem is one of education and ignorance. Just because you and I understand the good, bad and ugly of OSS, doesn't mean the business leaders do. They read the gartner reports and business papers (if they read anything) and get their knowledge of these things from there. Those places are ultimately driven by the software industry which is dependant on selling their own tools and generally undermining OSS.
I have seen articles that paint OSS in a good light, and the message is getting out, so maybe in a few years, OSS will be the first choice for a company (in fact, my other boss said that he thinks all software will be OSS in 10 years time, paid for by support contracts). Until then, its up to us to spread the word and improve the quality of the good stuff.
In my current place of employment, we use a lot of open source tools. In fact, outside of desktop operating systems (Windows or OSX), and Office apps, almost everything I use is open source.
I hate to say it, and was never 100% sure, but in a previous job - where the main organization was buying thousands of copies of some pieces of software - I (and others) had the suspicion that the selection of what software was to be used was influenced by the stock portfolios of those making the selections. Granted, the usual choice was software which had the widest use for its purpose, but there were some cases where the choices were curious. Anyway, to address the point, historically it seems that most FOSS software comes from sources which don't sell stock, so such software wouldn't be considered in places where stock portfolios are influencing the decision makers.
Some companies need to be evaluated by an external auditor before an acquisition and the presence of open source software modules in their software products usually lowers the value therefore reducing the company potential acquisition value.