Hi Stefano, a really nice fairy tale...
I totally agree with you, that we should get this release out very soon, but as the last months when we released the betas and the rcs showed, there were many new users which very totally frustrated with c2 as they didn't get it working. And I think 80% of them could have been helped if the documentation were more complete. OK, they all could use the mailing lists to get their problems fixed, but the usual user doesn't want to do so. He will something which simply works. And I really don't want to say: "Who cares about them?" And I personally don't want to say: "Hey, it's opensource, so what do you expect?" We all here know that Cocoon is a great piece of softwarwe, but for what, if noone except some geeks can use it? Ok, you argue that all these users will join the developer site and help us. This might be true. Who knows this? So, my plan was to get as much documentation as possible and use this time to sort out some other areas (like the directory structure etc. in the meantime). Not all of us are capable of writing good documentation and they can spend their time on the other things. But of course, you're a right that the directory structure should not delay the release. Ok, at least, the gap between our opinion about the final release date is not that wide. Let's see how we can make it? What about this? We leave the directory structure as it is for now and we add any documentation that is currently in the pipeline. If noone is currently working on documentation, we will do the release on monday as proposed some month ago. If there is someone working on it, he should comeup now and say if he it is worth waiting for it. Carsten Stefano Mazzocchi wrote: > > Once upon a time, > > there was a group of distinguished software engineers (also known as > 'geeks') who were redesigning a piece of software called "Cocoon". > > The geek who started all this was young and even was the technology so > he made a bunch of design mistakes trying to get it right the first > time. Other friendly geeks came, showed him the mistakes and worked > together in peace and harmony to come up with a new version that would > remove those issues. > > Being the second attempt, they called the effort "2.0". > > Seasons passed and the productive geeks were crunching lines and lines > of code and the more noise they were making, the more geeks were > attracted by this idea of the big "2.0" release. > > They knew how painful it was to discover the limitations of the first > release so, this time, they want to make it *right*. > > So, everytime somebody passed by and had to suggest something they found > important, they kept on saying "oh, this is right, the users will love > this, let's move this pixel down one spot". > > They were trapped in the "2.0 syndrome": an endless loop of postponing > the release for the fear of having to modify it again in the future. > > So they continued to work and work and work and they were producing an > incredibly valuable software, but their community died because nobody > could ever see what they were working on. > > The end. > > - o - > > Result: let's get this damn release out, people! > > Documentation is not good enough? who cares! > > Files are not in their *best* position? we'll move them later. > > It seems that everyone around here has gone nuts: in case you didn't > know, we are *NOT* a software house and the people using our software > are *used* to open source and "fixme" tokens scattered around. > > The *ONLY* thing we should be concerned for a final release is if the > *contracts* users will build on are *solid* enough to be considered > final. > > *contracts* people, CONTRACTS! > > Do you build your software on the location of our files into the > distribution? well, if you do it, you're nuts. > > Do you build your software on the wording of the documentation so that > if they change you're screwed? no way. > > Gosh, where did "release early and often go"? down the drain? > > Linus Torvalds invented the concept of open development by making a > kernel release *each* *day* for months! [of course, he never used CVS so > he was forced to] > > I started Cocoon 2.0 in November 1999. > > It took two damn years and we want to move files around few days before > final release? Are we going insane? > > The question is simple: are the code contracts (interfaces, components, > API, schemas, protocols) solid enough for a final release? > > If so, we release *NOW*. > > If not, we fix it. > > *ANYTHING ELSE* can be added to 2.0.1 or 2.1 (depending on what naming > scheme we'd like to use) > > Moreover: your *elegance taste* might tell you that the better a > software release is, the more people will use it. > > This might be correct (nobody knows). > > But, this also creates a big user community but doesn't help the > development one. > > We want people that uses cocoon in order for them to come here and help. > This is the final goal: the more hands the better. > > Is anybody going to help us if they find everything already good and > perfect in the final release? > > I love slightly confused distributions because they force you to come > back and interact with the community. > > This is the way I infected all of you: Cocoon 1.0 should have been > called Cocoon 0.01alpha but then we would now aim for Cocoon 1.0 today, > but I'd almost be alone around here. > > yes, people, I fooled you with inflated version numbers. > > Now, tell me, was I successful in creating this community? well, you > have to use a couple of tricks. > > And believe me, *polishing* a final release lowers the chance of > building a community around it in open source, unlike common sense seems > to suggest. > > So, guys, even if I totally understand your concerns, let's cut the crap > and release the damn thing as far as contracts are solid and *build > dist* works. > > We'll polish it down the road. > > -- > Stefano Mazzocchi One must still have chaos in oneself to be > able to give birth to a dancing star. > <[EMAIL PROTECTED]> Friedrich Nietzsche > -------------------------------------------------------------------- > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
