[consulting] Staying Current

[Bill Fitzgerald]

Hello, all,

As Khalid (and I'm sure others) have pointed out, this is far from the 
first time this conversation has occurred, and it surely won't be the 
last. As someone who has survived many of these conversations (and even 
participated actively in a few of them) here are my .02

Whenever I hear someone say:

"Drupal should maintain backward compatibility" I hear "It's 
inconvenient for me that some individual or company from within the 
Drupal community doesn't maintain backward compatibility."

Whenever I hear someone say:

"Drupal should maintain versions from X years ago" I hear "It would be 
convenient for me if some individual or company from within the Drupal 
community maintained versions from X years ago."

Whenever I hear someone say that maintaining a clean upgrade path, as 
opposed to backwards compatibility, is a detriment to Drupal, I have to 
wonder when that detriment will begin to be felt. The Drupal community 
has been growing steadily for the last several years. Drupal adoption 
has been growing steadily over the last several years. The lack of 
backwards compatibility has allowed the project to be more nimble and 
more adaptive, or the opposite of "stuck."

On a semi-related note, can we please stop saying that "Drupal" should 
do something. There is no "Drupal" -- I hate to break it to you, but the 
Druplicon is a symbol, and doesn't correspond to any carbon based life 
form. "Drupal" has no agency, outside of what we, the members of the 
community, provide.

More importantly, this is the consultants list of an open source 
project. Presumably, if you're on this list, you have either coding 
chops, or access to a team with some coding chops -- which means we can 
actually be the change we want to see.

So, here's my idea for the next big Drupal shop, and I'll give it away 
here, for nothing, because I have no interest in doing it:

Be the shop that specializes in maintaining legacy installs of Drupal. 
Come up with a list of supported modules (cck, views, etc) and support 
security releases of those modules, along with core. Combine that with 
streamlined upgrade paths: for example, jumping from 5.x to D7. This 
combination would likely be a very lucrative model, as there would be 
lots of work along these lines. Other shops might even outsource large 
upgrades to you.

So if you want to build the Backwards Compatibility API, do it. If you 
want to support legacy releases, do it. But if you want other people to 
put the time into building what you want, you will likely be disappointed.

Cheers,

Bill

--
FunnyMonkey -- Connect. Click. Learn
http://funnymonkey.com

Sean Burlington wrote:
> Khalid Baheyeldin wrote:
>> "Drupal is moving too fast".
>
> no
>
>> "Drupal should have backward compatibility".
>
> yes - at some point
>
>> "Drupal should support older versions".
>
> yes - ASAP
>
> ..
>
> OK - so that's where I stand
>
>>
>> We just this had this debate on the development list a couple of 
>> weeks back.
>>
>> It is something that used to come up every six months, and now it 
>> seems to be more frequent.
>
> as Drupal gets bigger the arguments for this will increase
>
>>
>> Before we delve into this again, please take the time to review the 
>> development list archives and read the arguments and counterarguments 
>
> do you mean this?
> http://lists.drupal.org/pipermail/development/2009-March/032240.html
>
> Doesn't seem like the same thing to me - so maybe you mean something 
> else?
>
>> there. Otherwise, we will keep rehashing them forever.
>
> I'll move on one way the other
>
> But this is what worries me about Drupal. It seems a bit stuck.
>
>