[infrastructure] Re: [development] Drupal 4.5 unsupported

[Jonathan Lambert]

> 
> 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. 
> 
> 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. 
> 
Liza et al:

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.

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.

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 really looking
forward to seeing this community in action!!

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 still 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.

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.

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.

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

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.

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.

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.

Please, let¹s move on.

Jonathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20060530/0588c460/attachment.htm