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 [EMAIL PROTECTED] 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 - http://tinyurl.com/86ke5 - 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 > > http://www.joelonsoftware.com/articles/fog0000000069.html. 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 ages. > 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? Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
