struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Revusky <>
Subject Re: has struts reached the saturation
Date Tue, 21 Mar 2006 01:32:48 GMT
Frank W. Zammetti wrote:
> Welcome Jonathan!  Better late than never :)
> Jonathan Revusky wrote:
>>> I think here we have to agree to disagree.  I see there being a 
>>> responsibility involved that you don't.  It isn't like anyone can 
>>> just come along and contribute, contrary to what we might want people 
>>> to believe, because there is a barrier to entry, namely those already 
>>> involved.  AND THAT IS FINE.  In fact, it *has* to be that way 
>>> because the alternative is just opening up commit privileges to SVN 
>>> to anyone and everyone, and clearly *that* isn't a good idea :)
>> You say this as if it is the most obvious thing in the world. But is 
>> it? I am quite skeptical. You take as a given that commit privileges 
>> have to be closely guarded, like a high priesthood guards the inner 
>> sanctum.
> Yes, I do think it has to be guarded.  I can think of two good reasons: 
> outright malice and bad code.

I think outright malice is quite rare. In fact, so rare as to be almost 
a non-problem. Have you actually run across this?

As for bad code, this is more likely. However, bad code that actually 
does something can be refactored into something better. At least it's a 
starting point. If it's so bad that nothing of value can be salvaged, 
you can always just roll it back.

I mean, this is a basic difference between software and other fields. If 
you just let anybody work on a construction project, and people did bad 
work, well, it can range from difficult to impossible to revert to the 
original state that the project was in before that work was done. In 
software, you have something completely malleable, and you can always 
just revert to some known state of the code at a given point in time.

So how much damage can anybody really do?

> I am inclined to believe there are some people who would actively try to 
> corrupt the code in some way simply because they have an axe to grind 
> with the project.  

Well, we should be empirical about this. If we're trading notes about 
how to run open source projects, it should be based on actual 
experiences, not just idly speculating on what could happen, right? How 
many cases of outright malice have you run into?

> This could be very subtle, maybe introducing pieces 
> of license-incompatible code.  I don't imagine this would be 
> wide-spread, I think the majority of people would behave themselves just 
> fine, but to ignore the bad parts of human nature would be folly, and I 
> think given the opportunity to add anything they wanted, the bad part 
> would surface at some point.
> There could also be innocent mistakes made, like committing things that 
> you think are license-compatible that really aren't.  This could happen 
> at any time obviously, but if you guard the commit rights, my hope is 
> that you only grant the rights to people you believe understand how to 
> avoid these mistakes more times than not.

Well, I have to admit that I was thinking in terms of being pretty open 
about letting people commit code to the repository, but I meant *their* 
code. I don't think the problem of somebody saying: "Hey, I wrote these 
classes that do X over the weekend." and it not being true, that they 
actually plagiarized them from somewhere else, that this is very 
frequent. But again, this would be a case of bad faith that one would 
class along with the malice issue, right?

And again, I don't think bad faith or malice on the part of people is 
that common a problem.

> Also, I think there has to be some check on the quality of the code 
> coming in.  Especially when your talking about something like Struts 
> that a lot of people base big, important projects on, I don't think it 
> would be wise to let any Java beginner commit code without it being 
> scrutinized.  

I never said that the code people commit should not be scrutinized! Most 
certainly it should be.

> There are better places to "get your legs" than something 
> like Struts.  And plus, it is important to me at least that any 
> committer on any project have a basic understanding of the overall code 
> base, not just a small part to be sure the committed code fits with the 
> overall code base. 

Well, you can always review what they did. Your comments almost would 
lead a casual observer to think that you are unaware that any changes 
people make can be backed out. And quite easily.

> I am not talking about an individual who makes a 
> targeted contribution here or there, I'm talking about a permanent 
> committer who can commit whatever they want at any time (subject to veto 
> by other committers).

> There is a third reason too actually: does the code at least somewhat 
> jive with where the project is going?  This was part of the debate all 
> along... there has to be a balance between being open-minded and 
> accepting new ideas, and just accepting anything that comes along.  A 
> good example is the SetupItems contribution I offered last year.  While 
> it doesn't represent a major paradigm shift or anything like that, the 
> fact is that with Struts 1.3 in the pipeline, and chain being arguably a 
> better solution to the same problem, it was, I feel, reasonable to say 
> that the contribution maybe shouldn't have come in.  I thought it was a 
> good contribution, I in fact know a fair number of people took it and 
> incorporated it on their own, but it was kind of superfluous with the 
> chain refactoring coming, and so in a sense didn't jive with where 
> Struts was going.
>> What is the basis for really believing this? The idea, AFAICS (you can 
>> clarify) is that if you let "anyone and everyone" commit code, they 
>> will commit all kinds of low-quality stuff willy-nilly. 
> Yes, I believe this is part of the risk.

