Bob Scheifler wrote:
There are definitely people in the community that want to see the
existing Jini community process maintained for approving standards.
I used to be one of them. But, when we've looked for volunteers
committed to running that process, there are very few takers.
I was one of those few volunteers, and maybe even more important most
people expressed they didn't see the need for "blessing" specifications
as Standards given the circumstances. They seem to be happy with the way
how Sun interacted with the Community with regard to their
specifications in the past years. I believe it is their expectation, and
I hope they are right, an ASF project will function in a similar way
with the added benefits of the Open Source dynamics found here at the ASF.
A few weeks ago I was not in favor of managing the specifications as
part of the same ASF project but given what the Jini Community seems to
want I changed opinion and decided it is better to spend my energy in
mentoring new developers with the core principals part of the current
Jini specifications and implementations instead of maintaining a process
that not that many seem to have interest in at this stage for the Jini
technology.
So I guess that means I can't support Geir's proposal as it is not in
line what I and the larger part of the Jini Community want.
This is a pretty important step, probably equally important as your
decision to use the Apache License for Jini. I don't want to impose
any arbitrary barriers to acceptance into the Apache incubator, but
I'd like to see a wider discussion of abandoning the "standard".
To my mind the wider discussions have already taken place within
the Jini community. At some point, I stop wishing for what could be
in theory, and start executing on what I think can be in practice.
My feeling too.
While I can understand the discussion came to this point I also feel
that we are deviating from whether "Jini" is an appropriate name for the
project. A few raised objections for reasons that IMHO are not always
*that* clear based on the answers given to Bob's questions.
Assuming it is legally allowed to use the name Jini I can't see why
"Apache Jini", "Codehaus Jini", "Jini Community", etc. would be
problematic especially as the "Apache Jini" project seems to have
multiple deliverables such as *various* Jini Specifications,
implementations of these specifications and additional tools targeted at
the development of Jini services.
The usage of the name Jini implies to me all these projects do something
Jini Technology related, so yes it is likely intended to define an
"umbrella" or category, but based on the above isn't that what is
proposed?
I think I've spent already a few hours trying to find the right
sentences to explain why the name Jini (if legally allowed) would be in
the interest of us all, but after writing large pieces of text that have
been deleted straight away I just can't seem to do that in a positive
way that won't raise more questions. So as a last resort I'm going to
try to do it the other way around, so already my excuses to the other
committers if I make things worse.
To be very blunt what is proposed here is that the ASF project is
"monopolizing" Jini ... in the interest of the larger Jini community.
This might seem a contradiction but this is how people in the Jini
Community seem to want how we deal with our current process, most
specifications and implementation. They just don't want to spend much
energy in a Jini Decision Process but the majority want to separate
specifications from implementations that was one of the fundamental
principals by the Sun team that is responsible for almost all of the
Jini Specifications.
They want these specifications to be in the net.jini namespace where
they are right now, not only because of the migration hell they would
otherwise be confronted with, all the documentation/books that become
useless, etc., but also because that namespace would imply stability,
opposed to a namespace org.apache.jini that is likely more subject to
change.
That means that the committers of the ASF project will debate what
should end up as specification (net.jini namespace) that allows for
multiple implementations and what ends up in the org.apache.jini.xxx
namespace. The major difference with the past situation is that there is
no way to 'correct' what ends up in the net.jini namespace by the larger
community, but, as I said before, that is what they want. And I have
confidence (based on past experience) that the group of committers is
willing to listen to any argument of those that have no formal say in
the ASF project.
And maybe when Jini gets wider adoption we could submit part of the
net.jini namespace to another standards body if that would be in the
interest of the wider community.
I would be saddened if we can't maintain "Jini" as project name, but if
it has to become something like "Genie" would it still be possible to do
the following:
- Create various specification deliverables that are of the form "Jini
bla bla bla Specification/API".
- Specifications/API in the net.jini namespace.
And remember that there is no body outside the ASF project that defines
those specifications, that is the job of the ASF project.
--
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
