cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianugo Rabellino <>
Subject Re: [RT] The next shiny thing?
Date Sun, 04 Dec 2005 18:53:27 GMT

thank you for taking the time to write this. I understand your
frustration, since the behaviour you're describing in your email has
clearly been a recurring pattern lately on dev@cocoon. However, I'd
like to ask you to try and see beyond what happened, asking yourself
why we have been able to build Cocoon 2 but we seem not to be able to
go any further: the answer to that, to me, clearly denotes the need
for some kind of (soft?) revolution, e.g. Cocoon 3.

My reading of what's happening over here is that we've got to a point
where Cocoon internals have become way too complicated, way to
difficult to understand and way too difficult to interact with: I
think we'd need no more than one hand to count the number of (active)
people over here who could comfortably talk about the pipeline engine,
the sitemap interpreter, the caching sytem and all that. We could go
on for ages and try to find a temporary solution (no matter how
architecturally sound) hoping that people like you get interested into
the framework in order to better separate stuff, but to me it's pretty
clear that we wouldn't be going anywhere far. So:

> The main problem with our community, IMO, is the lack of focus and
> persistance. We have so many great ideas, but as large parts of the
> community always are running towards the next shiny thing and have very
> little interest in polishing the design, contracts and implementations.

I don't buy it. It might look like that, and I understand why you read
it as that, but to me the truth is that there is little to no interest
in providing a small relief to a huge headache (I still have to
understand why real blocks would rock, apart from being ubercool
technically wise) when the amount of code to understand before you can
actually "fix" something is so massive that it makes your head spin.
And this is just talking about fixing existing stuff, when it's pretty
clear that we need to move way forward if we want to stay ahead of the
flock (something we *always* did in the past and we're failing to
achieve at this point).

> After having been around for a couple of years, I start to recognize our
> development cycle: First a new sexy idea is suggested, and we all jumps
> up and down shouting out our excitement. Then we might start to discuss
> design and implementation, and most people lose interest or maybe drop
> by and complains about that the discussion have become technical and
> that it bire them stiff. After that some people might even implement it.
> And as it often takes a lot of work to design and implement cool stuff
> it takes a while. And when it finally start to get somewhere, people are
> not even remotely interested anymore because there is something new and
> shiny to jump up and down and shout about.

So true. But you have to live with it and ask yourself why that new
and shiny stuff that got people so excited wasn't that sexy after all
to overcome the inertia of actually making it work. Either we're a
bunch of creative people with no technical skill (and no, I don't
believe that), or there is just *way* too much inertia to make
anything happen with the current codebase. I clearly buy the latter.

Community based Open Source shines when there is a (small) number of
technically strong people that provide a codebase where even medium to
low range guys can interact with: this happened in the very first days
of Cocoon 2, when everyone and his dog provided additional components
so fast that we soon filled up the available space, so what's next?

Are we looking for more de-facto one man shows with code spikes that
inevitably lead to frustration and make people disaffect or leave? I'd
much rather jump on what are the challenges we foresee and try to
catch them, even if that means ditching most of what we've got so far.

> Instead of focus on our core ideas and functionalities, and ensure that
> we have real high quality implementations of them, we just add still
> another prototype implementation of something new whithout bothering
> about how it integrates with the rest of what we have.

This is not so true. Sylvain's discussion is catalyzing an important
message there: there is really no reason to bother about integrating
with existing stuff, because this would just make things worse.
Rewrites are risky, that's true, but anything that takes more than
three years to become real is doomed to fail (this - - isn't the earliest example I could find,
but it shows you we were talking blocks back in 2002). When are we
going to realize it?

> So I'm sorry, I will not jump up and down and shout together with the
> rest of you this time. I will persist and continue with the work in
> trunk on what I think is important:
> * finishing blocks
> * make the m2 build system work and become the only one
> * binary releases
> * strengthen the contracts
> * improve the quality
> * split up Cocoon in smaller parts
> * deprecate things that not are or not should be used anymore
> * strive for coherence
> * refactoring and rearchitecturing mercelesly
> * 2.2 during Q1
> This work will continue to be evolutionary and incremental. And when we
> have the block system and have cleaned the contracts and the messy
> implementation of the core, it will be easy and safe to experiment with
> new great ideas. And we are getting rather close to this point, we just
> need to finish what we have started. And for the messines we solve that
> with refactoring.

Gosh, Daniel, an outstanding agenda. I'll be watching closely what
seems to be a notable list of accomplishments, hoping to help out as
well (whatever happens to 3.0, I intend to provide strong and
long-standing support for 2.x as well, so every step further is most
welcome). But I'm also most interested in seeing things moving forward
from a community point of view, stopping the drift of people looking
elsewhere (there must be a reason for that, right?).

> quite risky to try to rewrite everything from scratch, although I have
> felt the urge myself countless time while struggling with the messy
> internals. But before you go ahead and rewrite everything from scratch,
> take some minutes and read why Joel Spolesky thinks that rewriting
> software from scratch is the:
>   *single worst strategic mistake* that any software company can make

Two notes here:

1. Joel is talking about companies. Open Source is *much* different.

2. I don't read Sylvain's proposal as a "let's dump everything". What
I see is a different and fresh approach to real issues, and a solution
that goes towards maximum reuse of what we've got so far, ditching as
much as we can of the infrastructure burden we've been carrying on for

> For the actual functionality that Sylvain proposed I think much of it is
> great and I have argued for things similar to some of them earlier. And
> they can be added in an incremental way.

Here is where we basically disagree. I have this feeling that, unless
a major revamp, there is a very slim chance for Cocoon to progress
incrementally. I thought OSGi would have helped, with modularization
and the like, but as you can see, this is clearly has not been the
case: maybe the problem is elsewhere, e.g. the current core being too
heavyweight and the user visible part being way to hard to understand?
These are my major gripes at the moment, and while I still do believe
that the steep learning curve of Cocoon pays off big time, I've come
to think lately that we could actually do something to make it better.

> Leaving our core offering and rewriting everything from scratch means
> community and product suicide, don't do it.

Again, I don't feel this is rewriting from scratch. And while I see
your point, I can clearly a stagnation and starvation risk ahead if we
don't shift gears and move on. How would you risk manage that?


Gianugo Rabellino
Pro-netics s.r.l. -
Orixo, the XML business alliance:
(blogging at

View raw message