[infrastructure] Re: [development] Drupal 4.5 unsupported

[Gerhard Killesreiter]

Peter Kowalke wrote:
>> 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.
>   

Drupal has been doing fine before anybody was doing business with it.

> Some OSS projects are healthy and business friendly. Why can't Drupal be one
> of theme?

Drupal is very friendly to my business. :)

(and no, I am not referring to site upgrades, my clients are usually 
tech-savvy enough to do that themselves)

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

IMNSHO it is doing just fine. I am handing out new CVS accounts like 
I've never done before.

> Technical innovation is part of the answer, but not all of it.
>   

It seems to suffice for my clients.

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

Nice analogy. :p

But it doesn't hold, especially since you are setting such a short 
timeframe. Drupal.org for example hasn't had any updates from about 
November till March. We needed to wait for modules to be updated just 
like anybody else. This wasn't a problem at all and the update in March 
was a little bit exciting but nothing major, thanks to a lot of people 
who contributed. And drupal.org is still one of the bigger sites out 
there with some contributed modules and a custom theme.

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

Given the CVS access I don't really see the point, but I also don't mind.

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

I am looking forward to your contributions to this project...

Frankly, I think it isn't worth the effort, but if you volunteer to 
throw enough time and/ or money at the problem, you can probably find a 
semi-stable way to do that.

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

Yeah, I am looking forward to all the complaints about "Why can't Drupal 
run with 64M of PHP memory anymore?" too.

Drupal is and will always be a web application written in an interpreted 
language. This means you can't do stuff with it that you can with eg an 
operating system (running several Linuxes on one machine or other 
heavy-duty stuff) or a desktop application. This just won't fly. And I 
rather have a fast Drupal with a somewhat rugged upgrade path than a 
slow Drupal where I can do ultra-smooth upgrades and run old code inside 
an emulation layer.

Hint: The update is done once every six to twelve months, the webserver 
runs 24 hours a day.

And being able to use Drupal on less than fresh hardware has also its 
advantages[1].

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

IMHO it is not. And even if it were possible, I wouldn't deem it 
desirable. And even if you don't care about my opinion you still need to 
find somebody who writes the code for this.

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

Just keep it, sorry.

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

It is open source, it _can't_ go away (as long as anybody still has a copy).

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

Let me give you all a few hints what I do to check the activity and 
usefulness of a contributed module:

1) I check who the author and /or current maintainer is. If it is a long 
time Drupal contributor or somebody who frequently contributes patches 
to Drupal core, then I am quite sure I can use it, or I can at least 
send him patches for problems I encounter as he is likely to be very 
interested in improving Drupal.

2) Of course I also check the activity record of the module. There are 
two ways to do that:

a) check the CVS commit messages (and their dates), eg:

http://drupal.org/cvs?file=/modules/epublish/epublish.module

b) check the general statistics of open issues for the project:

http://drupal.org/project/issues/statistics

3) if an author is unknown to me, I might want to read the code, if that 
won't help you, you can check

the code checker report:

http://drupal.org/files/projects/epublish.status

(this used to be linked from the project page, apparently we need to add 
it again)

A script tries some basic analysis of the code. This is /very/ basic and 
should not instill a false sense of safety in you. Anybody is welcome to 
help us improve that script, it is in the tricks directory in contrib.

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

Drupal has a very wide market and there are consultants from a lot of 
countries who might work to local tariffs. I also attribute this to the 
fact that it can run on not too recent hardware (see [1]).

You can't really have both. Either you have a lightning fast application 
which serves the needs of many people or you have a behemoth which is so 
backwards compatibly you can't run Drupal on a decent webserver anymore. 
If you want the latter, I recommend to look at several Java applications...

Also, you don't really need to pay a consultant to get a module updated. 
Often there are more people interested in a module and one of them might 
even be able to update it. Sure, this won't be available on the same day 
that the new core version is available, but that isn't really important. 
I have never gotten so many contributed patches for my contributed 
modules than after this 4.7 release. True, most patches required extra 
work by me, but they at least did part of it.


Cheers,
    Gerhard