How can I convince conventional colleagues to venture out into the open source domain?

Question

How can I convince conventional colleagues to venture out into the open source domain? I have worked in large private companies, many are reluctant to adopt any open source libraries for any level of service.

I have for years endeavoured to introduce open source libraries as

1. an external modular “package” that provides an array of features
2. an efficient and up to date numerical computation approach to data
3. social friendly manner to evolve company's products, services and capabilities
4. interface to other groups of users who can result in inter-disciplinary collaborations
5. decentralising control.

However, the I have received the following list of negative feedback about open source, some of which is true but delving further into them, it appears to me that some of these points are found in closed source software. The major perogative in closed source was making money through patent royalties, licensing etc.

1. It is insecure and has no guarantees
2. It is creates confusion in interfacing legacy libraries with open source libraries
3. It is appallingly "buggy" with no support or updates.
4. it is incompatible with the target hardware
5. products and services that are free are misleading and cannot be trusted

Answer 1

While I cannot help to convince your colleagues, I can offer some of the answer I give to (more or less) the same objections.

1. It is insecure and has no guarantees

This is inherently true also for closed source software. No software is secure. The main advantage is, basically, that sometime you can fix an open source software yourself, while you cannot with closed source software. As for the guarantees, well, also closed source software comes without a warranty, if you read the license agreement

2. It is creates confusion in interfacing legacy libraries with open source libraries

That can be true, but I think it is very dependent from the your code, if it is difficult to interface with an external library, the fact that the library is open or closed is irrelevant.

3. It is appallingly "buggy" with no support or updates.

Simply false. Or better, it can be that a library after some time is no more actively developed, just as any closed source product. Again, the advantage is that with a open source library you can both take over the development or have a easier transition to anther library since you can fix some critical bug while migrating.

4. it is incompatible with the target hardware

This can be. It is the only point where there is no solution, if you must use that hardware.

5. products and services that are free are misleading and cannot be trusted

So I suppose that none of them use gmail or facebook or twitter or instagram or any other "free" service, right ? ;-)

While your colleagues can be right to not blindly trust an open source library, they should not blindly trust any closed source library/product they use in their code and then test boths to validate them anyway.