One well-known issue with Open Source is the so-called "Dependency Hell" problem.

Background

This situation arises when one package, let's call it "A", depends on a number of other packages, "B" and "C", that have their own dependencies in turn (B depends on D and E).  When trying to get A installed correctly, you first have to find and install all of it's dependencies.  In this case, you need to install B first.  But wait, that means you have to install D and E before B can work. 

The tree looks like this:

        A
       /  \
     B     C
    / \
  D    E

The Problem 

Here's where the real fun begins.

It turns out, according to your research, that D requires a special tool, compiler, or operating system library called "X" before it can do its thing.  And C requires another thing "Y".  That's all well and good, but lo and behold, X and Y are found to be incompatible.  For whatever technical reason, X and Y either can't be installed simultaneously, are different versions of the same tool, or simply cause another chain of problems when installed together.

This means it's time to start jumping through some hoops.  One option is that you can install X, build D, remove X, and finally put on Y to build C.  Whew, that was hard!  But wait, there's more.  What if both X and Y are required at runtime to work properly?  Now you're really in trouble.

Unfortunately, the scenario I just described is not simply fiction, it's an every day occurrence in the open source world.  Many projects, especially when they're based on the C programming language, get into these other circular dependency situations that make programmers pull their hair out and punch their neighbors.

The Solution

It might be hard to hear for some die-hard C fans, but I think the solution is either A) don't depend on shared libraries and other operating system resources, or B) use Java or another language that makes it easy to include all necessary run-time dependencies with your code.  Yes, both of these solutions can lead to dramatically increased disk space usage, but hey, when's the last time your new computer came with a 30 megabyte hard drive?  Laptops now ship with fast 160GB+ drives; it's time to move on.

How Operating System Vendors Help (Or Don't Help)

Okay, here's where I'm going with all of this.  Linux and most of the thousands of open source projects in its ecosystem are written in C.  Vast numbers of these projects suffer from the problems I've described above, so what are the Linux vendors doing about all of this?  Well, it looks like they're saying to developers and users, "Look at all these cool lego blocks we've given you! Have fun building things with them!"  In other words, they're doing nothing.  Actually, that's not quite right.  They're doing worse than nothing.  They're continuing to ship new versions of their operating systems with updates to all these shared libraries and other tools that quickly break fragile dependency trees.

But perhaps I'm not being fair to the OS distributors.  It's not like they're the ones creating the fragile dependency trees in the first place, right?  They're not the ones forcing people to use the outmoded tools and libraries they package up along with the core OS.

Hmm… maybe we're onto something here.  Why is it that the OS vendor ships this stuff in the first place?  I mean, they're just a bunch of unrelated add-on packages, applications, tools, and utilities that go uncertified, untested, and unsupported.  Why do they come with the operating system any way?  Shouldn't the operating system vendor spend all its time trying to make the operating system (and the accompanying desktop environment) as robust, stable, and security-hole-free as possible?  Or maybe they like this situation because large software vendors like Oracle can pay them to certify a particular application on each new release of the operating system?

Conclusion

I think what's needed to solve these nasty problems is for the open source community in general to move away from low-level operating system dependencies and other C-based tools that expect pre-existing shared resources in their run-time environment.  It's 2007; let's concentrate on virtual machine technology for both hardware and software purposes.  That is to say, let's continue the migration to Java, Python, Ruby, and other languages that shield us from these painful problems of yesteryear.  Let's move away from depending on operating system vendors to provide our above-the-os world.