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 22:24:05 GMT
On 12/4/05, Daniel Fagerstrom <> wrote:
> Gianugo Rabellino wrote:
> >Daniel,
> >
> >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,
> >
> Sorry, while I'm not juging people, I base my trust on what they will
> deliver in the future on what they have delivered in the past, rather
> than on promisses that everything will be different this time.

Are you sure you're being fair to this community? Just look back and
see what people has brought you before many of us even faced up: this
is what has been delivered in the past, and it's no peanuts to me.
Sure enough, if you consider the past year or so, there has been a lot
more talk then just code, but I don't think it's fair to look at what
we're currently discussing with a snicker, thinking that it's "just
talk as usual". This team did deliver lots of good stuff, then, while
enjoying some success, lost somehow motivation. What you don't seem to
understand is how, even among this closed group of highly committed
people, who nearly bet the house upon Cocoon, there is a clear will to
move on and, while at it, have fun again.

> >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.
> >
> We are having a soft revolution right now, I ask you and the rest of the
> community for some persistance instead of start running in still another
> direction.

I'm sorry, Daniel, but what I'm seeing doesn't look interesting enough
to (re)attract a large user base over here. Of course what I'm
expecting from 2.2 is a set of very nice improvements and some
solutions to a few problems, but I don't see how blocks would take the
real complexity out of Cocoon. Or better: some complexity will be
hidden, but still using Cocoon will mean committing to it and to the
way it does things, which is increasingly of little interest to the
vast majority of web developers out there. No fun, no gain.

And, to answer your specific question, yes, we can stick a few more
months watching you guys doing a terrific work in rationalising
internals, but even if you were doing the best work in the world, once
finished you'll risk to hear us saying "hmmmm... so what?" again and

> >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.
> >
> How can you be so certain that we would getting less complicated if we
> started from scratch? It might be complicated because it does something
> complicated. As long as you don't understand the internals you cannot
> really know, can you?

Sure, I might not grasp completely what's going on under the hood
today. But my gut feeling is that Cocoon is overengineered in many
parts of it and not correctly layered on some other parts. I have a
few opinions about it, but they are way off topic in this discussion.

> Managing complexity is much about finding the right concepts and work
> really hard to get the right interfaces. The people who built Cocoon
> from the begining spent a lot of time and effort in getting the apis
> right. Since then we have made the apis bulky whithout doing that much
> refactoring to keep things simple.
> What we need to do is to refactor and rearchitecture Cocoon so that we
> get rid of bulk that isn't used anymore. And to adapt for things that we
> would like to add.

I have the feeling that we're saying the same thing. What you don't
seem to grasp is why there is a camp that feels this is actually
Cocoon 3, something different from what we have now, something that
can be - and here is where we differ - achived best with revolution
rather than with evolution. Now, I think there is a major
misunderstanding in what "start from scratch" really means: to me, it
means getting back to the drawing board, trying to reuse what can be
reused but being ready to ditch unnecessary load just because it could
be incompatible with the vision.

> Every time I try to discuss apis people get bored. So I have not much
> faith in that the current community would end up with something better
> and more elegant than what we have if we started from scratch. Neither
> do I see that anyone would be prepared to spend the time and effort that
> it would take.
> But please, suprise me.

Oh, definitely hope so! :-) The good news for you is that so far such
attempts had a tendency to sudden failure, so I guess we'll see in a
very short time if this could be the right occasion to move things
forward or if we'll wake up to the 2.2 reality instead than pursuing a
3.0 vision. Won't take long, methinks.

> >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)
> >
> I'm sorry that Stefano and I and others have failed to communicate to
> you why blocks rocks. I guess I just can say that they do rock and that
> they solve a lot of our current problems.

Well, I think I do know at least something that blocks will buy us.
But again, what I'm questioning is whether the problems that blocks
solve are self-inflicted pains (love that wording, Berin) or real
problems that have a direct impact on users. So far what I'm seeing is
the need to learn yet another tool (Maven2) to manage block's
complexity: does that *really* go in the direction of helping users?
I'm not that sure anymore.

