[consulting] preparing clients for Drupal 5 obsolesence

Tue Mar 10 16:57:14 UTC 2009

This is a fascinating discussion.

I agree about the website being living and breathing, but if I just bought a
new car, and there are some inventions in the course of the next 18 months,
I don't want to be told that if I don't trade in immediagtely, I deserve
what I get.

All I am saying is that there are two living, breathing cycles, that of the
car and that of the automobile industry on a technological basis.

Some people do trade in their cars every 18 months, but they shouldn't be
told they have to.

A website developed in Drupal 5 last year is not at EOL.

Starting a new project in Drupal 5 would be wrong, however.

I think this EOL criteria you bring up could be very useful. Just I think
there is one for Drupal and another for the site.

Victor Kane
http://awebfactory.com.ar
http://projectflowandtracker.com

On Tue, Mar 10, 2009 at 8:27 AM, Susan Stewart
<hedgemage at binaryredneck.net>wrote:

> 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
> _______________________________________________
> consulting mailing list
> consulting at drupal.org
> http://lists.drupal.org/mailman/listinfo/consulting
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/consulting/attachments/20090310/1367380a/attachment-0001.htm 