[development] Freezing the Drupal API

[Sammy Spets]

I agree with what Richard is saying in a way. Using Drupal for a
commercial client doesn't provide that client with a guaranteed
hassle-free future of upgrades. The two reasons I see for this are:

	1. Custom modules require the creator to provide the upgrade path
	2. Theme system changes and UI changes may require site changes

I don't see how API changes affect the client directly. I only see those 
changes affecting the client via modules.

If a client uses modules (unmodified) provided as part of core only they
are covered for upgrades. Add to this modules maintained by commercially
supported developers there is little for them to worry about. If they
use custom modules or those maintained by part-time/transient
developers, they are in trouble. This is exactly what CivicSpace have
addressed. They are responsible for the upgrade path.

It is true that a client will always require some amount of custom 
modules. In that respect, you can provide them with the source for 
those modules and they can pay anyone to perform the upgrade for them. 
If you choose not to provide source, then it's time to negotiate a 
maintenance contract.

What do I think about freezing the API? I believe it's a bad idea. As
others have said, the freezing will prevent innovation. Innovation is
key to providing a timely, secure and valuable product. You'd want your 
clients to have that type of product wouldn't you? Imagine where we 
would be now (for Winblowz users) if Microsoft hadn't developed Windows 
95. We'd still be using a crappy OS. The transition from 3.11 to 95 was 
a very scary one for businesses, but it happened and the world has never 
looked back.

How do I believe we produce a commercially viable distro of Drupal?
Write modules properly. Many modules are written to address a small
subset of the functionality required globally. Improving modules to
address 80%+ of the functionality required, and maintaining them
properly, will provide the upgrade paths for commercial clients to
depend on.

I'm currently working to do just this. I'd like more people working 
towards that same goal. Drupal being a open source (read as volunteer) 
project makes it impossible to expect this to happen. As others have 
already said, find likeminded people and form a team. Here is my 
shoutout! :)

With my methodology above the core developers can go on their merry way
to keep their goals met. Their goals differ from mine. Provided I 
respect their goals and speak to them nicely (and perhaps submit a few 
patches here and there to either fix bugs and/or make my goals possible) 
everyone wins.

-- 
Sammy Spets
Synerger Pty Ltd
http://www.synerger.com/

On 16-May-06 11:24, Richard Archer wrote:
> At 5:31 PM -0400 15/5/06, Khalid B wrote:
> 
> >The core developers innovate as they see fit, and do not let the API freeze
> >limit their creativity, the features to be implemented, or the overall
> >flexibility, power and compactness of Drupal's core.
> 
> I know. This, along with "code is gold" is the Drupal mantra.
> And I would argue that this attitude has to change. It is a
> sign that Drupal is immature, without focus and not much more
> than a plaything for the core developers.
> 
> This "moving target" API model makes Drupal frustrating for
> someone building a site which they want to run in the long term.
> 
> And as for trying to build a business around Drupal... well,
> there's surely a lot of money in helping people upgrade their
> installations. But personally I want to be able to offer a
> reliable, up-to-date, feature-rich hosting environment, and
> all Drupal promises me is a world of hurt.
> 
> I would also argue that the lack of a robust API has a detrimental
> effect on the quality of the code in Drupal. For a simple example,
> trace through the code that displays a menu item and see how much
> code is executed to perform this task! I think this is a good
> example of where "code is gold" and not having a well-defined
> API to work within has led code which is complex, convoluted and
> inefficient.
> 
> 
> >Perhaps it is best to spend energy on migration paths (e.g. Flexinode
> >to CCK, forms updater, ...etc.) rather than freeze the API early.
> 
> I'm not talking about freezing the API early. I mentioned that
> my goal would be to have a stable API for Drupal 5.0 with CCK.
> 
> And upgrade paths don't help people upgrade their custom modules.
> I think this is where the most pain is felt with upgrades.
> 
> I realise there will always be major new features which require
> changes to the API. But what I want to do is work to create a
> robust API that will allow incremental changes to be made behind
> the scenes without impacting so heavily on both contrib and
> custom modules.
> 
>  ...R.