Hi,
I have been thinking a bit about this sort of thing lately. I am involved in
Avalon and have seen JDK expand to cover parts of code in that project. Other
JSRs are currently under development that will render even larger portions
"obsolete".
Is this, in itself, a bad thing? Not as far as I can see. One thing
opensource/freesoftware is not known for is creating "standards". We
implement standards great and many of the most renowned products (Apache
Httpd, GNU/Linux, Mesa3d) are known because they damn fine products and very
standards compliant. There are sections of the community that work good with
the standards bodies but they are rare (though this percentage has been
rising of late).
Large buisnesses need stability and documentation. While some OS projects can
reach that level of maturity after *many* years, a lotta luck and/or good
developers - this is not the norm. Standards are good because they provide
the stability (in theory) and facilitate documentation (or at least provide
raw standards document). Standards are good for one reason - they are
standard.
Even better - standards offer the opensource community at large a chance to
shine because that is what we are good at. Standards give a reference point
of where we want to end up - thus members of community have a common target
and there is vastly less confusion about direction (how to get there is
another thing...). This lowers communication costs which is better for usall
as we can get on doing with what we do best - code ;)
Sometimes standards end up making poor decisions or being of poor quality for
one reason or another. Ceki has been railing against recent Logging JSR, I
have heard others rant about JSPs being evil and there is always the EJBs
were product of an immature process wails. I am sure there are things all of
us dislike about one API or another. There are also APIs most people like
(Collections and Security Permissions come to mind).
In non-java world the sucky standards are ignored or newer better improved
versions are implemented over the top. However in many cases, us java users
do not have that luxury. The APIs are shipped with the core JVM. Most users
(and many developers) are lazy and if they have a product/API that
satisisfies their needs but is ugly/bad/evil they will use it anyway. The
only way to change this would be to make the "good" api as painless to use as
the standard but "evil" api.
This brings us back to the idea of CJAN. Scattered across a number of lists
there has been discussion of CJAN. I won't bore you with the details but the
core features of this service were
* (seemingly) centralized directory of java jars/libraries/components
* reolvable dependency relationships between these components
* standard mechanism for sucking down components and storing them in system
global, user-specific or project-specific locations
* Possibility of a java version of ld.so that loads relevent jars and
"injects" them into ClassLoader for apps
This would give the "other" APIs (non-standard but good) a fighting chance
against core JDK classes. It would also move java closer to being platform
agnostic.
However this doesn't really address the issue of whether Sun/JCP should be
duplicating work done in opensource projects like jakarta. I guess that is
really a loaded question. Given that I am very anti "duplication" especially
when source work is freely usable - the answer would be a clear no. However
if I was to slightly modify the question to something like "Should Sun/JCP
create standards based on work done in opensource projects like jakarta" then
I would 100% agree. Mainly because it is a standard and thus has associated
benefits (stability and documentation).
So I guess we have to ask - What would the best method be for increasing
quality of the standards? and/or getting Jakartas work accepted into JDK or
as a dejure/defacto standard etc? and/or as RI etc?
Our situation reminds me a lot of a situation described in a book I read
about a few years ago (I think it was called "Environmental Terrorism").
Essentially we are a group of "idealists" trying to convince the holders of
the purse strings to do the "right thing".
The book described a number of strategies to change peoples minds. The three
strategies that seem relevent in our situation are
1. Work from the inside
2. Spit in their face
3. Extend and imnovate
For instance if there is a JSR proposed that overlaps with something you are
working on then (1) would be the best strategy. Join with the tech lead and
other expert group members to work out the best possible API definition etc.
This however has the side-effect of supporting the powerbase that creates
standards (int this case Sun/JCP) and a few people have raised concerns that
you are lining Suns coffers by doing this.
(2) is an effective strategy to raise community awareness but it almost
certainly has no effect on the process. In this case it can effectively do
more damage than good. It tends to alienate the Spec Leads and other
participants in JCP which can put a halt on cooperation in the future.
(3) is a strategy that you probably recognize from groups like Microsoft or
GNU.org. They implement the standard and then add a number of extentions to
standard to increase ease of use. This has the effect of locking in users to
using their extended versions. As a long term strategy this is often the
best, unfortunately it takes time and a lot effort.
So to summarize
(1) effective, short-term, may leave participant feeling like they doing work
for another
(2) not effective, easy to do, raises awareness, leaves participant feeling
good about themselves
(3) most effective, long-term, ***lots*** of work, leaves participant feeling
good about themselves
Personally I prefer (1) - mainly as I am relatively lazy. It is the easiest
way to get changes instigated. So is (1) really a solution? At this stage,
not really. JCP is still too broken to achieve it effectively.
For those not familiar with JCP there is essentially 3 components. The
Committee (EC)(made of company reps and/or leading researchers), the Spec
Leads and the Expert Group (EG) members. When a new JSR is proposed it needs
to be approved by relevent EC. The group proposing it usually will provide a
Spec Lead. This Spec Lead will then *select* a group of "experts" to work
with. This group then writes/revises spec until approved by EC or until
dropped.
There are a few serious problems with this process; Spec Leads have absolute
control and Discussion is not open being the two obvious faults.
Spec Leads get to select the members of EG. Thus it is not inconceivable that
they would only select yes-men. They also are under no obligation to listen
to any EG members. They could almost submit a work that the rest of EG
disagrees with (Not strictly true as a 2/3rds vote can eject Spec Lead). The
only check on their power is the EC.
The Spec Leads also get to decide the working style. Some are relatively open
while others are very closed. The worst EG I have heard about disallowed
communication between EG members. They could only communicate with Spec Lead
and the Spec Lead may only forward limited sets of information to each
member. The other end of spectrum is groups where 99% of communication is
done on open mailing lists.
There is 3 types of information generally communicated between EG members.
a. private information (ie passwords and data that is restricted to EG
members)
b. protected information (ie can only talk with your own company)
c. public information (ie can talk to anyone about it)
I would love to see the JCP become a real community process. If any of you
become involved with the JCP I would encourage you to advocate placing (c) on
public mailing lists. It would also be good to distribute power in EG so that
decision process is a meritocracy or democracy of sorts.
There is one other danger present in current JCP process that I haven't seen
discussed before. If I was a selfish greedy entrenpreneur then I would see
the JCP as a great stomping ground. I could go in, create a spec and provide
a basic RI. Then sell a enhanced version of RI with patented techniques.
However I make sure that anyone who wants to be a serious user of API needs
to license my product. Thus I become "standards complying" and probably quite
wealthy. Not sure If I would go as far to say this is happening already
but...
Anyways this has become a rant so I will stop now ;)
Cheers,
Pete
*-----------------------------------------------------*
| "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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
