Consequences of open commit privileges (was: has struts reached the saturation)

[Ge...@wellsfargo.com]

Jonathan Revusky wrote:
> I revert to my statement that a version repository makes it 
> quite easy 
> to restore the code to any point it was at in the past.
> 
> In any case, consider some potential bad consequence of letting just 
> about anybody commit:
> 
> 1. On occasion, people start committing all kinds of bad code 
> and it's a 
> lot of work for you to start sorting it out. (This very 
> rarely happens 
> because new people are typically very timid in their initial commits, 
> and don't do drastic things, their cokmmits are small and 
> localized and 
> could be rolled back easily.)
> 
> 2. Once in a very long while, let's say 10 or 20 years, somebody with 
> sociopathic tendencies comes along and... I dunno... starts 
> introducing 
> bugs deliberately. (But c'mon, this just about never happens.)
> 
> Now, let's consider the consequences of making it very hard, nigh 
> impossible, for new people to get involved.
> 
> A talented, energetic person who has a fire in his belly to do some 
> stuff is given the runaround. You drive that person away. You 
> lose all 
> the contributions he would have made. Moreover, that energy gets 
> invested in the competing project (in our conceptual 
> experiment above) 
> with low barriers to entry.
> 
> Which is going to be the bigger negative for a project, the 
> above point, 
> or points 1 and 2 above?

There are other potential bad consequences than the two listed above.
Consider

3. Subtle errors and exploitable security holes get introduced, either
inadvertantly or intentionally.

While a revision control system allows backing out changes, each change
must be carefully considered.  A security hole or other error may not be
the result of a single change, but of multiple changes made in multiple
locations and, perhaps, at multiple times.

While open source allows a large number of eyes to see the code, it's
not that easy to review code in depth and spot such problems.  Much
trust is placed on the skill, attention, and thoroughness of the
committers.

Consider the C2 Wiki and Wikipedia as analogies.  Yes, it's easy to
delete obviously false information.  It's just as easy to reintroduce
it.  Keeping the worst of the cruft out is pretty much a full-time job
for volunteers who take on the task, and there's not even agreement
between them which is the cruft.  Subtle or infrequently viewed
incorrect information can, and does, remain for long periods of time.
Spectacular failures occur that make headlines in the mass news media.

I, for one, would never recommend to any business enterprise that they
use Struts for important applications if the source was not vetted and
controlled by a small, trusted committee.  Your needs may not have such
requirements for trustworthiness.

But if businesses were to abandon use of Struts for important
applications, would that be a reasonable trade-off for the contributions
of your talented, energetic person?  Or would the loss of talented,
careful people, who needed a framework for business use where large sums
of money are at risk, be a larger negative for the project?

 - George Dinwiddie
   http://www.idiacomputing.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: Consequences of open commit privileges (was: has struts reached the saturation)

[Jonathan Revusky <re...@wanadoo.es>]

Ted Husted wrote:
> On 3/21/06, George.Dinwiddie@wellsfargo.com <Ge...@wellsfargo.com>
> 
>>I, for one, would never recommend to any business enterprise that they
>>use Struts for important applications if the source was not vetted and
>>controlled by a small, trusted committee.  Your needs may not have such
>>requirements for trustworthiness.
> 
> 
> In the case of the Apache Software Foundation, we do take intellectual
> property very seriously. Before receiving an account, each committer
> must file with the ASF a "Contributor's License Agreement". In this
> way, when we make a commit, we legally donate the code to the ASF,
> which is a not-for-profit US corporation. It is the ASF's intention to
> have clear title to all the code in our repository, both for its
> benefit and for the benefit of the people who make use of ASF code. As
> the sole owner of the code, the ASF can also afford the individuals on
> the PMC some legal protection, since we act as agents of the ASF.

Well, yeah... blah blah.

Let's examine what this means in plain English. Correct if I'm wrong but 
  I think the above means that to become a committer on an ASF project, 
you have to print off some document and you sign it and send it in by fax.

Well, okay, fine. I previously suggested that the requirements for 
commiting code culd be that someone (a) has a name and (b) has expressed 
interest in working on the project. I append to those conditions that 
they (c) print off this thing and fax it in to ASF.

Does this substantially change anything? Does it bolster or undermine 
any arguments made so far on this topic? Frankly, it seems like a big 
red herring.

> 
> We do encourage non-committers to submit patches, and we take care to
> credit each person's contribution in the repository log when we make
> the commit. Depending on the nature of the contribution, we may ask
> someone to file a CLA, even if he or she is not a committer.

Yeah, okay, so other people fax the thing in too. Fine.

Now, in general, in this message, you're just repeating the theory, 
aren't you? But the problem is that many people in this conversation 
seem to believe that the theory isn't really working in practice. 
Moreover, the fact that Struts was unable to stay competitive with 
Webwork even given the huge advantages you should have in terms of 
attracting collaborators, this seems to suggest that your model did not 
work very well.

> 
> Many of the best features in Struts came from people who, at the time,
> were not committers. The Validator, for example, as well as Tiles.
> Features like the DispatchAction, roles-based authentification,
> declarative exception handling, among many others were contributed to
> the project by non-committers.
> 
> Most recently, opt-in cancel handling came in as a patch from a
> non-committer, after a lengthy discussion of the best way to solve the
> problem. Many ideas went into the patch, contributed by committers and
> non-committer alike.
> 
> * http://issues.apache.org/bugzilla/show_bug.cgi?id=38374
> 
> For more on contributiing to the project, see
> 
> * http://struts.apache.org/helping.html
> 
> Sadly, there are occasions when we cannot offter committer status to
> an individual. Usually, it is not because there is a problem with hsi
> or her code, 

I don't get it. If somebody can donate worthwhile code, why shouldn't 
they be allowed to commit it?

> but because all committers participate in the
> decision-making process. We don't have any peon-committers. 

I don't really understand what you're talking about here, Ted. I can't 
refute it because I just don't understand it. I think I understood your 
first paragraph. I read that 3 times or so and my analysis of it boiled 
down to the fact that commmitters have to sign some legal boilerplate 
and send it in. AFAICS, that's practically a non sequitir; it's just a 
legal/procedural detail that isn't very relevant to the real issues in 
running a project, but I processed what you were saying, I think. This 
stuff about peon-committers, I just don't understand.

> Every
> committer is considered on track to become a PMC member, with a
> binding vote on releases and other matters. In turn, some committers
> and PMC members also become ASF members. The ASF members are the
> "stakeholders" of the corporation and elect the board of directors.

So you are saying that the above means that somebody wants to hack the 
code, is able to hack the code, and can contribute, but because of the 
above, they can't become a committer.

I really think you should expound the various logical steps of your 
argument more clearly. You know, it may seem clear in your own mind, but 
of course, your goal must be to convey your message to others.  I can't 
understand your argument, and I'd say it's safe to say that if I don't 
understand it, other people probably don't either. Of course, only very 
few people who don't understand it have the self-confidence to say so 
forthrightly as I just did. You know, it's like the emperor's new 
clothes fable.

> 
> While ASF projects have a reputation for voting, most decisions are
> made through informal discussions on the dev mailing list. Someone
> commits some code, and the rest of us peer-review the change (by
> following the commit list). Usually, that's the end of it, but any PMC
> member can veto a product change if need be. It's rare that a PMC
> member will abuse his or her veto power, but it does happen. On one
> occasion, the board did have to strip an individual's commit
> privileges. But, given that there are almost two thousand (2,000) ASF
> committers now, working on more than thirty top-level projects, that
> seems like a pretty good batting average :)


