[consulting] preparing clients for Drupal 5 obsolesence

[Susan Stewart]

Victor Kane wrote:
<snip>
> They want a website application that will last several years and have
> every right to receive that. Only if they ask for new functionality and
> the cost of implementing it is cheaper if an upgrade is involved should
> the client be expected to change to the new shiny Drupal just because we
> are excited about it. I am against the "no support after 9 months" thing
> and in favor of backport support.

I *absolutely* disagree here.  If a client does not believe that a web
site is a living, breathing thing requiring regular care and
maintenance, the developer has failed to educate him/her.

I often use an automobile analogy when explaining this to client: sure,
you can buy a new car and never change the oil, just as you can get a
new web site and never do a security or bugfix update.  However, it
won't run smoothly for long.  Similarly, regardless of how well you keep
up with oil changes, the breaks and tires must eventually be replaced --
yes, it can be expensive, but not as expensive as getting in a car
accident -- it's part of car ownership.

When I first spec out a new project, I start talking to the client about
maintainability.  We've talked already about how using Drupal lets them
take advantage of development done by the whole community, so it goes
hand it hand to point out that in order to take advantage of this, all
we need to do is stay on a currently supported version of Drupal.

For clients who can't afford an expensive upgrade process, we carefully
choose our modules from the beginning, limiting ourselves to those most
certain to have a simple upgrade path.  My company's clients all know
from the start which modules will make upgrading more expensive, and
make those choices with long-term TCO in mind.

Just glancing at my recently completed projects list, I'd guess that
about 1/4 of my clients could do a d6-d7 migration for under $300.

> The solution is as web consultants, to be prepared to work on different
> versions.

Different versions, sure, but pinning my company's reputation on
something past it's EOL isn't good for business.

> So:
> 
> +1 on starting all new projects with Drupal 6

We've been doing that for ages, +1

> +1 on maintianing a centralized, community supported backport
> maintenance repository

A waste of time and energy, and I don't want to see it on Drupal.org --
I feel that would be tantamount to the Drupal community at large
endorsing the use of EOLed versions, and could only damage our
reputation for quality products.

Big, big -1

> -1 on ultimatums to the clients which will give Drupal a bad name (i.e.
> "if you use Drupal you have to do frequent and expensive upgrades").

It's not an ultimatum, and major version upgrades are neither that
frequent nor that expensive, *if* the site was planned well from the
beginning.

I won't tell a client it's okay to stick with an EOL'ed product -- my
clients trust my advice, and know I won't compromise its quality just to
avoid telling them something they may not want to hear.

Most of my clients just don't see major version upgrades as all that
painful, and I believe that is because they have been prepared for this
from day one.  The ones that tend to have sticker shock at upgrade time
are clients who began their project with another developer who just
slapped together whatever modules worked to get a desired result,
without thinking about how easy those modules would be to upgrade.

> If you feel that you don't want to be bothered with Drupal 5 anymore,

It's not that anyone don't want to be bothered, it's that there are a
limited number of versions we, as a community (let alone one company)
can support at once while providing the highest possible quality of code
and service.  More versions spreads us thinner, thus reducing quality.

> offer your clients a very cheap or free upgrade to 6. But let's not give
> the impression that Drupal is an unstable platform, it isn't.
<snip sig>

The idea that an upgrade needs to happen occasionally, and that that
upgrade comes at some cost, does not give any intelligent person the
impression that Drupal is unstable.

For sites that were developed with an eye toward future maintainability,
upgrading to the next major version of Drupal is a fairly painless
process.  I have *always* refused to work on EOL'ed versions, except to
upgrade them to a current version before doing anything else.  Sometimes
this loses me a client, but often those clients come back to me later,
having received poor service from whatever developer they did talk into
keeping their site woefully out of date.

--Susan