[consulting] preparing clients for Drupal 5 obsolesence

Tue Mar 10 17:22:19 UTC 2009

> 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.

The real problem is, imo, those consultatnts that hide the real costs of a
piece of technology. In a previous career I was a Sys/Network Admin for a
large shool, and at that school we were not allowed to just go buy a
computer for X amount if we only had X amount of dollars in the budget for
the forseeable future, as the on-going costs associated with maintaining
that computer had to be taken into account. I can't see why it should be any
different for purchasing a website (or any piece of equipment for that
matter). There are hidden costs in every technology, and it is our
responsibility as profressionals to inform/educate our clients on these.

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

It will be in 5 months. This is a fundamental decision that has been made by
the Drupal community, and I think it's a damn good one. If they need a
longer life cycle, they probably need Acquia (or a consultant such as
yourself or Eric that is willing to maintain a non-supported version of
software).

--
Alex Urevick-Ackelsberg
ZivTech, LLC
http://zivtech.com
alex at zivtech.com
office: (267) 940-7737
cell: (215) 866-8956
skype: zivtech
aim: zivtech

On Tue, Mar 10, 2009 at 12:57 PM, Victor Kane <victorkane at gmail.com> wrote:

> 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
>>
>
>
> _______________________________________________
> 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/3f90930d/attachment.htm 