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 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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
