deekayen: I sympathize with your plight (lack of cooperation between developers / projects; a general aimlessness in development). Most of what I've worked on has (generally) been a solo operation; when it hasn't, I've usually held the reins so I've been comfortable with its direction. But I can identify with where you're coming from.
Something that I think the average OSS "me too" hacker overlooks is a good design process. The attitude of most budding developers is, hey, I've got a cool idea, why don't I go bang it out on the keyboard and hack it into something workable? The hacker approach doesn't always cut it, though, and I think the more mature elements of the OSS community need to do more to emphasize this. The larger OSS projects, such as KDE, GNOME, and Mozilla, [seem to -- correct me if I'm wrong] embrace this approach. I think that more should be seen of it at the freshmeat level, however.
Eager as one may be to code, it is usually far more fruitful to step back a tad and contemplate the design of a project. Carefully think through those ER / SO models for your database! If you're doing it in some OO language, read up on object-oriented design and carefully work out your object model. If not, you should still carefully ponder program flow, etc. The rewards will be significant. I've also found that often it is more fun designing than coding (personal opinion).
This, I think, is where cooperation between developers can shine: people can discuss and debate elements of the design. (Prototypes can be whipped up, but the urge to code something "real" must be suppressed! I'm a member of the open-qubit development list, and have seen a bit of confusion result from a rush to code before design had been carefully considered.) After the design has been okayed by most of the serious participants, development can proceed. Since the design will be finalized, parallel development will be easier (one hopes). Only when divergent [acceptable] designs come to light should development efforts fork.
None of my college classes emphasized this approach (alas!). My real world experience, however, which has varied from ad hoc hacking to detailed process, taught me this: a careful approach to requirements, design, implementation, and testing will usually pay off in the end.