Adopting Open Source Software in an organization

Question

What are the pros and cons of adopting Open Source software for an organisation? Is there anybody out there who has done this and how well has it been working out with some examples of the softwares they adopted and how it has been in use?

Usually contributions come because people do it as a hobby, then how can we make sure that there will be continued support for it? IMHO, in case of proprietary software there is an incentive for the organisation (money), and they will keep hiring people to keep it under development as long as the software is profitable. Correct me if I am wrong. What are the arguments I might expect from a Manager who might oppose the suggestion to use Open Source softwares?

Answer 1

The term "Open Source" only describes a licensing model. Strictly speaking, the only pro that you are guaranteed to have are the freedoms given by the license, and there are no cons that you are guaranteed to have.

There are many Open Source products that are also commercial, created, maintained, and supported by a company for a profit. There are also many Open Source products that are maintained by volunteers but also supported commercially. For example, if you buy Red Hat Enterprise Linux, then Red Hat will support you on all of the products that come with it, even the ones that are maintained by volunteers.

As for how to be sure that there will be continued support, you can't. Not with Open Source, not with proprietary software, not with anything. With Open Source, if the community is large enough, you can be reasonably confident that the community will continue to maintain it (maybe under a new name) even if the current maintainers abandon it, and you have the option of maintaining it yourself or hiring someone else to do it. Maintaining it yourself may not be an attractive option, but it can be a life saver in a pinch.

With proprietary software, if the author decides to stop maintaining it, you are just plain out of luck. Consider, for example, the thousands of users of Visual Basic 6.

Answer 2

The main pro of Open Source software is illustrated by your comment:

[In the] case of proprietary software, there is an incentive for the organisation (money), and they will keep hiring people to keep it under development as long as the software is profitable.

The trouble is that if it ceases to be profitable (for example, because the code is so stable that people buy it and continue using it without needing upgrades), then the users of that software can be stranded with their nice stable product running on increasingly ancient machines until, one day, the machines crash, or must be upgraded to a new version of the operating system so that they can run some other system, but because the proprietary software is no longer maintained, you have to give up on the application. Indeed, it is not unheard of for companies that sell proprietary software to go out of business. And, if you did not ensure that there was a code escrow account for the software to protect you against the possibility of the vendor going out of business, then you are stuck.

If the code was Open Source and you were sensible (you obtained the source when you obtained the product), then you can take the old product and port it to the new system. How hard that will be depends on the nature and quality of the code - but it is possible. If the software was proprietary, you may never have the option.

Answer 3

The question is: what do you mean with "adopting open-source software". if you are planning to radically exchange every piece of closed-source software (CSS) with Open-Source Software (OSS), you will fail horribly.

I can guarantee you that your organisation is already using OSS in key parts of it's IT-infrastructure.

In my point of view, you only need to formalize how OSS may enter the company and if (and in which form) the company contributes back to OSS. Most companies require a support contract for mission-critical software and mandate that OSS needs to be bought through vendors which provide support.

In many cases, contributing back to OSS-projects is explicitly forbidden and only allowed after the CTO/CIO signs of on a specific contribution.

Simply make sure that your policies are flexible enough to allow what the IT-department currently runs.

Answer 4

It doesn't matter what Manager opposing Open Source is saying.

You have to know well Open Source product you are about to use.
You have to be sure that it right solution for company. You have to be confident that you can find people on market who know or can learn to use that product. You have to know TCO for that product.

Then you can argue with manager and give him good reasons how company can benefit from Open Source.

Keep in mind that cheapest solution is not best solution. Companies need to earn money not to save money.

Answer 5

Depends on the situation, but usually, for a, internal, non-critical, no need to secure system, like most of what is done in enterprise, open source is like Halloween and you don't really need to care as long as you follow enterprise policy.

For the other big, important, need to be secured projects, its really simple. You need to have a part in the projects you use and have an internal repository hosting the project (so you have an internal branch that is kept in sync with the external branch). The thing is that those apps are the ones that take a shit long time to make and are supported for thousands of years. The teams tends to change a lot and there's a lot of people involved. Somebody needs and can be assigned to repository/build management.

Now if its only about the manager, then its just about communication and argumentation. Usually they are scared about support because its the long term cost. They tend to like to hear about best practices, well tell them that's what the big companies do (and examples) and that they also tend to participate in the projects and other times they even or its possible to find support for it.

Also, any contractor will be glad to give support of an OSS. Who would say no to money and the ability to develop an OSS.