You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@poi.apache.org by "Andrew C. Oliver" <ac...@apache.org> on 2003/03/04 23:58:34 UTC
Jakarta-POI 1.10.0-dev released
While I was on my Western US tour, Glen cut the next "dev" release of
POI. You may find it here:
http://jakarta.apache.org/builds/jakarta-poi/dev/src/ and
http://jakarta.apache.org/builds/jakarta-poi/dev/bin/
Why we skipped a release number, only Glen would know. :-)
We do not yet follow whatever conventions we're supposed to be following
for mirroring because no one has described it intelligibly on any public
list to which Glen is subscribed.
Enjoy.
-Andy
Re: Jakarta: too many similar projects?
Posted by "Andrew C. Oliver" <ac...@apache.org>.
Its Sun's JSR, let them impelment it. Why does Apache have to play lap
dog to Sun? Who wants to spend their free time working on what are
usually lousy specifications that they have no input into? JSRs usually
come with community problems such as Non-Disclosure agreements which put
some members of any project created around one at a siginificant
disadvantage. Secondly, if some members go off to the specification
committee to make all of the decisions and the others are left just to
do what they say, how is that consensus based decision making? Overall,
it seems that JSRs make BAD apache projects.
Secondly, Jakarta/Apache isn't about providing one-size-fits-all
solutions. Its about supporting community based development. Meaning
projects that wish to develop via community-based development do not
belong here. However projects that DO wish to develop through
community-based development might belong here. This is regardless of
whether there is a similar project. Turbine/Velocity and friends is a
totally different approach than Struts/JSP (in part because JSP
completely and totatlly sucks, even struts is trying to support other
presentation layers). Tapestry is totally different then either of
those. I could see some situations where I might use Tapestry. I can
see other situations where it would totally suck. Hell I can even find
some situations where I might use Struts/JSP (though I'd be more
inclined if the XML stuff were incorporated and not forked off in
another project). Choice is good. Its also irrelevant to the issue
(community-based meritocratic development)
From a user perspective coming from commercial software, I can see
where this would be confusing. Why would a company put out products
that compete with each other? Well we're not limited by such thinking.
Live Well,
Andy
Howard M. Lewis Ship wrote:
>I don't know any of this stuff about Apache refusing a JSR.
>
>As I'm seeing it from my end, Jakarta looks to centralize good technologies,
>but only if a good community of developers and users are part of the deal.
>I suspect that this "rejecting a JSR" may come down to something like Sun
>trying to dump half-working code in Jakarta's lap and expecting folks to
>rise up and make it work.
>
>In terms of web apps and MVC ... well, everyone has their own approach and
>own definition of MVC, or pull-MVC, or whatever. I do some of my work in
>Struts (at my day job), but obviously, love Tapestry. Anyway, saying
>something is a "web app framework" doesn't really say too much, especially
>under the shadow of the Servlet API. You could just as easily clump Java,
>Objective-C and C++ as "C-like languages" and complain that people should
>chose one and back it. Aint gonna happen
>
>
>--
>Howard M. Lewis Ship
>Creator, Tapestry: Java Web Components
>http://jakarta.apache.org/proposals/tapestry
>
>
>
>
>
>>-----Original Message-----
>>From: Paulo Eduardo Azevedo Silveira [mailto:paulo@paulo.com.br]
>>Sent: Tuesday, March 04, 2003 11:07 PM
>>To: Jakarta General List
>>Subject: Jakarta: too many similar projects?
>>
>>
>>Ok, maybe this is the right place and time.
>>
>>I ve seen Howard talking about Tapestry, then I decided to
>>take a better look at it. At the first look, it seems as a
>>small front controller and a template engine. What I cant
>>understand is why does Jakarta keep getting new M or
>>V or C subprojects that almost compete with each other,
>>instead concentrating forces in a single one.
>>
>>In JCP I ve seen Apache refusing a JSR (JSF if I am not
>>wrong) because it would go directly "against" Struts. But
>>Jakarta is doing this to itself!
>>
>>I can understand having OJB even with Torque, its very
>>different and it will be JDO. What I dont get is Tapestry
>>AND Velocity AND EL AND Struts taglib AND maybe something
>>that I dont know.
>>
>>Sorry if I didnt get what is the real Jakarta proposal. And
>>Howard, I am really not complaining about Tapestry, it
>>is just one example (I reallylike the idea of removing all
>>links and URLs from templates). I really dont want a
>>flame.
>>
>>thanks
>>
>>Paulo
>>
>>
>>
>>
>>
>>On Tue, 4 Mar 2003 18:41:56 -0500, "Howard M. Lewis Ship"
>><hl...@attbi.com> escreveu :
>>
>>
>>
>>>De: "Howard M. Lewis Ship" <hl...@attbi.com>
>>>Data: Tue, 4 Mar 2003 18:41:56 -0500
>>>Para: "'Jakarta General List'" <ge...@jakarta.apache.org>
>>>Assunto: RE: Jakarta-POI 1.10.0-dev released
>>>
>>>I'm looking for a bit of advice.
>>>
>>>People keep asking me "how many people are using Tapestry"
>>>
>>>
>>... and I
>>
>>
>>>honestly have no idea. Insufficient feedback.
>>>
>>>Do you have a way of determining the user base of POI? Any
>>>
>>>
>>guidelines
>>
>>
>>>based on downloads?
>>>
>>>--
>>>Howard M. Lewis Ship
>>>Creator, Tapestry: Java Web Components
>>>http://jakarta.apache.org/proposals/tapestry
>>>
>>>
>>>
>>>
>>>
>>>
>>---------------------------------------------------------------------
>>
>>
>>>To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: general-help@jakarta.apache.org
>>>
>>>
>>>
>>>
>>>
>>>
>>----------------------------------
>>Paulo Silveira ICQ 5142673
>>Grupo de Usuários Java
>>http://www.guj.com.br/
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: general-help@jakarta.apache.org
>>
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: general-help@jakarta.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta: too many similar projects?
Posted by Santiago Gala <sg...@hisitech.com>.
Andrew C. Oliver wrote:
>
>
> What if later we want to do a .NET portlet or a (whatever comes along
> that is against Sun's interest) portlet spec?
>
I think Sun's NDA is not that bad (but I don't want to re-read it to
check). Once the JSR gets public, there is no provision against free use
of what they call "Residual knowledge" polluting your brain. I can't
remember what happens if you depart in the middle of the process. Or
about extra time (6 months? 1 year? I really don't remember).
You just grant a non-exclusive, transferrable license, to your
knowledge, and you agree ND in aspects related to the JSR.
For me, the crucial issue WRT the JCP process is enforcing "release
early, release often" at regular steps, with all the caveats that might
apply.
Also, having a intermediate figure of "free experts", which could answer
in public questions, clarify or ask the community about controversial
issues, without NDA. People in Apache would excel in this "hub" role.
I think this is in the best interest of Apache, Sun, and possibly other
participants in the community process.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta: too many similar projects?
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Wednesday, March 12, 2003, at 08:42 AM, Andrew C. Oliver wrote:
>>
>> 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.
>
>
> What if later we want to do a .NET portlet or a (whatever comes along
> that is against Sun's interest) portlet spec?
Then do a .NET portlet. Have a great time....
>>
>> 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....
>
> So why does he need a JSR?
I dunno - can't speak for Jason. I suspect it was because he felt his
model was a good one to standardize around. But you have to ask him...
geir
> -Andy
>
>>
>> geir
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
--
Geir Magnusson Jr 203-956-2604(w)
Adeptra, Inc. 203-434-2093(m)
geirm@adeptra.com 203-247-1713(m)
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta: too many similar projects?
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Thursday, March 13, 2003, at 08:52 AM, Andrew C. Oliver wrote:
>>
>>
>>>>
>>> And I don't have the privilege of speaking with Sun's lawyers?
>>
>>
>> Just don't return their calls.
>>
> And when I'm fined and held for contempt of court will you be there
> with me?
I had to go back and look at what I had responded to. Here's what I
found :
-----
> Paulo Silveira wrote:
>
>>> What if later we want to do a .NET portlet or a (whatever comes
>>> along that is against Sun's interest) portlet spec?
>>
>> Call it portal.net and change the method names to begin with a capital
>> letter.
>> done.
>>
> And I don't have the privilege of speaking with Sun's lawyers?
Just don't return their calls.
----
I was being flip, I guess. I want to make something clear - I don't
advocate violating anyone's copyright or intellectual property claims,
nor do I think you do.
geir
--
Geir Magnusson Jr 203-956-2604(w)
Adeptra, Inc. 203-434-2093(m)
geirm@adeptra.com 203-247-1713(m)
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta: too many similar projects?
Posted by "Andrew C. Oliver" <ac...@apache.org>.
>
>
>>>
>> And I don't have the privilege of speaking with Sun's lawyers?
>
>
> Just don't return their calls.
>
And when I'm fined and held for contempt of court will you be there with me?
-Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta: too many similar projects?
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Wednesday, March 12, 2003, at 05:18 PM, Andrew C. Oliver wrote:
> Paulo Silveira wrote:
>
>>> What if later we want to do a .NET portlet or a (whatever comes
>>> along that is against Sun's interest) portlet spec?
>>
>> Call it portal.net and change the method names to begin with a capital
>> letter.
>> done.
>>
> And I don't have the privilege of speaking with Sun's lawyers?
Just don't return their calls.
>
>> -- Paulo
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: general-help@jakarta.apache.org
>>
>>
>>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
--
Geir Magnusson Jr 203-956-2604(w)
Adeptra, Inc. 203-434-2093(m)
geirm@adeptra.com 203-247-1713(m)
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta: too many similar projects?
Posted by "Andrew C. Oliver" <ac...@apache.org>.
Paulo Silveira wrote:
>>What if later we want to do a .NET portlet or a (whatever comes along
>>that is against Sun's interest) portlet spec?
>>
>>
>
>Call it portal.net and change the method names to begin with a capital
>letter.
>done.
>
>
And I don't have the privilege of speaking with Sun's lawyers?
>-- Paulo
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: general-help@jakarta.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
RE: Jakarta: too many similar projects?
Posted by Paulo Silveira <pa...@paulo.com.br>.
>
> What if later we want to do a .NET portlet or a (whatever comes along
> that is against Sun's interest) portlet spec?
Call it portal.net and change the method names to begin with a capital
letter.
done.
-- Paulo
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
RE: Jakarta: too many similar projects?
Posted by "Howard M. Lewis Ship" <hl...@attbi.com>.
> >
> > 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....
JDom is an odd choice to support your side of the argument. JDom going the
JSR route has killed forward
progress on it for at nearly a year. It could have been a year of furious
effort on their parts during which great advances were made, or they could
have simply s/org.jdom/javax.xml.jdom/g and wasted the rest in burachracy
... I would guess they are NDA'd too much to say.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta: too many similar projects?
Posted by "Andrew C. Oliver" <ac...@apache.org>.
>
> 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.
What if later we want to do a .NET portlet or a (whatever comes along
that is against Sun's interest) portlet spec?
>
> 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....
So why does he need a JSR?
-Andy
>
> geir
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta: too many similar projects?
Posted by "Andrew C. Oliver" <ac...@apache.org>.
>
>
>>
>>
>> d) Convince everyone that they don't need the silly JCP or JSRs and
>> just set the standards and be real damn clear that we mean to set the
>> de-facto standard while laughing at Ra. OpenSource is the standard.
>
>
> Go for it.
I am...
-Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta: too many similar projects?
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Wednesday, March 12, 2003, at 09:02 AM, Andrew C. Oliver wrote:
>>
>> Either a community
>>
>> a) doesn't want to, in which case it doesn't matter how the Evil
>> Tyrannical Sun That Controls All behaves or
>> b) it does, but only as a participant on the EG (from which info can
>> be shared, I suppose - certainly something that can be negotiated
>> with the leads on the JSR), or
>> c) it does the JSR itself.
>>
>> I can't think of any other options.
>
>
> d) Convince everyone that they don't need the silly JCP or JSRs and
> just set the standards and be real damn clear that we mean to set the
> de-facto standard while laughing at Ra. OpenSource is the standard.
Go for it.
>
> -Andy
>
>>
>> Thanks for the informative history, BTW.
>>
>> geir
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
--
Geir Magnusson Jr 203-956-2604(w)
Adeptra, Inc. 203-434-2093(m)
geirm@adeptra.com 203-247-1713(m)
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta: too many similar projects?
Posted by "Andrew C. Oliver" <ac...@apache.org>.
>
> Either a community
>
> a) doesn't want to, in which case it doesn't matter how the Evil
> Tyrannical Sun That Controls All behaves or
> b) it does, but only as a participant on the EG (from which info can
> be shared, I suppose - certainly something that can be negotiated
> with the leads on the JSR), or
> c) it does the JSR itself.
>
> I can't think of any other options.
d) Convince everyone that they don't need the silly JCP or JSRs and just
set the standards and be real damn clear that we mean to set the
de-facto standard while laughing at Ra. OpenSource is the standard.
-Andy
>
> Thanks for the informative history, BTW.
>
> geir
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta: too many similar projects?
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Wednesday, March 12, 2003, at 03:05 AM, Santiago Gala wrote:
> Previously:
> Andrew C. Oliver wrote:
> > Lets talk about what a great thing the portlet specification
> committee >has done for the Jetspeed project.
> >
> Geir Magnusson Jr. wrote:
> > 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.)
>
> 1 out of 200 is misleading. I think you mean that Andrew had just 1
> example out of 200 JSR.
Yes - IOW, there are lots of JSR, and even if Andy has legitimate
complaints about how the Jetspeed JSR is happening, I can't see how it
thus applies to the whole thing.
> A more adequate comparison would be the other way round:
> . How many Apache projects are turned into JSR from the outside, not
> by the developers? I mean from people *not* in the team.
> (jserv/tomcat, the logging stuff, jetspeed) I bet that's it, please
> correct me. From the previous Pier email, it looks that we are close
> to 1.5 out of 3 than to 1 out of 200 (Just twisting as I see fit,
> following the previous example ;-)
The logging stuff was a real problem, and there is a *great* example of
what still needs to change in the JCP. I detest the idea of logging in
the standard JDK, and even worse, that it's not log4j.
>
> BTW, it looks like an excelent metrics for innovation in Open Source
> that the industry wants to standardize on OS projects.
>
Definitely.
> And later
> Geir Magnusson Jr. wrote:
> (...)
>> 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.
> It depends on your semantics for "recently". A historical account:
>
> People from IBM Germany approached the team (Raphael Luta, myself) in
> autumn 2000 (In the ApacheCON Europe) with a proposal. They were
> working in what became Websphere Portal Server and it looks like they
> would base it (partially, I'm sure) on the Jetspeed work. Kevin
> Burton, the original leader, misteriously disappeared from the project
> by then. This is how I became the speaker in this ApacheCON.
>
> A proposal was sent by the team to the list, and got heavily discussed
> (IRC, mail list, CVS repository). This
> (http://www.mail-archive.com/jetspeed@list.working-dogs.com/
> msg05121.html) excellent summary by Raphael Luta, who took most of the
> formalization effort gives an idea of the situation by Feb 2001. This
> (http://www.mail-archive.com/jetspeed@list.working-dogs.com/
> msg05089.html) post by Ingo Schuster (IBM voice in the list) gives
> idea to the level of discussion.
>
> After this, two things happened:
> * For the developers the priority was to stabilize the code base and
> have a release, *before* jumping to a heavy refactoring.
> * The IBM team (Ingo was the most visible part) disappeared completely
> from the public list.
>
> I have not been able to find anything in Google from those times, it
> seems they don't index "mbox.gz" archives (Please, Ovidiu, make them
> do it), so historicians will have to resort to
> http://jakarta.apache.org/mail/jetspeed-dev/ the .gz monthly archives
> :-)
>
> Everybody having more than enough work to do, and nobody really
> pushing the proposal (DOocrazy) it languished.
>
> In Dec 2001, a proposal was presented JSR 162 (Portlet API, Stefan
> Hepper, IBM http://www.jcp.org/en/jsr/detail?id=162). 6 days later JSR
> 167 (Java(TM) Portlet Specification, Alejandro Abdelnur, Sun
> Microsystems s/162/167/ in URL above) was presented. 20 Jan 2002 both
> were withdrawn, and 168 (with both leads s/167/168/ if you folloed the
> previous regexp).
>
Crystal clear :)
> So, the industry jumped in. From then on, only David, Alejandro,
> Stefan, people in BEA, HP, etc. can tell what is going on. The
> proposal is not even in the "Community Review" stage one year later,
> as far as http://www.jcp.org/en/jsr/detail?id=168 says. In fact, it
> does not appear in the "List JCP by stage" page, which means it is
> still in "fuzzyland".
>
Right. So what can you do? I'm assuming that the JetSpeed community
didn't stop what they were doing, and second, IIRC, no one from the ASF
stepped up to be spec lead. IOW, if we give a hoot about these JSRs,
which we should, why don't *we* do it?
Either a community
a) doesn't want to, in which case it doesn't matter how the Evil
Tyrannical Sun That Controls All behaves or
b) it does, but only as a participant on the EG (from which info can be
shared, I suppose - certainly something that can be negotiated with the
leads on the JSR), or
c) it does the JSR itself.
I can't think of any other options.
Thanks for the informative history, BTW.
geir
--
Geir Magnusson Jr 203-956-2604(w)
Adeptra, Inc. 203-434-2093(m)
geirm@adeptra.com 203-247-1713(m)
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta: too many similar projects?
Posted by Santiago Gala <sg...@hisitech.com>.
Previously:
Andrew C. Oliver wrote:
> Lets talk about what a great thing the portlet specification
committee >has done for the Jetspeed project.
>
Geir Magnusson Jr. wrote:
> 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.)
1 out of 200 is misleading. I think you mean that Andrew had just 1
example out of 200 JSR. A more adequate comparison would be the other
way round:
. How many Apache projects are turned into JSR from the outside, not by
the developers? I mean from people *not* in the team. (jserv/tomcat, the
logging stuff, jetspeed) I bet that's it, please correct me. From the
previous Pier email, it looks that we are close to 1.5 out of 3 than to
1 out of 200 (Just twisting as I see fit, following the previous example ;-)
BTW, it looks like an excelent metrics for innovation in Open Source
that the industry wants to standardize on OS projects.
And later
Geir Magnusson Jr. wrote:
(...)
> 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.
>
It depends on your semantics for "recently". A historical account:
People from IBM Germany approached the team (Raphael Luta, myself) in
autumn 2000 (In the ApacheCON Europe) with a proposal. They were working
in what became Websphere Portal Server and it looks like they would
base it (partially, I'm sure) on the Jetspeed work. Kevin Burton, the
original leader, misteriously disappeared from the project by then. This
is how I became the speaker in this ApacheCON.
A proposal was sent by the team to the list, and got heavily discussed
(IRC, mail list, CVS repository). This
(http://www.mail-archive.com/jetspeed@list.working-dogs.com/msg05121.html)
excellent summary by Raphael Luta, who took most of the formalization
effort gives an idea of the situation by Feb 2001. This
(http://www.mail-archive.com/jetspeed@list.working-dogs.com/msg05089.html)
post by Ingo Schuster (IBM voice in the list) gives idea to the level of
discussion.
After this, two things happened:
* For the developers the priority was to stabilize the code base and
have a release, *before* jumping to a heavy refactoring.
* The IBM team (Ingo was the most visible part) disappeared completely
from the public list.
I have not been able to find anything in Google from those times, it
seems they don't index "mbox.gz" archives (Please, Ovidiu, make them do
it), so historicians will have to resort to
http://jakarta.apache.org/mail/jetspeed-dev/ the .gz monthly archives :-)
Everybody having more than enough work to do, and nobody really pushing
the proposal (DOocrazy) it languished.
In Dec 2001, a proposal was presented JSR 162 (Portlet API, Stefan
Hepper, IBM http://www.jcp.org/en/jsr/detail?id=162). 6 days later JSR
167 (Java(TM) Portlet Specification, Alejandro Abdelnur, Sun
Microsystems s/162/167/ in URL above) was presented. 20 Jan 2002 both
were withdrawn, and 168 (with both leads s/167/168/ if you folloed the
previous regexp).
So, the industry jumped in. From then on, only David, Alejandro, Stefan,
people in BEA, HP, etc. can tell what is going on. The proposal is not
even in the "Community Review" stage one year later, as far as
http://www.jcp.org/en/jsr/detail?id=168 says. In fact, it does not
appear in the "List JCP by stage" page, which means it is still in
"fuzzyland".
My recent community weather reports
(http://blogs.cocoondev.org/stevenn/archives/000760.html) suggest that
it is about to go into Community Review, or at least that there is
movement inside. I could ellaborate on my prognosis techniques on
demand. general@jakarta busts of traffic seem good for predicting
political stress. :-)
No conclusions expected,
Santiago
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta: too many similar projects?
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
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)
geirm@adeptra.com 203-247-1713(m)
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta: too many similar projects?
Posted by Costin Manolache <cm...@yahoo.com>.
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: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta: too many similar projects?
Posted by Costin Manolache <cm...@yahoo.com>.
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 <ac...@apache.org>
>>>Reply-To: Jakarta General List <ge...@jakarta.apache.org>
>>>To: Jakarta General List <ge...@jakarta.apache.org>
>>>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: general-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: general-help@jakarta.apache.org
>>
>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta: too many similar projects?
Posted by Santiago Gala <sg...@hisitech.com>.
Peter Donald wrote:
> On Mon, 17 Mar 2003 07:20, Hans Bergsten wrote:
>
>>The "NDA" in the JCP agreement only applies to "confidential
>>information". After a public draft has been published, the info it
>>contains is no longer confidential.
>
>
> Not necessarily. There are plenty of information that may not make it into the
> public draft but may still be relevant. In particular implications of certain
> design decisions. Even when a draft becomes public you may be restricted from
> discussing points and implications of decisions.
>
I have been thinking about a "strategy pattern" which could have helped
in some cases.
Let us imagine that we fear that some decision will harm the forthcoming
spec. If we are inside, we know about it from discussions. If we are
not, we could just fear out of intuition, people speaking, "weather
reports", etc.
One possible strategy is:
* make a (good) open proposal which would neutralize/counteract this
decision in the public list, and have it accepted by the community. I
mean, outside of the EG or JSR process.
If your idea is good enough, it will catch and then:
* either the EG will be forced to accept it while the process is going
* or they will have to go out of their caves for a "public battle"
* or they will have to face disappointed users during the public draft
phase, as the idea would already be accepted, even on their way to be
implemented.
If we loose the open battle, maybe the proposal or the concern was not
that pertinent, after all. If you manage to shape the minds in the
community, the closed group will have a hard time reshaping them. After
all, a standard is like an ontology, its main value is that it forces us
to think in a given way towards a given kind of problems.
I think this *is* the way to go while a standard is not yet set. If we
are speaking about a revision of a spec, it can be much more difficult
to handle the situation in this way, as people minds are already
"framed" by the spec.
The key point is that the NDA binds you not to disclose other people's
intellectual property, but not yours. While it would be a lot of work to
try this approach, a healthy community would pick up a good proposal and
amplify it quickly.
P.S) I'm turning back to the original subject, as too many similar
projects, in a way, helps for this kinds of strategies to be viable in
the long term.
--
Santiago Gala
High Sierra Technology, S.L. (http://hisitech.com)
http://memojo.com?page=SantiagoGalaBlog
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta: too many similar projects?
Posted by Peter Donald <pe...@realityforge.org>.
On Mon, 17 Mar 2003 07:20, Hans Bergsten wrote:
> The "NDA" in the JCP agreement only applies to "confidential
> information". After a public draft has been published, the info it
> contains is no longer confidential.
Not necessarily. There are plenty of information that may not make it into the
public draft but may still be relevent. In particular implications of certain
design decisions. Even when a draft becomes public you may be restricted from
discussing points and implications of decisions.
--
Cheers,
Peter Donald
*-----------------------------------------------------*
* "Faced with the choice between changing one's mind, *
* and proving that there is no need to do so - almost *
* everyone gets busy on the proof." *
* - John Kenneth Galbraith *
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta: too many similar projects?
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 16/3/03 23:32 "Geir Magnusson Jr." <ge...@optonline.net> wrote:
> BTW, I *think* that you should be able to discuss the issues with any
> ASF member, if you are representing the ASF on the EG, not just other
> EG members. We all are bound by the agreements made by the ASF.
In fact I post my concerns to jcp@apache and from time to time to
members@apache as well... But I can't to tomcat-dev (I know only two
developers involved with the RI which are members: Remy and Craig, and the
latter is on that list in virtue of his employment with Sun - looking at me
Jon and Jason making fool of ourselves, of course)
Pier
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta: too many similar projects?
Posted by Santiago Gala <sg...@hisitech.com>.
Pier Fumagalli wrote:
> On 18/3/03 11:33 "Geir Magnusson Jr." <ge...@optonline.net> wrote:
>
>
>>On Sunday, March 16, 2003, at 10:02 PM, Pier Fumagalli wrote:
>>
>>
>>>On 17/3/03 1:24 "Hans Bergsten" <ha...@gefionsoftware.com> wrote:
>>>
>>>
>>>>I agree that there's been problem with the Servlet EG this time
>>>>around,
>>>>but what I'm saying is that there are avenues that we _could_ have
>>>>used to voice our concerns, but we didn't for some reason. There are a
>>>>number of mailing lists and online forums where developers interested
>>>>in the fate of the spec hangs out. We could have started discussions
>>>>there, and urged people to send feedback to Sun.
>>>
>>>This is why I feel that my work as the official representative to that
>>>EG has been a failure :-( _MY_ failure...
>>>
>>
>>Well - it's always easy to look back and see what you could have done
>>differently. Is it too late?
>
>
> Yes... Certain new features are in... Not much we can do now...
>
This is a long term run. And *you* should know that a Release always has
some bugs left. ;-)
Something we can learn for next time?
> Pier
--
Santiago Gala
High Sierra Technology, S.L. (http://hisitech.com)
http://memojo.com?page=SantiagoGalaBlog
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta: too many similar projects?
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Tuesday, March 18, 2003, at 03:08 PM, Pier Fumagalli wrote:
> On 18/3/03 11:33 "Geir Magnusson Jr." <ge...@optonline.net> wrote:
>
>>
>> On Sunday, March 16, 2003, at 10:02 PM, Pier Fumagalli wrote:
>>
>>> On 17/3/03 1:24 "Hans Bergsten" <ha...@gefionsoftware.com> wrote:
>>>
>>>> I agree that there's been problem with the Servlet EG this time
>>>> around,
>>>> but what I'm saying is that there are avenues that we _could_ have
>>>> used to voice our concerns, but we didn't for some reason. There
>>>> are a
>>>> number of mailing lists and online forums where developers
>>>> interested
>>>> in the fate of the spec hangs out. We could have started discussions
>>>> there, and urged people to send feedback to Sun.
>>>
>>> This is why I feel that my work as the official representative to
>>> that
>>> EG has been a failure :-( _MY_ failure...
>>>
>>
>> Well - it's always easy to look back and see what you could have done
>> differently. Is it too late?
>
> Yes... Certain new features are in... Not much we can do now...
Except vote against it, if that's what the ASF decides to do....
geir
>
> Pier
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
--
Geir Magnusson Jr 203-956-2604(w)
Adeptra, Inc. 203-434-2093(m)
geirm@adeptra.com 203-247-1713(m)
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta: too many similar projects?
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 18/3/03 11:33 "Geir Magnusson Jr." <ge...@optonline.net> wrote:
>
> On Sunday, March 16, 2003, at 10:02 PM, Pier Fumagalli wrote:
>
>> On 17/3/03 1:24 "Hans Bergsten" <ha...@gefionsoftware.com> wrote:
>>
>>> I agree that there's been problem with the Servlet EG this time
>>> around,
>>> but what I'm saying is that there are avenues that we _could_ have
>>> used to voice our concerns, but we didn't for some reason. There are a
>>> number of mailing lists and online forums where developers interested
>>> in the fate of the spec hangs out. We could have started discussions
>>> there, and urged people to send feedback to Sun.
>>
>> This is why I feel that my work as the official representative to that
>> EG has been a failure :-( _MY_ failure...
>>
>
> Well - it's always easy to look back and see what you could have done
> differently. Is it too late?
Yes... Certain new features are in... Not much we can do now...
Pier
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta: too many similar projects?
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Sunday, March 16, 2003, at 10:02 PM, Pier Fumagalli wrote:
> On 17/3/03 1:24 "Hans Bergsten" <ha...@gefionsoftware.com> wrote:
>
>> I agree that there's been problem with the Servlet EG this time
>> around,
>> but what I'm saying is that there are avenues that we _could_ have
>> used to voice our concerns, but we didn't for some reason. There are a
>> number of mailing lists and online forums where developers interested
>> in the fate of the spec hangs out. We could have started discussions
>> there, and urged people to send feedback to Sun.
>
> This is why I feel that my work as the official representative to that
> EG
> has been a failure :-( _MY_ failure...
>
Well - it's always easy to look back and see what you could have done
differently. Is it too late?
geir
--
Geir Magnusson Jr 203-956-2604(w)
Adeptra, Inc. 203-434-2093(m)
geirm@adeptra.com 203-247-1713(m)
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta: too many similar projects?
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 17/3/03 1:24 "Hans Bergsten" <ha...@gefionsoftware.com> wrote:
> I agree that there's been problem with the Servlet EG this time around,
> but what I'm saying is that there are avenues that we _could_ have
> used to voice our concerns, but we didn't for some reason. There are a
> number of mailing lists and online forums where developers interested
> in the fate of the spec hangs out. We could have started discussions
> there, and urged people to send feedback to Sun.
This is why I feel that my work as the official representative to that EG
has been a failure :-( _MY_ failure...
Pier
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta: too many similar projects?
Posted by Hans Bergsten <ha...@gefionsoftware.com>.
Pier Fumagalli wrote:
> On 16/3/03 20:20 "Hans Bergsten" <ha...@gefionsoftware.com> wrote:
>
>>>Geir, I _really_ am in troubles when dealing with Servlets. I cannot raise
>>>issues on the tomcat-dev mailing lists, all I can do is discuss them with
>>>Jon and Jason, as they both are on the spec...
>>
>>You can raise and discuss your concerns in public as soon as a public
>>draft of the spec is available, and there are at least two public drafts
>>before the spec is finalized; plenty of time to make sure the larger
>>community is aware of, and agrees with, what's being suggested.
>>
>>The "NDA" in the JCP agreement only applies to "confidential
>>information". After a public draft has been published, the info it
>>contains is no longer confidential.
>
>
> As you are on the EG yourself, you know how hard it is to have one word
> removed from the next revision of the spec once it gets in :-)
>
> Just thinking out loud...
I agree that there's been problem with the Servlet EG this time around,
but what I'm saying is that there are avenues that we _could_ have
used to voice our concerns, but we didn't for some reason. There are a
number of mailing lists and online forums where developers interested
in the fate of the spec hangs out. We could have started discussions
there, and urged people to send feedback to Sun.
The JCP does not demand a "closed room discussion" all the way through;
there's plenty of opportunity to raise concerns and put external
pressure on the spec lead organization before the spec is final. Also,
don't judge JCP based on a single EG. I'm in four EGs, and while there's
been problems now and then in some of them, on the whole they work
pretty good.
I would be happier if the whole discussion leading up to a spec was
more open (and the JCP allows for it), but even the way it's typically
done, it's not all that bad. And compared to other spec organizations
(W3C, ECMA, IETF, etc.), it has a pretty good track record on average
for getting out specs with industry support in a reasonable time.
There are exceptions, of course, but I'm sure that's true for all
similar efforts.
Hans
--
Hans Bergsten <ha...@gefionsoftware.com>
Gefion Software <http://www.gefionsoftware.com/>
Author of O'Reilly's "JavaServer Pages", covering JSP 1.2 and JSTL 1.0
Details at <http://TheJSPBook.com/>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta: too many similar projects?
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 16/3/03 20:20 "Hans Bergsten" <ha...@gefionsoftware.com> wrote:
>
>> Geir, I _really_ am in troubles when dealing with Servlets. I cannot raise
>> issues on the tomcat-dev mailing lists, all I can do is discuss them with
>> Jon and Jason, as they both are on the spec...
>
> You can raise and discuss your concerns in public as soon as a public
> draft of the spec is available, and there are at least two public drafts
> before the spec is finalized; plenty of time to make sure the larger
> community is aware of, and agrees with, what's being suggested.
>
> The "NDA" in the JCP agreement only applies to "confidential
> information". After a public draft has been published, the info it
> contains is no longer confidential.
As you are on the EG yourself, you know how hard it is to have one word
removed from the next revision of the spec once it gets in :-)
Just thinking out loud...
Pier
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta: too many similar projects?
Posted by Hans Bergsten <ha...@gefionsoftware.com>.
Pier Fumagalli wrote:
> On 12/3/03 6:53 "Geir Magnusson Jr." <ge...@optonline.net> wrote:
>
>
>>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...
>
>
> Yes, but why can I share with my friends concerns on the new W3C
> specifications and confront them in public, while I cannot do that with the
> JCP specifications???
>
> Geir, I _really_ am in troubles when dealing with Servlets. I cannot raise
> issues on the tomcat-dev mailing lists, all I can do is discuss them with
> Jon and Jason, as they both are on the spec...
You can raise and discuss your concerns in public as soon as a public
draft of the spec is available, and there are at least two public drafts
before the spec is finalized; plenty of time to make sure the larger
community is aware of, and agrees with, what's being suggested.
The "NDA" in the JCP agreement only applies to "confidential
information". After a public draft has been published, the info it
contains is no longer confidential.
Hans
--
Hans Bergsten <ha...@gefionsoftware.com>
Gefion Software <http://www.gefionsoftware.com/>
Author of O'Reilly's "JavaServer Pages", covering JSP 1.2 and JSTL 1.0
Details at <http://TheJSPBook.com/>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta: too many similar projects?
Posted by "Andrew C. Oliver" <ac...@apache.org>.
>
> I realize this isn't perfect. In some cases, it's not even good, the
> servlet EG sound like it belongs in the 'not good' category. I think
> we'd all like to see things changed so that there's a more open
> process for spec development, and there is a lot of interest on the
> JCP Exec Committee surrounding this issue.
>
> BTW, I *think* that you should be able to discuss the issues with any
> ASF member, if you are representing the ASF on the EG, not just other
> EG members. We all are bound by the agreements made by the ASF.
For the record.
I do not care to have ANY NDA-bound issues with those bound by NDAs.
For work where I do not recieve financial compensation, I prefer to work
in the open in a community/meritocratic/consensus basis rather than your
non-community/non-meritocratic basis such as I feel strongly is the case
with the JCP or any work which is bound by NDAs.
I will regard any communication sent to me as non-confidential unless it
is clearly stated in the subject line to be otherwise and will feel free
to disclose it.
NEVER send NDA material to me without my prior consent.
If at some point I have to choose between Apache Membership and
OpenSource. I will choose the latter.
thanks,
Andy
>
> geir
>
>>
>> Pier
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: general-help@jakarta.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta: too many similar projects?
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Sunday, March 16, 2003, at 02:53 PM, Pier Fumagalli wrote:
> On 12/3/03 6:53 "Geir Magnusson Jr." <ge...@optonline.net> wrote:
>
>>
>> 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...
>
> Yes, but why can I share with my friends concerns on the new W3C
> specifications and confront them in public, while I cannot do that
> with the
> JCP specifications???
You can do that after they are public specs, right? You can do the
same with complete JCP-produced specs.
>
> Geir, I _really_ am in troubles when dealing with Servlets. I cannot
> raise
> issues on the tomcat-dev mailing lists, all I can do is discuss them
> with
> Jon and Jason, as they both are on the spec...
I realize this isn't perfect. In some cases, it's not even good, the
servlet EG sound like it belongs in the 'not good' category. I think
we'd all like to see things changed so that there's a more open process
for spec development, and there is a lot of interest on the JCP Exec
Committee surrounding this issue.
BTW, I *think* that you should be able to discuss the issues with any
ASF member, if you are representing the ASF on the EG, not just other
EG members. We all are bound by the agreements made by the ASF.
geir
>
> Pier
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
--
Geir Magnusson Jr 203-956-2604(w)
Adeptra, Inc. 203-434-2093(m)
geirm@adeptra.com 203-247-1713(m)
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta: too many similar projects?
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 12/3/03 6:53 "Geir Magnusson Jr." <ge...@optonline.net> wrote:
>
> 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...
Yes, but why can I share with my friends concerns on the new W3C
specifications and confront them in public, while I cannot do that with the
JCP specifications???
Geir, I _really_ am in troubles when dealing with Servlets. I cannot raise
issues on the tomcat-dev mailing lists, all I can do is discuss them with
Jon and Jason, as they both are on the spec...
Pier
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta: too many similar projects?
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
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 <ac...@apache.org>
>>> Reply-To: Jakarta General List <ge...@jakarta.apache.org>
>>> To: Jakarta General List <ge...@jakarta.apache.org>
>>> 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: general-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: general-help@jakarta.apache.org
>>
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
--
Geir Magnusson Jr 203-956-2604(w)
Adeptra, Inc. 203-434-2093(m)
geirm@adeptra.com 203-247-1713(m)
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta: too many similar projects?
Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: "Andrew C. Oliver" <ac...@apache.org>
To: "Jakarta General List" <ge...@jakarta.apache.org>
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 <ac...@apache.org>
> >>Reply-To: Jakarta General List <ge...@jakarta.apache.org>
> >>To: Jakarta General List <ge...@jakarta.apache.org>
> >>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: general-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: general-help@jakarta.apache.org
> >
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta: too many similar projects?
Posted by "Andrew C. Oliver" <ac...@apache.org>.
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 <ac...@apache.org>
>>Reply-To: Jakarta General List <ge...@jakarta.apache.org>
>>To: Jakarta General List <ge...@jakarta.apache.org>
>>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: general-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: general-help@jakarta.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta: too many similar projects?
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
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)
geirm@adeptra.com 203-247-1713(m)
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta: too many similar projects?
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Tue, 11 Mar 2003, Andrew C. Oliver wrote:
> Date: Tue, 11 Mar 2003 22:09:14 -0500
> From: Andrew C. Oliver <ac...@apache.org>
> Reply-To: Jakarta General List <ge...@jakarta.apache.org>
> To: Jakarta General List <ge...@jakarta.apache.org>
> 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: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta: too many similar projects?
Posted by "Andrew C. Oliver" <ac...@apache.org>.
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" <ac...@apache.org> 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: general-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: general-help@jakarta.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta: too many similar projects?
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 11/3/03 23:40 "Andrew C. Oliver" <ac...@apache.org> 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: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta: too many similar projects?
Posted by "Andrew C. Oliver" <ac...@apache.org>.
>
> 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 jcp@apache.org 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: general-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail: general-help@jakarta.apache.org
>>>>
>>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: general-help@jakarta.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta: too many similar projects?
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
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: general-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: general-help@jakarta.apache.org
>>>
>>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
--
Geir Magnusson Jr 203-956-2604(w)
Adeptra, Inc. 203-434-2093(m)
geirm@adeptra.com 203-247-1713(m)
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta: too many similar projects?
Posted by "Andrew C. Oliver" <ac...@apache.org>.
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: general-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: general-help@jakarta.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta: too many similar projects?
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
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: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
--
Geir Magnusson Jr 203-956-2604(w)
Adeptra, Inc. 203-434-2093(m)
geirm@adeptra.com 203-247-1713(m)
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta: too many similar projects?
Posted by "Andrew C. Oliver" <ac...@apache.org>.
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: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta: too many similar projects?
Posted by Doug Bateman <do...@techie.net>.
> 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: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta: too many similar projects?
Posted by Pier Fumagalli <pi...@betaversion.org>.
"Paulo Silveira" <pa...@paulo.com.br> wrote:
> Sorry not giving a link the other time. Here is Apache voting against
> JSR 127 long time ago.
>
> http://www.jcp.org/en/jsr/results?id=614
>
> You can see Apache´s comment:
>
> "On 2001-05-28 Apache Software Foundation voted No with the following
> comment:
> This JSR conflicts with the Apache open source project Struts.
> Considering Sun's current position that JSRs may not be independently
> implemented under an open source license, we see little value in
> recreating a technology in a closed environment that is already
> available in an open environment."
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...
Pier
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta: too many similar projects?
Posted by Santiago Gala <sg...@hisitech.com>.
Danny Angus wrote:
>
>
>>>> Why create something in official Java APIs/Products when there
>>>> is allready a good OSS alternative.
>>>
>
>>> To standardise it. Why is OSS any different?
>>
>
>> Exactly! So why bother "standardizing" it via Sun. If there is a
>> ubiquitous Apache standard already, then there is NO need for a Sun
>> standard.
>
> Personally I think the danger is, as Andy pointed out, that Sun
> including a lot of functionality in the core distribution of Java JSE
> or in JEE limits the ability of third parties to develop solutions,
> in a way very similar to M$'s inclusion of extended functionality in
> the basic Windows OS installation.
>
*and* bloats Java. I have a JAXP and TRAX implementation in Sun's JRE,
that I need to override, because it does not work with most projects,
for instance. I have the whole Swing, even if I don't use it in my
tomcat VMs or with ant/maven... Those could be pluggable (as JAXP or
TRAX, or JAAS, or even parts of JDBC, used to be).
> Standards should not be taken to mean "product most widely used" or
> "the product officially supported" they are something else. IMO
> standards are, and should be, benchmarks against which people can
> compare their work and say either it does or it does not support
> standard x,y or z. Standards compliance can be a goal of any software
> project. Standards compliance as a goal of un-related projects
> results in the kind of interoperability that is fundamental to the
> character of the internet.
>
> Open Source has standards as a cornerstone because it allows loosely
> coordinated groups to produce interoperable systems simply by
> supporting common, published, contracts.
>
A wholehearted +1.
> Sun's use of JSR's to add core functionality, as far as I can see,
> goes way beyond the standardization of contracts to include
> implementations, and these implementations are often bundled with
> Java in one form or another.
>
> The result is that if you are interested in the contract you don't
> need to go elsewhere to find software implementing it, its right
> there already, and its free, so why bother?
>
> As far as I can see Apache's position in the JSR review defends the
> right of third parties to be allowed to implement contracts approved
> by JSR and adopted by Sun on an equal footing with the JSR's
> participants and cash rich commercial organisations.
>
While Apache is taking advantage of this with Tomcat and other projects,
I'm not sure it is a good thing.
and then Andrew C. Oliver wrote:
> Therefore, supporting JSRs where there are already good dominant
> Apache projects is against Apache's interest. You either get
> sidestepped like the JSP vs Velocity thing or you move the decision
> making process into Sun which is apt to happen with Jetspeed.
I don't think the Original proposal for the Portlet API is bad (I don't
know yet the outcome of the process). It was a light weight API,
modelled after the Servlet API, and offered possibilities for use.
But the whole discussion has been held behind doors. And the process has
frozen possible evolutions of the project in the wait (this is possibly
a tactical mistake on our part, coupled with one of the main developers
being forced to a very difficult position under NDA).
Also, like Danny wrote, the fact that the JSR comes with a RI coming
from the outside and "for free", brings a danger to kill possible
alternative designs.
All of this kills cyberdiversity. I imagine that it has helped a lot to
promote java as a programming platform and make it "feature complete",
but the times are coming where it is no longer a good policy.
Just Random Thoughts
Santiago
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
RE: Jakarta: too many similar projects?
Posted by Danny Angus <da...@apache.org>.
> >>Why create something in official Java APIs/Products when
> >>there is allready a good OSS alternative.
> >To standardise it. Why is OSS any different?
> Exactly! So why bother "standardizing" it via Sun. If there is a
> ubiquitous Apache standard already, then there is NO need for a Sun
> standard.
Personally I think the danger is, as Andy pointed out, that Sun including a lot of functionality in the core distribution of Java JSE or in JEE limits the ability of third parties to develop solutions, in a way very similar to M$'s inclusion of extended functionality in the basic Windows OS installation.
Standards should not be taken to mean "product most widely used" or "the product officially supported" they are something else.
IMO standards are, and should be, benchmarks against which people can compare their work and say either it does or it does not support standard x,y or z.
Standards compliance can be a goal of any software project.
Standards compliance as a goal of un-related projects results in the kind of interoperability that is fundamental to the character of the internet.
Open Source has standards as a cornerstone because it allows loosely coordinated groups to produce interoperable systems simply by supporting common, published, contracts.
Sun's use of JSR's to add core functionality, as far as I can see, goes way beyond the standardization of contracts to include implementations, and these implementations are often bundled with Java in one form or another.
The result is that if you are interested in the contract you don't need to go elsewhere to find software implementing it, its right there already, and its free, so why bother?
As far as I can see Apache's position in the JSR review defends the right of third parties to be allowed to implement contracts approved by JSR and adopted by Sun on an equal footing with the JSR's participants and cash rich commercial organisations.
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta: too many similar projects?
Posted by "Andrew C. Oliver" <ac...@apache.org>.
>
>
>
>I can understand it if the ASF were worried that a JSR would put the
>existence of the OSS project in doubt, due to the legalities of an OSS
>project not being able to be a JSR implementation in some cases, but not
>to protect their product.
>
>
Why not? What is the point of having a JSR which requires useless
changes in an OSS project just to support the JSR? Opensource standards
are DEFACTO standards. Economics works to their benefit. JSRs take the
decision making process AWAY from the community and puts it in the hands
of folks whom are willing to sign their brains away via NDAs. You
cannot have a community if members are under NDA. You also can't have a
meritocratic community if some members get to make specification
decisions and others don't based strictly on who has signed their brain
away to Sun.
Therefore, supporting JSRs where there are already good dominant Apache
projects is against Apache's interest. You either get sidestepped like
the JSP vs Velocity thing or you move the decision making process into
Sun which is apt to happen with Jetspeed.
I guess it depends on whether you think you're here to work in a
community and help yourself or if you're here to stroke Sun.
>
>
>>Why create something in official Java APIs/Products when
>>there is allready a good OSS alternative.
>>
>>
>
>To standardise it. Why is OSS any different?
>
>
Exactly! So why bother "standardizing" it via Sun. If there is a
ubiquitous Apache standard already, then there is NO need for a Sun
standard.
>Why create an official Java API when there is an already good commercial
>product?
>
>
This is irrelevant to the discussion.
>>It still a shame that Sun didn't selected log4j for 1.4.
>>
>>
>
>Because it was quite arguably the de facto standard by the point the JSR
>was announced.
>
>
And how does supporting Sun's JSR for logging help Apache? Especially
log4j?
>>Diversity is great.
>>
>>
>
>And forcing a lack of diversity merely prevents one set of possibilities
>happening. So +1 to diversity.
>
>
And JSRs limit diversity ;-) (you don't always want diversity, but note
that "standards" are a limit on diversity)
-Andy
>Hen
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: general-help@jakarta.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta: too many similar projects?
Posted by Henri Yandell <ba...@generationjava.com>.
On Fri, 7 Mar 2003, Henri Gomez wrote:
> Paulo Silveira wrote:
> > Sorry not giving a link the other time. Here is Apache voting against
> > JSR 127 long time ago.
>
> In such case we could (should) understand ASF position.
I can understand it if the ASF were worried that a JSR would put the
existence of the OSS project in doubt, due to the legalities of an OSS
project not being able to be a JSR implementation in some cases, but not
to protect their product.
> Why create something in official Java APIs/Products when
> there is allready a good OSS alternative.
To standardise it. Why is OSS any different?
Why create an official Java API when there is an already good commercial
product?
> It still a shame that Sun didn't selected log4j for 1.4.
Because it was quite arguably the de facto standard by the point the JSR
was announced.
> BTW, having multiple OSS competitors projects is a
> good stimulation and could result in a later merge
> (see TC3/TC4 => TC5).
I'm not sure two versions of one project quite shows the example, but it
is a good point.
> Diversity is great.
And forcing a lack of diversity merely prevents one set of possibilities
happening. So +1 to diversity.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta: too many similar projects?
Posted by Henri Gomez <hg...@apache.org>.
Paulo Silveira wrote:
> Sorry not giving a link the other time. Here is Apache voting against
> JSR 127 long time ago.
In such case we could (should) understand ASF position.
Why create something in official Java APIs/Products when
there is allready a good OSS alternative.
It still a shame that Sun didn't selected log4j for 1.4.
BTW, having multiple OSS competitors projects is a
good stimulation and could result in a later merge
(see TC3/TC4 => TC5).
Diversity is great.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta: too many similar projects?
Posted by Peter Royal <pr...@apache.org>.
On Wednesday, March 5, 2003, at 09:00 AM, Paulo Silveira wrote:
> "On 2001-05-28 Apache Software Foundation voted No with the following
> comment:
> This JSR conflicts with the Apache open source project Struts.
> Considering Sun's current position that JSRs may not be independently
> implemented under an open source license, we see little value in
> recreating a technology in a closed environment that is already
> available in an open environment."
Sun's position has changed since then :)
-pete
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
RE: Jakarta: too many similar projects?
Posted by Paulo Silveira <pa...@paulo.com.br>.
Sorry not giving a link the other time. Here is Apache voting against
JSR 127 long time ago.
http://www.jcp.org/en/jsr/results?id=614
You can see Apache´s comment:
"On 2001-05-28 Apache Software Foundation voted No with the following
comment:
This JSR conflicts with the Apache open source project Struts.
Considering Sun's current position that JSRs may not be independently
implemented under an open source license, we see little value in
recreating a technology in a closed environment that is already
available in an open environment."
thanks
-----Original Message-----
From: Howard M. Lewis Ship [mailto:hlship@attbi.com]
Sent: quarta-feira, 5 de março de 2003 01:37
To: 'Jakarta General List'
Subject: RE: Jakarta: too many similar projects?
I don't know any of this stuff about Apache refusing a JSR.
As I'm seeing it from my end, Jakarta looks to centralize good
technologies, but only if a good community of developers and users are
part of the deal. I suspect that this "rejecting a JSR" may come down to
something like Sun trying to dump half-working code in Jakarta's lap and
expecting folks to rise up and make it work.
In terms of web apps and MVC ... well, everyone has their own approach
and own definition of MVC, or pull-MVC, or whatever. I do some of my
work in Struts (at my day job), but obviously, love Tapestry. Anyway,
saying something is a "web app framework" doesn't really say too much,
especially under the shadow of the Servlet API. You could just as
easily clump Java, Objective-C and C++ as "C-like languages" and
complain that people should chose one and back it. Aint gonna happen
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/proposals/tapestry
> -----Original Message-----
> From: Paulo Eduardo Azevedo Silveira [mailto:paulo@paulo.com.br]
> Sent: Tuesday, March 04, 2003 11:07 PM
> To: Jakarta General List
> Subject: Jakarta: too many similar projects?
>
>
> Ok, maybe this is the right place and time.
>
> I ve seen Howard talking about Tapestry, then I decided to
> take a better look at it. At the first look, it seems as a
> small front controller and a template engine. What I cant
> understand is why does Jakarta keep getting new M or
> V or C subprojects that almost compete with each other,
> instead concentrating forces in a single one.
>
> In JCP I ve seen Apache refusing a JSR (JSF if I am not
> wrong) because it would go directly "against" Struts. But
> Jakarta is doing this to itself!
>
> I can understand having OJB even with Torque, its very
> different and it will be JDO. What I dont get is Tapestry
> AND Velocity AND EL AND Struts taglib AND maybe something
> that I dont know.
>
> Sorry if I didnt get what is the real Jakarta proposal. And
> Howard, I am really not complaining about Tapestry, it
> is just one example (I reallylike the idea of removing all
> links and URLs from templates). I really dont want a
> flame.
>
> thanks
>
> Paulo
>
>
>
>
>
> On Tue, 4 Mar 2003 18:41:56 -0500, "Howard M. Lewis Ship"
> <hl...@attbi.com> escreveu :
>
> > De: "Howard M. Lewis Ship" <hl...@attbi.com>
> > Data: Tue, 4 Mar 2003 18:41:56 -0500
> > Para: "'Jakarta General List'" <ge...@jakarta.apache.org>
> > Assunto: RE: Jakarta-POI 1.10.0-dev released
> >
> > I'm looking for a bit of advice.
> >
> > People keep asking me "how many people are using Tapestry"
> ... and I
> > honestly have no idea. Insufficient feedback.
> >
> > Do you have a way of determining the user base of POI? Any
> guidelines
> > based on downloads?
> >
> > --
> > Howard M. Lewis Ship
> > Creator, Tapestry: Java Web Components
> > http://jakarta.apache.org/proposals/tapestry
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: general-help@jakarta.apache.org
> >
> >
> >
> >
>
> ----------------------------------
> Paulo Silveira ICQ 5142673
> Grupo de Usuários Java
> http://www.guj.com.br/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
RE: Jakarta: too many similar projects?
Posted by "Howard M. Lewis Ship" <hl...@attbi.com>.
I don't know any of this stuff about Apache refusing a JSR.
As I'm seeing it from my end, Jakarta looks to centralize good technologies,
but only if a good community of developers and users are part of the deal.
I suspect that this "rejecting a JSR" may come down to something like Sun
trying to dump half-working code in Jakarta's lap and expecting folks to
rise up and make it work.
In terms of web apps and MVC ... well, everyone has their own approach and
own definition of MVC, or pull-MVC, or whatever. I do some of my work in
Struts (at my day job), but obviously, love Tapestry. Anyway, saying
something is a "web app framework" doesn't really say too much, especially
under the shadow of the Servlet API. You could just as easily clump Java,
Objective-C and C++ as "C-like languages" and complain that people should
chose one and back it. Aint gonna happen
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/proposals/tapestry
> -----Original Message-----
> From: Paulo Eduardo Azevedo Silveira [mailto:paulo@paulo.com.br]
> Sent: Tuesday, March 04, 2003 11:07 PM
> To: Jakarta General List
> Subject: Jakarta: too many similar projects?
>
>
> Ok, maybe this is the right place and time.
>
> I ve seen Howard talking about Tapestry, then I decided to
> take a better look at it. At the first look, it seems as a
> small front controller and a template engine. What I cant
> understand is why does Jakarta keep getting new M or
> V or C subprojects that almost compete with each other,
> instead concentrating forces in a single one.
>
> In JCP I ve seen Apache refusing a JSR (JSF if I am not
> wrong) because it would go directly "against" Struts. But
> Jakarta is doing this to itself!
>
> I can understand having OJB even with Torque, its very
> different and it will be JDO. What I dont get is Tapestry
> AND Velocity AND EL AND Struts taglib AND maybe something
> that I dont know.
>
> Sorry if I didnt get what is the real Jakarta proposal. And
> Howard, I am really not complaining about Tapestry, it
> is just one example (I reallylike the idea of removing all
> links and URLs from templates). I really dont want a
> flame.
>
> thanks
>
> Paulo
>
>
>
>
>
> On Tue, 4 Mar 2003 18:41:56 -0500, "Howard M. Lewis Ship"
> <hl...@attbi.com> escreveu :
>
> > De: "Howard M. Lewis Ship" <hl...@attbi.com>
> > Data: Tue, 4 Mar 2003 18:41:56 -0500
> > Para: "'Jakarta General List'" <ge...@jakarta.apache.org>
> > Assunto: RE: Jakarta-POI 1.10.0-dev released
> >
> > I'm looking for a bit of advice.
> >
> > People keep asking me "how many people are using Tapestry"
> ... and I
> > honestly have no idea. Insufficient feedback.
> >
> > Do you have a way of determining the user base of POI? Any
> guidelines
> > based on downloads?
> >
> > --
> > Howard M. Lewis Ship
> > Creator, Tapestry: Java Web Components
> > http://jakarta.apache.org/proposals/tapestry
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: general-help@jakarta.apache.org
> >
> >
> >
> >
>
> ----------------------------------
> Paulo Silveira ICQ 5142673
> Grupo de Usuários Java
> http://www.guj.com.br/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Jakarta: too many similar projects?
Posted by Paulo Eduardo Azevedo Silveira <pa...@paulo.com.br>.
Ok, maybe this is the right place and time.
I ve seen Howard talking about Tapestry, then I decided to take a better look at it. At the first look, it seems as a
small front controller and a template engine. What I cant understand is why does Jakarta keep getting new M or
V or C subprojects that almost compete with each other, instead concentrating forces in a single one.
In JCP I ve seen Apache refusing a JSR (JSF if I am not wrong) because it would go directly "against" Struts. But
Jakarta is doing this to itself!
I can understand having OJB even with Torque, its very different and it will be JDO. What I dont get is Tapestry
AND Velocity AND EL AND Struts taglib AND maybe something that I dont know.
Sorry if I didnt get what is the real Jakarta proposal. And Howard, I am really not complaining about Tapestry, it
is just one example (I reallylike the idea of removing all links and URLs from templates). I really dont want a
flame.
thanks
Paulo
On Tue, 4 Mar 2003 18:41:56 -0500, "Howard M. Lewis Ship" <hl...@attbi.com> escreveu :
> De: "Howard M. Lewis Ship" <hl...@attbi.com>
> Data: Tue, 4 Mar 2003 18:41:56 -0500
> Para: "'Jakarta General List'" <ge...@jakarta.apache.org>
> Assunto: RE: Jakarta-POI 1.10.0-dev released
>
> I'm looking for a bit of advice.
>
> People keep asking me "how many people are using Tapestry" ... and I
> honestly have no idea. Insufficient feedback.
>
> Do you have a way of determining the user base of POI? Any guidelines based
> on downloads?
>
> --
> Howard M. Lewis Ship
> Creator, Tapestry: Java Web Components
> http://jakarta.apache.org/proposals/tapestry
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
>
>
----------------------------------
Paulo Silveira ICQ 5142673
Grupo de Usuários Java
http://www.guj.com.br/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
RANT: Licensing, Business models and success metrics (was Re: answer
to Howard or State of the POI )
Posted by Santiago Gala <sg...@hisitech.com>.
Andrew C. Oliver wrote:
> This is going to be another one of my long answers to a short question...
>
Good! (I crosspost to community. I think it really belongs there ;-)
Some context:
Howard M. Lewis Ship asked about Tapestry/POI usage:
> People keep asking me "how many people are using Tapestry"
>> ... and I honestly have no idea. Insufficient feedback.
>>
>> Do you have a way of determining the user base of POI? Any
>> guidelines based on downloads?
>>
>>
Andy answers:
> I don't really attempt to measure this. It would be trivial to measure
> the number of downloads from the access logs; however, I prefer to
> mesure it subjectively.
> Note that its documented on the Jakarta site that Opensource is not
> about units shipped. I'd look up the page but I'm sure that if I don't
> someone will do it for me so why bother.
>
Specifically in server side applications. For instance, as Andy hints in
my next quote, a single download from a intranet server in a big
corporation can lead to tens of thousands of (unsuspecting) users.
(...big snip, not that I don't like it, but please read it in the archives)
> First, POI attacts mail from some of the largest banks in the word,
> financial institutions, governments, millitary institutions, nuclear
> power plants, etc. There is even a large Apache backer flirting with
> the idea of using it (while its irrelevant to me whether they do or not,
> it is relevant that they are considering it).
>
> Next, I measure the success of it by two other things: Microsoft's
> flirting with open file formats (I'm sure it will be "open" in that
> Microsoft sort of way) and the final crux will be the day this
> http://www.tidestone.com/index.jsp goes out of business. The first clue
> to eventual success is that Tidestone has re-emerged as a seperate
> business entity instead of just a redirect to a page on Actuate's site.
> The second is that they have lowered the price from 15k per processor to
> 5,000k per server (I'm sure there is a big astericks)
> http://www.tidestone.com/pricing/index.jsp. This is after an extensive
> advertising campaign including full page adds in Dr. Dobbs. This is
> despite some functionality that we do not yet have.
>
I don't agree that it is a good metrics, since it's a crisis situation
and a lot of other factors could be involved into pricing (product life
cycle, etc.). Also, we are not trying to make anybody unhappy, that
would be (at most) a side effect of our approach being successful. But
the post goes on:
> My final measure is how much money I'm making and how many other POI
> developers I'm able to cut in on it. Thus far (this year) I'm able to
> derive 35% of my income from opensource efforts (a percentage which is
> up about 800% from last year). I suppose all of those are directly or
> indirectly related to POI. I'll undoubtably be flamed for this unique
> viewpoint, but its a measure which I find important. I've managed to
> pass on some of this work to two other POI committers thus far. (no one
> bother writing me offering to do this work, I only pass this work on to
> contributers to the project)
>
> So to me how many people are using POI and not contributing to the
> project in any way is totally irrelevant. I measure it in actual
> benefit to myself and the other contributers. To me any other mesure is
> trivial.
>
This is the point I think merits further exposure/discussion. I'm not
going to flame Andy on this, since I fully agree with it. If we cannot
extract actual benefits from our involvement in Apache projects, the
projects will not work/scale well.
Each and everyone involved in Apache projects should benefit in terms of:
* better career opportunities
* being better known in the industry
* having better tools in our daily work toolset
* higher productivity in integration
* knowing where technology is moving
* __fill more here__
The Apache licensing model is oriented towards consultancy/system
integration rather than product sales. This is in opposition to other
licensing schemes like GNU:
* If you hold the copyright of a GNU licensed stuff, you can re-license
it as closed source (a lot of GNU-licensed projects are doing this, see
Aladdin or Transvirtual with ghostscript and kaffe)
* If you hold the copyright of an Apache, BSD or Artistic licensed
stuff, it is far more difficult to do this, because everybody is free to
do the same.
This introduces an asymmetry I don't like WRT GNU licensed projects: the
person transferring copyright looses rights WRT the person holding it. I
don't critizise this approach with the FSF proper, but I don't like, for
instance, kaffe benefiting from my patch and I being unable to benefit
in the same way.
Thus, I find that people doing system integration and consultancy, both
in big and small companies will naturally prefer Apache-like licenses:
* you don't need to care about your customer wanting closed
modifications, as they can do them --> less overhead
* you don't need to care if your customer wants to redistribute the
output --> less overhead
* if you happen to find a niche where closed source or just integration
with closed source makes sense, you can do it
This, IMO, is one of the big "assets" and branding elements of the ASF
(together with quality). YMMV applies here.
Some people will find that this would enable commercial companies to
"cheat", by keeping their patches private. It doesn't work in the long term:
* Open "variant" evolves faster, so maintenance of patches is a
nightmare (Brian has an interesting essay on this (look for software as
a liability), I know this from my fingers :-) ).
* Private extensions/functionality requires inmense ammounts of money to
get people to know about it and use new APIs, while exposing a public
API and a RI in Apache can give this with far less investment
* Open knowledge flows ordins of magnitude faster than closed knowledge
Conclusions? not many:
* Community success is community (user and developer) benefit, not
downloads or size. This is what stroke me of Andy's post
* I find Apache licenses to make us "freer" than free software, removing
significant business opportunities from our portfolio
* I like being a small part of such a big movement.
(...)
Regards,
Santiago
P.S.) You know I'm in flux when I nest parenthesis in my writings
(inheritance of my LISP past, I noticed re-reading this rant) ;-) BTW, I
don't know if it is legal to do this in natural languages.
P.P.S) It's not polished, but I *needed* to express this. It's just what
I think, and I *don't* want a licensing flame war.
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
RANT: Licensing, Business models and success metrics (was Re: answer
to Howard or State of the POI )
Posted by Santiago Gala <sg...@hisitech.com>.
Andrew C. Oliver wrote:
> This is going to be another one of my long answers to a short question...
>
Good! (I crosspost to community. I think it really belongs there ;-)
Some context:
Howard M. Lewis Ship asked about Tapestry/POI usage:
> People keep asking me "how many people are using Tapestry"
>> ... and I honestly have no idea. Insufficient feedback.
>>
>> Do you have a way of determining the user base of POI? Any
>> guidelines based on downloads?
>>
>>
Andy answers:
> I don't really attempt to measure this. It would be trivial to measure
> the number of downloads from the access logs; however, I prefer to
> mesure it subjectively.
> Note that its documented on the Jakarta site that Opensource is not
> about units shipped. I'd look up the page but I'm sure that if I don't
> someone will do it for me so why bother.
>
Specifically in server side applications. For instance, as Andy hints in
my next quote, a single download from a intranet server in a big
corporation can lead to tens of thousands of (unsuspecting) users.
(...big snip, not that I don't like it, but please read it in the archives)
> First, POI attacts mail from some of the largest banks in the word,
> financial institutions, governments, millitary institutions, nuclear
> power plants, etc. There is even a large Apache backer flirting with
> the idea of using it (while its irrelevant to me whether they do or not,
> it is relevant that they are considering it).
>
> Next, I measure the success of it by two other things: Microsoft's
> flirting with open file formats (I'm sure it will be "open" in that
> Microsoft sort of way) and the final crux will be the day this
> http://www.tidestone.com/index.jsp goes out of business. The first clue
> to eventual success is that Tidestone has re-emerged as a seperate
> business entity instead of just a redirect to a page on Actuate's site.
> The second is that they have lowered the price from 15k per processor to
> 5,000k per server (I'm sure there is a big astericks)
> http://www.tidestone.com/pricing/index.jsp. This is after an extensive
> advertising campaign including full page adds in Dr. Dobbs. This is
> despite some functionality that we do not yet have.
>
I don't agree that it is a good metrics, since it's a crisis situation
and a lot of other factors could be involved into pricing (product life
cycle, etc.). Also, we are not trying to make anybody unhappy, that
would be (at most) a side effect of our approach being successful. But
the post goes on:
> My final measure is how much money I'm making and how many other POI
> developers I'm able to cut in on it. Thus far (this year) I'm able to
> derive 35% of my income from opensource efforts (a percentage which is
> up about 800% from last year). I suppose all of those are directly or
> indirectly related to POI. I'll undoubtably be flamed for this unique
> viewpoint, but its a measure which I find important. I've managed to
> pass on some of this work to two other POI committers thus far. (no one
> bother writing me offering to do this work, I only pass this work on to
> contributers to the project)
>
> So to me how many people are using POI and not contributing to the
> project in any way is totally irrelevant. I measure it in actual
> benefit to myself and the other contributers. To me any other mesure is
> trivial.
>
This is the point I think merits further exposure/discussion. I'm not
going to flame Andy on this, since I fully agree with it. If we cannot
extract actual benefits from our involvement in Apache projects, the
projects will not work/scale well.
Each and everyone involved in Apache projects should benefit in terms of:
* better career opportunities
* being better known in the industry
* having better tools in our daily work toolset
* higher productivity in integration
* knowing where technology is moving
* __fill more here__
The Apache licensing model is oriented towards consultancy/system
integration rather than product sales. This is in opposition to other
licensing schemes like GNU:
* If you hold the copyright of a GNU licensed stuff, you can re-license
it as closed source (a lot of GNU-licensed projects are doing this, see
Aladdin or Transvirtual with ghostscript and kaffe)
* If you hold the copyright of an Apache, BSD or Artistic licensed
stuff, it is far more difficult to do this, because everybody is free to
do the same.
This introduces an asymmetry I don't like WRT GNU licensed projects: the
person transferring copyright looses rights WRT the person holding it. I
don't critizise this approach with the FSF proper, but I don't like, for
instance, kaffe benefiting from my patch and I being unable to benefit
in the same way.
Thus, I find that people doing system integration and consultancy, both
in big and small companies will naturally prefer Apache-like licenses:
* you don't need to care about your customer wanting closed
modifications, as they can do them --> less overhead
* you don't need to care if your customer wants to redistribute the
output --> less overhead
* if you happen to find a niche where closed source or just integration
with closed source makes sense, you can do it
This, IMO, is one of the big "assets" and branding elements of the ASF
(together with quality). YMMV applies here.
Some people will find that this would enable commercial companies to
"cheat", by keeping their patches private. It doesn't work in the long term:
* Open "variant" evolves faster, so maintenance of patches is a
nightmare (Brian has an interesting essay on this (look for software as
a liability), I know this from my fingers :-) ).
* Private extensions/functionality requires inmense ammounts of money to
get people to know about it and use new APIs, while exposing a public
API and a RI in Apache can give this with far less investment
* Open knowledge flows ordins of magnitude faster than closed knowledge
Conclusions? not many:
* Community success is community (user and developer) benefit, not
downloads or size. This is what stroke me of Andy's post
* I find Apache licenses to make us "freer" than free software, removing
significant business opportunities from our portfolio
* I like being a small part of such a big movement.
(...)
Regards,
Santiago
P.S.) You know I'm in flux when I nest parenthesis in my writings
(inheritance of my LISP past, I noticed re-reading this rant) ;-) BTW, I
don't know if it is legal to do this in natural languages.
P.P.S) It's not polished, but I *needed* to express this. It's just what
I think, and I *don't* want a licensing flame war.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
answer to Howard or State of the POI (WAS: Re: Jakarta-POI 1.10.0-dev
released)
Posted by "Andrew C. Oliver" <ac...@apache.org>.
This is going to be another one of my long answers to a short question...
I don't really attempt to measure this. It would be trivial to measure
the number of downloads from the access logs; however, I prefer to
mesure it subjectively.
Note that its documented on the Jakarta site that Opensource is not
about units shipped. I'd look up the page but I'm sure that if I don't
someone will do it for me so why bother.
== Start with Community aspects ==
We have an active and vibrant community which has improved the lives of
most of the project's members. Especially career-wise and financially.
We all work pretty well together and POI is devoid of the antipathy that
pervades other projects. We make decisions by concensus, but do not
seek the granularity of decision-making on other projects or projectless
mailing lists (in my view peanut galleries). All members feel free to
express dissent, but there isn't a great deal. Not saying its perfect,
but that its not held up.
We do have a bandwidth problem. Most members have real jobs and don't
get as much time to contribute as we'd like. There is also a
significant barrier to enter the community. Its like actually hard and
stuff. There are other projects with steep learning curves but
generally they are knowlege of a relatively well known technology.
Cocoon for instance just requires you to learn all about XML and Avalon,
and I do mean ALL about XML. However, POI requires you to understand
hexidecimal math and know how to use diff and investigate hex dumps.
This has frustrated some potentially contributing users, but in truth
we're not really so interested in helping folks who don't wish to help
themselves or POI (remember the bandwidth problem) or at least not for
free (too much like work). This keeps our community small, but also
serves as a natural QA control of sorts (snobby I know but it does).
However there are enough folks who wander in and say "Reading Hex dumps
is for me! Thats FUN!" so we grow...just slower than other projects.
Our attrition or partial attrition mostly happens due to the projects
tendency to cause excessive employment to its most active contributers.
I'm happy to say we've never lost anyone due to other factors so far.
== Next with my personal measures ==
First, POI attacts mail from some of the largest banks in the word,
financial institutions, governments, millitary institutions, nuclear
power plants, etc. There is even a large Apache backer flirting with
the idea of using it (while its irrelevant to me whether they do or not,
it is relevant that they are considering it).
Next, I measure the success of it by two other things: Microsoft's
flirting with open file formats (I'm sure it will be "open" in that
Microsoft sort of way) and the final crux will be the day this
http://www.tidestone.com/index.jsp goes out of business. The first clue
to eventual success is that Tidestone has re-emerged as a seperate
business entity instead of just a redirect to a page on Actuate's site.
The second is that they have lowered the price from 15k per processor to
5,000k per server (I'm sure there is a big astericks)
http://www.tidestone.com/pricing/index.jsp. This is after an extensive
advertising campaign including full page adds in Dr. Dobbs. This is
despite some functionality that we do not yet have.
My final measure is how much money I'm making and how many other POI
developers I'm able to cut in on it. Thus far (this year) I'm able to
derive 35% of my income from opensource efforts (a percentage which is
up about 800% from last year). I suppose all of those are directly or
indirectly related to POI. I'll undoubtably be flamed for this unique
viewpoint, but its a measure which I find important. I've managed to
pass on some of this work to two other POI committers thus far. (no one
bother writing me offering to do this work, I only pass this work on to
contributers to the project)
So to me how many people are using POI and not contributing to the
project in any way is totally irrelevant. I measure it in actual
benefit to myself and the other contributers. To me any other mesure is
trivial.
I know thats not what you want, but I hope it helps.
-Andy
Howard M. Lewis Ship wrote:
>Woops --- that was supposed to be private. But advice is still welcome.
>
>--
>Howard M. Lewis Ship
>Creator, Tapestry: Java Web Components
>http://jakarta.apache.org/proposals/tapestry
>
>
>
>
>
>>-----Original Message-----
>>From: Howard M. Lewis Ship [mailto:hlship@attbi.com]
>>Sent: Tuesday, March 04, 2003 6:42 PM
>>To: 'Jakarta General List'
>>Subject: RE: Jakarta-POI 1.10.0-dev released
>>
>>
>>I'm looking for a bit of advice.
>>
>>People keep asking me "how many people are using Tapestry"
>>... and I honestly have no idea. Insufficient feedback.
>>
>>Do you have a way of determining the user base of POI? Any
>>guidelines based on downloads?
>>
>>--
>>Howard M. Lewis Ship
>>Creator, Tapestry: Java Web Components
>>http://jakarta.apache.org/proposals/tapestry
>>
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: general-help@jakarta.apache.org
>>
>>
>>
>
>
>
>
answer to Howard or State of the POI (WAS: Re: Jakarta-POI 1.10.0-dev
released)
Posted by "Andrew C. Oliver" <ac...@apache.org>.
This is going to be another one of my long answers to a short question...
I don't really attempt to measure this. It would be trivial to measure
the number of downloads from the access logs; however, I prefer to
mesure it subjectively.
Note that its documented on the Jakarta site that Opensource is not
about units shipped. I'd look up the page but I'm sure that if I don't
someone will do it for me so why bother.
== Start with Community aspects ==
We have an active and vibrant community which has improved the lives of
most of the project's members. Especially career-wise and financially.
We all work pretty well together and POI is devoid of the antipathy that
pervades other projects. We make decisions by concensus, but do not
seek the granularity of decision-making on other projects or projectless
mailing lists (in my view peanut galleries). All members feel free to
express dissent, but there isn't a great deal. Not saying its perfect,
but that its not held up.
We do have a bandwidth problem. Most members have real jobs and don't
get as much time to contribute as we'd like. There is also a
significant barrier to enter the community. Its like actually hard and
stuff. There are other projects with steep learning curves but
generally they are knowlege of a relatively well known technology.
Cocoon for instance just requires you to learn all about XML and Avalon,
and I do mean ALL about XML. However, POI requires you to understand
hexidecimal math and know how to use diff and investigate hex dumps.
This has frustrated some potentially contributing users, but in truth
we're not really so interested in helping folks who don't wish to help
themselves or POI (remember the bandwidth problem) or at least not for
free (too much like work). This keeps our community small, but also
serves as a natural QA control of sorts (snobby I know but it does).
However there are enough folks who wander in and say "Reading Hex dumps
is for me! Thats FUN!" so we grow...just slower than other projects.
Our attrition or partial attrition mostly happens due to the projects
tendency to cause excessive employment to its most active contributers.
I'm happy to say we've never lost anyone due to other factors so far.
== Next with my personal measures ==
First, POI attacts mail from some of the largest banks in the word,
financial institutions, governments, millitary institutions, nuclear
power plants, etc. There is even a large Apache backer flirting with
the idea of using it (while its irrelevant to me whether they do or not,
it is relevant that they are considering it).
Next, I measure the success of it by two other things: Microsoft's
flirting with open file formats (I'm sure it will be "open" in that
Microsoft sort of way) and the final crux will be the day this
http://www.tidestone.com/index.jsp goes out of business. The first clue
to eventual success is that Tidestone has re-emerged as a seperate
business entity instead of just a redirect to a page on Actuate's site.
The second is that they have lowered the price from 15k per processor to
5,000k per server (I'm sure there is a big astericks)
http://www.tidestone.com/pricing/index.jsp. This is after an extensive
advertising campaign including full page adds in Dr. Dobbs. This is
despite some functionality that we do not yet have.
My final measure is how much money I'm making and how many other POI
developers I'm able to cut in on it. Thus far (this year) I'm able to
derive 35% of my income from opensource efforts (a percentage which is
up about 800% from last year). I suppose all of those are directly or
indirectly related to POI. I'll undoubtably be flamed for this unique
viewpoint, but its a measure which I find important. I've managed to
pass on some of this work to two other POI committers thus far. (no one
bother writing me offering to do this work, I only pass this work on to
contributers to the project)
So to me how many people are using POI and not contributing to the
project in any way is totally irrelevant. I measure it in actual
benefit to myself and the other contributers. To me any other mesure is
trivial.
I know thats not what you want, but I hope it helps.
-Andy
Howard M. Lewis Ship wrote:
>Woops --- that was supposed to be private. But advice is still welcome.
>
>--
>Howard M. Lewis Ship
>Creator, Tapestry: Java Web Components
>http://jakarta.apache.org/proposals/tapestry
>
>
>
>
>
>>-----Original Message-----
>>From: Howard M. Lewis Ship [mailto:hlship@attbi.com]
>>Sent: Tuesday, March 04, 2003 6:42 PM
>>To: 'Jakarta General List'
>>Subject: RE: Jakarta-POI 1.10.0-dev released
>>
>>
>>I'm looking for a bit of advice.
>>
>>People keep asking me "how many people are using Tapestry"
>>... and I honestly have no idea. Insufficient feedback.
>>
>>Do you have a way of determining the user base of POI? Any
>>guidelines based on downloads?
>>
>>--
>>Howard M. Lewis Ship
>>Creator, Tapestry: Java Web Components
>>http://jakarta.apache.org/proposals/tapestry
>>
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: general-help@jakarta.apache.org
>>
>>
>>
>
>
>
>
answer to Howard or State of the POI (WAS: Re: Jakarta-POI 1.10.0-dev
released)
Posted by "Andrew C. Oliver" <ac...@apache.org>.
This is going to be another one of my long answers to a short question...
I don't really attempt to measure this. It would be trivial to measure
the number of downloads from the access logs; however, I prefer to
mesure it subjectively.
Note that its documented on the Jakarta site that Opensource is not
about units shipped. I'd look up the page but I'm sure that if I don't
someone will do it for me so why bother.
== Start with Community aspects ==
We have an active and vibrant community which has improved the lives of
most of the project's members. Especially career-wise and financially.
We all work pretty well together and POI is devoid of the antipathy that
pervades other projects. We make decisions by concensus, but do not
seek the granularity of decision-making on other projects or projectless
mailing lists (in my view peanut galleries). All members feel free to
express dissent, but there isn't a great deal. Not saying its perfect,
but that its not held up.
We do have a bandwidth problem. Most members have real jobs and don't
get as much time to contribute as we'd like. There is also a
significant barrier to enter the community. Its like actually hard and
stuff. There are other projects with steep learning curves but
generally they are knowlege of a relatively well known technology.
Cocoon for instance just requires you to learn all about XML and Avalon,
and I do mean ALL about XML. However, POI requires you to understand
hexidecimal math and know how to use diff and investigate hex dumps.
This has frustrated some potentially contributing users, but in truth
we're not really so interested in helping folks who don't wish to help
themselves or POI (remember the bandwidth problem) or at least not for
free (too much like work). This keeps our community small, but also
serves as a natural QA control of sorts (snobby I know but it does).
However there are enough folks who wander in and say "Reading Hex dumps
is for me! Thats FUN!" so we grow...just slower than other projects.
Our attrition or partial attrition mostly happens due to the projects
tendency to cause excessive employment to its most active contributers.
I'm happy to say we've never lost anyone due to other factors so far.
== Next with my personal measures ==
First, POI attacts mail from some of the largest banks in the word,
financial institutions, governments, millitary institutions, nuclear
power plants, etc. There is even a large Apache backer flirting with
the idea of using it (while its irrelevant to me whether they do or not,
it is relevant that they are considering it).
Next, I measure the success of it by two other things: Microsoft's
flirting with open file formats (I'm sure it will be "open" in that
Microsoft sort of way) and the final crux will be the day this
http://www.tidestone.com/index.jsp goes out of business. The first clue
to eventual success is that Tidestone has re-emerged as a seperate
business entity instead of just a redirect to a page on Actuate's site.
The second is that they have lowered the price from 15k per processor to
5,000k per server (I'm sure there is a big astericks)
http://www.tidestone.com/pricing/index.jsp. This is after an extensive
advertising campaign including full page adds in Dr. Dobbs. This is
despite some functionality that we do not yet have.
My final measure is how much money I'm making and how many other POI
developers I'm able to cut in on it. Thus far (this year) I'm able to
derive 35% of my income from opensource efforts (a percentage which is
up about 800% from last year). I suppose all of those are directly or
indirectly related to POI. I'll undoubtably be flamed for this unique
viewpoint, but its a measure which I find important. I've managed to
pass on some of this work to two other POI committers thus far. (no one
bother writing me offering to do this work, I only pass this work on to
contributers to the project)
So to me how many people are using POI and not contributing to the
project in any way is totally irrelevant. I measure it in actual
benefit to myself and the other contributers. To me any other mesure is
trivial.
I know thats not what you want, but I hope it helps.
-Andy
Howard M. Lewis Ship wrote:
>Woops --- that was supposed to be private. But advice is still welcome.
>
>--
>Howard M. Lewis Ship
>Creator, Tapestry: Java Web Components
>http://jakarta.apache.org/proposals/tapestry
>
>
>
>
>
>>-----Original Message-----
>>From: Howard M. Lewis Ship [mailto:hlship@attbi.com]
>>Sent: Tuesday, March 04, 2003 6:42 PM
>>To: 'Jakarta General List'
>>Subject: RE: Jakarta-POI 1.10.0-dev released
>>
>>
>>I'm looking for a bit of advice.
>>
>>People keep asking me "how many people are using Tapestry"
>>... and I honestly have no idea. Insufficient feedback.
>>
>>Do you have a way of determining the user base of POI? Any
>>guidelines based on downloads?
>>
>>--
>>Howard M. Lewis Ship
>>Creator, Tapestry: Java Web Components
>>http://jakarta.apache.org/proposals/tapestry
>>
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: general-help@jakarta.apache.org
>>
>>
>>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
RE: Jakarta-POI 1.10.0-dev released
Posted by "Howard M. Lewis Ship" <hl...@attbi.com>.
Woops --- that was supposed to be private. But advice is still welcome.
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/proposals/tapestry
> -----Original Message-----
> From: Howard M. Lewis Ship [mailto:hlship@attbi.com]
> Sent: Tuesday, March 04, 2003 6:42 PM
> To: 'Jakarta General List'
> Subject: RE: Jakarta-POI 1.10.0-dev released
>
>
> I'm looking for a bit of advice.
>
> People keep asking me "how many people are using Tapestry"
> ... and I honestly have no idea. Insufficient feedback.
>
> Do you have a way of determining the user base of POI? Any
> guidelines based on downloads?
>
> --
> Howard M. Lewis Ship
> Creator, Tapestry: Java Web Components
> http://jakarta.apache.org/proposals/tapestry
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
RE: Jakarta-POI 1.10.0-dev released
Posted by "Howard M. Lewis Ship" <hl...@attbi.com>.
I'm looking for a bit of advice.
People keep asking me "how many people are using Tapestry" ... and I
honestly have no idea. Insufficient feedback.
Do you have a way of determining the user base of POI? Any guidelines based
on downloads?
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/proposals/tapestry
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta-POI 1.10.0-dev released
Posted by "Andrew C. Oliver" <ac...@apache.org>.
>
> The primary advantage of doing this was to simply to avoid confusion.
> When people say they are using 1.9 it's obvious that it was a nightly
> and not the milestone build.
makes sense. Thats why you're the man.
> PS: Announcement to the announcement list is coming.
cool. Note that I sent this here due to the stated eventual preference
that releases will be voted on here. This is just a development release
or milestone so I doubt it would be subject to this, but I thought it
responsible to post it to further the evolution of this process.
> PSS: Hopefully my access request will come through so I can publish a
> myself without having to wait and I can time the announcements correctly.
Brian has already granted your access with the same password as on
icarus. Give it a whirl. He also noted that your .forward seems to be
malfunctioning. While you're at it you might want to update the web
pages (I left that to you so that you would have something to do to try
it out)...
-Andy
Re: Jakarta-POI 1.10.0-dev released
Posted by "Andrew C. Oliver" <ac...@apache.org>.
>
> The primary advantage of doing this was to simply to avoid confusion.
> When people say they are using 1.9 it's obvious that it was a nightly
> and not the milestone build.
makes sense. Thats why you're the man.
> PS: Announcement to the announcement list is coming.
cool. Note that I sent this here due to the stated eventual preference
that releases will be voted on here. This is just a development release
or milestone so I doubt it would be subject to this, but I thought it
responsible to post it to further the evolution of this process.
> PSS: Hopefully my access request will come through so I can publish a
> myself without having to wait and I can time the announcements correctly.
Brian has already granted your access with the same password as on
icarus. Give it a whirl. He also noted that your .forward seems to be
malfunctioning. While you're at it you might want to update the web
pages (I left that to you so that you would have something to do to try
it out)...
-Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta-POI 1.10.0-dev released
Posted by Glen Stampoultzis <gs...@iinet.net.au>.
At 09:58 AM 5/03/2003, you wrote:
>Why we skipped a release number, only Glen would know. :-)
I guess we really need to write this down.
To clarify my (maybe flawed) thinking:
We were running a nightly build called 1.9-dev. The milestone build before
that was 1.8-dev. In order to avoid confusion with the milestone and
nightly build I bumped up the build number to 1.10-dev and make the new
nightly builds 1.11-dev.
The primary advantage of doing this was to simply to avoid confusion. When
people say they are using 1.9 it's obvious that it was a nightly and not
the milestone build.
Regards,
Glen
PS: Announcement to the announcement list is coming.
PSS: Hopefully my access request will come through so I can publish a
myself without having to wait and I can time the announcements correctly.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org