[consulting] Staying Current

Sun Mar 29 14:09:37 UTC 2009

I can't speak for how all consultants/companies build their Drupal sites,
but we are always building sites with an eye towards upgrading them when the
next version is available, which means a few things to me:

1) We try to use as little "custom code" as possible. If we are changing the
way a module works, we submit our changes as a patch and work to get the
patch committed. This means easier updates in the near term, and (hopefully)
an easier upgrade path in the medium-long term.

2) We release every module that is not specific to the site we're building
back to d.o. This is really an extension of the first item, but on a
slightly different scale. The idea of both 1 and 2 is that by releasing the
code we create into "the wild" it will get picked up (and hopefully
supported) by more developers.

3) We keep up-to-date on what is happening with the next Drupal release (and
our devs actively participate in the next release, at different levels) and
we try and backport whatever improvements we know the client will need. See
our "Book_Bridge" module for a released example of this.

And we do build this into our estimates. Of course planning takes more
time/money, but if the client is worth their weight in foo-bars then they
will not flinch at the additional up-front cost that will save them
time/money/headaches/downtime in the future.

IMO- it's all about "what are you selling". Some consultants/shops sell the
"short game"--getting a site up in the shortest amount of time for the least
amount of money-- while others (like ourselves) sell the "long game", which
includes ensuring that a site is "Future Ready". If a client isn't willing
or able to pay for a site that can stand the test of time, then they
probably aren't the right client for us. Someone else may be willing to
sacrifice quality for cost, but they most likely won't be a client of ours.

That's not to say we don't have any "legacy" clients whose systems we did
not build using the "short" method, but over time it has become
painstakingly obvious that while you can lower upfront costs for cheap/poor
clients, the expense grows astronomically for those same clients over time.

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

2009/3/29 Sam Cohen <sam at samcohen.com>

> I understand the logic in what you're saying, but it makes me wonder
> whether or not in the real world, big site developers who are now building
> complex sites in Drupal 6, with lots of customization, are building into
> their fees and being upfront with clients about what it's going to cost to
> upgrade that site to Drupal 7.
>
> And you can't tell me this is a small cost for anything but the simplest
> sites.  How many hours of work were required to take Drupal.org to Drupal 6?
>
> Sam
>
> 2009/3/29 Alex Urevick-Ackelsberg <Alex at zivtech.com>
>
> > Whatever that figure is, there certainly tens if not hundreds of
>> > thousands of D5 sites out there, and as mentioned, many of them are
>> > large sites owned by large entities. My guess is that a very large
>> > percentage, if not the majority, do not have a strong interest in
>> > upgrading. That's just my guess.
>>
>> I highly, highly doubt that this is true. If you are a "large entity"
>> running a "large site" then you are almost certainly going to update as
>> often as you need to in order to keep your site alive and healthy. Even
>> those dinosaurs that refuses to update ie6 are constantly forced to update
>> almost every other piece of software and hardware, most often around ideas
>> of EoL and support.
>>
>> It's the small sites that we're talking about here, really. Any big site
>> that doesn't update *deserves *whatever bad things happen to their site.
>> If you can't be bothered to put locks on your house, don't be surprised when
>> someone breaks in, espescially when your house is accessible from almost
>> anywhere on earth.
>>
>> --
>> 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 Sun, Mar 29, 2009 at 7:43 AM, Fred Jones <fredthejonester at gmail.com>
>> wrote:
>> >
>> > >> When D7 gets released, the community will support D7 and D6.
>> > >>
>> > >> D5 support will be dropped at that juncture.
>> > >
>> > > Who gets to say what "the community" will do?
>> > >
>> > > 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.
>> >
>> > I have wondered the same thing. How many more D5 sites are there than
>> > D4? A factor of 10, 100 or 1000? Very hard to say I think but there
>> > are a few facts about core downloads at least here
>> > http://buytaert.net/drupal-download-statistics-2008
>> >
>> > Whatever that figure is, there certainly tens if not hundreds of
>> > thousands of D5 sites out there, and as mentioned, many of them are
>> > large sites owned by large entities. My guess is that a very large
>> > percentage, if not the majority, do not have a strong interest in
>> > upgrading. That's just my guess.
>> >
>> > Fred
>> > _______________________________________________
>> > 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
>>
>>
>
> _______________________________________________
> 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/20090329/d7475769/attachment.htm>