Re: Thinking beyond 1.0 (e.g 1.1, 1.2) -- more feedback please

[David Blevins <da...@visi.com>]

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
>
>

Re: Thinking beyond 1.0 (e.g 1.1, 1.2) -- more feedback please

[Joe Bohn <jo...@earthlink.net>]

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     

joe.bohn@earthlink.net 
"He is no fool who gives what he cannot keep, to gain what he cannot lose."   -- Jim Elliot