[consulting] Staying Current

Sam Cohen sam at samcohen.com
Mon Mar 30 12:56:07 UTC 2009


What this thread has answered is how this all works on a practical level.

Here's an example.  A client comes to me with specs for a site.  I decide to
built in D6, and let's just say, the total cost is $5,000, because it relies
very little customization.  I'm using about 15 contributed modules too do
almost everything they want. .

Now how exactly do I tell the client that D6 site may reach it's end of life
in 2 years -- and more importantly, how to tell them how much it will cost
in two years -- or over a 5 year period?

When D6 reaches EOL, the 15 modules may or may not have been ported to D7.
In fact, some may have abandoned..  So in two years, upgrading the site, in
a best case scenario, maycost the client  $500 or, because, say, there's no
Ubercart in Drupal 7 or 8,  it might cost $20,000, because all those nice
Ubercart modules I used aren't around any more.

I mean its hard enough coming up with an estimate to built a site in the
current version of Drupal.  If the current version is going to be obsolete
in a couple of years, I don't see you build that cost in as well, when you
have no idea whether or not the contributed modules you are using today will
be available tomorrow.

Or when you don't know how long the custom code, that uses all those great
hooks and depends on other modules, is going to have to be rewrriten due to
changes in the core and in those modules.

If folks are saying the right practice is to keep sites current and not run
them on versions of Drupal no longer supported by the community, it does
raise the issue of how exactly this works in everyday practice.

Sam

On Mon, Mar 30, 2009 at 3:30 AM, Sean Burlington <sean at practicalweb.co.uk>wrote:

> Bill Fitzgerald wrote:
>
>>
>> Whenever I hear someone say:
>>
>> "Drupal should maintain backward compatibility" I hear "It's inconvenient
>> for me that some individual or company from within the Drupal community
>> doesn't maintain backward compatibility."
>>
>> Whenever I hear someone say:
>>
>> "Drupal should maintain versions from X years ago" I hear "It would be
>> convenient for me if some individual or company from within the Drupal
>> community maintained versions from X years ago."
>>
>>
> What I said was
>
> -----
> Because Drupal has expanded a lot over recent years and has been adopted by
> some big sites - surely there is a stronger argument than in the past for
> longer term support.
>
> So maybe the existing security team won't take it on - but if there are
> enough people in the community who do want to support D5 for longer then I
> can't see why anyone else in the community would want to prevent this. -----
>
> As Shai says - maybe we're not so far apart.
>
>
>
>
> --
>
> Sean Burlington
>
> www.practicalweb.co.uk
>
>
>
> _______________________________________________
> 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/20090330/1dbebe54/attachment.htm>


More information about the consulting mailing list