> 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.<br><br>OK. Now what if it was another shop that had to update your code? Of course it's easier to update your own code, but what if a meteor was to strike PingV headquarters? Would it be easier for me to look at what you had done using CCK + Views than it would be for me to decipher your FormAPI + custom queries? Obviously, it would. <br>
<br>> 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<br><br>I'm curious: where do you draw the line with what you use or don't use from contrib? Are you saying you don't use Token, Pathauto, CCK, Views, OG, or Image/Imagefield? It seems like your argument is just a short step removed from the "I'll build my own CMS". Sure, dealing with contrib can be a royal pain in the butt, but try deciphering a single developer's solution ot the problems that any of those module try to address and I think you'll see my point: you can't use contrib all the time, but you should use it *whenever possible*, and try to fix problems you see with it, rather than going off on your own. <br>
<br>> 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.<br><br>I don't really think that's what's being said here, and it's certainly not what I'm saying. Every site we build includes a large portion of code that is completely custom for that site. The key is to understand that there's a cost in maintaining that code moving forward, much of which will come from further integrations or updates/upgrades, and that cost is almost certainly higher than the cost of maintaining contrib (since obviously the cost can be spread around "the network", instead of falling all on one "node").<br>
<br>>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.<br><br>But you're not talking about *using* a screwdriver instead of a leatherman, you're talking about *building* a screwdriver when a leatherman's available. Yeah, the leatherman probaby does more than you need right now, but you can't really anticipate whether any of those other included tools will be necessary in the future, and you can be sure that your screwdriver will have one potential avenue of support (you) while the leatherman will be widely used and supported. And again, this seems like an argument against Drupal itself, not just contrib. Don't use the poll module? How about the core feed capabilities? The PHP Filter? No? Then why use Drupal?<br>
<br>>Awkward analogy, perhaps, but there really are times when the open source approach costs more now and costs more later.<br><br>That's possibly true, though I sincerly doubt it. OSS isn't a panacea, but on long term costs I'm guessing that it will beat proprietary software on price 95% of the time.<br>
<br>> 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?<br><br>Well, while you can't be sure of anything in OSS (in life?), you can be sure that all the other people/companies that are using Views plus that handfull of modules will have to come up with an upgrade path in the future. It might not be within your desired time frame, but it's waaaaaay more reliable (and almost certainly cheaper) then hoping some developer or shop will be available and willing to port all your custom code when the next version of Drupal comes out. <br>
<br>> It's not about "what you're selling." It's about what the client needs, isn't it?<br><br>I don't assume our clients know what they need on the technical side. That's why they hire experts, right? It's up to developers to guide their clients business goals into sustainable technologies and best practices. <br>
<br>> +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.<br><br>This is no doubt true, and we certainly work this way. The way I would put it is "use contrib *when possible*, even if it seems like a bit of overkill at times." <br>
<br>> And that doesn't mean upgrading will be harder, either.<br><br>True enough, but it certainly makes it more likely that someone else will have a harder time keeping the code/site up to date. But, again, where do you draw the line? Do you hack core if that's the easiest way to go?<br>
<br>> To me the real problem is still incompetence.<br><br>Can't argue with you there, though I would add inexperience and lack of commitment to the "OSS/Drupal way" as equally problematic.<br><br><br>--<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>2009/3/29 Laura Scott <<a href="mailto:pinglaura@gmail.com">pinglaura@gmail.com</a>><br>><br>>> 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).<br>
><br>> 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<br>
><br>> 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!)<br>
><br>> 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.<br>
><br>> 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?<br>
><br>>> 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.<br>
><br>> 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.<br>
><br>> It's not about "what you're selling." It's about what the client needs, isn't it?<br>><br>> 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.<br>
><br>>> 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.<br>
><br>> +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.<br>
><br>> And that doesn't mean upgrading will be harder, either.<br>><br>>> 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?<br>
><br>> 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.<br>
><br>> 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.<br>
><br>> Laura<br>><br>><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">http://lists.drupal.org/mailman/listinfo/consulting</a><br>
<br>