On January 15, 2007 (Drupal's 6th Birthday), Drupal 5.0 was released. Neil Drumm acted as the Branch Maintainer for the past four years up until one final commit on January 6, 2011 to clarify the PHP compatibility.

When Drupal 7 was released that meant that Drupal 5 was no longer supported. This announcement is merely a reminder of that fact. It is the policy (and, to large extent a matter of pragmatics) of the Drupal community to support only the current major release of Drupal (currently Drupal 7.x), and the previous release (currently Drupal 6.x). See Drupal's version info for more details on this policy.

Drupal 5 is no longer officially supported

What does it mean that Drupal 5 is no longer officially supported?

  1. You should not expect any of these issues to be fixed in Drupal core.
  2. The Drupal Security team will no longer solicit nor work to address issues that are reported in the 5.x branch of Drupal core or contributed projects.
  3. The Update Status module, introduced with Drupal 5, relies on XML from drupal.org. That XML is still used for newer versions of the module but may be changed in ways that break the Drupal 5 version of the Update Status module.

What does this mean for you?

  • If you are responsible for sites that are running Drupal 5.x, it's time to upgrade to 6.x or 7.x. See instructions on how to upgrade and a video on Drupal 5 to Drupal 6 upgrade. Note that 7.x is still relatively young so you may not be able to make that transition just yet.
  • Module, theme and project maintainers are encouraged to mark their 5.x versions as unsupported so it is clear to end users that these are no longer supported. You can do that by going to your project, clicking the Edit tab, clicking the Releases sub-tab, and unchecking the boxes for "Supported" in the rows for 5.x releases (screenshots below).

Disabling support for 5.x modules

You may be thinking "Hey, let's keep Drupal number 5 alive!" You are not alone in this thought process. There is a Drupal Long Term Support group devoted to the concept but it has met with limited success so far.

Thanks, Neil!

Much like we thanked Gerhard in the Drupal 4.7 End Of Life, we'd like to wish Neil Drumm a warm thank you for all his efforts with Drupal 5.

Comments

yaph’s picture

From my experience Drupal has been a very stable system since I use it and people running Drupal 5 sites should not start to panic now. An upgrade to Drupal 6 or higher is probably the most sensible option, but if your systems runs smoothly there is certainly no need for rash decisions.
I don't recommend to stick to an unsupported version of Drupal but I am sure Drupal 5 will run for years to come as it is a solid piece of software.

d85y81’s picture

Thanks Neil, you did a great job, although the official support is closed, we still need you and happy to be with you. I have a question, what will you do after drupal5?

david

tgeller’s picture

I disagree with yaph, for one overwhelming reason: Security. There are enough Drupal 5 sites out there that online attackers would find it worth their time to create tools to break it. Now that D5 is no longer maintained, there will be no fixes for new cracks.

So even if your D5 site is running well, upgrade for security's sake, or it might not run well -- or at all -- for long.

---
Tom Geller * tomgeller.com * Oberlin, Ohio
See my lynda.com videos about Drupal

Boobaa’s picture

Besides security considerations, will your site run for years with unchanged code? I mean have a look at the mess PHP 5.3 has created, especially against D5 in general and D5 contribs in particular, and think about the providers that will have to switch sooner or later to PHP 5.3 (preferably sooner than later, if haven't done so yet, since PHP 5.2 has reached end of support--even some releases ago, to be precise in 5.2.14 dated back at 2010-07, with the latest 5.2 being 5.2.17 just after the day D7 was released on 2011-01-05).

carnevaledesign’s picture

We began using Drupal just prior to the first release of 5.x. It's exciting to see how far the project has come since then!

vimalramaka’s picture

Thanks Drumm, you're one of the amazing people! Bu-bye Drupal 5.

parasolx’s picture

Got used D5 for 5 month, then I start using D6.
rest in peace.. D5..

https://www.drupalnote.my (Drupal tutorial in Malay)
http://parasolx.net (my personal blog; Drupal)

ubersoft’s picture

That was just my experience, and I waited a long time to try. Ultimately I wound up essentially re-creating the site from scratch because it was easier than upgrading. But D6 was a radical departure from D5, at least that's how it seemed at the time. And it looks like D7 was designed to be somewhat easily upgradable.

I don't post that to discourage people from upgrading... I think they should. The D6 version of my site has been a lot easier to maintain than the D5 version of my site, but there was a certain amount of pain involved in getting there, which may be why some people have held off.

Whoops, meant to post this off the original announcement, not as a reply to a comment. Oh well. :)

mradcliffe’s picture

It took a lot of work to update a site with over 100 modules to D5, but it was worth it to go through the upgrade process. Even with a serious bug in the upgrade process that lost book menu data (skip book, re-run it after).

One of the bigger issues I see is the changed functionality from contrib modules (guilty as charged ;-). I think this makes the process a bit more painful because you're not expecting it. In total it took me 3 months (not development hours) of test runs and writing process & documentation to get ready for a 6-hour upgrade. And then several hot fixes over the next couple of months to either fix missing functionality or bugs that cropped up in the new versions (includes architectural changes).

So I guess for a big site: half a year to upgrade. Yikes!

Mr. Sharkey’s picture

While it's nice that the developers and maintainers of 5.x are getting some recognition, I have to inject a sour note in the festivities.

After investing hundreds, if not thousands of hours into building and grooming a site using D5.x, I now find that I am stuck with an orphaned CMS that has no support, upgrades, or security patches available and for which module support is being withdrawn. This is NOT making me very happy.

Before anyone glibly suggests that I upgrade to 6.x or 7.0, let me affirm that I wouldn't have installed 5.x in the first place if the server I'm on supported these versions with newer installs of PHP and MySQL. The sysadmin has no interest in updating these packages, and I don't have the chops to do it myself despite having root access. Moving to a new server is also not in the budget. A no-win situation all the way around.

Some couple of years back, phpBB deprecated version 2 when v.3 was released. They went as far as locking the v.2 support forum so that it's not even possible for users to help each other to keep existing and otherwise functioning installations in use. I fear that the same will happen here. The brilliant minds run off to take care of the lovely newborn while the older siblings are left to rot. Thanks a lot. With this knowledge, maybe Joomla or Woodpress would look a lot better than they did two years ago when I was deciding which CMS to use in production.

Turning your back on a large group of otherwise dedicated users by completely dropping support for legacy versions doesn't seem to be to be at all in the spirit of open source.

There is NOTHING wrong with D5 apart from it's being abandoned by the "community". I bet you also leave your elders outside in the winter when they get too old to be useful.

danielb’s picture

Dries did say today, in his keynote presentation at Drupal Downunder, that if enough people wanted 5.x to be supported, and there are people in the community willing to provide that support, then something could be worked out, like an extra core maintainer that backports security patches.

kaakuu’s picture

I am glad that someone wrote this.
This is the problem with internet that is going to happen - see more of that further down.

I do use a drupal five site and upgrading is out of question at least now because
- some of the modules are not available or ready for drupal six
- I chose drupal 5 because of those modules only, other cms-es would be as good except that they lacked those modules. Many people actually came to drupal for the modules not the core.

There are 2 reasons we are urged to upgrade
1.
- security : admitted that security issues are there but for the average joe the main problem in security recently has not been due to any version of drupal but some ftp related or otherwise malicious scripts that ran wild and those were outside the scope of drupal
2.
php version
php 5.3 breaks a few things in drupal five.

There can be solution in these way:

- Ignore security cries as much or as little is practicable - - security is never foolproof : the most secure version may publish another patch or patches tomorrow and theoritically during that gap your site may be ransacked
- Have some dedicated or vps or even shared server that agrees to carry on php 5.2.x for eternity. In fact I think some hosting companies will come up with that ( on parties like us agreeing that security will be as is ) and that may be the only way to save thousands of sites with very rich content from access-oblivion, otherwise they will just die and we will lose the most valuable net heritage

While drupal has traditionally followed the "2 versions" policy this would have been the time to change that. I think there are too many sites with drupal 5 just to ignore. Due to lack of ready-for-six modules and due to various factors they will never be able to upgrade. If php 5.3 is forced some time in future and there s really really no way to carry on with php 5.2.x many of these sites will raise a cry - but that is not for now. If that happens either commercial or free support will be needed to keep these "live".
However since many were hobby sites just as drupal itself was a hobby project there will be budget restrictions or no budget for these sites to live on. We will need some one like Dries of Drupal one, young and missionary, to come to the rescue then.

In short the to-do list for now :
1
urge hosting companies to keep zones of php 5.2.x for eternity just like modern civlisations do not demolish everything that is old or may crumble, you call it archive or heritage or whatever
If this is done internet will really retain its rich, varied and original text and image content as current contents are mostly facebook and twitter superficial "scraps" or tv-like videos.
2
find out ways that drupal 5 or certain modules of it that do not function in php 5.3 can work in php 5.3
I am trying myself to see which modules are causing problem with php 5.3 and what solution can be done by looking up the relevant threads. People having probem should join force.

Michelle’s picture

No one is going to lock support for D5. Heck, if you want to chat with other 4.6 users, feel free. The only thing that is being dropped here is official support. The core won't be updated nor will it be checked for security. This is a matter of practicality. There's just not enough manpower available to actively support 3 major branches. If a group of D5 using people want to get together and make a supported version, the software is all GPL. Unlike when a proprietary software company EOLs a product, with open source you have full control over the source and can put in your resources to make it work for as long as you need it.

Also, this has been the policy for as long as I've been here, well before D5, so it's not like this is a surprise they're springing on people.

Michelle

Mr. Sharkey’s picture

Thanks for the reasonable response. I was all ready to scorch the keyboard in reply to a load of "you're an idiot of you don't upgrade" comments.

Since new users of Drupal can expect the versions that they install to only be supported for a period of time until the new releases take up the developers resources and time, how about setting a time period in advance, setting out at a minumum how long the version will be supported.

Oh, sure, it's impossible to say how long it will be until the new version is released and the development team loses interest in the support of the older versions, but it would lend a lot of credence to their efforts if a minimum span of official support could be counted upon -before- someone like me comes along and downloads, installs, learns the system, and develops an entire production site based on that version. If I'd known that I had only two years of support, I would not have chosen Drupal. I'm not sorry that I did, but it would have been an important piece of information I could have used in the decision at the time.

Take D6 for example. Who knows how long it will be until D8 comes along and kills it? Three years? Four? If the developers really wanted to reassure users that they are going to have support for what is arguably an important set of code to them, it would be good to allow those people to know that D6 will be supported until at least four years into the future, or five, or whatever seems reasonable. Make this a commitment of the community to those who trust that they are "buying into" a CMS that doesn't let the stragglers drop to the rear of the column and get eaten by the following lions and tigers and bears (not to mention hackers and spammers and script kiddies).

Michelle’s picture

Upgrading is difficult. While it's the best idea it's not always the most practical.

What you're asking for isn't possible. There is no roadmap in Drupal, no timeline. No one knows for sure when Drupal 8 will be released. It's been 3 years since Drupal 6 was released and it will be definitely more than a year before Drupal 8, so four years of it being supported for sure. Beyond that, it's hard to say. Drupal 5 was supported for 4 years so Drupal 6 is sure to beat that.

Things are always changing on the web. Maybe some day that will settle down but, for now, software has to continue to evolve or it will be bypassed. And the reality is that there just isn't enough interest in supporting those older versions as the majority move on to the next thing.

The thing to remember is there is no "development team". This is open source. The "development team" is anyone who submits a patch, reviews a patch, documents a change, etc. Forcing a team of volunteers to support 4+ old software that they have no use for anymore just isn't going to happen.

Michelle

Mr. Sharkey’s picture

Telling me that something "Isn't going to happen" is dismissive and not productive.

In the US, when an auto maker puts an auto make/model into production they are ~required~ to support that vehicle with parts and service for a period of 11 years. This is to ensure that consumers don't get stuck with a low-production-run, one-off vehicle for which they can't get repair parts, etc.

What I am proposing is that the Drupal "Team" (although you eschew that there is such) commit to supporting current versions for a minimum period of time. This would have the effect of instilling confidence in the users of Drupal that they (like me) aren't going to end up stranded when everyone throws down their tools and runs off to be the stars of the new release show.

I'm sure that a history of Drupal releases could be calculated to come up with an average life expectancy for a given version. Let's take D7 for example. It took what, four years to make it to release? Four more years 'till D8, then four more until D9, then D7 gets the axe. Would it seriously overextend the resources of the non-team to make a commitment to support D7 for eight years? Even if that support was limited to backporting security patches after a third version was released and current?

Users deserve to know (approximately) how much time is left on the clock for the version that ~they~ are committing to. And make no mistake, building an entire, complex site around a software package such as Drupal is a commitment.

Support for D5 effectively ended back in August of 2010 with the last release of 5.23. Since then, nothing. I anxiously kept watching and hoping for 5.24 to be released before D7 was released, but it was too late, D5 had already been dumped. I feel betrayed.

Forcing users to dump the old versions and buy into the new and latest is a tactic that I expect from Micro$oft, not GPL adherents.

But, as usual, I tilt at windmills expecting what's right, not what's likely.

Michelle’s picture

I'm not being dismissive; just realistic. I've been around long enough to know how things work around here and am trying to explain it to you. There is no Drupal team. There are people who step up to work on things. The only real constant is Dries. Others, even very high profile people, come and go.

Would you be willing to guarantee to support something for X years no matter what? What if you moved on to something else? Would you honor your promise and continue supporting something you no longer use and no longer have interest in? For free? That's what you're asking here. The people who have a patch committed in D7 may not be the same people who have patches committed in D8. There's a good chance a lot of them will be but no guarantee.

There is a policy in place of supporting the current version and the prior version. There is no time line attached to that. Support outside of that policy depends on people stepping up and making it happen. That could be anyone. Even you.

Michelle

Mr. Sharkey’s picture

I'm not trying to be argumentative, but you say there is no "team", while a few comments below this, Dries mentions the "security team" Which is it? Someone must be in an administrative position to implement decisions such as retiring versions.

Also, maybe it's time to wiki up the definition of "commitment". A commitment is a decision by an individual to do something regardless of the end returns. When a couple commits to marriage, they promise to love each other in sickness and in health, in old age, etc, not until the newest version of Mate 2.0 is released. I would expect that programmers smart enough to actually come up with a product like Drupal could be counted upon to at least honor a commitment to support their efforts for some agreed-upon time frame. Yes, there will always be shirkers who bail out early, but some model for this must already exist in the Drupal community. Don't you already expect the authors of modules to stick around and support their code? Not everyone does, but if you don't have a policy and an expectation, then it's that much easier for them to drop out.

And yes, if I had he level of programming experience to lend the kind of support we are talking about, I'd be willing to help keep D5 alive, but I'm just a user with paltry PHP skills.

I suppose I've pushed this far enough. D5 is good as dead, and whether future versions of Drupal come with a support commitment is not my decision to make. Just keep in mind that all successful products come with a warranty of some sort. Offering to keep Drupal installations healthy and safe for a determined period of time is only going to improve it's stature as a whole.

Michelle’s picture

There are some small teams, such as the security team, that perform specific functions. There is no over all "Drupal team". There could be a "support Drupal 5 team" if people step up to do it. There is no reason D5 must die, there is no authority insisting no further development be done on it. All that it would take for Drupal 5 to be supported forever is for one or more people to decide to do it. The problem is expecting some "Drupal team" to make the decision to do it. There isn't one. The team is all of us and anyone who has the need just needs to step up and do it.

And, no, module authors have no requirement to stick around. Many do either pass on their modules to someone else or abandon them outright. Contrib often stops being supported even before core.

Michelle

nirbhasa’s picture

Another thread on Long Term support here:

http://drupal.org/node/1036542

My $.02 would be that a 5-year long term support guarantee would be more feasible to implement, from a volunteer resource point of view, and from the point of view of the natural life cycle of the site itself. Websites evolve much quicker than cars :)