Frank, I do not know all the answers, but here is what I suspect. If you 
just give commit access to anybody who asks for it -- as revolutionary 
an idea as that may sound to you -- most likely the sky will *not* fall in.

That the person who wants the commit access actually does malicious 
things -- I suspect this will just about never happen. That, when you 
review some of the code, you have objections to it, this can happen, but 
is not the end of the world.

You have the pros and the cons. Lowering the barrier to entry has the 
pros that you have a much better chance of getting fresh blood in the 
project. Keeping barriers high leads to what we observe around here.

I suspect the latter is the greater danger.

>  > My own experience
>> running open-source projects has been that the vast majority of times 
>> that you give somebody commit rights to the code repository, they 
>> simply do nothing -- good or bad. 
> In fact, my own experience would echo that.  But I'm not sure that says 
> giving commit privileges is inherently safe... 

Crossing the street is not inherently safe. OTOH, that, when crossing 
the street some homicidal maniac decides to run you over just for the 
hell of it -- this could happen, but quite rarely.

I say the malice thing is just not going to happen that much. Consider 
this. Despite your being a wonderful guy (I'm sure) somebody has a 
grudge against you. Is that person going to: (i) do nothing, 'cause he's 
got a life (ii) get on your mailing list and write an email entitled 
"Frank is an asshole" or (iii) dissimulate his grudge against you, 
pretend he's on your side and ask for CVS access all nice and then do 
malicious things.

I conjecture that (i) is 100 times more likely than (ii) which is in 
turn 100 times more likely than (iii)

What do you think?

> maybe it just says people 
> tend to get a little gun-shy when they are given extra power :)
>  > When they do something, they are typically
>> quite conservative initially since they are aware that they are new 
>> kids on the block and the others are watching closely.
> I agree, that is generally true.  But would it be a good idea to open up 
> the repository to just *anyone*? 

Well, this is an empirical question. I have stated publicly that our 
policy with FreeMarker is basically to give commit access to anybody who 
asks for it. (YOu may note that there aren't that many developers on our 
project, which would seem to contradict this, but the thing is that I 
tend to remove people who, after a 6 months or more, haven't done 
anything, simply because I think the list should reflect people who 
actually have done something.

  That's what I was talking about.
> Certainly some people wouldn't be conservative at first, they would jump 
> right in, and without some sort of vetting process you can't be sure 
> what will get in.  Sure, you could always back it out if you had to, but 
> that seems like cleaning up a nuclear meltdown rather than having safety 
> regulations before-hand to avoid it in the first place :) (Sorry, just 
> watched The West Wing)

I do not seriously see how restoring the code repository to some known 
state in the past is comparable to cleaning up a nuclear meltdown.

But it's an empirical question anyway, subject to an empirical test. 
Give commit privileges to anybody who wants them and see if the sky 
falls in. My conjecture is that it won't.

>> BTW, as regards the overall topic of discussion, I don't know whether 
>> JSF will be the next big thing or not. I have not the foggiest idea. 
>> OTOH, I do have an opinion about the Action/Shale cohabitation. My 
>> opinion, looking at the Struts community and website and the rest with 
>> newbie eyes is that this is disastrous. I think that any project has 
>> to have some coherent message and a person who visits your website and 
>> starts looking at the mail archive and so on has to be able to figure 
>> out quite quickly "WTF is struts" and to have such an incoherent 
>> message due to this Action/Shale bifurcation seems very negative. It 
>> just seems complicated and confused.
> I think it is fair to say you are not alone in that opinion.  What can 
> be done about it, other than voicing the concern, I don't know.  And 
> heck, those that hold that opinion *could* be wrong.

Yes, that is always a possibility. But somehow I doubt it.

Besides, it's unlikely. The last time I was wrong about something was in 
the late 1980's. :-)

>> Well, to put it another way, if I were assigned the task of evaluating 
>> different things in this space, and Struts was one of them, it is very 
>> unlikely that I would settle on it. I would almost certainly end up 
>> opting for a non-schizophrenic alternative.
>> I don't know how other people see things. This is just my honest 
>> reaction. I have no vested interest in this.
> I think it is fair to say that some people see no problem, others see a 
> potentially big problem.  Aside from that, I'm not sure any conclusion 
> can be drawn :)

Well, that's not true, Frank. A conclusion can be drawn since it's an 
empirically resolvable question. You can replicate (roughly) the same 
experiment enough times to draw a pretty definitive conclusion. I don't 
say my own experience is enough to be definitive. But so far, my 
experience suggests that the fears you express about letting people 
commit code are not very well founded. In particular, the malice issue 
is pretty much an ersatz problem, I think. Also, that people start 
committing oodles of low quality code all of a sudden doesn't seem to 
happen either.

Jonathan Revusky
lead developer, FreeMarker project
FreeMarker group blog,

>> Regards,
>> Jonathan Revusky
> Frank

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message