I agree entirely that the expanding gap between core & contrib is a major problem, and one that seems to be underestimated by some core developers. However, I'm slightly concerned that establishing a set of golden modules in this way will stifle the evolution by natural selection that has served Drupal so well. To make the point, imagine if it had been decided that Drupal 5 was not ready for release until Flexinode was updated.... It's not so important to users that module X be available, but that feature Y be provided by some module; preferably with an upgrade path from module X, but that is secondary from a development perspective. Rather than golden modules, what we need are golden 'use cases.' Perhaps this takes the form of supported Profiles or Patterns. (I'll use the term 'profile' to mean any means of collecting modules and configurations for implementing a specific end-user functionality. I think installation profiles as currently supported by Drupal are severely lacking, having abandoned one in favor of database dumps for the time being.) It has been my experience that the lack of a D6 version for needed modules caused me to look for and find other, better solutions. Or it forced me to more closely analyze the strengths and weaknesses of the various solutions, to determine which is most worth my effort to upgrade myself. Also, I strongly suspect that it is often the case that the modules with a better underlying architecture are easiest to upgrade. A lag in upgrading a particular module may be a sign that it could be replaced by a better solution. Finally, supporting profiles instead of modules makes the system less susceptible to single points of failure. It takes less technical expertise to maintain a profile than it does to maintain a module. If I maintain the Community Events Management profile, and there's no e-mail reminder functionality available for Drupal 7, I can petition 3 or 4 different module developers to upgrade their module, or I can try to organize some developers to create a new, better one, to leverage the new DX features of Drupal 7. You may say, 'What about modules that are so generic that they are used in most any site?' I'd suggest that those are exactly the sorts of modules that should be included in Core. We're seeing this happen with CCK, and Views seems poised to follow shortly. We could even make the criteria for core eligibility more explicit: If a module is used in EVERY supported profile, then it should be moved to core in some form. (And the converse: if a module is not used by any supported profile, it should probably be removed from core.) One thing that would really help this is more street cred for profile maintainers. However about some front-page case studies for a couple profiles? Hey, Acquia, could you throw some money at a few profile maintainers to get them to really polish their profiles, or convert them into patterns & add the patterns module into your distro? All the Best, Matt http://www.NinjitsuWeb.com