On Mon, 29 Sep 2003, Serge Huber wrote: | | I'll second that, thanks David and Scott for taking the time to answer our | frustrations over and over :) I've been lurking a bit since I'm very busy | at work with an upcoming product release, but I see the same question | coming over and over about when will Pluto finally be delivered and I'm | still surprised nobody has landed a replacement by now :) If somebody did | maybe it would change the view of the people in the PMC that are reluctant | to open source it ?
I don't believe it's the PMC that's having problems open sourcing it. If PMC is the problem, then I would instead think that some people in PMC would rather like to decline the offer.. Read on..: | | But before I go down that road again, I must say if the code for Pluto was | also entirely developed by IBM that in a way we should be thankful that | they are willing to contribute it for free ! After all this code didn't | write itself, and just like we are thankful to all the contributors to the | Apache Foundation I think we will have to thank IBM for their contributions | as soon as they finally land it :) There are several arguments against accepting stash from "here we contribute it for free, you should be thankful"-organizations. Apache (Jakarta) was apparently very sad that they ever accepted the Tomcat code (RI for Servlets) from Sun. It wasn't of good quality. Apache is very wary of accepting any project - it should have a community and blah blah and whatnot. Why should it suddenly become so extremely thankful for -IBM- "donating" some piece of software?! One -could- imagine that they were just "going for the feather", instead of sincerly aiming for a true open source development process and community. People at Apache apparently feel that open source code should be developed in an open source fashion. The opposite was once called something like "blackboxware", and is described in this post: http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html This link is actually found from the PlutoProposal wiki page: http://nagoya.apache.org/wiki/apachewiki.cgi?PlutoProposal .. more specifically, the "Talk Page" : http://nagoya.apache.org/wiki/apachewiki.cgi?TalkPlutoProposal | | As for the PMC members and the process, I understand a small group of | volunteers must be able to decide for the masses on some issues. But I'm | sure that corporate issues can get in the way of the committee but hey | that's just how the world is :) But this s... is really dragging along. There are just too much corporate legacy stuff here. That you can clearly observe from the spec (JSR 168) too; it is clearly something like the least common denominator of all the portal implementations that the vendors that developed this specification had when they entered it, and is tailored so that everyone of them easily can implement it - logically enough. Then, all the vendors inside that club have delayed and halted the specification for a REALLY long time, so that -they- could be "compliant" to the still-not-released specification -before- the spec is out (check out e.g. Sun and IBM's "beta" portal products: HOW COME they already are "JSR 168 compliant", one might start to wonder).. This -could- be the reason why Pluto is being halted too, you know. Then the spec could be out and everything fine, and the commercial entities would get a first stake at the market. If pluto gets out now (or earlier), I and several others would try to make our portal products compliant as fast as possible, using the OS Pluto code. This would be bad for business for IBM and the others that have spent so much time (and hence money) on this specification, and on their already developed implementations. Just speculations.. ranting away.. Still looking forward to the RI! Endre. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
