You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Sam Ruby <ru...@apache.org> on 2002/11/24 18:44:57 UTC

The Rules of Open-Source Programming

Why does the Phoenix [1] page *still* say that it is the reference 
implementation?  Is everybody waiting for Peter Donald to do it?

If you have time for an amusing diversion, take a look at the Rules for 
Open-Source Programming [2].  Be sure to read the Meta-Rules first as 
you will inevitably find that the rules when taken as a whole are 
self-contradictory and some are outright false.  But as with most humor, 
each nugget is based on a kernel of truth.

Mostly, I would like to draw your attention to Sunir's corollaries [2]. 
  In particular, the statement that "as long as the project *looks* like 
one person's work, it *is* one person's work."

Until the recent global change eradicating personal @author tags, 
approximately 75% of the source files in the framework had Peter's name 
on them.  This exceeded the number of files which contained an author's 
tag with any other name.  Combined.  (Out of 62 files, 46 contained 
Peter's name, 45 contained any other name, 17 contained only Peter's 
name, and only 16 did not contain Peter's name).

I suspect that if you narrow the focus to recent history, the results 
would be even more dramatic.  It is clear that Peter has the drive, 
ability, interest, and dedication to out-code the rest of the project 
combined.  He also challenges each contributor to maintain the highest 
standards of quality and attention to customer requirements.

In many contexts, these would be good things.  And, in moderation, these 
are good things here.  But things are out of balance in Avalon.  Lately, 
this project *looks* like one person's work, and Sunir's observations 
apply.  In particular, I notice that several members of the community 
seem to derive a tad too much pleasure in the rare events where Peter is 
proven wrong.

The alternative is to require consensus.  Strive always to do as Noel so 
eloquently described [4] with the words "we did it as a community, we 
support it as a community, and if necessary we'll fix it as a 
community.".  Achieving this will require changes in behavior from 
pretty much everybody here.  It will also be hard work.  And require 
much patience.  And endurance.

Meanwhile, there is some low hanging fruit.  For starters, it is 
detrimental to the community for the words "The reference 
implementation" to appear prominently on the Phoenix page [1].  Peter 
has already indicated that this wording was a historical accident.  So 
what's everybody waiting for?

- Sam Ruby

[1] http://jakarta.apache.org/avalon/phoenix/index.html
[2] http://www.advogato.org/article/395.html
[3] http://www.advogato.org/article/395.html#5
[4] http://marc.theaimsgroup.com/?l=avalon-dev&m=103802938922576&w=2


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: The Rules of Open-Source Programming

Posted by Leo Simons <le...@apache.org>.
not understanding why exactly we're talking about this, I had a good
laugh......

On Sun, 2002-11-24 at 18:44, Sam Ruby wrote:
> Why does the Phoenix [1] page *still* say that it is the reference 
> implementation?  Is everybody waiting for Peter Donald to do it?

the usual answer would be along the lines of (though in different
wording) "apparently, no-one was bothered enough to fix it in the time
frame that you would like; you are welcome to provide patches....if you
persevere in providing valuable input, commentary, documentation,
patches.......rather than just asking others to do work....we'll thank
you very much, be very happy, and we'll happily make you part of the
"everyone" that can actually make the fix!"

or something like that. Such a statement doesn't apply here at all
(you're not here to contribute code or anything like that; you're using
this as an example of pointing out community issues), but I am terribly
inclined to make it anyway. Conditioning :D

> Mostly, I would like to draw your attention to Sunir's corollaries [2]. 
>   In particular, the statement that "as long as the project *looks* like 
> one person's work, it *is* one person's work."

Also found this on the same page:

 1. Always give attribution. If you don't, you're not doing free
software, no matter what the license lets you get away with. 

there's your contradiction :D

> It is clear that Peter has the drive, 
> ability, interest, and dedication to out-code the rest of the project 
> combined.  He also challenges each contributor to maintain the highest 
> standards of quality and attention to customer requirements.
> 
> In many contexts, these would be good things.  And, in moderation, these 
> are good things here.  But things are out of balance in Avalon.

in some areas (example: XCommander (in an obscure corner of some avalon
cvs somewhere is definitely a one-man-show). Where it matters most
(speaking technically), not.

> The alternative is to require consensus.  Strive always to do as Noel so 
> eloquently described [4] with the words "we did it as a community, we 
> support it as a community, and if necessary we'll fix it as a 
> community.".  Achieving this will require changes in behavior from 
> pretty much everybody here.  It will also be hard work.  And require 
> much patience.  And endurance.

I like. Next action item :D

> Meanwhile, there is some low hanging fruit.  For starters, it is 
> detrimental to the community for the words "The reference 
> implementation" to appear prominently on the Phoenix page [1].  Peter 
> has already indicated that this wording was a historical accident.

dead wrong, btw. I think I put that in, and I think I put it in because
I believed it would be a good idea for avalon to have one authoritative
container codebase and one only (with everything else in non-apache
cvs). I still believe we need a reference implementation, but I
understand now (well, quite some time ago) phoenix is not and should not
be that :D

cheers,

- Leo



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: The Rules of Open-Source Programming

Posted by Peter Donald <pe...@realityforge.org>.
On Mon, 25 Nov 2002 21:25, Leo Simons wrote:
> > No, Sam, Phoenix *IS* one person's work. As Merlin is.
>
> that first statement is not true. I think it is unfair to the other
> people that contribute and work on phoenix to keep making statements
> like this. Please stop.

agreed.

> Peter has never pretended to be a leader (disagree? just find me an
> example or two :).

Peter has pretty much gone out of his way to make sure he is not seen as a 
leader :)

-- 
Cheers,

Peter Donald
------------------------------------------------------------
 militant agnostic: i don't know, and you don't know either.
------------------------------------------------------------ 



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: The Rules of Open-Source Programming

Posted by Leo Simons <le...@apache.org>.
On Mon, 2002-11-25 at 01:10, Stefano Mazzocchi wrote:
<lots-of-snips/>
> more than these statistical details, I would like to know if somebody 
> ever implemented something in Phoneix that Peter didn't like

yes

> or voted -1 on.

no (IIRC)

> No, Sam, Phoenix *IS* one person's work. As Merlin is.

that first statement is not true. I think it is unfair to the other
people that contribute and work on phoenix to keep making statements
like this. Please stop.

The second started out as true and will shift toward not true if things
go happily. If not it will probably become zero person's work.

> History proved me dead wrong: Peter has not been able to create one 
> single healthy and diverse community around his code. This is an 
> indisputable fact and would not be bad by itself (a committer isn't 
> required to be a consensus builder) but it *is* bad for somebody that 
> pretends to be a leader.

Peter has never pretended to be a leader (disagree? just find me an
example or two :).

Two more objections: I object to "single healthy and diverse community"
not existing (but keep saying it for long enough and it will come true
(I think paraphrasing yourself ;)), I also object to "his code" (again
keep saying it long enough....)

ta-dah: disputable facts :D

> Yes, I'm saying this in the open because I would like other people to do 
> the same with me.

another "Rule" from Sunir:
The task for the leader of a team project is to work on the team, not
the project.

I'd say "primary task", but otherwise I'll happily say that with you.

cheers,

- Leo


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


RE: The Rules of Open-Source Programming

Posted by Paul Hammant <pa...@yahoo.com>.
> 
> > Out of Avalon-Framework, we proposed the same jar split to 
> > cornerstone.jar and got it thru despite Peter's objection.
> 
> Again, I believe that JAR multiplication isn't the solution.

It's your choice dude, there are three jars :

1) cornerstone-api.jar (10K)
2) cornerstone-refiml.jar (40K)
1) cornerstone.jar (50K)