Oh, so there are actually more committers around than you can shake a 
stick at, eh? All working away. Then why IYO did progress on Struts 1.x 
completely stagnate?

> 
> We also take project management seriously. 

Yeah, imagine how things would be if you didn't take things seriously....

(There maybe a problem of taking yourselves a tad too seriously, but 
that is another matter, of course... ;-))

> Every project has a
> designated "Chair" who is a vice-president of the foundation. The
> Chair/VP must tender a status report to the board on at least a
> quarterly basis, to be sure the project remains vital and
> collaborative.
> 
> For more about how the ASF (and by extension Apache Struts) works, see
> 
> * http://www.apache.org/foundation/how-it-works.html

You keep pointing people to this the way a devout muslim would point 
somebody to the holy Koran. I can't read your mind. Which particular 
verse(s) of the scripture you cite are you referring to?

Regards,

Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
FreeMarker group blog, http://freemarker.blogspot.com/


> 
> -Ted.


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: Consequences of open commit privileges (was: has struts reached the saturation)

[Ted Husted <te...@gmail.com>]

On 3/21/06, George.Dinwiddie@wellsfargo.com <Ge...@wellsfargo.com>
> I, for one, would never recommend to any business enterprise that they
> use Struts for important applications if the source was not vetted and
> controlled by a small, trusted committee.  Your needs may not have such
> requirements for trustworthiness.