There seems to be a consensus that the D7 release cycle was a little too long (almost 3 years), and the D8 cycle should be quicker, so lets estimate a maximum 2 years cycle for subsequent releases. Its reasonable then to assume that under the current system, the D7 release will be supported for at least the next 4 years. If this reasoning is correct, then perhaps giving a 5 year LTS for D7 wouldn't take a huge amount of extra work, and might be an extra clinching argument for people to persuade clients to adopt Drupal.

(edit: some grammatical tidyups)

catch’s picture

Would it seriously overextend the resources of the non-team to make a commitment to support D7 for eight years?

Yes. At the moment there are precisely two people who can commit to any of the past three Drupal core releases:

5.x - Dries and Neil Drumm
6.x - Dries and Gábor Hojtsy
7.x - Dries and webchick

You will notice that one of those names is the same for every release, so you are talking about an extremely finite resource in terms of getting patches committed.

Yet another finite resource is the security team - there are a small number on that team, completely volunteers, who are handling co-ordination and release management for security issues for several thousand contributed projects. You are asking those volunteers to double or triple their workload (and it's one that depends on timely responses from contrib maintainers), when this is a team that is already massively stretched.

Additionally, most contributed module maintainers (and there are similarly often only one or two of these per module) stopped active development on Drupal 5 versions of their modules months or years ago. It is entirely pointless to continue supporting Drupal 5 core, if the modules that people are using aren't also supported.

While there is no schedule for Drupal releases, Drupal 7.0 was released about a year later than most of us working on it would have predicted (at least 2-3 years ago I certainly didn't think it would be in 2011). This 'delay' in the 7.0 release is the only reason that Drupal 5 support lasted as long as it did - if we'd released 7.0 a year earlier, this announcement would have been posted a year earlier too.

Support for D5 effectively ended back in August of 2010 with the last release of 5.23. Since then, nothing. I anxiously kept watching and hoping for 5.24 to be released before D7 was released, but it was too late, D5 had already been dumped. I feel betrayed.

Since Drupal 5 only gets a new release when there is a new security issue reported and fixed, this means there has not been a known security issue in D5 core since August 2010, it's great that you equate stability with betrayal, I'm sure that will really make the people who worked on the previous 23 releases of Drupal 5 inclined to keep going even longer. You can only feel betrayed if you had expectations which didn't match what actually happened, which suggests you have never, ever read http://drupal.org/node/65922

catch’s picture

Reading below, if Dries and/or Neil is happy committing patches to Drupal 5, then the one bottleneck that needs to be removed is the security team.

So....

- Any new security issue for Drupal 5 would need to be immediately posted as a public issue as long as they don't exist in Drupal 6 or 7 (in most cases this will sound worse than it is, since it's unlikely there are anything easily exploited that hasn't already been found).

- Fixes for those could be worked on by whoever cares in the public issue queue.

- They get committed and a new 5.x issue is released.

- The same for contrib, but that would require contrib maintainers being prepared to follow this model, which is going to be case by case.

- It is easy to filter all issues on Drupal.org by 5.x + the 'security' tag, so if a group of people wanted to team up to support 5.x versions of things in general, then it's easy to create a list of what to work on.

Also

And yes, if I had the level of programming experience to lend the kind of support we are talking about, I'd be willing to help keep D5 alive, but I'm just a user with paltry PHP skills.

If you have 'paltry' PHP skills, then you know more PHP than I did when I started getting patches committed to Drupal 6, since I had absolutely no PHP knowledge at all when I started. My first core contributions were re-rolling and updating patches in the queue that I needed for my own site, but which had grown stale - which usually involved copying and pasting a few lines of code manually and making sure there wasn't a WSOD. This is about the same as is needed for most backports from Drupal 6 to Drupal 5 too, while you might not be able to take an issue the full distance to commit, nothing stops anyone from chipping in to keep things moving (probably being able to tell the difference between PHP, HTML and JavaScript would be enough to get started).

dwknighton’s picture

With all due respect, your analogy to car manufacturers being required to support models for 11 years is not applicable. Auto owners pay tens of thousands of dollars for their cars, if not more. Drupal costs you nothing except for what you put into it, or pay someone independently to put into it.

mcurry’s picture

I understand the need to EOL D5, but as much as I like D6 (and D7!), there are way too many modules that just don't exist in D6 to make the switch anything but a major undertaking for some of my sites. I expect that this is true for many other site operators as well. So I expect that many D5 sites will stick around for a long time.

This is the recurring headache with Drupal major version upgrades: contrib modules lag behind. D6 was a prime example of this phenomenon. This is the downside to the Drupal core philosophy of not maintaining backwards compatibility -- many contrib module developers just can't keep up.

When someone builds a non-trivial site with Drupal, they come to rely on contrib modules. That's the allure of Drupal -- hey, there's a module for that! So they make an investment in the Drupal infrastructure and contributed modules -- time, effort, etc. Then comes the major version upgrade. Some of the important modules you've come to rely on are not available in any stable form. Now what? (I know one standard answer: grab a shovel and start digging.)

I'm lucky: I can sling PHP and SQL, though I'd prefer not to unless there's a good reason. I've done (mediocre) module development. I can deal with replacing missing functionality, though it will cost me time and trouble. But what about those other Drupal operators who are not as technically competent as me? Do they fork over money to Drupal consultants to help perform the upgrade? What if they don't have the money to do so?

The Drupal community should be realistic about major version upgrades and EOL issues -- for many Drupal site operators, it is just not possible to throw the switch and upgrade promptly. So old versions linger...

I recognize that I am not offering solutions to the problem. I don't have any. Drupal is a very nice, very helpful, well supported platform for many purposes, so lots of people use it -- and that very popularity creates this conflict, this tension between Drupal core development and the installed user base.

edit I'll add that my experience moving from D4.7 to D5, then D6 on a number of my sites taught me one thing: think long and hard about whether you really need that non-core module. Adding lots of non-core modules will only make your maintenance and upgrade path more difficult (not to mention degrade performance). Things have improved, but I think this is still true, and Drupal site operators need to avoid the kid-in-a-candy-store effect that the plethora of contrib modules can have on you. :D

tgeller’s picture

This sounds like a job for Acquia! (Or any other enterprising and serious party.)

Seriously, I smell a business opportunity. The questions are: How many organizations have sites are on Drupal 5 and aren't able to go to D6/D7? How many of them are willing to pay for support?

---
Tom Geller * tomgeller.com * Oberlin, Ohio
See my lynda.com videos about Drupal

Dave Reid’s picture

Well, their site is using Drupal 5... :)

Dries’s picture

Yes, the acquia.com website is still running on Drupal 5, but is currently being upgraded to Drupal 7. All our other sites are running Drupal 6 or Drupal 7 though.

tgeller’s picture

Yes, the acquia.com website is still running on Drupal 5

Wow. I'm dumbfounded.

As they say, "The shoemaker's children have no shoes...." ;)

