Promoting FOSS in a big company

[glennji]

A quick(ish) question: how do I go about promoting the use of open source within my company?

We use quite a few open source libraries (Java, primarily from jakarta.apache.org) but don't tend to integrate the latest and greatest -- instead we stick with whatever was around when the s/w architect penned the initial design spec ... including version numbers, usually.

We even have specs which mandate the version of Ant to use for building -- "you must install Ant 1.4.2" -- despite the fact that it (usually) runs unchanged with a newer revision.

So how do YOU out there in the wired go about using open source in your day job?

[scmadmin]

Hi,

I am also implementing Subversion in my company at enterprise level.
We are setting it as a standard in company, though u need an in house team to support it as pretty less commercial support available, but my experience with subversion has been so far pretty good.

My team gives support to complete enterprise of around 3000 employees, other than this we also use maven, ant and eclipse as well.

[jwenting]

running blindly after projects to have the "latest and greates" version at all times is NOT a good idea.
Yet that's exactly what your "promoting open source" seems to be all about.

It in contrast makes perfect sense to thoroughly test and evaluate a library or tool before adopting it and, especially with open source libraries and tools which have a tendency to be released without proper testing (the "community" are the testers...) to repeat that testing cycle with each new version you want to adopt.

In general: if it ain't broke don't fix it.
So if a specific version works as required, stick with it until you have a technical requirement to use another one. And "there's a new version out on the cvs server" is not a good reason.
Having problems with the chosen version is, if a newer version cures the problem without introducing more problems elsewhere in the application (did I talk yet about backwards compatibility and the lack of testing for it in many open source projects?).

[jwenting]

and as to using open source in general, we choose the best tools for the job that we know of (within project budget, etc. of course).
If they're open source, so be it.
If they're not, fine.
There's a set of preferred technologies and libraries that we're working on (and which will be a work in progress of course forever), which will be a mix of open and closed source.
No room in business for the religious zeal of many open source people who refuse to use anything that's not open source (or often worse, anything that doesn't use a specific license model they like).