OK, you asked for it so here is my opinion.
I agree that once R1 is delivered there should be no more milestones ...
but rather maintenance releases. I assume
that by not doing milestones we will be creating new releases instead.
This is what should be planned out in our
roadmap. We should have a general statement like "we will build a
maintenance release (which may include minor
enhancements) every 6-8 weeks." I think we should strive for a major
release every year or sooner. The thing
that I've seen stymie other projects is to get so wrapped up in
incremental change that the "big things" can never
really get done because there just isn't enough time. Having a roadmap
and focusing some energy on larger
items that are targeted for new releases (or span multiple smaller
releases) would help to prevent this problem.
It's also been my experience that nobody really installs release 1.0,
2.0, or x.0 on any production system. It is
always assumed that there are bugs that still need to be worked out so
most people will wait until a .1 or .2 release
before moving it into production. This is also another reason to
ensure that we have regular deliveries that
follow the "large" releases to "clean up the loose ends".
David Blevins wrote:
Panagiotis,
Thank you very much for posting some feedback. We need a lot more
people like you helping us with direction and feedback!
Hey everyone, seriously, post! We are here to serve.
Best regards,
David
On Jul 20, 2005, at 3:16 AM, Panagiotis Astithas wrote:
David Blevins wrote:
We are still hammering on M4, so I don't want to distract people
to much. Just want to get people thinking.
I have a couple things in my mind still in the abstract. Will try
to get them out in some sensible way. Bare with me.
<rambling>
RELEASE OFTEN, PERFECT OR NOT
Amen :-)
Ok, so it's been a year since M3 (ouch) and we have threatened to
do an M4 several times. Why did we keep putting off M4 even
though we knew very well M3 was no good? I think the reason is
something along the lines of 1) being optimistic in many forms, 2)
wanting the next release to be some form of perfect, 3) being
focused on a couple (or one) very large goal.
More important than 1, 2 or 3 is time.
Let's ask ourselves:
- How much usablility feedback could we have gotten in an entire
year's time?
- How many releases could we have done in the last year?
- How many would-be committers and users did we miss out on by
not releasing?
It is interesting that even Erich Gamma (among others) considers
this to be an important factor in building a thriving community
around Eclipse:
http://www.artima.com/lejava/articles/eclipse_culture.html
Let's be more humble and admit that every release is going to
"suck" to some degree (i.e. not be perfect) and it's better to
work on getting them out faster, not slower.
We need to stop making such a bid deal about the next release,
which only slows it down, and start thinking two or three releases
out.
Normally some form of competition would drive us to push releases
out the door quickly and keep our goals in check with what people
really do need now and what they would be fine having later.
There is competition out there, but it's us not competing with
them, not the other way around. Sorry, just calling it like I see
it.
MILESTONES AND USABILITY
Alright, IMHO, we've outgrown milestones. Better said we've
attained our goal of passing the CTS, the major technical
milestone. Now we all are focusing on usability. From my
experience, obtaining usability is all about iterations, as many
as you can get and as often as you can get them. I think
milestones will actually slow us down on achieving our goal of
usability.
We are going to have to crank out a half dozen releases minimum
over the next couple months in order to achieve the kind of growth
we want. At this point in the game it's all about momentum. We
need to be an unstoppable freight-train leaving a trail of release
numbers behind us and picking up as much community we can carry as
we go forward.
Precisely!
Pushing a milestone every three months is not going to cut it, nor
is Geronimo 1.0 M12 such good idea either.
While Geronimo 1.0.8 is perfectly fine.
1.0, THE UNATTAINABLE GOAL (CROSSING THE LINE)
The 1.0 release is not about the cool things we want to add to
make Geronimo great. It's about reaching a point where you and
the users agree on what will be supported in a year's time, which
won't be much as it's a 1.0, not a 2.0 or 3.0 or 4.0. That's it,
no more, no less. All sorts of cool things can be added later!
We should also keep in mind that hardly anyone is going to recommend
a Geronimo installation in production while still in beta versions.
Here is the point where I have particular experience, ... you will
cross that magical "1.0" line at some point, wether you choose to
call it 1.0 or not!
At some point, people will start using the software and become
dependent on whatever you are at the time. Their expectations
will naturally settle on what you have and not where you say you
are going. 1.0 or not, you now have to maintain stability, only
you weren't so clear on what was going to change and what was to
remain supported (be at least backwards compatible), so now you
are in the position to have to support much more than you wanted.
</rambling>
Anyway, those are my rambling thoughts and experiences. Just
throwing them out there for now.
-David
I've been seeing many open-source projects gradually transitioning
from feature-oriented releases to time-based ones. Users tend to
upgrade regularly, treating software like a constantly evolving
organism that grows and matures.
Regards,
Panagiotis
--
Joe Bohn
[EMAIL PROTECTED]
"He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
