> 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.<br><br>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.<br>
<br>> A website developed in Drupal 5 last year is not at EOL.<br><br>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). <br>
<br clear="all">--<br>Alex Urevick-Ackelsberg<br>ZivTech, LLC<br><a href="http://zivtech.com">http://zivtech.com</a><br><a href="mailto:alex@zivtech.com">alex@zivtech.com</a><br>office: (267) 940-7737<br>cell: (215) 866-8956<br>
skype: zivtech<br>aim: zivtech<br>
<br><br><div class="gmail_quote">On Tue, Mar 10, 2009 at 12:57 PM, Victor Kane <span dir="ltr"><<a href="mailto:victorkane@gmail.com">victorkane@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
This is a fascinating discussion.<br><br>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.<br>
<br>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.<br><br>Some people do trade in their cars every 18 months, but they shouldn't be told they have to.<br>
<br>A website developed in Drupal 5 last year is not at EOL.<br><br>Starting a new project in Drupal 5 would be wrong, however.<br><br>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.<div class="im">
<br>
<br>Victor Kane<br><a href="http://awebfactory.com.ar" target="_blank">http://awebfactory.com.ar</a><br><a href="http://projectflowandtracker.com" target="_blank">http://projectflowandtracker.com</a><br><br></div><div><div>
</div><div class="h5"><div class="gmail_quote">On Tue, Mar 10, 2009 at 8:27 AM, Susan Stewart <span dir="ltr"><<a href="mailto:hedgemage@binaryredneck.net" target="_blank">hedgemage@binaryredneck.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Victor Kane wrote:<br>
<snip><br>
<div>> They want a website application that will last several years and have<br>
> every right to receive that. Only if they ask for new functionality and<br>
> the cost of implementing it is cheaper if an upgrade is involved should<br>
> the client be expected to change to the new shiny Drupal just because we<br>
> are excited about it. I am against the "no support after 9 months" thing<br>
> and in favor of backport support.<br>
<br>
</div>I *absolutely* disagree here. If a client does not believe that a web<br>
site is a living, breathing thing requiring regular care and<br>
maintenance, the developer has failed to educate him/her.<br>
<br>
I often use an automobile analogy when explaining this to client: sure,<br>
you can buy a new car and never change the oil, just as you can get a<br>
new web site and never do a security or bugfix update. However, it<br>
won't run smoothly for long. Similarly, regardless of how well you keep<br>
up with oil changes, the breaks and tires must eventually be replaced --<br>
yes, it can be expensive, but not as expensive as getting in a car<br>
accident -- it's part of car ownership.<br>
<br>
When I first spec out a new project, I start talking to the client about<br>
maintainability. We've talked already about how using Drupal lets them<br>
take advantage of development done by the whole community, so it goes<br>
hand it hand to point out that in order to take advantage of this, all<br>
we need to do is stay on a currently supported version of Drupal.<br>
<br>
For clients who can't afford an expensive upgrade process, we carefully<br>
choose our modules from the beginning, limiting ourselves to those most<br>
certain to have a simple upgrade path. My company's clients all know<br>
from the start which modules will make upgrading more expensive, and<br>
make those choices with long-term TCO in mind.<br>
<br>
Just glancing at my recently completed projects list, I'd guess that<br>
about 1/4 of my clients could do a d6-d7 migration for under $300.<br>
<div><br>
> The solution is as web consultants, to be prepared to work on different<br>
> versions.<br>
<br>
</div>Different versions, sure, but pinning my company's reputation on<br>
something past it's EOL isn't good for business.<br>
<div><br>
> So:<br>
><br>
> +1 on starting all new projects with Drupal 6<br>
<br>
</div>We've been doing that for ages, +1<br>
<div><br>
> +1 on maintianing a centralized, community supported backport<br>
> maintenance repository<br>
<br>
</div>A waste of time and energy, and I don't want to see it on Drupal.org --<br>
I feel that would be tantamount to the Drupal community at large<br>
endorsing the use of EOLed versions, and could only damage our<br>
reputation for quality products.<br>
<br>
Big, big -1<br>
<div><br>
> -1 on ultimatums to the clients which will give Drupal a bad name (i.e.<br>
> "if you use Drupal you have to do frequent and expensive upgrades").<br>
<br>
</div>It's not an ultimatum, and major version upgrades are neither that<br>
frequent nor that expensive, *if* the site was planned well from the<br>
beginning.<br>
<br>
I won't tell a client it's okay to stick with an EOL'ed product -- my<br>
clients trust my advice, and know I won't compromise its quality just to<br>
avoid telling them something they may not want to hear.<br>
<br>
Most of my clients just don't see major version upgrades as all that<br>
painful, and I believe that is because they have been prepared for this<br>
from day one. The ones that tend to have sticker shock at upgrade time<br>
are clients who began their project with another developer who just<br>
slapped together whatever modules worked to get a desired result,<br>
without thinking about how easy those modules would be to upgrade.<br>
<div><br>
> If you feel that you don't want to be bothered with Drupal 5 anymore,<br>
<br>
</div>It's not that anyone don't want to be bothered, it's that there are a<br>
limited number of versions we, as a community (let alone one company)<br>
can support at once while providing the highest possible quality of code<br>
and service. More versions spreads us thinner, thus reducing quality.<br>
<div><br>
> offer your clients a very cheap or free upgrade to 6. But let's not give<br>
> the impression that Drupal is an unstable platform, it isn't.<br>
</div><snip sig><br>
<br>
The idea that an upgrade needs to happen occasionally, and that that<br>
upgrade comes at some cost, does not give any intelligent person the<br>
impression that Drupal is unstable.<br>
<br>
For sites that were developed with an eye toward future maintainability,<br>
upgrading to the next major version of Drupal is a fairly painless<br>
process. I have *always* refused to work on EOL'ed versions, except to<br>
upgrade them to a current version before doing anything else. Sometimes<br>
this loses me a client, but often those clients come back to me later,<br>
having received poor service from whatever developer they did talk into<br>
keeping their site woefully out of date.<br>
<font color="#888888"><br>
--Susan<br>
</font><div><div></div><div>_______________________________________________<br>
consulting mailing list<br>
<a href="mailto:consulting@drupal.org" target="_blank">consulting@drupal.org</a><br>
<a href="http://lists.drupal.org/mailman/listinfo/consulting" target="_blank">http://lists.drupal.org/mailman/listinfo/consulting</a><br>
</div></div></blockquote></div><br>
</div></div><br>_______________________________________________<br>
consulting mailing list<br>
<a href="mailto:consulting@drupal.org">consulting@drupal.org</a><br>
<a href="http://lists.drupal.org/mailman/listinfo/consulting" target="_blank">http://lists.drupal.org/mailman/listinfo/consulting</a><br>
<br></blockquote></div><br>