In the case of the Apache Software Foundation, we do take intellectual
property very seriously. Before receiving an account, each committer
must file with the ASF a "Contributor's License Agreement". In this
way, when we make a commit, we legally donate the code to the ASF,
which is a not-for-profit US corporation. It is the ASF's intention to
have clear title to all the code in our repository, both for its
benefit and for the benefit of the people who make use of ASF code. As
the sole owner of the code, the ASF can also afford the individuals on
the PMC some legal protection, since we act as agents of the ASF.

We do encourage non-committers to submit patches, and we take care to
credit each person's contribution in the repository log when we make
the commit. Depending on the nature of the contribution, we may ask
someone to file a CLA, even if he or she is not a committer.

Many of the best features in Struts came from people who, at the time,
were not committers. The Validator, for example, as well as Tiles.
Features like the DispatchAction, roles-based authentification,
declarative exception handling, among many others were contributed to
the project by non-committers.

Most recently, opt-in cancel handling came in as a patch from a
non-committer, after a lengthy discussion of the best way to solve the
problem. Many ideas went into the patch, contributed by committers and
non-committer alike.

* http://issues.apache.org/bugzilla/show_bug.cgi?id=38374

For more on contributiing to the project, see

* http://struts.apache.org/helping.html

Sadly, there are occasions when we cannot offter committer status to
an individual. Usually, it is not because there is a problem with hsi
or her code, but because all committers participate in the
decision-making process. We don't have any peon-committers. Every
committer is considered on track to become a PMC member, with a
binding vote on releases and other matters. In turn, some committers
and PMC members also become ASF members. The ASF members are the
"stakeholders" of the corporation and elect the board of directors.

While ASF projects have a reputation for voting, most decisions are
made through informal discussions on the dev mailing list. Someone
commits some code, and the rest of us peer-review the change (by
following the commit list). Usually, that's the end of it, but any PMC
member can veto a product change if need be. It's rare that a PMC
member will abuse his or her veto power, but it does happen. On one
occasion, the board did have to strip an individual's commit
privileges. But, given that there are almost two thousand (2,000) ASF
committers now, working on more than thirty top-level projects, that
seems like a pretty good batting average :)

We also take project management seriously. Every project has a
designated "Chair" who is a vice-president of the foundation. The
Chair/VP must tender a status report to the board on at least a
quarterly basis, to be sure the project remains vital and
collaborative.

For more about how the ASF (and by extension Apache Struts) works, see

* http://www.apache.org/foundation/how-it-works.html

-Ted.

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: Consequences of open commit privileges (was: has struts reached the saturation)

[Jonathan Revusky <re...@wanadoo.es>]

Michael Jouravlev wrote:
> On 3/21/06, Jonathan Revusky <re...@wanadoo.es> wrote:
> 
>>Michael Jouravlev wrote:
>>
>>>On 3/21/06, Jonathan Revusky <re...@wanadoo.es> wrote:
>>>
>>>
>>>>George.Dinwiddie@wellsfargo.com wrote:
>>>>
>>>>
>>>>>Consider the C2 Wiki and Wikipedia as analogies.  Yes, it's easy to
>>>>>delete obviously false information.  It's just as easy to reintroduce
>>>>>it.  Keeping the worst of the cruft out is pretty much a full-time job
>>>>>for volunteers who take on the task, and there's not even agreement
>>>>>between them which is the cruft.  Subtle or infrequently viewed
>>>>>incorrect information can, and does, remain for long periods of time.
>>>>>Spectacular failures occur that make headlines in the mass news media.
>>>>
>>>>Just to be clear: are you speculating in the above, or are you speaking
>>>
>>>>from direct experience maintaining such resources?
>>>
>>>
>>>This happens all the time.
>>
>>I'll ask you the same question I asked of George: Are you speaking from
>>personal experience maintaining wiki resources?
> 
> 
> Yeah, usually political stuff. Old Pope - new Pope, for example.

