[development] RFC: drupal as a moving target

[Ivan Sergio Borgonovo]

On Mon, 28 Apr 2008 17:35:35 -0700
"Steven Peck" <sepeck at gmail.com> wrote:

> >  And I don't think anyone is willing to scare off someone that is
> >  going to write a 10K line module just because he doesn't get
> > involved in core dev. And anyway it seems that core decisions are
> > made among a 10-20 people.

> See now, what is this?  This is one of those 'what if' emotional
> blackmail/threat things that are false justifications for arguments.
> What if someone... was willing to save us if we did as we were told?
> What if someone... would invest in Drupal if only we gave up
> 'something' or change 'something else'

This is not a black mail. I already made a 8000+ line investment in
Drupal, I hope it will be out of the gates in the coming weeks.
There will still be some rough edges since some parts have been
highly customized for a specific situations and it may not be ready
for public consumption as soon as it is released.
I plan to make it publicly available under GPL no later than 1 week
from when it will reach production.
But considering I wrote it as an investment it should be enough
elastic to be made even more general in the parts where due to timing
constraint I had to chose a less general path.

I still think that it would be a good thing the more Drupal get
mature the less contrib modules have to be involved in core.
Earls is the author of 2 important modules that actually would take
great advantage from core changes. Other modules may prefer
"decoupling".

I've heard you already made some pool and that the idea of keeping
Drupal API so fluid is still welcome. Still this topic resurface
regularly.

May I say that the 5.X -> 6.X -> 7.0 looks like a rough path at least
for me?
Larry said that the cost of upgrade is nearly 60% of the cost of
building things up and that most of its clients can't afford it.

With a 2 years life span and a cost of upgrade of 60% you're going to
have a hard time to write modules of thousands lines. Still I'd
consider modules of several thousands line valuable for the overall
Drupal project. Actually I'd consider such module more valuable
because few people take the risk of such a long term investment.

Now... isn't it the time to lower that cost just managing upgrades
differently?
Are you saying that welcome contribution are just the one of smaller
modules of few lines that see the light in a week and the one that
take place in core?
That anyone that has no time to send more than a few patches to core
since he is busy to write a 10K line module has no words on core dev
life cycle?

If we just vote with our direct contribution. Once I'll finish my
module I'll vote with my non contribution and switch to something
else since if you insist in this wall against wall and calling names,
it doesn't look the place where I can make long term investments.

Again... I know there are people in core that know how to write code
and how to design it. I know there are people that have the right
skill to understand software management and planning.
Even Dries wrote *at present time*... when did he wrote that? 2 years
ago? more than 2 years ago?

As a contrib developer and occasional contributor to drupal code I'm
expressing my need to lower that percentage and I feel that my need
is in line with the reached maturity of Drupal.
I don't think it is not in line with natural life cycle of any
project getting more mature and I don't think I'm an isolated case.

Is Drupal market place the one for 2 years web sites?
A sort of RAD for small sites?
This market place has its dignity too.

Or is it willing to become a RAD for something more complex where you
can put a larger investment in.
I forecast I'll have a hard time to port my work to 6 or to 7. I may
be wrong, but I'm concerned and I'm asking do you think that the
coming versions will take into account the cost of upgrades more than
now?

Is it mature and complex enough that API don't have to be changed
twice in a row for the same functionality, so that changes for
each releases will impact just few aspect so that can be easier
managed during an upgrade cycle?
Maybe radical but circumscribed changes so to be more manageable?
Is there any interest in lowering that cost percentage so people will
see flourish contrib projects that span more than few hundreds lines
or are times still not mature enough?
I know that lowering the cost of upgrades may have an impact on
development speed... but well resources aren't illimitate for any
project... it is just a matter of deciding where they give the best
ROI.

Does it sound not respectful?

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