[development] Re: enterprise needs

[Ken Rickard]

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.

All that said, we still haven't committed to Drupal long-term because for us
there is  big issue that hasn't been fully solved: Drupal scalability.  I'm
pretty confident that Drupal scales, but optimizing servers for Drupal is
still a pretty rare skill.  (And, yes, we are diving into the forums on the
topic.)

And, wouldn't you know, solving the scalability problem conflicts with our
current IT culture.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20060226/761a9b16/attachment.htm