who uses open source products for work?

[timwilky]

Ok globally we run about 700 work stations with "Linux" and about 64,000 with windoze. So the Linux community is the poor relative when it comes to support/standardisation etc. As in we don't officially support it. (Poor I know).


We are attempting to standardise it though. We have a number of staff that have now been Redhat certified and only now provide Redhat Enterprise Linux and require that third party engineering application providers must in turn certify their products with RHEL 5.3. (Our current base).

The issue I have is end users requiring open source libraries/applications. As soon as these are installed I can no longer guarantee the operational integrity of the system. As such I now want to establish a procedure that if open source is installed a disclaimer is presented to the end user that the system is to no longer be used for design or calculation purposes. The management are now getting twitchy. Do we tell our users that because of their requirement for open source that have broken the certification of the system or do we accept it that if design/calculation are in error because of bust software that is a user problem even if it cost serious money or potentially lives.

Firstly I am a great supporter of open source. Whilst I like the idea of community participation, I do want it anywhere near engineering systems.

How do others manage open source applications within their businesses?

Originally Posted by timwilky

How do others manage open source applications within their businesses?

Easily, as my business does not require technical software, just office.

In the spirit of OSS, you could suggest an inhouse programme to certify particular releases (and contribute the fixes/enhancements back to the source). Then it becomes a cost/benefit calculation - a programmer or two to certify the app vs the cost of using proprietary software.

(I assume the root cause of this is lack of somebody to sue if the software calculation is incorrect?)

[timwilky]

Not necessarily sue, we use a large number of hi end engineering calculation and design packages that have been certified by their developers to run on a certain flavour of linux. What we do not have is access to their certification process/methodology etc.

By adding 3rd party stuff, we can no longer argue that the platform still conforms to that standard and without fully testing each application to its developers standard we can no long guarantee installed applications still work as designed. To add to complications I was this morning reading a product install guide that says it runs on Redhat Linux 3 & 4. Now our standard deploy is 5.3. So we end up with work stations at lower revisions of the OS simply because one supplier is too lazy to certify their software, or more likely update their documentation. Which means the poor engineer has 2 systems on his desk at different revisions simply because of the software he requires.

Here, we use open source libraries, in fact most of our in-built infrastructure libraries use open source stuff as their underlying base to enhance the libraries before providing them to us.

The way it works is that we have a distribution system (firm-system-wide) where near-enough every application in the firm is stored and distributed. So we already have a release system, then the infrastructure teams here add the open source libraries into the system (same as you'd do after writing one from scratch) after they have certified it. It won't go to the level of testing against every application in the firm (not possible, too many) but just a check of the library itself so the infrastucture guys understand what it's doing if they need to investigate issues.

The distribution system at a high level involves keeping the releases of each library separate, i.e. in release-numbered folders (this is VERY high level so it's more than that) where people can include them from, when they build their team's applications (i.e. the actual apps that get used). At this point it's the application owner's responsibility to upgrade to the new version (or new library if first release in the firm) and verify it works with their application, *before* distributing their app to their users. The old version is still available (and unchanged) so the only blame is to the application owners if they upgrade and something breaks.