> FWIW, this has been running on cocoon.cocoondev.org for more than two > years, but I pulled it down due to lack of hits. Similarly, I will be > dropping the webmail.cocoondev.org demo soonish.
Too bad I didn't know this before. But maybe that's exactly the reason for the low hitrate: too few people knew about it and therefore too few people referred newbies to it. > Some recurring complaints were: > > * documentation (oh well) > * cohesive direction (as in: _only_ explain folks about > things like the > power trio, and make sure these things work flawlessly, and > stop being > hesitant about deprecation and removal of alternatives) > * prune, prune, prune: make blocks separately downloadable, and drop > blocks which aren't supported nor used > * make sure people don't need a bit of everything to build a decent > Cocoon app (as in: some Actions, some Input modules, some Javascript, > some Java, a bit of CForms, a choice over various O/R efforts, some > Springkles here and there, and so on and so forth) > > The last one doesn't mean people shouldn't use all this, it's > just that > all this is now perceived as totally separated, isolated, > unrelated and > incohesively documented stuff. True, from a simple user's perspective: it is difficult to figure out what the best practice currently is. I joined the Cocoon community exactly one year ago and since then have seen the rise of flow, the "deprecated as best practice" of XSP and multiple other major changes. Cocoon is exciting stuff and the community is wonderful. I truly believe that the community of committers and active contributers is a self-organising development team of a size that can hardly be found in any business. Something many businesses could learn from. Too bad the quality of Cocoon is obscured by the perceived complexity. I know I'm currently not contributing more than just some posts on the discussion lists, but I do hope that some of my comments spark great ideas in others that do have the time, knowledge and resources to actually do something about it. > The JBoss folks were right when they told me over drinks that > Cocoon is too much of a research project. > > Just to give an example: JXTG isn't even used massively (too > many folks still stuck with XSPs), and already we start chatting about JXTG-NG. This might be a valid argument to keep the rate of new things down. > How should users believe we actually care about them? > (= literal remark I got yesterday!) But I don't see how this is connected. After all deprecation of "old" technology is done after extensive discussion on this list and then there is still support on the users list. I must confess I haven't read up on all the "roadmap" and "cocoon's future" threads, so I don't know if I now propose something that's already there. I just wonder if it is possible that those of you with in-depth knowledge of Cocoon and the way open source communities work, can investigate other major open source projects like Apache server, Mozilla/FireFox, Tomcat, JBoss for that matter and see what makes them different, "better" if you like. I'm not talking about documentation here. There are already steps taken in the right direction. More like: the rate of new releases, deprecation of older techniques, the number of ways to solve a problem, user support. I've seen you guys discussing this for Cocoon and coming up with rules of thumb that most of you stick too. So where are you in this when you compare this to the other major open source projects? Bye, Helma
