----------
From: "Craig R. McClanahan" cmcclanahan@mytownnet.com
To: Java Apache java-apache@list.working-dogs.com
Subject: Re: API 2.2 discussion list
Date: Tue, Jul 13, 1999, 9:58 AM


Michal Mosiewicz wrote:

> jon * wrote:
> >
> > > How would you feel about setting up a list for public discussion of
> > > the Servlet 2.2 API?
> >
> > This is all good and fine, but does not help us any if Sun isn't listening.
>
> That's true, but it seems that Sun has no capabilities to listen us all.
> Currently one cannot even subscribe to servlet-interest. It's like
> cathedral, where you have to pray and beg, to get blessed and passed
> inside. There is no bazaar. I believe it's not only me who is pretty
> discouraged.
>

A ridiculously overloaded mail server happens because of ignorance or
incompetence, not dictatorial intent.  OTOH, you don't want to subscribe to
servlet-interest unless you like seeing the Apache JServ newbie questions * 100
or so, believe me ...

Sun listens to feedback about the spec, at the feedback address published right
on the spec itself:

    servletapi-feedback@eng.sun.com

This stuff gets recorded and summarized, and (where relevant) discussed in the
"experts group" that is primarily responsible for the content of the spec (I'm a
member of this group, as are several others with Apache JServ connections).  It
is not ignored.

>
> Even if it was not officially approved, maybe we would work out
> something good, that could be officially proposed.
>

The mechanics of doing this (providing a forum for discussing future specs) is
pretty straightforward.  But, if it tempts people to voice their opinions only
here (instead of at the official feedback address above), it's going to mislead
people into complaining about why this forum is being "ignored".  I would urge
you not to set something like this up unless someone takes formal responsibility
for collating the "voice of the public" into feedback that is forwarded to the
official address.

Even if you do all of that, though, I would caution you not to expect to have
much impact on the significant direction of the spec (although more hands fixing
the details is always useful).  Why?  Because of the timing of when the spec is
available to the public compared to when the underlying assumptions about what
is being accomplished were articulated and discussed.  The servlet 2.2 spec is a
case in point -- it went through internal development inside Sun, six (!) expert
working group drafts with intense discussions on each of them, and is now in the
first of (at least) two rounds of public review.  This has taken several months
The basic direction is pretty well set by now, and is unlikely to be
fundamentally changed.

Open source mechanisms work very well at creating implementations, but not so
well at creating specifications.  Look at Linux and Apache themselves as
examples -- very small teams decide what really makes it in to the core releases
(or what the key interfaces look like), but code implementations are welcomed
from everywhere.  Spec-writing is just not an activity that works well in a
populist setting.

If you want to significantly influence the direction that a Java-related spec
takes, there are three effective mechanisms:

* Work for Sun in that group, and get in early :-).

* Lobby James Davidson (in this case) to be
  included in the "experts group" that reviews
  the specs before they go public.  But the group
  is pretty picky -- demonstrated compentence
  and/or endorsement of other members is
  really important.  Even with that, though, the
  group is probably already at the upper end of
  practical size, given the purely human issues of
  consensus building and group dynamics.  It
  also already includes appropriate representation
  from the various constituencies.

* Lobby people who are members of the expert
  group to present your ideas.

Note that none of this has anything to do with contributing to the
implementations in Apache JServ (now) or Jakarta (later).  It is important to
understand, though, that these projects must take the spec as a given, not
something that is negotiable.

>
> Mike
>

Craig