A few days ago, Michelle blogged to announce Author Pane (a glue module) and took that occasion to complain about the circumstances that made it necessary.
In a nutshell: Some modules could work very well together, if only one of them contained the required hook implementation. Nobody felt up to putting the code into their module.
Finally, I had enough. [...] So, grudgingly, I decided the only way out of this was to create a third module.
I experienced something vaguely similar a while back with a contrib module of my own, DHTML Menu, although that case hinged more on a conflict between two modules (I18n Menu) than on a glue feature.
It is a big logical leap to generalize from two occurrences to a trend, as the system has obviously worked for years. Still I can't help but theorize that this has a common cause: As long as modules work on their own to extend core, everyone knows where they stand, but try to get them to work together, and the development process hits a dead end: Where should the code go?
Neither developer wants to implement someone else's hooks if they're not directly dependent on the module. It's not simply some stupid ego issue ("Why should MY mighty module code for YOUR lousy module's API?"), but a problem of (plainly speaking) convenience. Drupal APIs are fast-changing, and contrib is even worse than core. Implement an API today, and you get to re-implement it tomorrow. Not something developers happily volunteer for. Nobody wants to have to acknowledge another module's existence in their own code - especially a module only tangentially related to theirs, or one they don't use themselves ("scratch your own itch").
The easy solution here is to make a glue module that implements both, but this module still needs to go somewhere specific: Do you put it into one of the two existing projects (which)? Or do you have to clutter the project namespace (as here) with a separate project that contains only glue code?
I can only conclude that the infinitely extensible modularity of Drupal works great on the code and usability side, but clashes with the "project ownership" mentality on Drupal.org. Perhaps it would help to open up sub-module creation to all developers (in the form of a "contrib" folder in every project to imitate "translations")? Or perhaps such things just have to be decided in face-to-face meetings at Drupalcon: "Heads says I implement the hook, tails you" :D .