---
Tom Geller * tomgeller.com * Oberlin, Ohio
See my lynda.com videos about Drupal

dddbbb’s picture

"The shoemaker's children have no shoes...."

I love that expression.

mcurry’s picture

the acquia.com website is still running on Drupal 5, but is currently being upgraded to Drupal 7

It would be an interesting study to detail the effort and cost (man-hours, money) of that upgrade. I assume acquia.com does not lack talent or other resources necessary to make the upgrade, so it would be interesting to relate that to the expectation that 'lone wolf' operators do the same.

(For the record, I agree that the D5 EOL needs to happen, and that people need to upgrade -- but I think people need to be realistic about the prospects of the real-world conversion rate.)

Dries’s picture

I'm happy to keep committing patches to the DRUPAL-5 branch, and Neil is welcome to do the same. I'm also happy to roll new releases for the DRUPAL-5 branch. However, it will take people or organizations in the community to help maintain Drupal 5 and to backport (security) fixes because the security team no longer has to. Long story short -- with your help, Drupal 5 can still be supported. This is Open Source, remember. :)

te-brian’s picture

D5 is what I learned Drupal on ... and man have both I and Drupal come a long way since then. Its been a fun ride and I look forward to the future of this great community.

The one thing I will miss is the speed. We only have one client left on D5, but their site is blazingly fast compared to some of our more modern sites. Technology moves on, however, and varnish and other innovative caching has allowed us to enjoy D6 (and soon enough D7), so long as you're not user 1:)

