Re: Jakarta: too many similar projects?
I would simply like to point out WHO is the specification lead of JSR-127 (see http://www.jcp.org/en/jsr/detail?id=127), and who was the initial author of Struts (see http://jakarta.apache.org/struts/volunteers.html)... Apache's concerns were Considering Sun's current position that JSRs may not be independently implemented under an open source license [...], and I'll let you make 1 + 1 here... Thanks Pier. I had wondered when someone would point this out. Having clarity on the facts is very important, because all too often non-reasons distract us from the really important reasons. With respect to having multiple projects doing the same thing, I believe Apache's approach has been very balanced and laudable. You've got 3 fundamental forces at play: + The need to maintain backwards compatibility so you don't burn your existing users. + The desire to continue innovation, advancing our designs and APIs. + The desire to support and recognize strong, healthy developer communities which share the Apache values of innovation, open software, community, and meritocracy. Apache has met all three of these forces in it's decisions to adopt additional projects, such as Struts and Tapestry. Whereas businesses aim to maximize profit, and academia structures to maximize ego, Apache and open source have routinely demonstrated a true commitment to maximizing community. And we are all better off for it. Doug -- Yet each man kills the thing he loves, By each let this be heard, Some do it with a bitter look, Some with a flattering word. The coward does it with a kiss, The brave man with a sword! Oscar Wilde (1854-1900) British Author and Wit - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: too many similar projects?
Note that Sun's JCP NDA agreements burn the second and third completely. And possibly the first (though i'm not a big fan of long standing deprecations.. ). -Andy Thanks Pier. I had wondered when someone would point this out. Having clarity on the facts is very important, because all too often non-reasons distract us from the really important reasons. With respect to having multiple projects doing the same thing, I believe Apache's approach has been very balanced and laudable. You've got 3 fundamental forces at play: + The need to maintain backwards compatibility so you don't burn your existing users. + The desire to continue innovation, advancing our designs and APIs. + The desire to support and recognize strong, healthy developer communities which share the Apache values of innovation, open software, community, and meritocracy. Apache has met all three of these forces in it's decisions to adopt additional projects, such as Struts and Tapestry. Whereas businesses aim to maximize profit, and academia structures to maximize ego, Apache and open source have routinely demonstrated a true commitment to maximizing community. And we are all better off for it. Doug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: too many similar projects?
On Tuesday, March 11, 2003, at 06:08 PM, Andrew C. Oliver wrote: Note that Sun's JCP NDA agreements burn the second and third completely. Utter nonsense. Are you saying that there's a dearth of innovation at apache? Or that Apache doesn't support strong communities? geir And possibly the first (though i'm not a big fan of long standing deprecations.. ). -Andy Thanks Pier. I had wondered when someone would point this out. Having clarity on the facts is very important, because all too often non-reasons distract us from the really important reasons. With respect to having multiple projects doing the same thing, I believe Apache's approach has been very balanced and laudable. You've got 3 fundamental forces at play: + The need to maintain backwards compatibility so you don't burn your existing users. + The desire to continue innovation, advancing our designs and APIs. + The desire to support and recognize strong, healthy developer communities which share the Apache values of innovation, open software, community, and meritocracy. Apache has met all three of these forces in it's decisions to adopt additional projects, such as Struts and Tapestry. Whereas businesses aim to maximize profit, and academia structures to maximize ego, Apache and open source have routinely demonstrated a true commitment to maximizing community. And we are all better off for it. Doug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-956-2604(w) Adeptra, Inc. 203-434-2093(m) [EMAIL PROTECTED] 203-247-1713(m) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: too many similar projects?
No I'm saying that projects which some committers are bound by Sun's NDAs and are on the specification commmittees do not have meritocratic consensus based communities. The committers engaged in the legal agreement with sun cannot talk to the other committers about important decisions affecting the project and secondly the major decisions are made in the specification committee and not in the project itself. Committers are promoted to the decision making process by an outside entity (sun) and not by their own community. The communication bonds twart collaboration which degrades innovation. The JCP does not encourage innovative processes which Sun or the Spec lead might disagree with. So I'll say it more clearly JCP NDAs are anti-communalistic and twart innovation. Lets talk about what a great thing the portlet specification committee has done for the Jetspeed project. -Andy Geir Magnusson Jr. wrote: On Tuesday, March 11, 2003, at 06:08 PM, Andrew C. Oliver wrote: Note that Sun's JCP NDA agreements burn the second and third completely. Utter nonsense. Are you saying that there's a dearth of innovation at apache? Or that Apache doesn't support strong communities? geir And possibly the first (though i'm not a big fan of long standing deprecations.. ). -Andy Thanks Pier. I had wondered when someone would point this out. Having clarity on the facts is very important, because all too often non-reasons distract us from the really important reasons. With respect to having multiple projects doing the same thing, I believe Apache's approach has been very balanced and laudable. You've got 3 fundamental forces at play: + The need to maintain backwards compatibility so you don't burn your existing users. + The desire to continue innovation, advancing our designs and APIs. + The desire to support and recognize strong, healthy developer communities which share the Apache values of innovation, open software, community, and meritocracy. Apache has met all three of these forces in it's decisions to adopt additional projects, such as Struts and Tapestry. Whereas businesses aim to maximize profit, and academia structures to maximize ego, Apache and open source have routinely demonstrated a true commitment to maximizing community. And we are all better off for it. Doug - 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: Jakarta: too many similar projects?
On Tuesday, March 11, 2003, at 06:40 PM, Andrew C. Oliver wrote: No I'm saying that projects which some committers are bound by Sun's NDAs and are on the specification commmittees do not have meritocratic consensus based communities. Do you have any examples of this? You aren't confusing the material I submit to the ASF JCP group from the EC with whatever you are thinking about, are you? The committers engaged in the legal agreement with sun cannot talk to the other committers about important decisions affecting the project and secondly the major decisions are made in the specification committee and not in the project itself. What? How would that work, logically? I mean, if the committers on the JSR are bound by an NDA, and thus can't talk to the committers on a related Apache project, how can they communicate the 'major decisions' from this committee, and inflict them on the project? Some sort of 'double-secret' commit? Add code that no one can look at? There is no project here at the ASF that isn't open for public review. Committers are promoted to the decision making process by an outside entity (sun) and not by their own community. I'm starting to think this is a troll. Committers are promoted by their community. Sun has nothing to do with it. Further, most JSR's have nothing to do with Sun, except that Sun is financing the process management. The spec leads, in conjunction with the expert group, get copyright of the spec, dictate the license terms, etc, etc, etc. Sun has nothing to do with it, unless Sun is the spec lead. I'll be the first to say that the JCP is far from perfect, but what you are saying here doesn't make any sense. The communication bonds twart collaboration which degrades innovation. The JCP does not encourage innovative processes which Sun or the Spec lead might disagree with. There is no reason why a JSR can't be totally open. It's up to the spec lead, as is the license. The innovation to the platform is brought by people like you and me that decide we have an API, technology, etc, that is appropriate for addition to the platform. The innovation happens before the JSR even starts. No one proposes a JSR to do something innovative that we haven't thought of yet. They do something innovative that they have done something with already. So I'll say it more clearly JCP NDAs are anti-communalistic and twart innovation. I'm sure you believe this. Lets talk about what a great thing the portlet specification committee has done for the Jetspeed project. Yes, lets do that. (That's 1 out of 200 or so, so while there may be a problem with that specific JSR, we might have to look at a few more before generalizing.) -Andy Geir Magnusson Jr. wrote: On Tuesday, March 11, 2003, at 06:08 PM, Andrew C. Oliver wrote: Note that Sun's JCP NDA agreements burn the second and third completely. Utter nonsense. Are you saying that there's a dearth of innovation at apache? Or that Apache doesn't support strong communities? geir And possibly the first (though i'm not a big fan of long standing deprecations.. ). -Andy Thanks Pier. I had wondered when someone would point this out. Having clarity on the facts is very important, because all too often non-reasons distract us from the really important reasons. With respect to having multiple projects doing the same thing, I believe Apache's approach has been very balanced and laudable. You've got 3 fundamental forces at play: + The need to maintain backwards compatibility so you don't burn your existing users. + The desire to continue innovation, advancing our designs and APIs. + The desire to support and recognize strong, healthy developer communities which share the Apache values of innovation, open software, community, and meritocracy. Apache has met all three of these forces in it's decisions to adopt additional projects, such as Struts and Tapestry. Whereas businesses aim to maximize profit, and academia structures to maximize ego, Apache and open source have routinely demonstrated a true commitment to maximizing community. And we are all better off for it. Doug - 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] -- Geir Magnusson Jr 203-956-2604(w) Adeptra, Inc. 203-434-2093(m) [EMAIL PROTECTED] 203-247-1713(m) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: too many similar projects?
Do you have any examples of this? You aren't confusing the material I submit to the ASF JCP group from the EC with whatever you are thinking about, are you? I do not subscribe to the [EMAIL PROTECTED] list as I was informed that it would bind me in the ASF's NDA agreements with Sun. (and I don't know what the EC is in this context ... European commission?) The committers engaged in the legal agreement with sun cannot talk to the other committers about important decisions affecting the project and secondly the major decisions are made in the specification committee and not in the project itself. What? How would that work, logically? I mean, if the committers on the JSR are bound by an NDA, and thus can't talk to the committers on a related Apache project, how can they communicate the 'major decisions' from this committee, and inflict them on the project? Some sort of 'double-secret' commit? Add code that no one can look at? There is no project here at the ASF that isn't open for public review. Is not the specification itself a major decision? Yes the Portlet JSR has secret code that no one can look at. No one can know the goings on. Only David Taylor whom is on the committee knows what is going on and he is not permitted to talk about it. Committers are promoted to the decision making process by an outside entity (sun) and not by their own community. I'm starting to think this is a troll. Committers are promoted by their community. Sun has nothing to do with it. Further, most JSR's have nothing to do with Sun, except that Sun is financing the process management. The spec leads, in conjunction with the expert group, get copyright of the spec, dictate the license terms, etc, etc, etc. Sun has nothing to do with it, unless Sun is the spec lead. I'll be the first to say that the JCP is far from perfect, but what you are saying here doesn't make any sense. I never said it wasn't (http://www.datanation.com/fallacies/attack.htm troll). I still regard the JCP NDA agreements as detrimental to community and to innovation. Until such time as NDAs are not part of the JCP and the door is open to committers on affected projects, I will regard it as an antidote for community and innovation. The communication bonds twart collaboration which degrades innovation. The JCP does not encourage innovative processes which Sun or the Spec lead might disagree with. There is no reason why a JSR can't be totally open. It's up to the spec lead, as is the license. The innovation to the platform is brought by people like you and me that decide we have an API, technology, etc, that is appropriate for addition to the platform. The innovation happens before the JSR even starts. No one proposes a JSR to do something innovative that we haven't thought of yet. They do something innovative that they have done something with already. And you do not see a dictatorial spec lead and a override by sun as being anti-community? I have not and will not sign an NDA or non-compete with Sun without substantial monetary compensation and therefore while I might innovate using the platform, I shall not be bringing my innovations to the JCP. I see no need to propose a specification or what have you via the JCP once the project has become dominant. If I had a bad standard that I wanted to push, the JCP would seem the most reasonable route to push it. So I'll say it more clearly JCP NDAs are anti-communalistic and twart innovation. I'm sure you believe this. I'm sure you have sufficient motivation not to believe that. ;-) (http://www.datanation.com/fallacies/attack.htm and one in turn) Lets talk about what a great thing the portlet specification committee has done for the Jetspeed project. Yes, lets do that. (That's 1 out of 200 or so, so while there may be a problem with that specific JSR, we might have to look at a few more before generalizing.) So give me a count of how many do not require NDAs and where all committers on an affected project could participate on the spec committee's decision making. (You're attacking the basis. I gave an example. There is another logical fallacy that states saying well most of the 200 might not be like this and improperly shifting the burden onto the other party for refuting it.) -Andy -Andy Geir Magnusson Jr. wrote: On Tuesday, March 11, 2003, at 06:08 PM, Andrew C. Oliver wrote: Note that Sun's JCP NDA agreements burn the second and third completely. Utter nonsense. Are you saying that there's a dearth of innovation at apache? Or that Apache doesn't support strong communities? geir And possibly the first (though i'm not a big fan of long standing deprecations.. ). -Andy Thanks Pier. I had wondered when someone would point this out. Having clarity on the facts is very important, because all too often non-reasons distract us from the really important reasons. With respect to having multiple projects
Re: Jakarta: too many similar projects?
Andrew C. Oliver wrote: have meritocratic consensus based communities. The committers engaged in the legal agreement with sun cannot talk to the other committers about important decisions affecting the project and secondly the major decisions are made in the specification committee and not in the project itself. Committers are promoted to the decision making process by an outside entity (sun) and not by their own community. My understanding is that the NDA prevent those in the JCP from sharing with the world - but AFAIK they can share it with other ASF members. If we could find a way to extend this to the whole PMC - then we can improve a bit the communication problem. Regarding the selection - I think it's up to ASF to set the policy on who will represent it in the various JCP groups. Right now it's whoever volunteers - which is reasonable. There is no ASF policy that I know about the responsibilities of those who represent the ASF in JCP - with regard to sharing the info with at least the members in the interested PMC - and I think this is a problem. As with any standard, the decision making is based on a group of people representing different interests. Apache does have a vote ( AFAIK ), just like Sun or IBM. Projects should be able to participate - and we should find a way to apply the apache meritocracy and community rules in our participation to JCP ( for example by a vote by committers who are affected or by PMCs ). In any case - your comment that the decision is made by a committee is right, and it is the way things happen in all standard organizations that I know. Even in Apache - the products are defined by a community of committers, and the decisions are made by a consensus or majority vote. The communication bonds twart collaboration which degrades innovation. The JCP does not encourage innovative processes which Sun or the Spec lead might disagree with. The spec is approved by a majority vote. I don't think standard goal should be to innovate - but recognize common patterns and practices and set ground rules. As with any project - the quality of the participants and the quality of the communication has a big effect on the end result. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: too many similar projects?
On 11/3/03 23:40 Andrew C. Oliver [EMAIL PROTECTED] wrote: No I'm saying that projects which some committers are bound by Sun's NDAs and are on the specification commmittees do not have meritocratic consensus based communities. The committers engaged in the legal agreement with sun cannot talk to the other committers about important decisions affecting the project and secondly the major decisions are made in the specification committee and not in the project itself. Committers are promoted to the decision making process by an outside entity (sun) and not by their own community. The communication bonds twart collaboration which degrades innovation. I am the official Apache representative for Servlet, and in my personal experience it is quite difficult to voice some concerns I have on the direction of the with the developer community of Jakarta, because, as you said, I am not supposed to mention what goes on in the JSR lists in public whilst over in Apache land I'm not supposed to keep something private. The JCP does not encourage innovative processes which Sun or the Spec lead might disagree with. Sometimes it does, sometimes it doesn't... We have example swinging both ways, the spec lead enforcing something on the JSR expert group, or in other cases, the expert group driven by the community outside forcing something on the spec lead... Most of the times, in my experience, it all comes down to how receptive the spec lead is in regards to new ideas coming from outside, and how much weight he has in his company (the JSR sponsoring company)... But my experience is too little to say what happens more often. Pier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: too many similar projects?
Thanks Pier. Thats a great perpective. Lets have some more. Anyone have a remarkably positive Gee the JCP listens to everyone and I can disclose everything to my fellow committers and its been great for our community? -Andy Pier Fumagalli wrote: On 11/3/03 23:40 Andrew C. Oliver [EMAIL PROTECTED] wrote: No I'm saying that projects which some committers are bound by Sun's NDAs and are on the specification commmittees do not have meritocratic consensus based communities. The committers engaged in the legal agreement with sun cannot talk to the other committers about important decisions affecting the project and secondly the major decisions are made in the specification committee and not in the project itself. Committers are promoted to the decision making process by an outside entity (sun) and not by their own community. The communication bonds twart collaboration which degrades innovation. I am the official Apache representative for Servlet, and in my personal experience it is quite difficult to voice some concerns I have on the direction of the with the developer community of Jakarta, because, as you said, I am not supposed to mention what goes on in the JSR lists in public whilst over in Apache land I'm not supposed to keep something private. The JCP does not encourage innovative processes which Sun or the Spec lead might disagree with. Sometimes it does, sometimes it doesn't... We have example swinging both ways, the spec lead enforcing something on the JSR expert group, or in other cases, the expert group driven by the community outside forcing something on the spec lead... Most of the times, in my experience, it all comes down to how receptive the spec lead is in regards to new ideas coming from outside, and how much weight he has in his company (the JSR sponsoring company)... But my experience is too little to say what happens more often. Pier - 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: Jakarta: too many similar projects?
On Tue, 11 Mar 2003, Andrew C. Oliver wrote: Date: Tue, 11 Mar 2003 22:09:14 -0500 From: Andrew C. Oliver [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Subject: Re: Jakarta: too many similar projects? Thanks Pier. Thats a great perpective. Lets have some more. Anyone have a remarkably positive Gee the JCP listens to everyone and I can disclose everything to my fellow committers and its been great for our community? Andy seems to believe that *implementing* a specification (as opposed to creating one) is not a valid itch to be scratched if he doesn't like the mechanism by which the specification is created. It's perfectly reasonable for Andy to decide that for the projects he gets personally involved in, but it seems awfully arrogant to argue that no one at Apache should involve themselves in such an implementation project on that basis. As it turns out, there is substantial room for innovation and debate in the implementation of API specs like servlet and JSP (see the history of Tomcat development, and the recent innovation going on there for an example), just like there is lots of room to be creative in implementing something like HTTP, which has been done, and continues to be done, in a very large number of implementations in a very large number of languages -- despite the fact that the W3C standards process, like many others, includes periods of time when only the privileged few are allowed to be involved. -Andy Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
re: Jakarta: too many similar projects?
Craig M. wrote: | Andy seems to believe that *implementing* a specification (as opposed to | creating one) is not a valid itch to be scratched if he doesn't like the | mechanism by which the specification is created. It's perfectly | reasonable for Andy to decide that for the projects he gets personally | involved in, but it seems awfully arrogant to argue that no one at Apache | should involve themselves in such an implementation project on that basis. It is straightforward to replace brand overloading with brand segmentation, including informal segmentation that is later formalized upon wide adoption. Rich - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
re[2]: Jakarta: too many similar projects?
| It is straightforward to replace brand overloading with brand segmentation, | including informal segmentation that is later formalized upon wide | adoption. | | | huh? | | Conor Andy (or Craig or anyone) can fork the single Apache brand to differentiate projects that are community or standards or foo -oriented. If the distinction turns out be predictive (of code quality or innovation or discussion quality or ...), then people will use the - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: too many similar projects?
Yeah, on second thought, its a great idea to remove choice in a project and instead submit it to a JSR committee and hence Suns conrol, take a few folks and put them on NDA so that they can't talk about certain decisions which will affect the project. I'm not against all standards...just NDA-based vendor baby kissing. -Andy Craig R. McClanahan wrote: On Tue, 11 Mar 2003, Andrew C. Oliver wrote: Date: Tue, 11 Mar 2003 22:09:14 -0500 From: Andrew C. Oliver [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Subject: Re: Jakarta: too many similar projects? Thanks Pier. Thats a great perpective. Lets have some more. Anyone have a remarkably positive Gee the JCP listens to everyone and I can disclose everything to my fellow committers and its been great for our community? Andy seems to believe that *implementing* a specification (as opposed to creating one) is not a valid itch to be scratched if he doesn't like the mechanism by which the specification is created. It's perfectly reasonable for Andy to decide that for the projects he gets personally involved in, but it seems awfully arrogant to argue that no one at Apache should involve themselves in such an implementation project on that basis. As it turns out, there is substantial room for innovation and debate in the implementation of API specs like servlet and JSP (see the history of Tomcat development, and the recent innovation going on there for an example), just like there is lots of room to be creative in implementing something like HTTP, which has been done, and continues to be done, in a very large number of implementations in a very large number of languages -- despite the fact that the W3C standards process, like many others, includes periods of time when only the privileged few are allowed to be involved. -Andy Craig McClanahan - 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: Jakarta: too many similar projects?
Andrew C. Oliver wrote: Yeah, on second thought, its a great idea to remove choice in a project and instead submit it to a JSR committee and hence Suns conrol, take a few folks and put them on NDA so that they can't talk about certain decisions which will affect the project. I'm not against all standards...just NDA-based vendor baby kissing. Andy: Sun doesn't control, it has one vote just like ASF or IBM. ( at least AFAIK ). If the lead is an Apache representative he can choose open mailing lists - there are few JSRs that do that. I don't know if W3C or Ecma are using only public mailing list and no NDS - but I'm pretty sure there are enough big corporations involved:-) Costin -Andy Craig R. McClanahan wrote: On Tue, 11 Mar 2003, Andrew C. Oliver wrote: Date: Tue, 11 Mar 2003 22:09:14 -0500 From: Andrew C. Oliver [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Subject: Re: Jakarta: too many similar projects? Thanks Pier. Thats a great perpective. Lets have some more. Anyone have a remarkably positive Gee the JCP listens to everyone and I can disclose everything to my fellow committers and its been great for our community? Andy seems to believe that *implementing* a specification (as opposed to creating one) is not a valid itch to be scratched if he doesn't like the mechanism by which the specification is created. It's perfectly reasonable for Andy to decide that for the projects he gets personally involved in, but it seems awfully arrogant to argue that no one at Apache should involve themselves in such an implementation project on that basis. As it turns out, there is substantial room for innovation and debate in the implementation of API specs like servlet and JSP (see the history of Tomcat development, and the recent innovation going on there for an example), just like there is lots of room to be creative in implementing something like HTTP, which has been done, and continues to be done, in a very large number of implementations in a very large number of languages -- despite the fact that the W3C standards process, like many others, includes periods of time when only the privileged few are allowed to be involved. -Andy Craig McClanahan - 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[3]: Jakarta: too many similar projects?
I wrote: | Andy (or Craig or anyone) can fork the single Apache brand to differentiate | projects that are community or standards or foo -oriented. If the | distinction turns out be predictive (of code quality or innovation or | discussion | quality or ...), then people will use the sorry about the early send new terminology. The brand is the first interface to the community. Just as new app requirements can improve code refactoring or interface definitions, new audiences can improve organizational refactoring. It's not necessary to jump directly to group policy or reorg, you can use a view to prototype the benefits for your communities of interest. Any set of interactions among people with common interests (incl. NDAs) creates a community. Those within may debate values or objectives, but a community only becomes real via the experiences of *external* people, This is why Pringles should start a WiFi antenna company. Rich - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JCP NDA (was: too many similar projects?)
Andy wrote: | Yeah, on second thought, its a great idea to remove choice in a project | and instead submit it to a JSR committee and hence Suns conrol, take a | few folks and put them on NDA so that they can't talk about certain | decisions which will affect the project. [** disclaimer: I was a consultant to the team that developed http://sun.com/codingforcurrency . I don't speak for Sun or any past or present client. ] Is the NDA under NDA? Or can someone post a copy? NDA is as descriptive as license. There are many species of NDA and they are subject to evolution, like all social contracts. Yes, a lazy lawyer could draft, You agree (a) not to say anything, and (b) not to say that you agreed to this agreement, and (c) not to acknowledge that this agreement exists, but educated parties don't sign vague and non-specific agreements. Boundaries (physics and law) are improved by documentation. First-party testing is not an efficient means of documentation. Rich - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
re: JCP NDA (was: too many similar projects?)
I wrote: | Is the NDA under NDA? Or can someone post a copy? Ok, there's no separate NDA, it's part of the standard agreements: http://jcp.org/en/participation/membership Follow-up questions: 1. Is there an Apache-specific, public archive of JCP discussion, including the negotiation of JCP 2.5? This seems to exclude [EMAIL PROTECTED] . Is there a [EMAIL PROTECTED] ? If not, one could be culled from the archives of other lists. 2. Is there an Apache-specific, public archive of the discussion that preceded the decision to make [EMAIL PROTECTED] non-public ? Pier wrote: | Most of the times, in my experience, it all comes down to how receptive | the spec lead is in regards to new ideas coming from outside, and how much | weight he has in his company (the JSR sponsoring company)... | | But my experience is too little to say what happens more often. Are there any metrics on the performance of spec leads, besides: http://jcp.org/aboutJava/communityprocess/withdrawn.html http://jcp.org/aboutJava/communityprocess/rejected.html Apache has tools that provide quantitative feedback on the development process. Can any of these be adapted to provide quantitative feedback on the post-public spec development process, using historical (public) data? Spec leads need to be JCP members and there's a $5K threshold for commercial companies. That's a large gap between Tier $0 (Apache and fully open) and Tier $5K (JCP and open/closed per above cited agreements). Is there a subset of Apache members who represent smaller commercial companies, who won't/can't incur the JCP overhead, but who wish to give their customers the benefits of inter-vendor portability and test compliance? Rich - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: too many similar projects?
- Original Message - From: Andrew C. Oliver [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Sent: Tuesday, March 11, 2003 8:40 PM Subject: Re: Jakarta: too many similar projects? Yeah, on second thought, its a great idea to remove choice in a project and instead submit it to a JSR committee and hence Suns conrol, take a few folks and put them on NDA so that they can't talk about certain decisions which will affect the project. I'm not against all standards...just NDA-based vendor baby kissing. Please don't feed the Trolls. -Andy Craig R. McClanahan wrote: On Tue, 11 Mar 2003, Andrew C. Oliver wrote: Date: Tue, 11 Mar 2003 22:09:14 -0500 From: Andrew C. Oliver [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Subject: Re: Jakarta: too many similar projects? Thanks Pier. Thats a great perpective. Lets have some more. Anyone have a remarkably positive Gee the JCP listens to everyone and I can disclose everything to my fellow committers and its been great for our community? Andy seems to believe that *implementing* a specification (as opposed to creating one) is not a valid itch to be scratched if he doesn't like the mechanism by which the specification is created. It's perfectly reasonable for Andy to decide that for the projects he gets personally involved in, but it seems awfully arrogant to argue that no one at Apache should involve themselves in such an implementation project on that basis. As it turns out, there is substantial room for innovation and debate in the implementation of API specs like servlet and JSP (see the history of Tomcat development, and the recent innovation going on there for an example), just like there is lots of room to be creative in implementing something like HTTP, which has been done, and continues to be done, in a very large number of implementations in a very large number of languages -- despite the fact that the W3C standards process, like many others, includes periods of time when only the privileged few are allowed to be involved. -Andy Craig McClanahan - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: too many similar projects?
On Tuesday, March 11, 2003, at 08:21 PM, Costin Manolache wrote: As with any standard, the decision making is based on a group of people representing different interests. Apache does have a vote ( AFAIK ), just like Sun or IBM. Projects should be able to participate - and we should find a way to apply the apache meritocracy and community rules in our participation to JCP ( for example by a vote by committers who are affected or by PMCs ). One way we can do this is for ourselves to do be spec leads for JSR's. Then we can set the rules for the group, and the license. Jetspeed has been around for a while - it was only recently that IBM (and ?) proposed the JSR. We could have done it long before that. The communication bonds twart collaboration which degrades innovation. The JCP does not encourage innovative processes which Sun or the Spec lead might disagree with. The spec is approved by a majority vote. I don't think standard goal should be to innovate - but recognize common patterns and practices and set ground rules. Well - that's one way to describe it. The other way is that the JCP is how innovations are brought to the platform - the innovation was done before you tried to make a JSR. For example, Jason Hunter is running a JSR for JDOM. JDOM was done, and the benefits of the software clear, before he proposed the JSR geir -- Geir Magnusson Jr 203-956-2604(w) Adeptra, Inc. 203-434-2093(m) [EMAIL PROTECTED] 203-247-1713(m) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: too many similar projects?
On Tuesday, March 11, 2003, at 10:58 PM, Craig R. McClanahan wrote: As it turns out, there is substantial room for innovation and debate in the implementation of API specs like servlet and JSP (see the history of Tomcat development, and the recent innovation going on there for an example), just like there is lots of room to be creative in implementing something like HTTP, which has been done, and continues to be done, in a very large number of implementations in a very large number of languages -- despite the fact that the W3C standards process, like many others, includes periods of time when only the privileged few are allowed to be involved. Take it a step further - how many internationally recognized standards processes will allow a single individual to propose, develop and deliver a standard? The JCP will... geir -- Geir Magnusson Jr 203-956-2604(w) Adeptra, Inc. 203-434-2093(m) [EMAIL PROTECTED] 203-247-1713(m) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: too many similar projects?
On Tuesday, March 11, 2003, at 11:40 PM, Andrew C. Oliver wrote: Yeah, on second thought, its a great idea to remove choice in a project and instead submit it to a JSR committee and hence Suns conrol, Andy, you have pretty much the same power over a JSR as Scott McNeely does. The ASF has a vote on the EC, and Sun has a vote on the EC. Why do you think Sun has more control? take a few folks and put them on NDA so that they can't talk about certain decisions which will affect the project. Or make the rules for your JSR to be open. it's up to the spec lead. geir I'm not against all standards...just NDA-based vendor baby kissing. -Andy Craig R. McClanahan wrote: On Tue, 11 Mar 2003, Andrew C. Oliver wrote: Date: Tue, 11 Mar 2003 22:09:14 -0500 From: Andrew C. Oliver [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Subject: Re: Jakarta: too many similar projects? Thanks Pier. Thats a great perpective. Lets have some more. Anyone have a remarkably positive Gee the JCP listens to everyone and I can disclose everything to my fellow committers and its been great for our community? Andy seems to believe that *implementing* a specification (as opposed to creating one) is not a valid itch to be scratched if he doesn't like the mechanism by which the specification is created. It's perfectly reasonable for Andy to decide that for the projects he gets personally involved in, but it seems awfully arrogant to argue that no one at Apache should involve themselves in such an implementation project on that basis. As it turns out, there is substantial room for innovation and debate in the implementation of API specs like servlet and JSP (see the history of Tomcat development, and the recent innovation going on there for an example), just like there is lots of room to be creative in implementing something like HTTP, which has been done, and continues to be done, in a very large number of implementations in a very large number of languages -- despite the fact that the W3C standards process, like many others, includes periods of time when only the privileged few are allowed to be involved. -Andy Craig McClanahan - 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] -- Geir Magnusson Jr 203-956-2604(w) Adeptra, Inc. 203-434-2093(m) [EMAIL PROTECTED] 203-247-1713(m) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JCP NDA (was: too many similar projects?)
On Wednesday, March 12, 2003, at 01:32 AM, Rich Persaud wrote: I wrote: | Is the NDA under NDA? Or can someone post a copy? Ok, there's no separate NDA, it's part of the standard agreements: http://jcp.org/en/participation/membership Follow-up questions: 1. Is there an Apache-specific, public archive of JCP discussion, including the negotiation of JCP 2.5? This seems to exclude [EMAIL PROTECTED] . Is there a [EMAIL PROTECTED] ? If not, one could be culled from the archives of other lists. I keep offering to setup [EMAIL PROTECTED], but there never is much interest. Sam? Can you setup that list please? Make me the moderator and we'll see what happens 2. Is there an Apache-specific, public archive of the discussion that preceded the decision to make [EMAIL PROTECTED] non-public ? No - because the ASF, as a member of the EC, has signed the agreements that require us to keep the information about our JCP work non-public. Thus, we can't open that list. I, as the current EC representative, submit things to that list which are confidential to the EC, and we have discussions on that list which are private to the ASF. Nothing sinister going on there, but we are just respecting the rules to which we have agreed. And despite the closed aspects of the JCP, I think it's vital that the ASF remain a participant. Apaches has a record for positive change on the JCP, and will continue to push for change in line with our values and philosophy, something we can only do while participating. geir Pier wrote: | Most of the times, in my experience, it all comes down to how receptive | the spec lead is in regards to new ideas coming from outside, and how much | weight he has in his company (the JSR sponsoring company)... | | But my experience is too little to say what happens more often. Are there any metrics on the performance of spec leads, besides: http://jcp.org/aboutJava/communityprocess/withdrawn.html http://jcp.org/aboutJava/communityprocess/rejected.html Apache has tools that provide quantitative feedback on the development process. Can any of these be adapted to provide quantitative feedback on the post-public spec development process, using historical (public) data? Spec leads need to be JCP members and there's a $5K threshold for commercial companies. That's a large gap between Tier $0 (Apache and fully open) and Tier $5K (JCP and open/closed per above cited agreements). Is there a subset of Apache members who represent smaller commercial companies, who won't/can't incur the JCP overhead, but who wish to give their customers the benefits of inter-vendor portability and test compliance? Rich - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-956-2604(w) Adeptra, Inc. 203-434-2093(m) [EMAIL PROTECTED] 203-247-1713(m) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incubator DOA (Re: [STATUS] Tapestry [LACK-OF] Progress)
I'd add to the list the Pluto and Charon proposals. I haven't seen any reaction from the incubator to these? I know there was some discussions and issues/hurdles raised by Andy but some sort of acknowledgment would be polite. Note that as a member of the Jakarta PMC I'm -1 on the Pluto project until such time as the issues are resolved. I think there was some consensus on that. It seemed to me that this isn't an incubator issue so much as the Pluto folks hoped this would be a rubber stamp process and didn't like it when they found out they had to change and hence took their cookies and went home. The was some discussion from David Taylor that perhaps Pluto should just be part of Jetspeed after all, but then came one of those mysterious silences. In any case. I do not regard this as fault of the incubator. -Andy Conor - 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]
