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

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, 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. Just my opinion.

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.

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? Even if it can all be undone, is it fair for any of them to have to take the time to do so?

I could quote Spock here, but I probably don't need to :)

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.

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'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, 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.

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

I really don't know either. I say that this kind of thing is something not to be approached dogmatically. It's like the question of how much strictness and discipline to use in child-rearing. You need some but you can also overdo it.

Agreed.  It's all a question of degrees.

I think a lot of what has to happen revolves around common sense, and common sense, like intuition and so on, is going to be quite hard to formalize into a set of rules. Personally, I don't take the idea of formalized voting that seriously. I think an open-source project is surely more like a dictatorship. But the dictator needs to listen to people. It just occurred to me that one basic difference between a dictatorship and this is that in a dictatorship like Sadam's Iraq or someplace, the Iraqis just had to keep living there. In an open-source project, everybody can just leave and you're left dictating to nobody but yourself.

I think a "benevolent" dictatorship in an open-source project is only ever appropriate in the early stages of a project. In many cases, a single individual has the original idea, has the original vision, and they get the ball rolling. After that though, they should give up that power and let the community drive. This is the path JWP took.

The one argument against my own position is in direction-setting. One of the things that has made Linux so successful is Linus still kind of guiding things. Part of me really hates that he hasn't given up his control (and, contrary to anything he might say, he *does* have more power than anyone else), but another part of me thinks that Linux would never have gotten as far as it has without him as the guiding force.

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.

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

--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: [EMAIL PROTECTED]
Java Web Parts -
http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to