lismail’s picture

It is always great to look back and remember our excitement when we tried D5 for the first time.
Thank you to Neil and the community for such wonderful memory of D5.

TaraRowell’s picture

I think it's appropriate to give Dries and the committed contributors a round of applause. It takes untold hours to maintain platforms and I, for one, and very grateful that you choose to use your talents to develop support an Open Source Project. It's quite unbelievable, really.

THANK YOU~!

yareckon’s picture

Neil,

A hearty thanks for many years of work. Your dedication brought millions of people more flexible, stable, and powerful software during some explosive years when everyone and their grandson got online 24/7 for real. Drupal 5 was the first grown up drupal in my opinion, still a bit rough around the edges, but a muscular platform that made a lot of people sit up and take notice of open source.

For those who feel that their sites and investment are being left behind, there are a number of ways that D5 could still be supported in an organized way, but there are some difficulties with all of them.

There is potentially an income opportunity for a small company with a couple of employees to keep people from having to put in the expense of upgrading their sites by producing patches. But how to they get paid? The problem for this business model is that the security fixes produced by the firm would be GPL as well, and folks would be in the right to also share the patches with each other for free. There would have to be something like a Flattr support stream, or folks at companies paying a retainer from a lot of folks to justify a company putting in the time to keep patching away. Or maybe the company could charge for some type of upgrade management service or software, but probably that would be more dev work than could be justified on a shrinking product.