> >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.
> >
> >
> I think we are a bunch of CTO types that where really good programmers
> in the past but have been used to that someone else does the programming
> and that it is enough for us to talk ;)

You know, this wink actually makes a lot of sense. It's definitely
true that in these past five years many of us (myself included)
switched to the "executive" field. It could possibly be that this
Cocoon 3 discussion is also an excuse to fire up that IDE again, but
do remind that there are no CTOs in OSS: I'd rather talk about
motivators and catalysts. Fair enough, we have to show some code to
see the final proof: we'll see if these old farts can come up with
something nice. :-)

> >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?
> >
> >
> Real blocks.

Nah. Real blocks don't seem to solve real issues, to me. Love to be
proven wrong, of course: the idea of ditching stuff really doesn't
have a strong appeal to me, unless it's a last resort alternative.

> >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.
> >
> >
> It is so easy to ditch other peoples work, isn't it?

Oh, come on Daniel, you're taking this personally. I strongly respect
and admire what you've been doing to push Cocoon 2.2 forward, but you
also have to realize how hard it would be for you to carry the burden
of being the main responsible for such a core part of Cocoon without a
real committment from the community, which I'm not really seeing at
the moment. You should realize how the biggest feeling floating around
the Cocoon community is that we want to do something to make Cocoon
fly and soar high in the skies, instead than strive to survive its own

> >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?
> >
> >
> I started to work on blocks in April this year,
> since then I and others have implemented most of what was discussed in
> 2002 and have a good plan for implementing the rest.

Again, you shouldn't take these discussion as a personal attack to
your work as in you not being fast enough in completing the journey to
real blocks. What happened here is that people started to realize how
real blocks aren't the real solution to what our audience wants, no
matter how big and great they might be.

> >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?).
> >
> >
> I guess there are many reasons for people looking elsewhere. IMO, some
> important reasons is that Cocoon is incoherent and that it is hard to
> develop it further. That we never release so that you never get the
> pleasure of being able to use your new code and innovations in new
> projects or seeing other people use it.

OK, that's a great way of pointing up symptoms, and we basically all
agree on them. Can we move on to diagnosing the reasons for that and
finding a cure? Can you try and prove us wrong when we say that the
current mix of community and code base doesn't seem likely to bring
innovation back to Cocoon-land?

> >>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.
> >
> It is, but it is so different wrt rewriting from scratch?

Yup. Because Open Source as a whole can afford it. Because Open Source
as a whole doesn't have a real budget or a mission when it comes to a
project that counts as a drop in the ocean. Because the Open Source
communities swarm around cool technologies and, just like locusts,
tend to abandon fields where the technical stuff is basically over.
That's the flip side of the coin, of course, we all know the major
pluses that come from this very peculiar environment, and I think we
all want to leverage them.

And, then again, clean slate doesn't necessarily mean rewriting from
scratch: what we're trying to achieve is a drastic semplification on
the way Cocoon is built today, while following the usual goal of world
domination through XML pipelines and continuation-based webapp

> >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
> >ages.
> >
> >
> I agree with Sylvain about much of the suggested improvements, but not
> about starting from scratch.

I think here Sylvain might shed some more light on what he does mean
exactly with starting from scratch: I can only reiterate that what I
mean with that is starting with a clear mind, ready to abandon
unneeded stuff if it make sense, while trying to retain as much as
possible of what we've got now.

> > maybe the problem is elsewhere, e.g. the current core being too
> >heavyweight and the user visible part being way to hard to understand?
> >
> Yes, it needs refactoring.

Let's then see what we mean with refactoring: it could well be that
what I consider a rewrite in large chunks is just refactoring to you.
I have the feeling that if we take personal feelings like ditching
other's people work off from this discussion, we have a good chance to
get very far. Just keep the ball rolling.

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

View raw message