Re: Consequences of open commit privileges (was: has struts reached the saturation)
I like your analogy, however I disagree with the following: > Core Struts people are moving to JSF/Shale ... That's not true for everyone. The whole reason Shale is not Struts 2.0 in the first place is that a majority of the Struts leadership decided that JSF should not be the future direction for Struts. Some people still have not bought into JSF and some probably never will. For me, I wish I had the time to mess around with JSF/shale, but that doesn't mean I am 'moving to JSF/Shale'. Several months ago I thought I was going to be working on a JSF project, but it turned out that we went with Struts 1.2.7 instead. -- James Mitchell EdgeTech, Inc. http://edgetechservices.net/ 678.910.8017 Skype: jmitchtx On Mar 23, 2006, at 4:54 PM, Michael Jouravlev wrote: On 3/23/06, Jonathan Revusky <[EMAIL PROTECTED]> wrote: In order to be able to offer something reasonably state of the art, the Struts community is basically abandoning the Struts 1.x codebase and inviting the Webwork people in. The Webwork 2.2 codebase then gets rechristened "Struts Action Framework 2". But what has happened is definitely a failure of the Struts people to stay competitive technically. You like to write a lot, but you don't like to read. You don't find searching for answer yourself quite entertaining too. I will try again to explain the possible reason for Struts->WebWork move, as *I* see it: Core Struts people are moving to JSF/Shale, leaving the original Struts Classic niche up for grabs. This niche could (and still can) be taken by a "next best thing in action frameworks" whatever it may be, WebWork or Stripes or Spring MVC or something else. In this case the public perception would have been that Struts lost the battle. Struts guys made a smart move bringing WebWork in as Struts 2.0. The name is preserved and all that is related to the name is preserved too, not just software but people as well. This way Struts originators and committers retain their respectable status, while WebWork guys get the market: "I was a Struts committer once" - "Oh, cool! I've heard that version 2.0 will be really a leap forward". Very, very nice deal for all interested parties. Committers work on new interesting stuff, releaving themselves from boring 1.x maintenance. Six years, are you kidding? After all, they work on a new product now, so it will be beneficial for the community too. WebWork guys get the recognition, the market and the influence. Struts Action users get new version of the framework. Who cares that it was called WebWork before? Struts Classic needs/needed a serious makeover anyway, so why not to take others' code instead? Do you care that Pontiac GTO is actually a Holden Monaro, which is heavily based on Opel Omega? GM did not have anything like it anyway, they killed Camaro/Firebird because it was a farm tractor not a sports car. Bringing in GTO was an answer to public demand for a new muscle car. Was this a reasonable choice? Um, for "true" Camaro aficionados, maybe not. For them, Camaro will probably be revived in couple of years. But software is not exactly like automotive industry anyway. GM does not give away GTO for free. Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Consequences of open commit privileges (was: has struts reached the saturation)
On 3/23/06, Jonathan Revusky <[EMAIL PROTECTED]> wrote: > Michael Jouravlev wrote: > In the above you say you will "try again" to explain this. I have no > recollection that you ever tried to explain it to me before. It was in the other longer thread :) > > Core Struts people are moving to JSF/Shale, leaving the original > > Struts Classic niche up for grabs. > > Well, this means that nobody wants to work on the Struts 1.x codebase. > Why? I presume because it's considered to be technically obsolete. > > Why is the Struts 1.x codebase technically obsolete? Is GM's 3.8L pushrod technically obsolete? It is still used by GM and is loved by many. Do you remember Oldsmobile Intrigue, introduced in 1997, I think. It had 3800 pushrod first, then in about two years the engine was replaced with new shiny 3.5L 24-valve Shortstar. Where is Oldsmobile now? Where is Shortstar now? (hint: both discontinued). I do not defent Struts 1.x codebase, I just say that technical pros and cons sometimes matter less than cost to produce, cost to maintain and availability of repair shops. Oldsmobile clientelle was not ready for complex and expensive high-rpm DOHC engine. > One problem is that the whole thing seems to have intent to deceive > behind it. A casual observer will believe that Struts Action 2 is the > continuation of the Struts 1.x codebase and the work of the Struts > community. It is not. It is a codebase that was a competing product, > developed by a different community. Casual observers want software for free. > > Six years, are you kidding? After all, they > > work on a new product now, so it will be beneficial for the community > > too. WebWork guys get the recognition, the market and the influence. > > Struts Action users get new version of the framework. Who cares that > > it was called WebWork before? > > Well, what you're saying, Michael is basically: "Yeah, isn't this great > marketing?" Yeah, isn't it? I think it is. It's now or never. Because when people start to move to Java5 massively, they will look at simpler alternatives that use annotations and other new stuff. I still use JDK1.4, so these alternatives are not for me. > Maybe it is, but you're talking like a marketing guy, not an engineer. Maybe I should move forward then, to big-window office away from my cubicle :) > The intent behind this is to mislead people. Nah. The intent is to break away, keeping/repairing the good image of Struts and of what is related to Struts. > I see intent to deceive. And that does not set well with me. As long as you keep it for yourself to muse about, that's ok. Keep the pitchfork in the barn ;) Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Consequences of open commit privileges (was: has struts reached the saturation)
Michael Jouravlev wrote: On 3/23/06, Jonathan Revusky <[EMAIL PROTECTED]> wrote: In order to be able to offer something reasonably state of the art, the Struts community is basically abandoning the Struts 1.x codebase and inviting the Webwork people in. The Webwork 2.2 codebase then gets rechristened "Struts Action Framework 2". But what has happened is definitely a failure of the Struts people to stay competitive technically. You like to write a lot, but you don't like to read. You don't find searching for answer yourself quite entertaining too. I will try again to explain the possible reason for Struts->WebWork move, as *I* see it: In the above you say you will "try again" to explain this. I have no recollection that you ever tried to explain it to me before. In any case, I appreciate the explanation. Thank you. However, I have the honest impression that I understood all of this already by now. Core Struts people are moving to JSF/Shale, leaving the original Struts Classic niche up for grabs. Well, this means that nobody wants to work on the Struts 1.x codebase. Why? I presume because it's considered to be technically obsolete. Why is the Struts 1.x codebase technically obsolete? This niche could (and still can) be taken by a "next best thing in action frameworks" whatever it may be, WebWork or Stripes or Spring MVC or something else. In this case the public perception would have been that Struts lost the battle. Well, as far as I can see, that perception would be correct. There has been a failure to keep Struts up to date with the state of the art. That is what is behind the move of Webwork over here. Struts guys made a smart move bringing WebWork in as Struts 2.0. The name is preserved and all that is related to the name is preserved too, not just software but people as well. This way Struts originators and committers retain their respectable status, while WebWork guys get the market: "I was a Struts committer once" - "Oh, cool! I've heard that version 2.0 will be really a leap forward". Very, very nice deal for all interested parties. One problem is that the whole thing seems to have intent to deceive behind it. A casual observer will believe that Struts Action 2 is the continuation of the Struts 1.x codebase and the work of the Struts community. It is not. It is a codebase that was a competing product, developed by a different community. The whole thing is structured so as to create a maximum of confusion about what really happened. This is an objection that I lay out here: http://freemarker.blogspot.com/2006/03/musings-about-competition-ego-open.html Committers work on new interesting stuff, releaving themselves from boring 1.x maintenance. Well, maintaining 1.x is quite uninteresting because it has become technically obsolete, due to a failure to keep up with other things in the space, like Webwork. There seems to be a "beg the question" fallacy in what you're saying. Six years, are you kidding? After all, they work on a new product now, so it will be beneficial for the community too. WebWork guys get the recognition, the market and the influence. Struts Action users get new version of the framework. Who cares that it was called WebWork before? Well, what you're saying, Michael is basically: "Yeah, isn't this great marketing?" Maybe it is, but you're talking like a marketing guy, not an engineer. The intent behind this is to mislead people. The casual observer will think that this Webwork codebase is the continuation of Struts 1.x. Eventually, people will even point to Struts Action 2 (i.e. Webwork) as an example of how well "the Apache way" works. However, it is not an example of that. The whole thing is an example of a project that presumably followed the so-called Apache Way failng to stay competitive technically with another project that was developed outside ASF. I see intent to deceive. And that does not set well with me. Jonathan Revusky -- lead developer, FreeMarker project, http://freemarker.org/ Struts Classic needs/needed a serious makeover anyway, so why not to take others' code instead? Do you care that Pontiac GTO is actually a Holden Monaro, which is heavily based on Opel Omega? GM did not have anything like it anyway, they killed Camaro/Firebird because it was a farm tractor not a sports car. Bringing in GTO was an answer to public demand for a new muscle car. Was this a reasonable choice? Um, for "true" Camaro aficionados, maybe not. For them, Camaro will probably be revived in couple of years. But software is not exactly like automotive industry anyway. GM does not give away GTO for free. Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Consequences of open commit privileges (was: has struts reached the saturation)
On 3/23/06, Jonathan Revusky <[EMAIL PROTECTED]> wrote: > In order to be able to offer something > reasonably state of the art, the Struts community is basically > abandoning the Struts 1.x codebase and inviting the Webwork people in. > The Webwork 2.2 codebase then gets rechristened "Struts Action Framework > 2". But what has happened is definitely a failure of the Struts people > to stay competitive technically. You like to write a lot, but you don't like to read. You don't find searching for answer yourself quite entertaining too. I will try again to explain the possible reason for Struts->WebWork move, as *I* see it: Core Struts people are moving to JSF/Shale, leaving the original Struts Classic niche up for grabs. This niche could (and still can) be taken by a "next best thing in action frameworks" whatever it may be, WebWork or Stripes or Spring MVC or something else. In this case the public perception would have been that Struts lost the battle. Struts guys made a smart move bringing WebWork in as Struts 2.0. The name is preserved and all that is related to the name is preserved too, not just software but people as well. This way Struts originators and committers retain their respectable status, while WebWork guys get the market: "I was a Struts committer once" - "Oh, cool! I've heard that version 2.0 will be really a leap forward". Very, very nice deal for all interested parties. Committers work on new interesting stuff, releaving themselves from boring 1.x maintenance. Six years, are you kidding? After all, they work on a new product now, so it will be beneficial for the community too. WebWork guys get the recognition, the market and the influence. Struts Action users get new version of the framework. Who cares that it was called WebWork before? Struts Classic needs/needed a serious makeover anyway, so why not to take others' code instead? Do you care that Pontiac GTO is actually a Holden Monaro, which is heavily based on Opel Omega? GM did not have anything like it anyway, they killed Camaro/Firebird because it was a farm tractor not a sports car. Bringing in GTO was an answer to public demand for a new muscle car. Was this a reasonable choice? Um, for "true" Camaro aficionados, maybe not. For them, Camaro will probably be revived in couple of years. But software is not exactly like automotive industry anyway. GM does not give away GTO for free. Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Consequences of open commit privileges (was: has struts reached the saturation)
Jonathan Revusky wrote: > [EMAIL PROTECTED] wrote: >> Now we're leaving empiricism for speculation. > No, because the above propositions can, in principle, be put to an > empirical test. If it _hasn't_ been put to an empirical test then it's speculation. > Obviously, it is completely natural to wonder whether Struts 1.x > development would not be in a healthier state if it had been easier > for new people to get involved. Wondering is a natural human phenomenon. I assume you meant that it's natural to wonder if the dev _would_ be in a healthier state if it had been easier; I wonder both. We'll never know, though, will we. > When was your youth? I am in my early forties. Am I in my youth? O. I guess I would have thought you'd be further along by now, but we all progress at our own rate, and that's okay. > If you do something and fail, you have to humbly accept advice from > people. Says who? You sure like those absolutes, huh. > In an open source project, somebody who thinks he can pitch in and > contribute should have a chance to do so. Even in Apache, they have a chance to do so. Doesn't mean it'll happen, though. > That is why, yes, this closed club stuff deeply offends me on some level. Maybe some counseling would be in order. > [...] members of the Struts PMC do not behave like seasoned adults. I like seasoned adults, but with more paprika than most prefer. > Obviously, if somebody gives you feedback on your work, you thank them > and consider it. (Or at least say you'll consider it...) Hey, I think FreeMarker sucks. You're welcome? Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Consequences of open commit privileges (was: has struts reached the saturation)
[EMAIL PROTECTED] wrote: Jonathan Revusky wrote: George Dinwiddie wrote: Scott Adams has made his fortune displaying the cynical view of managers that you describe. Indeed, from the point of view of the technical staff or others with limited access to those managers, it often looks like decisions are being made very arbitrarily. In some cases, they actually are. Incompetent managers are probably as common as incompetent developers. In reality, most managers do have a brain and use it. Most managers are not merely trying to avoid drawing attention to themselves so they can draw a salary for doing no work. Believe it or not, most managers take their jobs seriously and make the best decisions they can given the knowledge they have and the circumstances in which they make them. By "knowledge they have" I don't mean technical ignorance. Sure, some are quite ignorant technically and most do not have the detailed technical knowledge of a developer, but they also have knowledge of non-technical issues of which most developers are rather ignorant. The question under discussion is whether managers who opt for Struts have, typically, much notion of the process by which this software was developed. Based on what experience I have of interacting with corporate type people, my bet is that usually they don't. In some cases, maybe they do, but that would be a comparative rarity. That is why I don't easily believe that if Struts were to adopt a more open approach to letting people commit code that it would affect corporate adoption that much, simply because the corporate people, by and large, do not know that much about how open source software really is developed. You yourself seem to be operating under various misconceptions in this regard. You have, from what I see, a misplaced confidence in the procedures that allowed the current committers to actually become committers. I get the feeling that you don't have a sense of just how arbitrary the whole thing is. 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.) Now we're leaving empiricism for speculation. No, because the above propositions can, in principle, be put to an empirical test. The one thing that's clear is that technical progress on Struts ground to a halt and they were superseded technically by Webwork, which was not developed at ASF. So, what is not speculative at all, is that the development process did not have very good results. In order to be able to offer something reasonably state of the art, the Struts community is basically abandoning the Struts 1.x codebase and inviting the Webwork people in. The Webwork 2.2 codebase then gets rechristened "Struts Action Framework 2". But what has happened is definitely a failure of the Struts people to stay competitive technically. Meanwhile, in my following of this discussion, it is clear that there are people who were able and eager to pitch in and work on the code, who, due to this process, were unable to. Obviously, it is completely natural to wonder whether Struts 1.x development would not be in a healthier state if it had been easier for new people to get involved. 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... You've extrapolated several suppositions, here. Who says their beliefs are misguided? Reread it carefully, Geoge. I didn't say that they were definitely misguided. I just said they might be. "If people believe this but it's not true, should one condition one's behavior on people's misguided beliefs?" It was the first part of a conditional. You didn't quite grasp that, it seems. I presume from these statements that you're rather young. In my youth, I tended to believe that those who didn't agree with my beliefs were misguided. And I was not shy of telling them so. When was your youth? I am in my early forties. Am I in my youth? But even supposing that I am right and they are wrong (and I no longer believe that these are boolean values), I am unlikely to convince them by announcing that they're all wrong. They will naturally think, "On the one hand, I have this kid without the experience to understand the issues which I'm balancing telling me that I'm wrong. Well, in this exact case, you're unlikely to convince them of anything. These are people who simply don't listen. Could this possibly be lost on you at this point, George? :-) Really... On the other hand, my view of the world and the way it works ha
RE: Re: Consequences of open commit privileges (was: has struts reached the saturation)
Jonathan Revusky wrote: > George Dinwiddie wrote: > > 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. I presume that you've never worked in a corporate environment. Proceeding on that assumption, let me explain a little to you. Scott Adams has made his fortune displaying the cynical view of managers that you describe. Indeed, from the point of view of the technical staff or others with limited access to those managers, it often looks like decisions are being made very arbitrarily. In some cases, they actually are. Incompetent managers are probably as common as incompetent developers. In reality, most managers do have a brain and use it. Most managers are not merely trying to avoid drawing attention to themselves so they can draw a salary for doing no work. Believe it or not, most managers take their jobs seriously and make the best decisions they can given the knowledge they have and the circumstances in which they make them. By "knowledge they have" I don't mean technical ignorance. Sure, some are quite ignorant technically and most do not have the detailed technical knowledge of a developer, but they also have knowledge of non-technical issues of which most developers are rather ignorant. > 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.) Now we're leaving empiricism for speculation. > 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... You've extrapolated several suppositions, here. Who says their beliefs are misguided? I presume from these statements that you're rather young. In my youth, I tended to believe that those who didn't agree with my beliefs were misguided. And I was not shy of telling them so. But even supposing that I am right and they are wrong (and I no longer believe that these are boolean values), I am unlikely to convince them by announcing that they're all wrong. They will naturally think, "On the one hand, I have this kid without the experience to understand the issues which I'm balancing telling me that I'm wrong. On the other hand, my view of the world and the way it works has done pretty well for me so far." Do you doubt everything you've learned when someone walks up and says you're wrong? I thought not. Is your lack of success in convincing someone that they're wrong their problem or yours? Do you want to do something about that lack of success? Or do you like that status quo? If you like futile arguments, then you seem to be doing a fine job on your own. But if you want to argue more effectively, then I can suggest the AYE Conference (http://www.ayeconference.com/conference.html). And if you can't find the time or money to attend, there's still lots of good information in the blogs and articles of the people who put on that conference--more than you could assimilate in a lifetime. > 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. Do you want to contribute to Struts and feel excluded? Or are you morally indignant based on higher principles? I can't figure this out. As for the technology, and the rules of running the project, in both cases I'm glad that the wide world provides more than one choice. I'm glad t
Re: Consequences of open commit privileges (was: has struts reached the saturation)
[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
RE: Re: Consequences of open commit privileges (was: has struts reached the saturation)
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. > 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. > > 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. > 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. I'm saying it would be less trusted. It's harder for me to trust a large group than a small one. > 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
Re: Consequences of open commit privileges (was: has struts reached the saturation)
Michael Jouravlev wrote: On 3/21/06, Jonathan Revusky <[EMAIL PROTECTED]> wrote: Michael Jouravlev wrote: On 3/21/06, Jonathan Revusky <[EMAIL PROTECTED]> wrote: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Consequences of open commit privileges (was: has struts reached the saturation)
Ted Husted wrote: On 3/21/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> 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 reputat
Re: Consequences of open commit privileges (was: has struts reached the saturation)
On 3/21/06, Jonathan Revusky <[EMAIL PROTECTED]> wrote: > Michael Jouravlev wrote: > > On 3/21/06, Jonathan Revusky <[EMAIL PROTECTED]> wrote: > > > >>[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Consequences of open commit privileges (was: has struts reached the saturation)
Michael Jouravlev wrote: On 3/21/06, Jonathan Revusky <[EMAIL PROTECTED]> wrote: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Consequences of open commit privileges (was: has struts reached the saturation)
On 3/21/06, Jonathan Revusky <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Consequences of open commit privileges (was: has struts reached the saturation)
[EMAIL PROTECTED] 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,
Re: Consequences of open commit privileges (was: has struts reached the saturation)
On 3/21/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