(not sizes are representative).

Different container makers use different combinations of jars in different classloader
configurations.

There is no revolution described here....

- Paul


__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


RE: The Rules of Open-Source Programming

Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Paul Hammant [mailto:Paul_Hammant@yahoo.com]
> 
> Stefano,
> 
> > more than these statistical details, I would like to know 
> if somebody 
> > ever implemented something in Phoenix that Peter didn't 
> like or voted 
> > -1 on.
> 
> There are numerous I'm sure.  Servicable was a triumph of 
> group design, 
> with Peter (as well as a number of us) modifying proposals 
> multiple times.
> 
> More recently Peter -1'd the split of avalon-framework.jar 
> into two 
> (three incl existing).  Having said that he's not longer objecting.

But I am :P

You can't expect everyone to follow suit with the implementation
and API in separate JARs.  Even Sun combines them.  There are
solutions that don't impose packaging requirements on others.
I suggest we pursue those.


> Out of Avalon-Framework, we proposed the same jar split to 
> cornerstone.jar and got it thru despite Peter's objection.

Again, I believe that JAR multiplication isn't the solution.

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: The Rules of Open-Source Programming

Posted by Paul Hammant <Pa...@yahoo.com>.
Stefano,

> more than these statistical details, I would like to know if somebody 
> ever implemented something in Phoneix that Peter didn't like or voted 
> -1 on.

