[consulting] Staying Current

[Laura Scott]

> The key to this is your assumption that there is "lots of  
> customization". My goal is always to do as *little* customization as  
> possible by finding modules that are a good fit and have lots of  
> flexibility, or by educating the client on ways to bend their goals  
> a bit to do things in a way that they can be done without a lot of  
> customization, or by writing patches to modules that make them  
> flexible enough to do what I need them to do and contributing the  
> patches back so that they will be maintained and supported, and by  
> trying to avoid using modules that are not widely-adopted (which  
> therefore may have upgrade and maintenance problems).

What is "customization"? I'd say it goes beyond custom code and into  
configuration as well. And configuration is something you can't really  
put under version control. We provide alternatives so clients can make  
informed decisions, but we don't think

We recently upgraded a site we did years ago, from 4.7 to 6, and by  
far the biggest complications were in dealing with contributed  
modules, not the custom modules we had done ourselves. Coder module  
and familiarity with the Drupal API changes can make upgrading a  
custom module much easier than dealing with contributed modules that  
don't have smooth upgrade paths or have disappeared altogether.  
(Remember Flexinode!)

There are some false assumptions I see out there: That you are better  
in every case if you use contrib or give back to contrib. It's a nice  
ideal, but it doesn't always serve the client. If all I need is a  
screwdriver, I don't need to use a Leatherman tool. The screwdriver is  
going to do the job better anyway. And when I need to upgrade, all I'm  
upgrading is the screwdriver, not hoping that the Leatherman still  
supports the kind of tip I need. Awkward analogy, perhaps, but there  
really are times when the open source approach costs more now and  
costs more later.

For example, if we write a simple module to generate a page that could  
have been generated by Views plus a handful of other modules, it  
doesn't always follow that the simple custom module will result in a  
rougher upgrade path. Who says that combination of modules will be  
available? One clear argument in this case for the Views approach  
would be that the client needs to be able to change that configuration  
through an admin interface. But another clear argument the other way  
might be to optimize performance on that page, or to put the  
progressive enhancement of that functionality under version control  
for developers. It's never cut and dried, is it?

>  I'm talking about big sites with lots of customization, where  
> clients might spend well over 100k on customization.  I'm just  
> questioning whether those who build those sites are building in --  
> or being upfront -- about the cost of upgrading to D6 and then D7.

What the developers are telling the client is important no matter what  
the size. Just because a site is large and complex with lots of  
customization doesn't mean the client was misled. There are many  
different approaches to web properties. We are quite up-front about  
the costs of upgrading (which are far far lower than developing from  
scratch, as long as the site, custom or not, was developed following  
best practices). Compared with the costs of large integrated systems  
like Vignette, it's a bargain.

It's not about "what you're selling." It's about what the client  
needs, isn't it?

And it's open source, which means there is no real EOL. You can always  
change/fix/update the code yourself, which is something you cannot do  
with proprietary systems.

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

+1 on the patching! But I don't agree that using as little custom code  
(which I will take to mean custom modules) is always best serving the  
client. There are many instances where a simple custom module can  
replace three or four complicated modules cobbled together and  
containing a bunch of code for functionality not needed. There are  
instances where we might write a custom module rather than use a  
contrib module simply for site performance and responsiveness.

And that doesn't mean upgrading will be harder, either.

> It strikes me that we've moved away from "Should Drupal be supported  
> for more than two releases?" to "Are there salespeople that mislead  
> clients about the full cost of acquiring some piece of technology?".  
> And since the answer to the second question is so obvious, what are  
> we even talking about?

To me the real problem is still incompetence. We don't run into many  
clients who have sticker shock over upgrading costs. However, every  
week we are approached by clients who hired the wrong company to  
develop their site, and spent all their money on a site that is not  
simply "incomplete" (which can happen if a project runs out of  
funding) but was actually built with such incompetence that the only  
solution is to start over. There's no happy answer in these cases.

And that's part and parcel with the world of open source. The upside  
(if you could call it that) is that lack of competence ranges deep,  
far and wide in the proprietary world, too. Caveat emptor is always  
the message.

Laura