[consulting] Staying Current

[Alex Urevick-Ackelsberg]

> Yes Fred, that's exactly what I did.  It seems to me insist on a writing a
plugin for so simple a task would have been overkill.  And if I had written
a plugin, who bears the cost of my time maintaining that plugin -- the
client?

Well, my first question would be: what does this have to do with updating?
If it's a simple db query, then it should have little/nothing to do with
updating to a new version of Drupal. The only reason it should matter is if
either the table names or fields changed (an easy fix) or you were actually
using one of Drupal's APIs and that API changed (a harder fix).

> I always thought the best practice was to offer the client the option to
generalize it and contribute it back, not that the best practice is to
insist on it being done that way.

Well, my opinion is that the best practice is to insist on this. If too many
others agreed with you, you'd probably be building your own CMS right now...

> It seems like Alex is arguing that the correct practice is that all
customizations should be either contributed back as modules -- or I suppose
-- contirbuted as patches and improvements on existing modules. And if a
client doesn't like that, you shouldn't do it.

You are missing one giant caveat: the use of the term "when possible". We
don't contribute everything back, but we do release *every single patch* we
create. What would be the benefit of keeping it to ourselves? If we had a
problem, someone else almost certainly did, and maintaining a forked version
of any code (which is what a patched version of a module is) is expensive
over time.

> Maybe Alex is right, but if so, that's news to me.

I think that would be news to many people. Hmm, I think I need to make that
my twitter status! ;-)

--
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 disagree. I think you didn't understand Sam. I think he wrote a
>> simple SQL call and a simple loop to display data, as opposed to
>> writing a Views plugin module. For me at least that certainly would be
>> FAR easier, then learning how to write a Views plugin.
>
>
> Yes Fred, that's exactly what I did.  It seems to me insist on a writing a
plugin for so simple a task would have been overkill.  And if I had written
a plugin, who bears the cost of my time maintaining that plugin -- the
client?
>
> But I think this is a really important conversation for Drupal
customization.
>
> I have always thought that there's nothing "wrong" with building custom
functionality that you don't contribute back --and the only time you would
generalize it and contribute it back is if
>
> 1.  The client agrees and wants to pay for it
> 2.  You do it on your own time
> 3.  It's something that would be generally be useful to the community --
not too specific.
>
> I always thought the best practice was to offer the client the option to
generalize it and contribute it back, not that the best practice is to
insist on it being done that way.
>
> It seems like Alex is arguing that the correct practice is that all
customizations should be either contributed back as modules -- or I suppose
-- contirbuted as patches and improvements on existing modules. And if a
client doesn't like that, you shouldn't do it.
>
> Maybe Alex is right, but if so, that's news to me. It be great if some of
the rest of you can chime in on this.
>
> Sam
>
>
> _______________________________________________
> 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/4b2142e3/attachment.htm>