Idle curiosity. Which site is that?

> 
> 
>>Despite the extreme kinds of comparisons like that, there are attempts
>>here to portray what I am saying as unreasonable. But how unreasonable
>>is it? Basically I am saying that you can drastically reduce the
>>barriers to entry for new committers and the potential gains for the
>>project far outweigh the risks.
> 
> 
> Why giving a commit priviliges to someone if you don't like (or
> haven't even seen) stuff that he brings in? 

Well, I've already presented my views on this and this gets repetitious.

All I can do is make the general comment that the reason to adopt a 
different approach would be that you recognize that the current approach 
is not really working.

I grant that if you think everything is basically hunky dory, then there 
is no reason to change tack. Why fix what is not broken? So maybe it 
comes down to that. Is everything hunky dory?

Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
FreeMarker group blog, http://freemarker.blogspot.com/


 > Not to question does he
 > really bring something in . Most project originators are dictators.
 > They want to share and they want to use external force to move
 > forward, but they want the project to reflect their ideas.




> 
> Michael.


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: Consequences of open commit privileges (was: has struts reached the saturation)

[Michael Jouravlev <jm...@gmail.com>]

On 3/21/06, Jonathan Revusky <re...@wanadoo.es> wrote:
> Michael Jouravlev wrote:
> > On 3/21/06, Jonathan Revusky <re...@wanadoo.es> wrote:
> >
> >>George.Dinwiddie@wellsfargo.com wrote:
> >>
> >>>Consider the C2 Wiki and Wikipedia as analogies.  Yes, it's easy to
> >>>delete obviously false information.  It's just as easy to reintroduce
> >>>it.  Keeping the worst of the cruft out is pretty much a full-time job
> >>>for volunteers who take on the task, and there's not even agreement
> >>>between them which is the cruft.  Subtle or infrequently viewed
> >>>incorrect information can, and does, remain for long periods of time.
> >>>Spectacular failures occur that make headlines in the mass news media.
> >>
> >>Just to be clear: are you speculating in the above, or are you speaking
> >>from direct experience maintaining such resources?
> >
> >
> > This happens all the time.
>
> I'll ask you the same question I asked of George: Are you speaking from
> personal experience maintaining wiki resources?

Yeah, usually political stuff. Old Pope - new Pope, for example.

> Despite the extreme kinds of comparisons like that, there are attempts
> here to portray what I am saying as unreasonable. But how unreasonable
> is it? Basically I am saying that you can drastically reduce the
> barriers to entry for new committers and the potential gains for the
> project far outweigh the risks.

Why giving a commit priviliges to someone if you don't like (or
haven't even seen) stuff that he brings in? Not to question does he
really bring something in . Most project originators are dictators.
They want to share and they want to use external force to move
forward, but they want the project to reflect their ideas.

Michael.

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: Consequences of open commit privileges (was: has struts reached the saturation)

[Jonathan Revusky <re...@wanadoo.es>]

Michael Jouravlev wrote:
> On 3/21/06, Jonathan Revusky <re...@wanadoo.es> wrote:
> 
>>George.Dinwiddie@wellsfargo.com wrote:
>>
>>>Consider the C2 Wiki and Wikipedia as analogies.  Yes, it's easy to
>>>delete obviously false information.  It's just as easy to reintroduce
>>>it.  Keeping the worst of the cruft out is pretty much a full-time job
>>>for volunteers who take on the task, and there's not even agreement
>>>between them which is the cruft.  Subtle or infrequently viewed
>>>incorrect information can, and does, remain for long periods of time.
>>>Spectacular failures occur that make headlines in the mass news media.
>>
>>Just to be clear: are you speculating in the above, or are you speaking
>>from direct experience maintaining such resources?
> 
> 
> This happens all the time. 

I'll ask you the same question I asked of George: Are you speaking from 
personal experience maintaining wiki resources?

I don't meant that sarcastically or anything. I just want to know, in 
these cases, whether people are sharing actual experiences with 
collaborative development of different types or are mostly just speculating.

> Wikipedia is not the trusted place. It is
> just a place where you can look for quick description or links, but
> Wikipedia is unofficial
> 
> Also, I think that repairing one wiki page is a lot simpler than
> rolling back a CVS or SVN update of multiple interdependent source
> files.

