geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <david.blev...@visi.com>
Subject Re: Thinking beyond 1.0 (e.g 1.1, 1.2) -- more feedback please
Date Wed, 20 Jul 2005 17:45:09 GMT
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
>
>


Mime
View raw message