On 12/4/05, Daniel Fagerstrom <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] 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 again. > >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 complexity. > >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? > > > > > I started to work on blocks in April this year, > http://marc.theaimsgroup.com/?l=xml-cocoon-cvs&m=111411975927551&w=2, > 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 > >> > >>http://www.joelonsoftware.com/articles/fog0000000069.html. > >> > >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 development. > >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. 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/)