Well, it is still child's play compared to fixing up a person who fell 
off a cliff or was in a major automotive accident, or cleaning up after 
a nuclear meltdown. These were some of the incredible comparisons 
offered in this discussion.

Despite the extreme kinds of comparisons like that, there are attempts 
here to portray what I am saying as unreasonable. But how unreasonable 
is it? Basically I am saying that you can drastically reduce the 
barriers to entry for new committers and the potential gains for the 
project far outweigh the risks.


Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/

> 
> Michael.


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: Consequences of open commit privileges (was: has struts reached the saturation)

[Michael Jouravlev <jm...@gmail.com>]

On 3/21/06, Jonathan Revusky <re...@wanadoo.es> wrote:
> George.Dinwiddie@wellsfargo.com wrote:
> > Consider the C2 Wiki and Wikipedia as analogies.  Yes, it's easy to
> > delete obviously false information.  It's just as easy to reintroduce
> > it.  Keeping the worst of the cruft out is pretty much a full-time job
> > for volunteers who take on the task, and there's not even agreement
> > between them which is the cruft.  Subtle or infrequently viewed
> > incorrect information can, and does, remain for long periods of time.
> > Spectacular failures occur that make headlines in the mass news media.
>
> Just to be clear: are you speculating in the above, or are you speaking
> from direct experience maintaining such resources?

This happens all the time. Wikipedia is not the trusted place. It is
just a place where you can look for quick description or links, but
Wikipedia is unofficial.

Also, I think that repairing one wiki page is a lot simpler than
rolling back a CVS or SVN update of multiple interdependent source
files.

Michael.

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: Consequences of open commit privileges (was: has struts reached the saturation)

[Jonathan Revusky <re...@wanadoo.es>]

