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