[drupal-devel] Let's accept more interim solutions

[Syscrusher]

On Thursday 21 April 2005 09:28, Bèr Kessels wrote:
> But to allow "interim" solutions? naah. I think it will bring down our overall 
> quality a lot. And it will make our porject a lot harder to maintain, since 
> our CVS will be in a constant status of no--really-working. Much more than 
> now. 

I've been reading both sides of this thread with interest, and after thinking
about it, I'm mostly with Bèr on this issue. He expresses concerns that crossed
my mind from the very first post on this thread.

One of the best things about Drupal is that by the time a module makes it into
the "Releases" page on drupal.org, it's ready for production use. If people
want things on a faster schedule, the Sandbox system and the HEAD CVS branch
are a great way to get your hands on early code. The drupal.org site has a
better visibility into CVS (for non-technical people) than many other open
source project sites, in my opinion. Kudos to the site designers for that!

One possibility might be to create Project nodes on drupal.org earlier in the
life cycle of a new module, and have a way for code that is still in a Sandbox
to show up as a link from an associated Project, but on a page that's separate
from the stable/released download pages. This would have the added benefit of
helping contributed-module coders (like myself) recruit "alpha testers" earlier
in the development cycle.

Drupal's single greatest strength, IMO, is its well-thought-out architecture.
Well-thought-out architectures don't often happen if interim solutions
get adopted on a large scale. The problem is that the interim solution becomes
the foundation for other interim solutions that rely on its code, and by the
time someone gets around to really coding up the *right* solution, it's too
late because of all the legacy code. (Here in the U.S., it's a running joke
how many "temporary" Quonset huts built by the Army in WWII are still being
used today. Friends of my family used to live in one, in fact.)

One of Drupal's few weaknesses, IMO, is that for some modules the upgrade path
is not clean. Often upgade-XYZ.php scripts are not thoroughly tested, in my
experience, and also there is the problem with modules popping up for one Drupal
version and then not being maintained going forward. Or they get merged into
core (a good thing) but the data migration path is a little bumpy for non-
technical site owners. Having more interim code in core might make this even
worse, because core API changes are what makes contrib modules incompatible
from release to release.

I don't mean to be overly critical on this last point. If I didn't consider
Drupal to be utterly fantastic in every way that matters, I wouldn't be here.
But I think we have good, solid, stable core right now, and acceptably-stable
contributed modules. To step back from that stability even a little would, in
my opinion, be a mistake.

Now, I also recognize the legitimate desire to not hold back good features
forever. There's an old adage in buying hardware that says, "You can get a PC
with infinite capacity and infinite speed for free, if you wait for infinite
years." The same holds in software -- waiting for the "perfect" design vs.
moving ahead with "good enough" is a balancing act, a compromise.

As a good example of a compromise that works well, I would point to the recent
inclusion of free-tagging vocabularies into core for 4.7. Most of us would
agree that, while Morbus Iff's code is a great start, it doesn't include every
possible feature that people could want. Some argue for user-specific free
tags, some argue for automatic detection of similar tags. BUT...The existing
patch is a good interim solution because it blends smoothly into the existing
core architecture. Morbus Iff's patch provides a new UI for creating and
editing terms, but the underlying taxonomy schema doesn't really change except
for adding a boolean flag to each vocabulary to indicate that it allows free
tags. This interim solution doesn't constrain us for the future.

Thus, I would argue that a balance is the best policy, and probably one that
is close to what we do now -- an evolutionary, rather than revolutionary,
change, such as making early-stage projects more visible but not changing the
speed of putting things into Drupal core.

Kind regards,

Scott

-- 
-------------------------------------------------------------------------------
Scott Courtney     Drupal user name: "syscrusher"   http://drupal.org/user/9184
scott at 4th dot com       Drupal projects: http://drupal.org/project/user/9184
Sandbox:  http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/syscrusher