<HTML>
<HEAD>
<TITLE>Re: [infrastructure] Re: [development] Drupal 4.5 unsupported</TITLE>
</HEAD>
<BODY>
<BLOCKQUOTE><FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'><BR>
Which is why upgrading is costly. When you've tweaked things in 20, 30, 50 heres and theres, writing over them for the next decimal upgrade becomes prohibitive. It's time and money gone completely out of the window. <BR>
<BR>
>From a consultant's perspective this is great because it ensures you're gonna get paid for a while. Form the point of view of a small publisher, the problem is terrible. <BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'>Liza et al:<BR>
<BR>
I really can’t bear to let this thread go on any longer. I know what Laura is getting at, and she is absolutely spot on in that thread. But, I disagree with you about the severity of the problem of unsupported older versions.<BR>
<BR>
Fact of the matter is, 6-12 month upgrade timeframes are actually conservative in this era, and rapid upgrade cycles are absolutely indemic in web development, a.k.a., they are actually a good thing. The reason the web is what it is, rapidly evolving and changing is namely because of the rapid pace at which things are moving. The idea of slowing down to support those who don’t want to upgrade or who can’t handle the time/money (they are the same) investment is (so!) not a good one.<BR>
<BR>
I personally think that Drupal is moving too slowly! I worry about it falling behind, and other worthy competitors coming out that really could give Drupal a run for it’s money. There certainly are, to those of us who follow Open Source and OS CMS particularly, a number of possible competitors. It’s really important that we keep adding new features, and Drupal is headed towards some major architectural changes, which I doubt will be backwards compatible, and which are necessary in the near/mid term to keep the platform viable as a development platform. I’m <I>really</I> looking forward to seeing this community in action!!<BR>
<BR>
I was involved in the eZ Publish (ez.no) community when they went from the 2.x series to the 3.x series, and I listened to a lot of posts about how it was going to damage businesses, and how could they stop support? EZ was kind enough NOT to stop support, and in fact kept the 2.x version up for a long time. We <I>still</I> to this day have customers running 2.x platforms on our servers, often after significant investment in customization, and there entire purpose is to try to get their money’s worth out of the platform before it catastrophically fails. It’s become impossible for US to support them, and I honestly feel bad for them, but the platforms are making money and/or fulfilling their requirements for their owners, so I understand where they are coming from. But I blame the 2.x updates for this, because it made a lot of site owners complacent. Instead of upgrading, they settled on a release, and now they’re absolutely, totally, utterly and completely screwed because the cost of moving to the better development 3.x platform is sky-high – they would have been better off getting hit by the incremental costs. I like to call this a “fake fork”. Often because there is a remedial but incomplete effort to “fork” the project in response to the progression, usually by a couple of specialists in that particular version who are very invested in the code base. It’s basically where the OS project has moved on, and nobody but a few consultants will benefit from the ongoing work. From a businesses perspective, the results of participation in a “fake fork” can be absolutely devastating. No support from the community, lock in from a few consultants, and no clear upgrade path are just a few of the reasons that settling on a particular version that’s too far off the source control’s head is a bad idea. I’ve got customers who have 250k US in software investment in platforms that are dead because some consultant sold them a solution they couldn’t feasibly maintain. Now, because they implemented on a particular version of a product as one project, rather than incrementally investing in continuous basis, they’re 250k from having anything maintainable and have nobody to turn to – certainly the consultant is long gone once they couldn’t keep the customer happy. And the platform is making their daily bread, so they’re locked in to using it.<BR>
<BR>
There are a number of ways that OS Projects and Organizations can cope with change. But they are strategic compromises in investment vs return. If you look at this not from a developer’s perspective, but from an investor’s for a moment, you’ll see that often these users see Open Source systems as a strategy instead of an approach. From an investor’s point-of-view, the decision to use an Open Source platform for your development is the decision NOT to use a commercial alternative. And part of this compromise is inherently (on the little checklist of OS VS Commercial that business people like to make) to embrace this rapid development cycle of OS, be it Linux, eZ or Drupal. It’s actually in vogue to consider the rapid speed of revision a technical and commercial advantage! 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.<BR>
<BR>
Commercial organizations are paid to keep their support organization going for versions of their software that are put into production. Open Source projects cannot afford to dedicate the resources to doing so, nor is it really in the best interest (or interesting) for the user community to do so. If you need long support horizons, use a commercial product. <BR>
<BR>
So, the idea of clinging on to a release that is already past is absolutely terrible. It works backwards from what you are claiming to want to achieve – i.e. a sustainable user community and happy consumers of the product, and lower overall costs (it’s false economy to think so). Absolutely the only person it benefits is the consultant who’s doing the work. And nobody ultimately benefits. The people who stay on the version end up on a “fake fork”, the user community may get materially fragmented, the users end up with a “tough luck pal” response from the community for support, and good developers end up sidetracked on projects that do nothing to drive the platform forward and in fact generally damage everyone involved with them. Sometimes tremendously... <BR>
<BR>
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.<BR>
<BR>
If anything, Drupal needs to move forward towards continuous integration and test-driven development, so changes can be more rapidly integrated into consuming sites. If anything, we need to get more customers on a daily or weekly upgrade, and build systems to help drive upgrades that make it easier to do so. Locking stuff down, or supporting old platforms, will kill Drupal. This beast breaths with every new release.<BR>
<BR>
Dries has already laid down the word on this, and I agree with his approach. Let’s make the archives available (they are), but not spend any time on it. Customers who are on the platform should know the risks of using an Open Source platform. If this is a serious issue, I would post to the Drupal.org site some content that will help people understand what they are taking on with an Open Source platform, i.e. Rapid integration, many upgrades, and relatively continuous integration projects as new tools (like the forms api) are released. I also back Laura’s doc (nice approach!), who said it mighty well and whom I work with and respect.<BR>
<BR>
Please, let’s move on.<BR>
<BR>
Jonathan</SPAN></FONT>
</BODY>
</HTML>