[infrastructure] Re: [development] Drupal 4.5 unsupported

[Peter Kowalke]

> 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