[EMAIL PROTECTED] wrote:
Jonathan Revusky wrote:
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.
I never said that the sky would fall in. I just said that committing
code from a wide range of producers prior to review by a small group of
people deeply immersed in the project would reduce the trust in the
project. You may have no objection to this, but you cannot make that
decision for others. There are many companies using Struts for far more
important things than simple websites. I believe that many of these
companies would be unwilling to trust Struts for these uses if the
project were to greatly open up the commit privileges.
You really believe that, huh? I don't know. I am very skeptical about
this because I just find it hard to believe that... well... certain
kinds of pointy-head managers who insist on using Struts or some other
well known thing have very clear ideas about the processes by which
these software products were actually developed. I see a lot of it is a
herd mentality, essentially. "Everybody else is using this thing so it's
the 'safe choice'." (i.e. "Nobody can fire my ass for recommending
Oracle, say, because everybody else is using Oracle, but if I recommend
that we use Acme RDBMS, that nobody has heard of, my ass is on the
line....")
OTOH, maybe what you say is true. I can only speculate about the basis
on which other people make decisions. They may really believe that if
you let more people get involved this way, product quality will go down
and there will be more risk and so on. What I find odd about what you
are saying is the idea that people who think that way would use open
source software at all. Wouldn't people who are that distrustful of a
more open collaborative model just tend to prefer closed commercial
software?
Anyway, supposing for the sake of argument that what you believe is
true, then this leads to another basic question.
Would such a belief be well founded? (I mean the belief that it would
somehow become riskier to use Struts, say, if the barriers to becoming a
committer were drastically lowered.)
This is actually the question that interests me. If people believe this
but it's not true, then.... well... you know, should one condition one's
behavior based on other people's misguided beliefs? Or actually, in this
case, the misguided beliefs you are speculating that certain other
people may hold...
And again, I am saying that if you greatly open up commit privileges,
all the code should still be peer reviewed. What I have heard back is
the counterargument that reviewing whatever code is contributed is a lot
of work. Well, is that really a valid objection? The fact remains that,
well... work is a lot of work. Sitting on your arse and saying "We're a
self-selected meritocracy" is less work.
Given the choice, a self-selected meritocracy, like tenured professors
or something will likely do less work rather than more. But that
something proposed involves work is not in and of itself a valid
objection to the proposal, is it?
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.
Effectiveness of code review depends on the depth of that code review,
not merely the number of people who have reviewed it. While broad
review, which any open-source project may have, can bring a benefit in
reducing errors, I have generally found it better for catching coding
errors than design errors. In many cases, it weakens the review because
it dilutes the sense of responsibility.
Well, in the exact case of letting new people commit code, as a matter
of practical experience, it will be very rare that a new committer will
initially embark on major redesign of the product. Usually a new kid on
the block committer starts off with relatively small localized
contributions that do not involve redesigns.
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 was using this as an example, and don't wish to debate the question of
open Wikis. For the record, I have given up on maintaining the C2 Wiki
(after many years of contributing) because the cruft is added faster
than it can be cleaned, and it's no longer worth my time to work on it.
I rarely refer to it for reference, either, for the same reason.
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?
You have an objective measurement of trustworthiness? I thought that
trust was a human (or perhaps animate) value.
Well, you seem to be saying (at least implicitly) that you "trust"
Struts and the Struts team more than other corresponding products. I
think it is a valid question to ask whether you have an objective basis
for this. "Everybody else is using it so it must be good" is of course a
false syllogism.
If you were asked pointedly on what objective basis you place more trust
in Struts and so on, how would you answer? I think, at the end of the
day, it is a valid, well constructed question.
George, I'm rather unconvinced by your arguments.
That's OK with me. I'm rather unconvinced by your arguments. I'm just
stating the case that, as it is, Struts is rather widely trusted for
enterprise systems. I believe that much of that trust is due to the
empirical track record of the small team controlling changes to the
code. I believe that much of that trust by those businesses would be
lost were this model of control to be radically altered.
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.
I'm not saying that it would have more bugs.
Well, the proof of the pudding is in the eating, isn't it? If a more
open process did not, by any objective measure, result in less reliable
software, and meanwhile resulted in more technical innovation and thus
more productivity for Struts users, wouldn't you have to be in favor of
that?
I'm saying it would be
less trusted. It's harder for me to trust a large group than a small
one.
Well, I might decide I don't trust a guy's code because this is a guy
who wears goofy T-shirts to work. Fine. This does lead to the question
of whether that criterion is actually valid or not.... Do people who
wear goofy T-shirts write better or worse code than other people? I know
that sounds silly, but basically there's the question that somebody
might have whatever bias, but still, we should be rational here. The
more important question IMO is whether the bias is actually well founded
or not.
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 think you're mis-reading the discussion. I don't hear any dogma here.
Well, what I see is that there are people here (not just me) seriously
questioning whether the so-called "Apache Way" is really all it's
cracked up to be. In response, you have people saying: "This is how the
Apache Way works" or simply pointing to some document somewhere in the
same way that a religious fundamentalist would quote scripture.
I mean, it's as if you critique the design of Struts, say, and then the
response to your design critique is that people say: "Here is a document
outlining the design of Struts." It does beg the question, does it not?
I hear the Struts team saying, "We don't want to do that." They're
perfectly willing to let you run a project with whatever commit criteria
you want. They're even willing to let you start with their code base.
Well, that's very generous of them, I'm sure. Note, however, that, as
regards Struts Action Framework 2.x, they themselves do not even want to
start with their current code base.
Knock yourself out. Personally, as a Struts user, I'm pretty
comfortable with the project, as is. On a take-it-or-leave-it basis,
I'll take it.
Well, if you're completely happy, that's fine. But does that, in itself,
mean that everybody is happy? If not, does it also mean that the people
who are unhappy should not express that?
What I see is people arguing that they're wrong for feeling that way. I
hear people saying that the Struts team should change their behavior and
that we will know, empirically and in the future, if it was a good or
bad change. And I don't blame them for dismissing those arguments.
There is an infinite number of ways to run a project. There is no "one
best way." Empirical evidence shows that the Apache way has been
successful by a number of measurements. It might not be the way that I
would run a project or that you would run a project, but neither of us
has any right to tell them it's the wrong way.
Why not? :-)
Oh, we can tell them
Oh, so we do have the right of free speech. What a relief!
but they have no obligation to listen.
I think you have some fundamental misconceptions about the logic and
structure of the situation.
IMO, there is a basic moral obligation to listen to your community. I am
prominent in an open source project that is fairly well known and has a
healthy user community.
For the record, yes, I feel that, I have an obligation to listen. The
day I don't want to listen to anybody's gripes, I'll willingly pass the
torch on to somebody who does want to listen.
Therefore, if you want to
influence the way they run the project, you need to present that
influence in ways in which it may be more likely to be favorably
received. Empirical evidence shows that saying "you're doing it wrong"
is not a terribly effective way of influencing someone.
Well, according to you, they have the right not to listen to you anyway...
Basically, you seem to have some basic misconceptions about what is
going on around here. The Struts people have convinced the developers of
Webwork, a heretofore competing product, to donate their codebase to ASF
and have that be called Struts Action Framework 2.0. This basically
means that the Struts people have tacitly accepted that Webwork is a lot
better and that current Struts users would be better off using that.
This means that there was a technical competition to produce the better
framework, and the Struts people have conceded defeat. When you lose,
you generally have to humbly accept that you did at least some things
wrong. The logic and structure of the situation is such that these
people have to accept that they did some things wrong.
Anyway, I have made clear my thoughts on this in a blog article that can
be read here:
http://freemarker.blogspot.com/2006/03/musings-about-competition-ego-open.html
Anyway, we probably do have legitimate differences of opinin about
certain things and I do not presume to have absolute truth. But, really,
George, as a favor to yourself, you should really reconsider this idea
that people in the position of Craig and Ted and so on have no
obligation to listen.
Yes, they do....
Regards,
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
Your mileage
may vary.
- George Dinwiddie
http://www.idiacomputing.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