George.Dinwiddie@wellsfargo.com wrote:
> Jonathan Revusky wrote:
> 
>>I revert to my statement that a version repository makes it 
>>quite easy 
>>to restore the code to any point it was at in the past.
>>
>>In any case, consider some potential bad consequence of letting just 
>>about anybody commit:
>>
>>1. On occasion, people start committing all kinds of bad code 
>>and it's a 
>>lot of work for you to start sorting it out. (This very 
>>rarely happens 
>>because new people are typically very timid in their initial commits, 
>>and don't do drastic things, their cokmmits are small and 
>>localized and 
>>could be rolled back easily.)
>>
>>2. Once in a very long while, let's say 10 or 20 years, somebody with 
>>sociopathic tendencies comes along and... I dunno... starts 
>>introducing 
>>bugs deliberately. (But c'mon, this just about never happens.)
>>
>>Now, let's consider the consequences of making it very hard, nigh 
>>impossible, for new people to get involved.
>>
>>A talented, energetic person who has a fire in his belly to do some 
>>stuff is given the runaround. You drive that person away. You 
>>lose all 
>>the contributions he would have made. Moreover, that energy gets 
>>invested in the competing project (in our conceptual 
>>experiment above) 
>>with low barriers to entry.
>>
>>Which is going to be the bigger negative for a project, the 
>>above point, 
>>or points 1 and 2 above?
> 
> 
> There are other potential bad consequences than the two listed above.
> Consider
> 
> 3. Subtle errors and exploitable security holes get introduced, either
> inadvertantly or intentionally.

First of all, pPeople seem to be addressing things I never said. For 
example, I don't think I ever said that people should be allowed to 
commit _anonymously_. I simply said that I believed you could be quite 
liberal about granting commit privileges to people and the sky would not 
fall in.

Now, here you seem to be suggesting that I see no need for code review 
on new code that is committed.

No, I certainly don't believe that. Of course, code that is committed 
should be reviewed carefully. However, I don't know if this is such a 
problem as regards this kind of situation. If you imagine a situationin 
which a new guy is given commit access, I think it's totally normal that 
the established developers will be quite carefully reviewing the things 
this guy does.

So basically, I don't think your above point 3 is such an objection.

Also, there is a countervailing point here: in terms of subtle errors 
and so on, simply getting more people involved may well reduce the 
number of such subtle errors for the basic principle of more eyeballs. 
So this works both ways.

> 
> While a revision control system allows backing out changes, each change
> must be carefully considered.  A security hole or other error may not be
> the result of a single change, but of multiple changes made in multiple
> locations and, perhaps, at multiple times.

If you are going to go the route of drastically reduce the barriers to 
people committing code, you do need some people to keep an eye on this, 
sure. One aspect of this is that security holes can be introduced 
independently of whether you let in new committers or not.

Now, of course, if the project simply stagnates because no new blood is 
allowed in, then no new security holes get introduced, but that is for 
the trivial reason that nothing is being done... period. But surely 
that's not your point, because that's kinda silly, right?

> 
> While open source allows a large number of eyes to see the code, it's
> not that easy to review code in depth and spot such problems.  Much
> trust is placed on the skill, attention, and thoroughness of the
> committers.

Well, if you don't give somebody commit privileges and they offer a 
patch, and somebody has to review that patch, well, is that more work 
than if you give somebody commit privileges and they commit their patch 
and then it has to be reviewed? The argument that it is hard work to 
dilligently review code seems to be orthogonal to what we are talking 
about. Surely, in a well run project, code contributions would be 
reviewed carefully, right?

So the contributed code needs to be reviewed in either case, right? And 
requires the same skill, attention, and thoroughness.

> 
> Consider the C2 Wiki and Wikipedia as analogies.  Yes, it's easy to
> delete obviously false information.  It's just as easy to reintroduce
> it.  Keeping the worst of the cruft out is pretty much a full-time job
> for volunteers who take on the task, and there's not even agreement
> between them which is the cruft.  Subtle or infrequently viewed
> incorrect information can, and does, remain for long periods of time.
> Spectacular failures occur that make headlines in the mass news media.

Just to be clear: are you speculating in the above, or are you speaking 
from direct experience maintaining such resources?

> 
> I, for one, would never recommend to any business enterprise that they
> use Struts for important applications if the source was not vetted and
> controlled by a small, trusted committee.  Your needs may not have such
> requirements for trustworthiness.

Do you have objective proof that Struts is more "trustworthy" -- i.e. 
lack of subtle security holes and so on -- than other comparable projects?

I mean, as I said to Frank Zametti, this all is stuff that can, at least 
in theory, be resolved empirically. If you assert that a software 
project that lowers the barriers to entry for committers is going to 
have more security holes in it than it would otherwise, then this is 
verifiable empirically, in principle, right?

> 
> But if businesses were to abandon use of Struts for important
> applications, would that be a reasonable trade-off for the contributions
> of your talented, energetic person?  Or would the loss of talented,
> careful people, who needed a framework for business use where large sums
> of money are at risk, be a larger negative for the project?


George, I'm rather unconvinced by your arguments. If a business is 
extremely conservative and risk-averse, they can always use a version of 
the software that is a couple of versions behind (and they typically do 
that) and thus, in principle, any security holes would likely have come 
to light -- admittedly because there are early adopters out there 
willing to use more bleeding edge stuff. There's sort of an ecology out 
there, with more conservative people and earlier adopters and people 
willing to use the nightly build. A countervailing aspect of what you 
are saying is that any process that got more people involved with the 
code could actually reduce the number of bugs and other issues, simply 
by the basic mechanism of bringing more eyeballs to bear.

But I reiterate: the idea that a more open collaborative model is going 
to produce software with more bugs or more security holes is an 
empirical question that cannot be resolved by a priori reasoning.

An interesting related thing is that the quality of wiki-based 
collaboratively developed materials actually can be surprisingly high. 
One recent study (I mention this in a blog entry about this kind of 
topic here BTW 
http://freemarker.blogspot.com/2006/02/musings-on-wikipedia-and-open-source.html 
) actually shows that the number of serious factual errors in wikipedia 
versus Encyclopedia Britannica is not so different.

But to summarize: the basic idea that you need to closely guard commit 
privileges should not be a dogma. It is a hypothesis that should stand 
and fall based on empirical evidence. All I see here is people arguing 
that this is a bad idea based on a priori reasoning. Has anybody jumped 
up and said something like: "Oh, we tried that and it was a disaster. 
This happened and the other thing happened and we had to revert to a 
less open approach."

With my kind of empirical mind-set, this is the kind of thing more 
likely to convince me I'm wrong, or at least cause me to doubt.

I see people willing to say that this is a terrible idea but no 
empirical evidence is offered. I ask you: what would a fair-minded
observer of this discussion conclude from that?

Regards,

Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/

> 
>  - George Dinwiddie
>    http://www.idiacomputing.com/


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org