After reading dman's Open Letter I started to think about how module management on d.o can be improved. Not just to identify duplicated modules, but also regarding dependencies and incompatibilities.
With the absolutely fantastic growth in the number of contributed modules for Drupal it is quickly becoming more difficult to navigate through them, both to find a module that suites the needs and information about if it may create problems with modules already installed. Often this require quite a bit of research through various issue queues, forum threads and so on.
Incompatibility will be a growing issue as the number of modules keeps growing. Sometimes there exists incompatibility between two modules that are completely unrelated, which are difficult to spot.
Many module maintainers do great work documenting their modules, including listing problems, dependencies and so on.
The problem, as I see it, is that each module is managed individually. If module X improves functionality of module Y, then it generally says so on the project page for module X but not very often of the page for module Y. To get that information on the page of module Y someone needs to take the time to contact the maintainer, create an issue ticket and then hope the maintainer updates the page.
Module Relationships
After thinking a bit I came up with a method that can automate this in one step by simply creating creating Module Relationships.
This is how I propose it will work:
For each project there is a new feature - Create Relationship.
When clicking on this you will see a form where it is possible to select what type of relationship it is. The ones on the top of my head is:
- Depends on - Here it is possible to select one or more modules this module is depended on, both mandatory and optional.
- Improves on - This option will both list modules this module improves feature wise and modules that add features to this module such as when for example Tokens support is in the module.
- Incompatible with - Simply modules that it will conflict with.
- Similar to - Other modules with similar features or duplicated modules. There could even be a link to a page that gives an overview of the similarities and differences.
Depending on the type of relationship the form to fill in will look different. But there has to be versions in there so it is possible to set which version of other modules it is incompatible with and so on.
It should also be possible to add on to each existing relationship so they can be updated when changes to modules are made. Default will be the current official version, but then it should also be possible to see info for older versions since not every site is, or can be, updated for various reasons.
When a relationship is created it will automatically show up on the project page for each module related to.
I can also see some interesting side effects to this.
Looking at Depends on and Improves on they can be used to build a very nice, easy to use and flexible module finder. As the relationships already are there then when looking at for example the CCK module there will be a list of every module that is depending on it.
As it will be possible to set categories etc. for the module it will then be easy to narrow down the CCK modules as well.
For each relationship or sub item to a relationship it should be easy to add links to related pages, tickets and so on that contain related information to it, such as a page/ticket that explains how to fix the incompatibility.
I think that if something like this can be implemented it will have many positive effects. It will be easier to navigate through the thousands of existing modules, it will be easier to quickly find, prevent and/or fix problems such as incompatibilities and so on.
I also believe that this will make it easier for module developers as well. When for example an incompatibility relationship is created then a notification can be emailed to the maintainers of each involved module.
Could this be something you think?

Comments
interesting!
Is there a way for the community to create those relationships? Sometimes module authors don't necessarily know all the relationships.
Have you checked out Pivots?
Daniel Zhou has been working on a system that will generate some of these relationships automatically using the <a href='http://drupal.org/project/pivots">Pivots module - you may want to check out his recent blog post on the subject.
Similar efforts
http://drupal.org/project/module_supports (pretty similar I would say)
http://drupal.org/project/module_browser
Nice. I think I'll start
Nice. I think I'll start using module_supports.
Well, in a way maybe but
Well, in a way maybe but they require that you install the modules in a Drupal installation.
My proposal is all about making it easier to both navigate through the 4-5,000+ modules that exist today and quickly get a good idea of the existing options for the functionality your looking for. Also to make relevant information better, such as that a relationship shows up on all involved modules and then make it easier and quicker to be able to know if the module will work with your installation.
A lot of time is today spent on testing x number of modules until you find the one that both works and suites your needs closest.
I also think that if something like this is implemented it will make it much easier for everyone who is not a coder to find relevant information as it will be more structured.
--
/thomas
T: @tsvenson | S: tsvenson.com
Besides "Improves on," maybe
Besides "Improves on," maybe there should be an "Improves with" relationship for when your module does not require, but gains functionality, when another module is present. For example, my Mollom Stats uses Token to allow users to customize the message it displays, but it works just fine without Token - you just can't customize the message without it.
EDIT: I should have checked out module_supports before posting that… that's pretty much exactly what it does.
The Boise Drupal Guy!
This needs to be per-release, not per-project -- related efforts
Good points. However, these sorts of relationships can/do change with each release -- they're not attributes of the projects themselves, but of specific releases of each project. That complicates things a bit.
Furthermore, I think the module_supports approach is a good one -- it is important to have this data embedded in the .info files so it can show up in your live site directly, just like the dependencies.
So, I think the best solution for drupal.org is a combination of getting module_supports-esque support in core in D7, encouraging project maintainers to start providing that meta data in their D6 (and even D5) .info files (which will be ignored by D6 or D5 core, but potentially useful to things like module_supports in contrib), and then harness all this metadata into the d.o DB via something like:
#102102: New module to parse project .info files and present dependency information.
See #328932-62: Modules and partial dependencies - "Enhanced by" field in modules .info file if you want to help make the above strategy happen.
See also http://groups.drupal.org/node/21295
+1 for module_supports-alike in core :)
Where do we monitor to know when we can start building our .info files using this extensions? If not known, yet. Then please announce this somewhere module developers can be aware of it.
This extension will be a great addition for the community in my opinion. :)