There are numerous I'm sure.  Servicable was a triumph of group design, 
with Peter (as well as a number of us) modifying proposals multiple times.

More recently Peter -1'd the split of of avalon-framework.jar into two 
(three incl existing).  Having said that he's not longer objecting.

Out of Avalon-Framework, we proposed the same jar split to 
cornerstone.jar and got it thru depite Peter's objection.

- Paul



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: The Rules of Open-Source Programming

Posted by Stefano Mazzocchi <st...@apache.org>.
Sam Ruby wrote:
> Why does the Phoenix [1] page *still* say that it is the reference 
> implementation?  Is everybody waiting for Peter Donald to do it?

no, it was already done.

> If you have time for an amusing diversion, take a look at the Rules for 
> Open-Source Programming [2].  Be sure to read the Meta-Rules first as 
> you will inevitably find that the rules when taken as a whole are 
> self-contradictory and some are outright false.  But as with most humor, 
> each nugget is based on a kernel of truth.
> 
> Mostly, I would like to draw your attention to Sunir's corollaries [2]. 
>  In particular, the statement that "as long as the project *looks* like 
> one person's work, it *is* one person's work."

Look, I don't think that removing Peter's name from the entire codebase 
will change anything in the way it is developped.

> Until the recent global change eradicating personal @author tags, 
> approximately 75% of the source files in the framework had Peter's name 
> on them.  This exceeded the number of files which contained an author's 
> tag with any other name.  Combined.  (Out of 62 files, 46 contained 
> Peter's name, 45 contained any other name, 17 contained only Peter's 
> name, and only 16 did not contain Peter's name).

more than these statistical details, I would like to know if somebody 
ever implemented something in Phoneix that Peter didn't like or voted -1 on.

> I suspect that if you narrow the focus to recent history, the results 
> would be even more dramatic.  It is clear that Peter has the drive, 
> ability, interest, and dedication to out-code the rest of the project 
> combined.  He also challenges each contributor to maintain the highest 
> standards of quality and attention to customer requirements.
> 
> In many contexts, these would be good things.

Yeah, it would be an *awesome* thing. I think that *nobody* here lacks 
respect for Peter's technical skills and commitment. The problem is his 
attitude against confrontation.

> And, in moderation, these 
> are good things here.  But things are out of balance in Avalon.  Lately, 
> this project *looks* like one person's work, and Sunir's observations 
> apply.

No, Sam, Phoenix *IS* one person's work. As Merlin is.

> In particular, I notice that several members of the community 
> seem to derive a tad too much pleasure in the rare events where Peter is 
> proven wrong.

I remember with great pleasure when I managed to change Peter's mind on 
blocks a while back, but not because I proved him wrong, but because I 
felt he had the skills I value for community building: technical value 
mixed with moderation and humbleness and respect for other people's 
ideas. I left this project with great respect for him and his community 
building skills.

History proved me dead wrong: Peter has not been able to create one 
single healthy and diverse community around his code. This is an 
indisputable fact and would not be bad by itself (a committer isn't 
required to be a consensus builder) but it *is* bad for somebody that 
pretends to be a leader.

Yes, I'm saying this in the open because I would like other people to do 
the same with me.

I consider this a form of respect: I respect you so much that I want to 
tell you loud and clear what I think about you and I want to suggest you 
ways to improve.

It might hurt, but in the long run, it's the only way we can learn 
something.

> The alternative is to require consensus.  Strive always to do as Noel so 
> eloquently described [4] with the words "we did it as a community, we 
> support it as a community, and if necessary we'll fix it as a 
> community.".  Achieving this will require changes in behavior from 
> pretty much everybody here.  It will also be hard work.  And require 
> much patience.  And endurance.

Yes.

-- 
Stefano Mazzocchi                               <st...@apache.org>
--------------------------------------------------------------------



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: The Rules of Open-Source Programming

Posted by Stephen McConnell <mc...@apache.org>.
Its Fixed.


Sam Ruby wrote:

> Why does the Phoenix [1] page *still* say that it is the reference 
> implementation?  Is everybody waiting for Peter Donald to do it?
>
> If you have time for an amusing diversion, take a look at the Rules 
> for Open-Source Programming [2].  Be sure to read the Meta-Rules first 
> as you will inevitably find that the rules when taken as a whole are 
> self-contradictory and some are outright false.  But as with most 
> humor, each nugget is based on a kernel of truth.
>
> Mostly, I would like to draw your attention to Sunir's corollaries 
> [2].  In particular, the statement that "as long as the project 
> *looks* like one person's work, it *is* one person's work."
>
> Until the recent global change eradicating personal @author tags, 
> approximately 75% of the source files in the framework had Peter's 
> name on them.  This exceeded the number of files which contained an 
> author's tag with any other name.  Combined.  (Out of 62 files, 46 
> contained Peter's name, 45 contained any other name, 17 contained only 
> Peter's name, and only 16 did not contain Peter's name).
>
> I suspect that if you narrow the focus to recent history, the results 
> would be even more dramatic.  It is clear that Peter has the drive, 
> ability, interest, and dedication to out-code the rest of the project 
> combined.  He also challenges each contributor to maintain the highest 
> standards of quality and attention to customer requirements.
>
> In many contexts, these would be good things.  And, in moderation, 
> these are good things here.  But things are out of balance in Avalon.  
> Lately, this project *looks* like one person's work, and Sunir's 
> observations apply.  In particular, I notice that several members of 
> the community seem to derive a tad too much pleasure in the rare 
> events where Peter is proven wrong.
>
> The alternative is to require consensus.  Strive always to do as Noel 
> so eloquently described [4] with the words "we did it as a community, 
> we support it as a community, and if necessary we'll fix it as a 
> community.".  Achieving this will require changes in behavior from 
> pretty much everybody here.  It will also be hard work.  And require 
> much patience.  And endurance.
>
> Meanwhile, there is some low hanging fruit.  For starters, it is 
> detrimental to the community for the words "The reference 
> implementation" to appear prominently on the Phoenix page [1].  Peter 
> has already indicated that this wording was a historical accident.  So 
> what's everybody waiting for?
>
> - Sam Ruby
>
> [1] http://jakarta.apache.org/avalon/phoenix/index.html
> [2] http://www.advogato.org/article/395.html
> [3] http://www.advogato.org/article/395.html#5
> [4] http://marc.theaimsgroup.com/?l=avalon-dev&m=103802938922576&w=2
>
>
> -- 
> To unsubscribe, e-mail:   
> <ma...@jakarta.apache.org>
> For additional commands, e-mail: 
> <ma...@jakarta.apache.org>
>
>
>

-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: The Rules of Open-Source Programming

Posted by Stephen McConnell <mc...@apache.org>.

Leo Simons wrote:

>On Sun, 2002-11-24 at 18:44, Sam Ruby wrote:
>  
>
>>Why does the Phoenix [1] page *still* say that it is the reference 
>>implementation?  Is everybody waiting for Peter Donald to do it?
>>    
>>
>
>the xdocs had been patched but I forgot to actually update the site. Low
>bandwidth because of fire, stuff like that.
>  
>

Site is patched already.

Cheers, Steve.

>cheers,
>
>- Leo
>
>
>--
>To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>  
>

-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: The Rules of Open-Source Programming

Posted by Leo Simons <le...@apache.org>.
On Sun, 2002-11-24 at 18:44, Sam Ruby wrote:
> Why does the Phoenix [1] page *still* say that it is the reference 
> implementation?  Is everybody waiting for Peter Donald to do it?

the xdocs had been patched but I forgot to actually update the site. Low
bandwidth because of fire, stuff like that.

cheers,

- Leo


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>