Another thing that might work for a time is that a company or several companies with a large D5 install base might do internal patches that they would then externally release to the community. There would have to be a semi official central point to aggregate patches for this to be a reliable way to keep up to date. Eventually, these firms are going to upgrade though, and the folks depending on them to keep the fixes coming would have to upgrade too.

Lastly, drupal could officially name a D5 legacy maintainer for a few more years and hope that someone was willing to get some recognition and take on a relatively thankless job. This person would have to be getting something pretty valuable to them out of the deal, and would be more and more unsupported over time unless some sort of team was kept together to back them up. Core would likely be maintainable this way, and contrib would be out in the cold.

An additional problem with any of the above approaches is simply finding the vulnerabilities in the first place. When the rest of the community has moved on, its gonna be a few website owners against a few crackers.

In many ways, open source is very different from closed source products. You are likely to get the new stuff for free, and once times have moved on, you have the rights to stay on the old stuff and keep going, or even develop it further if you are able. Rarely is either true for closed source. Unfortunately, after a tech is no longer the thing that the developers are investing in, you have to replace that free manpower you got with a more traditional do it yourself, or pay someone to do it for you approach.

Site builders are in a tough spot, and will have to either put in the hours to upgrade, put in the time to become a good enough developer to support themselves, or actively support a community / business that will do it for them. They also need to develop good habits for building a site for maintainability for next time.

