[development] RFC: drupal as a moving target

[Larry Garfield]

On Monday 28 April 2008, Neil Drumm wrote:

> Before I would consider maintaining 5.x beyond the planned timespan,
> paid or not, I would need to see a well-thought-out analysis of how it
> would affect the community as a whole, and agreement from the security
> team, core branch maintainers, and community. A few people saying they
> want something, which they are not personally helping with, is simply
> not sufficient.

I'm going to ignore most of the debate on this thread as off-topic (I am not 
saying the quoted portion above is, as I think it's quite on-topic), but will 
offer the following perspectives:

<consultant hat>
Most of the clients we work with don't have the budget for a 1- or 2-year 
upgrade cycle.  We estimate that a port of a medium to large site from one 
version to the next costs about 60% of the cost of the original build.  (We 
haven't done many, though, so I welcome input from other consulting shops on 
what their average costs for an upgrade are.)  That's out of the budget of 
many of the clients we work with, who are not-for-profits of one form or 
another.  For that reason, we recommend that they skip versions, but that 
still leaves them with, as someone else pointed out, a period of 
unsupportedness.

For most of my clients, a 3-year cycle is within budget.  Frequently after 3 
years they need to revamp the site anyway, which means we'd do a site rebuild 
on the latest version.  Given a roughly 1 year dev cycle, that would mean 
supporting 2 versions back instead of just one.  

As Niel, Moshe, and others pointed out, though, there is a non-trivial cost to 
that.  There are a couple of things we can do to help make that feasible:

1) Fund a security team or security team lead.  This could be through the DA, 
or some angel company, or some other mechanism I can't think of at the 
moment.  

2) More automated testing will, hopefully, reduce the number of bugs and 
security holes we have in the first place, which should make long-term 
maintenance easier.  Read: If you want longer-term stable support, go help 
with testing!

3) During GHOP one of the tasks I proposed was a review of penetration testing 
tools, which resulted in a very extensive writeup that is, I believe, still 
sitting in the issue queue.  Penetration testing is the security equivalent 
of unit testing; automate trying to break a program to find holes sooner 
rather than later.  Like unit testing, it can have immense long-term savings 
both in time and in break-in costs.  I don't know if the security team has 
done anything with that yet (I am not on the security team), but if we can 
make penetration testing part of our routine that should reduce the long-term 
cost of maintenance.  Security team folks, has anything happened with that, 
and if not, is there anything the rest of us can do to help?

4) Tracking contrib is a decidedly non-small task, and one that gets larger by 
about 4 modules a day, I estimate.  Perhaps we could pair that down, thanks 
to more recent developments in project management?  For instance, state that 
the sec team will only track contribs that have a published release node for 
a given version, so a contrib owner can deprecate his own module for D5 
before D5 itself is, at which point the security team does as well?  Or go a 
step further and only track modules that have a proper stable release node?  
(One more reason to not use modules that don't have stable releases.)  Would 
that make life easier, or introduce too much of a security hole?

All of the above possibilities come down to "make long-term maintenance easier 
so we can have more long-term maintenance" (or at least less strain on our 
long-term maintainers, and I freely admit that I am not a role model in that 
regard).  So if we want longer-term maintenance, which I think is a good 
thing, we need to make long-term maintenance easier.  Let's do that.
</consultant hat>

<developer hat>

Ivan does raise a valid point about Drupal's stance on OOP.  Much of it is 
based on "PHP 4 OOP sucks anway", which as of D7 is no longer a 
consideration.  Perhaps we do need to update that document to reflect 3-4 
years of further development and the introduction of PHP 5?  (Not to 
say "yay, OOP!" but to at least be less negative about OOP in general.)

</developer hat>

<community hat>

I am going to borrow the spotlight for a moment to say a huge thank you to all 
of those people who do spend inordinate amounts of time not just writing but 
maintaining huge tracts of code; leading module maintainers, release 
managers, the security team, etc.  Without them, Drupal would be so much pile 
of useless, buggy code.  Guys (and gals!), you rock!

</community hat>

-- 
Larry Garfield			AIM: LOLG42
larry at garfieldtech.com		ICQ: 6817012

"If nature has made any one thing less susceptible than all others of 
exclusive property, it is the action of the thinking power called an idea, 
which an individual may exclusively possess as long as he keeps it to 
himself; but the moment it is divulged, it forces itself into the possession 
of every one, and the receiver cannot dispossess himself of it."  -- Thomas 
Jefferson