I just sent this off to the Drupal developer’s list. It’s worth keeping here, too.
—

Just some thoughts based on the discussion so far, from the perpective of a large enterprise that is evaluating our future use of Drupal. For perspective, we run about 10 million page views per month across 30+ sites.

- 4,6 v. 4.7. We use what is appropriate at the time our projects start, with an eye towards maintaining an upgraded path. In one case, that means we’re running a security patched 4.5. In another, 4.6.5 (which is our current standard). While I was at OSCMS, I heard good, passionate reasons for upgrading to 4.7, but I can’t justify it for two reasons: 1) It’s still in ‘beta’ and I don’t have the resources to help move it out of beta (more on that below); 2) We ‘froze’ our selection of contributed modules on November 15, 2005 for this project. The module compatibility issue would be largge if we moved to 4.7.

- Drupal already _is_ ready for enterprise use: it just depends on your enterprise. Bryght, OurMedia, and NowPublic all come to mind as ‘enterprise’ Drupal companies. The issue (at least in my experience) is that those three are all ‘new’ ventures that used Drupal as the basline of their IT infrastructure. Integrating Drupal into an existing IT structure (including all the ‘policies and procedures’ that you currently have in place) can be quite daunting.

- Commit to Drupal or not? This depends on the fundamental question: “How much time does Drupal save you versus 1) creating your own CMS; 2) using some other OSS or commercial CMS? This one, I think is a no-brainer, with one caveat, which is:

- Commit to Drupal.org. After spending the week in Vancouver, I made the following report to our management team. If we are to go forward using Drupal, we need a dedicated support-and-development team of 3 people. (And my eyeball prediictions of such things are ususally pretty accurate.) The team lead will have, as one of his/her main responsibilities, the task of being our public face within the Drupal community. This includes going to events, encouraging contributions of code, and helping with documentation. This is crucial, because without being a valued member of the community, all you’ll ever really have is your own Drupal fork to support. If your organization goes forward with the idea of contributing patches to core, helping document Drupal, and so forth, then you will have a voice in future Drupal development.

/climbs off soapbox.