If you need a 5 year support horizon, which many organizations do, then you shouldn¹t be using an Open Source CMS. You should be using Redhat, or IBM, or one of the big CMS vendors.
This might be the crux of the thread. Business commonly needs a longer software lifecycle, so we're telling businesses to go elsewhere. Effectively saying no to business use will doom Drupal much faster than anything I can imagine. Some OSS projects are healthy and business friendly. Why can't Drupal be one of theme? The best technical products don't usually win in the end--the winners are the best technical products that ALSO cater to businesses and laymen. How can Drupal thrive and grow like a mySQL or a Linux or a PHP? Technical innovation is part of the answer, but not all of it.
I say, archive the old versions, let people make their own mistakes if they want to run them, but Drupal needs to drive forward with laser focus to delivery on the promise it has given it¹s Open Source community that it will be one of, if not the, absolute best platforms out there. And one of the compromises people make by using the platform is keeping up with the rapid pace of innovation that is delivering that promise.
I thought the point was usability, not just innovation? Drupal is community plumbing that makes an online community run much better. If I'm under the sink every month or two, that's not very good plumbing! I may need new pipes installed for that newfangled beer faucet, but the promise of the beer faucet isn't why I installed the plumbing to begin with. Amen to a clearly labeled and easy to use archive where those too poor, too stupid, too contented or too technically shaky can continue to use their old Drupal installations. Let the community march on, but without burning or hiding what came before. I'd like to see a http://archive.drupal.org/ for anything 4.5 and below. If Drupal is going to press ever onward with technical innovation, which it should, it needs more than just a well-marked archive. From a business mindset it needs: 1) A really easy upgrade path. Maybe an auto-update feature--although I know that gets sticky really fast given homemade modules...there would need to be a lot of thought on how to do it sanely. 2) If not an unchanging API, then an API abstraction layer of some kind. Wouldn't it be great if a 4.5 user could install an API-engine of sorts that would allow him to run 4.5 modules and stuff on a newer install? Definitely there would be a performance hit when the 4.5 mods were used, but someone who absolutely needed an old mod or whatever could do it. Microsoft caters too much to legacy code, and we all know how bad that has been. Apple changed too often, hurting business, but then the tech got better and they wised up--people now can emulate their old software on a Mac if they're willing to take a performance hit. This is where Drupal should go if technically possible--and hey, this is a way that legacy support BECOMES a technical innovation. If an API-engine concept was developed, Drupal probably would have my heart for life. :-) 3) An easy way for less technical people to know the stability of a contributed module. Some modules are constantly being improved, and there is no doubt they will update with each new Drupal release. Other modules are close to dormant, and there's a good chance they are Drupal version specific because they're a niche module and the creator doesn't really support it any longer. As a business person, I need to have at least a sense which modules I can rely upon--I might go with Drupal if mailhandler is updated regularly, but I'll probably pass on Drupal if it really only is a 4.6 module. Worse, I might go with Drupal then curse the community if I think mailhandler is a long-term module and it goes away in 4.7. There are ways to get a sense for this if you're experienced, but I think a lot of new or non-technical users can't see the signals--and no, they also can't adopt the project(s) if they foolishly rely on a 4.6-only mod. We need a warning system that gauges risk. I'd be more than happy to lay out ideas on this if others are interested.
I can tell you it¹s in your best interest, and your customer¹s best interest, to keep up with current releases, and fix/rebuild anything build on old releases as opposed to trying to protect the investment it¹s definitely a false safety.
Any site that uses a contrib module has to wait for that module to be updated, OR pay for someone to update it, OR update it themselves.
Money is a factor for open source adoption, too--a lot of non-profits that can't afford commercial CMSes use open source instead. OSS also is gaining a following in less developed countries because anyone can get the software (not just because anyone can develop it). I see open source as being more than just about technological innovation at this point. It is many things to many people--and a common one is its use as a cheaper alternative. I don't want to damn all these folks who need it but can't afford to hire a consultant or learn the skills to do it themselves. Software is for the technical user, first and foremost--but the breakthrough OSS projects have been those that reach and help a wider market. And, I'd like to think this wider market often helps improve the software in the long run, too. -Peter -- Peter Kowalke Port Chester, NY