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]
