Frank W. Zammetti wrote:
Jonathan Revusky wrote:
I guess you and I think quite differently about certain things. In
another part of this discussion, you mentioned malice as a reason not
to give people commit access on an "on-demand" basis. However, this is
something that hardly occurs to me as being much of a reason. In the
above, you mention the idea that your secret voting mechanism could be
"cooked" or people could suspect it is. This also never really
occurred to me. I guess I just have a certain basic trust in the
ethics of other open source people, and it does not occur to me that
someone would cook the voting or that anybody would think that I would
cook the voting.
No question I tend to take a pessimistic view of things until I have
reason to believe otherwise. I dare say all you have to do is look
around the world and you will see more evidence to support that
perspective than the more positive perspective. Sad, but I think true.
But you say "...certain basic trust in the ethics of other open source
people..."... do you mean that you would allow anonymous, full commit
privileges to anyone and everyone?
It is very unlikely that I would ever let anybody muck with the
repository anonymously. For starters, while I think malice is quite rare
in this case, the chances become much higher when you're talking about
people who aren't taking the basic minimal responsibility of saying who
they are.
As a practical matter, the issue only will come up with people who have
been on your mailing list and have some ideas and the subject of them
becoming more involved comes up. In most (maybe all) cases I actually
have been the one to bring it up.
Basically, I'm arguing that being extremely liberal about giving people
who shown some interest commit access is not nearly as dangerous as you
are portraying it to be. I think the dangers of this kind of elitist
closed club attitude that you see here are greater.
In other words, a situation where
anyone who wants to, whether they have ever seen the project before or
not, can commit to the repository. This I absolutely think is a bad
idea. A very bad one at that.
Frank, isn't this a bit of a red herring? Who on earth who has not seen
the project before *wants* to commit code? It really seems to me that
you keep bringing up cases that have no relation to anything I recognize
from my own experience as resembling reality.
Again, the basic question we are discussing is subject to empirical
verification. To keep talking, from first principles, about whether
something is a good idea or not, when it can be tested empirically, is
ultimately sterile. (I originally wrote "masturbatory" here, but find
that too inflammatory...) It's like a bunch of ivory tower intellectuals
having a theoretical debate about whether it's raining outside or not.
Some illiterate janitor or somebody happens into the room, opens the
window, sticks out his hand and says. "Fellas, it's raining out there."
Now, when I say this is empirically resolvable, I don't mean it's all
that easy to run a well controlled experiment since each case will be
different. However, here is the basic idea. You have one project that
takes the elitist "committers as high priesthood" approach and another
comparable project that has practically no barriers to entry (you do
have to say what your name is but that should not be a big barrier.) You
also have to be interested, but that's possibly a red herring because
somebody who is not interested simply does nothing and never asks for
commit access.
The basic question is which project are you going to bet on in terms of
it continuing to evolve and innovate? I don't know for absolutely sure,
but in the experiment outlined above, given my thinking right now, I
would bet my money on the project with low barriers to entry.
While you can't run a perfectly controlled experiment, once you
accumulate enough data points on this, you can start to, at least
tentatively, draw some real conclusions.
But look, if somebody distrusts your ethics to that extent, why would
they be in your community?
I guess it could be more me expecting people to be expecting the worst
of me :)
Well, you know, it could also be that a public vote is preferred
because project leaders are (at least vaguely) aware that if the vote
is public people are less likely to disagree with them. (Of course,
that is not exactly a legitimate reason.)
That could be part of it, sure.
But now, which one of us has the basic distrust issue here?? ;) LOL
Well, it's not comparable. That the project leaders would prefer to
structure the voting in such a way that they tend to get their way is
not the same as actually cooking the vote count or something. In any
case, in my world view, it's normal that the people who did the lion's
share of the work basically make the decisions, so I don't even see much
problem with that. But my own suspicion is that most of the formalized
voting stuff is an empty farce anyway.
Well, if it comes into play at all, it should be considered.
I would generally agree.
Well, maybe (just maybe, I'm not really *so* presumptuous) the next
step of evolution of your thinking is to move more towards implicitly
trusting people. I mean: trust people to be acting in good faith until
proven otherwise. Trust people to be at least moderately competent
until proven otherwise.
With the potential of major effort to clean up a corrupt source
repository, I don't think you can do that.
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?
Just my opinion.
Sure, and you have the right to your opinion.
But, when a question is subject to empirical validation, once there
starts to be overwhelming evidence that your opinion was wrong, you have
to be flexible, don't you?
In general, in this kind of collaborative internet model, don't you
have to make a leap of faith and implicitly trust (until proven
otherwise, of course) people you've never met?
To some degree, yes. But what that degree is, well, that's where we
don't completely agree :) I think there has to be *some* vetting that
takes place, no matter how minor.
Well, I agree with you (and Craig) that the person should have a real name.
So maybe somebody whose mommy and daddy neglected to give him a name
gets unfairly filtered out... ;-)
Aside from that, if somebody says he wants to work, I say, go to it,
show us what you can do.
Look at it this way... let's say you have 20 people actively working on
a project, doing fantastic work. All of a sudden, you let the 21st
person in, and they proceed to commit some less than stellar work, or
maybe even break code because they don't yet have a good understanding
of the project. Is that fair to the 20 others?
How on earth is it unfair? They knew what they were getting into, an
online collaborative project. Was there ever a guarantee offered that
nobody would step on your toes a bit at some point?
If I am working on a project, and the other guys are obstructionist and
I lose the possibility of collaborating with a talented volunteer who is
given the runaround, I lose the benefit of that enriching experience,
right? Possibly because the other guys are insecurely guarding their
turf and so on. Is that fair to me?
In which case is the loss greater? I say the latter one, because the
first thing is more like a minor inconvenience.
Even if it can all be
undone, is it fair for any of them to have to take the time to do so?
It could be a PITA, but there is nothing inherently unfair about it.
What's unfair about it?
I could quote Spock here, but I probably don't need to :)
That would be the "appeal to higher authority" fallacy....
You see, what is the alternative? If you don't trust people by
default, then how is trust established?
>
I mean, this seems to be related to the catch 22 problem that you
become a committer by contributing a lot, but it's practically
impossible to contribute without being a committer in the first place,
Craig never responded to this basic question. (Somehow, I suspect he
won't.)
But this is where the attitude of the committers (of any project, not
talking Struts specifically here) comes into play. They have to be
willing to accept contributions that don't come from themselves. If
that is the case, a person can build up that trust and build up that
reputation that leads to an invitation to join. One could even envision
a situation where a person submits 10 things, none of them is accepted,
and the person is still invited to join. That obviously would require
the existing committers have a very open-mindedness about them, but it
could happen. This serves your point of view and mine: there is a
vetting process that I like, and there is a basic trust by default for
you, maybe not quite to the degree you like, but I think its a
reasonable compromise position.
Well, that could be good. It all comes down to empirical questions. If
an approach works, it works. Black cat, white cat... both catch mice....
Once your approach clearly didn't work in a case, though, there has to
be an honest taking of stock. That is what I see as quite absent in the
Struts community.
But the real problem here, that just about everybody seems to be
skirting around is that, given the utter failure of the Struts
community to compete with Webwork technically, there surely is a need
for an open-minded exchange of ideas about these project management
issues. And the people who lost the technical competition (the Struts
people) should, by the basic logic and structure of competitition,
adopt a fairly humble attitude about these topics.
Can you point out where Struts has "utterly failed" to compete with
Webwork technically?
I don't know either product so well in detail. My interest in Webwork
and hence, Struts Action, is that FreeMarker is used very extensively there.
But I don't think there's much onus on me to answer this question
anyway. If the main Struts people want Webwork to be Struts Action 2.x,
and for Struts 1.x users (at least the ones who want an action
framework) to migrate to that, they are saying that WW is superior.
It would be silly of me to question that, especially when the Struts
people would, under normal circumstances, be the last ones to admit that
WW is better.
I've looked at Struts 1.3, and I've looked at WW,
and I don't see them as being light years apart frankly. I certainly
think there are pluses and minuses both ways, but the one thing that
struck me the most when I was reading about WW was how essentially
similar to Struts it was, and I didn't see anything that made me sit up
and go "oh wow, that's SO much better than Struts".
Well, the responsible struts people threw in the towel, as far as a
technical competition is concerned. They accepted that webwork was
better. Now, if you think the boxer's manager threw in the towel
prematurely, that could be an issue, but that he lost the fight is clear
enough.
Look, try this. Work up a list of all the evolution, improvements and
innovations that have happened in Webwork over the last 3 years. And
work up a corresponding list of the evolution that happened in Struts
over the same time period.
Now, on that basis, let's examine which community had a more effective
development process. My bet is that you'll have to conclude that the
Webwork community was more innovative and more effective.
Note also that this is quite damning, since the two things were not
competing on an even playing field. Struts should have had a huge
advantage in terms of attracting technically able collaborators. Yet
still, they were not able to compete.
Well, it's like the alcoholic who has to admit that he has a problem,
this community would have to admit that it has certain problems for
any improvements to occur. But of course, since they won't admit it,
no improvements will occur and.... well,... look, it's obviously a
lost cause.... (I quickly came to that conclusion after reading some
of Craig's (and Ted's) recent comments.)
Hehe, ironically, we've flipped positions :) I actually have a great
deal of hope for the Struts community. Firstly, I don't think it's in
quite as much disarray as others may. I think there is room for
improvement, but I don't think it's doomed or anything like that.
Well, this is empirically resolvable. We simply wait and see. :-)
I actually am not somebody with strong opinions at the moment about
web app development. I don't know so much about Spring and other
frameworks and so on. However, just from what I observe lurking in
this community, I would have one recommendation for anybody who asked
my opinion on these matters. And that is: Whatever else you decide on,
do not use Struts (I mean, don't use Struts Classic, don't use Struts
Action, don't use Struts Shale) because the community is
dysfunctional... major league FUBAR...
This I can't agree with.
Well, you have an existing investment.
Here is something I am wondering about. If you had no existing
investment in Struts, and you were in the market for a framework, would
you try to get involved with this community or would you look elsewhere
-- Spring, or whatever other alternatives....?
And I mean, looking at the project with fresh eyes, trying to sort out
your initial confusion about Struts/Action/Shale, and all that, and so
on. Would you get involved here or opt for something else?
It's not a rhetorical question. I ask because I don't know.
The 1.2.x branch of Struts is in pretty good
shape... one of the reasons there hasn't been a lot of evolution is that
it *is* stable and does the job for a lot of people.
Well, that people use 1.2.x and it basically works does not really have
that much to do with whether the project's development process is
healthy at this point in time.
When I referred to this as a FUBAR, I was thinking more of the
sociological aspects of all this. Craig was right to say that this is a
lot about people as opposed to code, and it is particularly for these
reasons that I would not consider getting involved in this project and
community.
The 1.3 branch
brings a lot of power, but it almost feels superfluous with the pending
WW merger (I have my suspicion that it hasn't gotten the attention it
should have ever since the merger decision was made, but that's just my
suspicion).
Yes, but the WW merger came about specifically because Struts was
falling further and further behind. At least this is what I infer. So
maybe there is some confusion of cause and effect in all this.
Shale, however you or I may feel about it, continues to
evolve and get better, and again, putting our feelings about it aside,
there is no doubt more and more people are finding it interesting.
Projects on ASF will always generate a lot more interest than what they
deserve on pure technical merit.
Suppose you put Shale on sf.net without any ASF projection. How
interesting would people find it?
<snip>
If I have a choice though, I would rather a democracy fail than a
dictatorship succeed. There is something at a very low, fundamental
level that I just abhor about not giving people a voice, freedom and
choice.
Well, Democracy is a basic value in the running of a nation and society
overall, I suppose. But whether it's a basic value in terms of the
running of an open source project, I don't know. I think that the
various approaches to running an open-source project have to be judged
on results.
Even in the case of countries, I don't know how far you can take the
idea that you prefer a failed democracy to a functioning dictatorship.
If it comes between a democracy in which people are starving and there
is anarchy vs. a dictatorship where people have food on the table and
there is law and order, I think that morally and ethically, one has to
opt for the dictatorship -- if those really are the basic parameters.
Political freedom is meaningless if you have no food to eat. And how
"free" are you if you cannot walk down the street in safety anyway?
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
FreeMarker group blog, http://freemarker.blogspot.com/
I say that no formalized voting system will substitute a basic need to
be able to listen to people in an open-minded way (that means,
considering seriously the possibility that you are wrong) and being
flexible and so on.
I agree.
This actually reminds me of the various attempts to set up democracy
in backward, third world places. These countries do not have the basic
institutions or culture of democracy. Having the formal vote does not
make them into democracies.
I agree again. But what it DOES give them is a vote. There is no
trusting that the leaders will be open-minded. You have clearly stated
you don't feel the Struts committers are being open-minded, so in the
case of Struts, from your point of view, your own philosophy has failed.
If there was at least a formalized vote, the closed-mindedness you
perceive would have far less impact, and possibly even none.
Jonathan Revusky
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
