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]