When acquiring open source software, for zero initial cost, there is a huge temptation to use every contrib module and build in every feature. Because drupal is so modular, 50% of your functionality is not relying on a community of thousands, but on a few developers on modules strewn around contrib. This often works in the phase when it is new hotness and vigorously supported. However, for each module, there will be a day when it enters an unsupported phase, or you realize that it was never really supported to begin with :(. You simply have to plan for this from the beginning. It is important to minimize the amount of features you build into your site to a manageable codebase that you will later have time / money to upgrade later, and stay on the most well worn paths that are likely to lead somewhere.

It remains to be proven if hosted, managed drupal like say drupal gardens can provide a sustainable solution to the site building with drupal without upgrade pain problem. Or just get used to building simpler, more focused sites with a smaller toolset.

vegantriathlete’s picture

I started with Drupal on 6.9 (in April of 2009) and gave no thought to how long it would be supported. I used it because it was free, it made sense to me, and it worked. I had tried other options via the Fantastico scripts on my shared hosting account. [At the time I had no intention of becoming a web developer.] I clicked (no pun intended) with Drupal immediately. I also quickly moved away from dependence on the Fantastico script, as it just didn't keep up with the new releases.

I think we need to recognize that nothing lasts forever, especially a website. At some point, I think you will need to completely rebuild your website. So, maybe you can take the path of skipping the upgrade and just doing a redeployment. Understand that I am not trying to make light of how much effort goes into either option. But, I think that you need to recognize that no product is supported indefinitely.

Finally, as others have already pointed out, this is Open Source. Never mind the fact that Dries has already indicated he is willing to continue committing patches. It is possible to grab the code and share it on github for free. You can start your own repository and do your own commits.

I love the fact that the Drupal project keeps on striving to get better and doesn't lock itself into an old structure, when it's obvious that it can be improved. I also love all those wonderful contributed modules that make it so easy to add functionality to a site. I refuse to "dumb down" a site just so I don't have to add another contrib module. I'm amazed by the talent in this community and look forward to the day that I have built my chops to the point that I can start contributing modules and submitting patches to commit to core. Until then, I will be forever grateful for the time and effort others put in and hold no expectations for anyone to make a promise to me to do it for any specified period of time.

All my sites are built on Drupal 6.x. But, you can bet that I will start building sites on D7 for every site for which it is an option. I've just about wrapped up a new site in D6 and will be starting another next week. For the former, it was the client's request to stay with D6. For the latter, there were too many modules that aren't available in an official D7 release yet for us to give it a go. If there's an easy upgrade path from 6.x to 7, that's great. If not, then I'll just deal with it.

Many thanks to all the hard working volunteers in the Drupal community. You rock!

yeagermiester’s picture

I was surprised to read such a heated debate over a subject that I thought was readily understood. I've only been using Drupal for about half a year, and I don't remember not knowing that official support was only offered a single version back (which is why I waited for D7 to begin a a more recent project). I haven't the skill yet to be a contributor (though I hope to be sometime in the near future), so perhaps my thought means squat, but I think there is a more important issue being addressed here: this is free. The reason automakers commit to supporting their vehicles is because they are trying to make money. They would give you a ten year guarantee on a box of crap if they thought you would buy it (thank you, Tommy Boy). What you are doing is demanding that the massive group of people who love and support Drupal in their free time meet your needs. The one thing that I have learned about open source is that--and I do not mean this in any way as an insult--it doesn't need you. We want people to use Drupal, absolutely, but customers are not necessary when no one is buying. You see this with Linux systems all the time. The reason Linux has not been accepted in the mainstream is there was no one willing to make it as "user-friendly" as Windows or Mac OS. For years, it was a geek's OS. Only since people have started to care about making it "user-friendly" has it gained attention in the mainstream (though, admittedly, this is still very small). And, for the most part, no one makes money off of Ubuntu (or at least support for Ubuntu), for example. We want you to use and love Drupal like we do. We want you to contribute and make Drupal the best CMS is the whole world. But, remember who you are talking to. We are doing this for free. Many of us do this for fun. The fact that even one version earlier is supported amazes me. People will still work on the "old" version when the awesome "new" version is out there in all of it's awesomeness. That is commitment.

Edit: Poop. This was supposed to be at the end of the discussion Mr. Sharkey started.

kaakuu’s picture

The problem is modules. More than 50% or even more came to Drupal for that much needed xyz module that was there and that makes their site. If that has no 6x or 7x version they cannot upgrade. 5x still runs fine and fast and has least cpu resource consumption - only problem is that some code or some code in some module will not let some thing run in php 5.3x. That part is intriguing. Rest how much debate may be there, there are still Drupal 4x and 5x sites in plenty, whether supported or not.

BTW, getting for ?free is a 2 way process. Thousand of user hours have gone into the forum and issue feedbacks by thousand of users, and few devs or few companies do make money. No need to elaborate on this. Nothing is taken by the user for "free" - there is always some return.

Mr. Sharkey’s picture

[edit] You know what? After reading the comments by user "catch" to my comments above, I've decided, "Never mind". [/edit]

jpl-2’s picture

I've recently upgraded a production site from D5 to D6 (low-traffic, but many contrib modules and significant custom code/patches, a workflow-heavy site geared toward multiparty document management). The whole process took 216 hours. To be fair, 120 hours of that were spent on writing automated tests to ensure that the site doesn't break after this and future upgrades (an alternative may have been to spend perhaps a shorter time on manual QA). Of course, the amount of work will vary wildly from site to site, but this recurring cost is something that you must budget in if you decide to build a long-living site using Drupal. It is not secret by any means, but certainly it is not emphasized enough in the Drupal documentation or Acquia's PR efforts, and it surely has potential to do damage to Drupal's public image.

I even suspect a possible conflict of interest here. Those of us providing commercial Drupal-related services would in fact be happy to help you upgrade your site or port missing modules (for a fee). Attempting to delegate this (very specific) sort of migration work to "the community" would mean taking away potential business and resources from the (more general) feature development.

susheel_c’s picture

I started off on my drupal journey with Drupal 5. I created my first CMS based website with it. I'm very excited by where Drupal has gone in the last few years and can't wait for D7 to come in to it's own, like D6 has... Great stuff by this community.

Anonymous’s picture

I need to upgrade from D5 to D6 and find myself 'locked out'. All the reading I have done recommends updating all modules to the latest version before upgrading to D6. Unfortunatelly, all the 5.X versions of modules are gone at this late date. Am I out of luck or is there a way to download the latest 5.x modules?

Thanks!

Michelle’s picture

Click the "View all releases" link on the project page to see the whole lot of them.

Michelle

Mark_L6n’s picture

Would it make more sense to extend support for a version until the time it is realistically feasible to upgrade to 2 versions higher? For example, it is not realistically feasible yet to upgrade from D5 to D7 because of the many important D7 modules that are not ready yet.

Michelle’s picture

You really need to read the rest of this thread. That's been well covered.

Michelle

Mark_L6n’s picture

Apologies, but I didn't see that exact suggestion on this page.

Michelle’s picture

http://drupal.org/node/1027214#comment-3991330 and http://drupal.org/node/1027214#comment-3987782 are two comments in particular that are relevant.

Basically, yeah, would be lovely if D5 could be supported until everyone has moved to D7 or at least D6. But that takes people willing to step up and do it. No one likes the "if you want it, do it or sponsor it" answer but that's reality. Nothing gets done without someone doing it or paying someone to do it.

Michelle

tuthanh’s picture

I started to learn Drupal in 2008 and jumped straight to Drupal 6. Haven't had a chance to use Drupal 5 and never again.

It is necessary. I still saw many important modules which are still unstable in D7. So let's focus on D7 and let D5 rest in peace.