[development] RFC: drupal as a moving target

[Ivan Sergio Borgonovo]

On Tue, 29 Apr 2008 12:24:00 +0200
Jakob Petsovits <jpetso at gmx.at> wrote:

> Ivan, I feel your pain, I'm having a hard time with porting my
> modules in time as well (in addition to "new features" work). The
> problem does exist.
> 
> However, what I miss from your mails is a constructive proposal how
> to make it better. Even now, the APIs are not changed for the fun
> of it but always come with a significant improvement. You request
> that the core devs take care not to change stuff *without a good
> reason*, but that's what they do already.

It depends on the weights you put in the equation.

> In that case, you disagree with the community (including me), and
> we expect you to make concrete proposals which type of API changes
> should be frozen under which exact circumstances, and present
> compelling arguments why that is better than the status quo.

I think the DB API is a good example. Beware I'm not criticizing the
current work. I love it.
Maybe when D6 DB API was planned that was the best thing to do. Now
we will see another change of DB API.
D7 DB API does really look as a good candidate to be frizzed for at
least 2 releases if not more if all the efforts needed will be put
into getting it right. Should this change be accompanied by another
FAPI change? Should the DB and FAPI change be accompanied by cosmetic
changes to other 10 helper functions?
I think that shouldn't happen for D8.

> You argued that Drupal is becoming stable and mature enough to
> freeze some aspects of the API. If that is the case, I believe that
> no more API changes will be written up for these areas, and the
> problem will be solving itself in time. However, I believe that
> Drupal has still years to go until it reaches that state of
> maturity, and that each API change causes more good than harm in
> the end.

If you've a 2 years life cycle and a bunch of 3 hundreds lines
modules yes, absolutely. What you could get building up such kind of
sites with 5.7 compared to what you got with 4.7 was definitively
worth the change. been there, done that.
I'd like to get out of that line of business, I think it is more
suited for other CMS. I think it is good for my pocket and good for
the overall quality and fame of Drupal project.
I did chose Drupal inspite of the concurrence because I thought it
was a good development platform. Development have a higher value when
it get complex not when you use a RAD and a bunch of modules.
You can't build up a higher value product if you have a short life
cycle and high upgrade costs.

> If you believe that some of the changes from Drupal 5 to 6 caused
> more harm (in terms of slowing the upgrade process) than good (in
> terms of consistency, long-time maintainability and important
> features), then by all means, "show us the code".

> Which changes would better have been left out in your opinion?
> I'm keen on seeing examples from you, because the process can only
> be changed if we recognize what actually went wrong. If you can't
> find good examples, then this whole discussion is moot because
> there's nothing to complain about.

Nothing went wrong. I'm looking forward. D7 is under development.
Will the cost of upgrading D7 to D8 still be 60% of the development
cost of a web site?
Are we going to see a part of the API changed twice in a row?
Is there any chance that future development will focus on some API
part at a time, rather than putting so much stuff on the fire.

Till now the answer has been... yes we do care but you're going to
see this things happen for a long way ahead. My *opinion* is that it
is not going to be sustainable any longer in the future.

Drupal is halfway between Django and Joomla. If you see the positive
sides you'd say it is better than Django since you start with a self
sufficient application and it is better than Jommla cos you've a more
flexible framework. If you see the negative side you'd say you don't
have a stable API and you're missing a "polished" nice looking CMS.

While making Drupal a polished nice CMS is "just" a matter of
configuring it and spending some money on a theme and writing a 300
lines module in Drupal or in Joomla doesn't require a very different
effort, you've to be "competitive" as a tool on the "framework" side
for building more complex applications.
How can you be competitive on that field if upgrade costs are 60%?

This is my forecast and I'm asking if people agree and we are going
to see any change in approach.

I've already noted all the positive changes that took place in this
direction but it seems that if it will ever happen that upgrade costs
will get lower it will happen by chance as a negligible side effect.
The published policy is still: things are going to break and we won't
care.

I know people are not crazy and they weight pros and cons. I feel
that it is time to put more weight on the cost of upgrades or making
the lifespan of a release longer so that we will see more complex
projects flourish.

I already put my time and money on seeing this happen. And I took the
risk on developing a quite complex module on Drupal. It will be hard
to afford an upgrade once at the current state of affairs, it will be
unmanageable to sustain a second upgrade at the current estimated
cost. I'll survive back-porting sec patches to 5 so that the cost will
be spread over a longer period. I rely on very few contrib modules so
that will be feasible. But meanwhile I think my project will continue
to grow... once it will reach 20K lines of code it will be of
comparable size to Drupal... if it is going to cost 60% to upgrade
I'll start to look around for something different and I'll regret
when I chose Drupal in spite of having longer starting development
time and start from the beginning with a mature stable framework
while I was paying my bills with more "vanity sites" on Drupal.

Oh yeah it is a selfish personal problem... but it may be
representative and more common than what it is thought and it may
have an impact on Drupal future as a whole.

60% cost in upgrade is a huge percentage if you've projects that have
more than 2 years life span.
Is there an interest in making Drupal attractive for projects that
have longer life span in the short term? (that means starting from
D7-D8 transition?).

-- 
Ivan Sergio Borgonovo
http://www.webthatworks.it