Apache Ivy and Apache Maven are two tools that use can use to manage this situation. They handle project build and dependency management. You can use them to access external (open source) dependencies and internal (not-open-source) dependencies.

Excellent question. The answer is that, in my experience, they all do it differently. Generally speaking, we've seen a trend towards distributed - vs centralized - source code management tools to allow for, well, distributed development. But here's a sample of some of the SCM systems employed by notable open source projects:

Linux: git PHP: Subversion Ubuntu: Bazaar Mozilla: Mercurial WordPress: Subversion Hadoop: Subversion Cassandra: Subversion (read-only git available)

That doesn't necessarily answer the question of how to managing the versioning and dependency challenges, but it gives you an idea of what some people are using, and as James said, Maven in particular is employed towards that end.

I've seen this done the way the OP describes but what I think works best is having an in-house repository of approved versions that people can use. Usually a senior developer or architect shakes out a version and approves it for use and compatibility. There is no reason to treat a new release or patch for Apache any differently than you would Oracle. Same for other projects/software. Sysadmins also should not treat patch sets from their Linux vendor/distro any differently then they would patches from MS or HP for HP/UX.

The other thing this allows companies to do is manage what licenses they are willing to use. Licenses need to be reviewed and approved. You don't want to accidentally start using software that is under the Affero GPL if that would compromise your business and developers are typically not the ones that can make those decisions for a company. So having a repository of approved software (FOSS and proprietary alike) and versions of it as well as an approved set of FOSS licenses should, IMHO, go hand in hand.

The projects I've been on, where the issue has been competently managed, handle it this way:

• Everyone's workstation runs Debian GNU+Linux, so that there is a great range of software available directly from the operating system.
• Everyone's workstation is kept up-to-date with the Debian “testing” suite, so that reasonably-recent versions are available but there's low chance of breakage.
• All project dependencies are expressed in terms of what's available in Debian “testing”.
• Anything not available in Debian “testing” must be packaged for Debian, by someone on the project who takes on the role of package maintainer for that work, and is then published on an internal repository (managed using the reprepro package) for all workstations to install from.
• Bonus points for submitting third-party packages created for this purpose to Debian, so that maintenance stops being exclusively our problem.