from http://www.tensegrity.hellblazer.com/2009/03/osgi-rfp-122---the-osgi-bundle-repository.html
This week at EclipseCon, I discovered that I
had inadvertently opened a can of worms and found the entire Landsraad
of the Open Source community arrayed against me. My crime? Apparently
it's simply that I've had the audacity to pick up an OSGi specification
that has been in existence - and in the public domain - since 2005
(i.e.
OSGi RFC 112, the OSGi Bundle Repository)
and attempt to work out the issues with that specification so that we
can finally formally release it as part of the OSGi specification.
Much
of the suffering I was dealt was due to serious misunderstandings of
those involved with the process that is currently being played out.
Some of this misunderstanding is due to ignorance of the OSGi process -
and note that I use the term "ignorance" not as a pejorative, rather
simply as a statement of fact. Those who aren't involved in the OSGi
process, nor familiar with the way that specifications in general are
produced can sometimes be left bewildered by the array of TLAs and the
process by which consensus is reached. Certainly in the Open Source
world, sometimes things are done quite differently than they are done
in standards bodies (note: I'm not saying that this is universal, only
making the point that standards bodies are their own beasts and Open
Source communities rarely conform to such formalized systems).
So
let me make a couple of points, and talk about how I'm going to carry
out the process of specification of the OSGi Bundle Repository to
ensure that the world outside of OSGi can participate in this process.
First, I would appreciate actual technical conversation in a forum,
rather than back door politicking and pressure tactics. One of the things that
I've found enormous value in the OSGi is the fact that all the
specifications and discussions I've been a part of during my tenure in
the organization have all been above board and professional. What I
mean is that we air our disagreements out in the open and discuss them
on the technical merits. I have had serious disagreements with others
on any number of matters in the OSGi and I have yet to have people not
discuss the issues like professionals.
Second, I would like to
explain the process of this specification as it has been quite
unusual. The OSGi Bundle Repository (OBR) first started out its life as the
OSCAR bundle repository.
OSCAR
was the predecessor to the Apache Felix OSGi framework, headed by
Richard Hall. As far as I can tell, the OSCAR Bundle Repository was
first presented to the world in 2004, so it's been around for quite a
while. In 2005, an OSGi RFC was produced - RFC 112, and it was renamed
the OSGi Bundle Repository. Now, for those not familiar with the way
specifications are produced in OSGi, it is unusual that the OBR became
a specification without ever going through the requirements process (in
OSGi parlance, the production of an RFP). RFC 112 sat on the shelf
gathering a bit of dust, although it was still in wide use, until late
2008 when I decided to pick up the ball and try to finish the
outstanding work still required to make the OBR part of the released
OSGi specification.
Prior
to the OSGi F2F meeting in Feburary of 2009, I worked with Richard Hall
and Peter Kriens to work out the remaining issues tha they had left
unanswered in their work on the specification. I also enlisted the
help of the folks at Paremus, who had also been making use of the OBR
in their excellent work on their
Sigil project.
After rendevousing a couple times, I had filed a number of bugs against
the spec regarding what I thought were the remaining issues that needed
to be pinned down, so that we could discuss them at the next F2F.
Little
did I know what I was walking into, being ignorant of the various
political activity that festers around such things. At the February
OSGi F2F, it became quite clear that we needed to go back to the
requirements phase of the OSGi process so that we could get clear
consensus as to what we were trying ot accomplish before proceeding
with the specification phase.
Now, at this point I'd like to
stress that this is no trivial thing. What it means is that I have
effectively given up the RFC "blessing" that RFC 112 had - regardless
of how unusual it had acquired that blessing. What this means is that
by going back to the RFP stage, I have thrown this process back on the
mercy of the OSGi process for accepting a requirements document. For
those of you who are not members of the OSGi, what this means is that I
have to now produce an RFP - i.e. RFP 122 - and get consensus within
the OSGi organization on its contents. After this is done, the RFP is
then brought up for a vote. And what this means is that the majority
of voting members has to approve the RFP before it can then proceed
back to the RFC stage.
Which brings me to my third point, that I
have not been trying to ramrod the OBR through the process as some have
misperceived. Rather, I have done precisely the opposite. If I was
actually trying to ram this through the process, I would not have
voluntarily
reverted the process back to the RFP stage. Instead, I would have
taken advantage of the RFC status of the OBR and simply ignored all the
issues that were brought up at the F2F. Instead, I decided that the
concerns that people had raised needed to be addressed in the
appropriate forum, and process - i.e. an RFP was needed.
Having
said that, I am not going to take the slow route with this process.
I'm going to press the issue and demand that those who have an interest
in defining the OBR actively participate. As I pointed out previously,
the OBR has been around since 2004 and is in active use, both in the
open source community as well as in private industry. Further, the
actual specification, RFC 112, has been in the public domain since 2005
as well - something highly unusual for an OSGi specification, which is
normally closed intellectual property of the OSGi until it becomes a
released specification.
Consequently, I don't really take well
to the idea that people will "get around" to dealing with the
specification. It's been around forever, and it's not like this
appeared out of the blue. Several implementations exist and are in
active use. If you're interested in the specification, then you should
make it priority to deal with, just as I have made it a priority to
deal with. I, like many others, have a lot of stuff on my plate and a
job I do every day. This specification is important to me and I intend
to make sure that it becomes a released standard and will work hard to
ensure that it will become one.
Finally, my fourth point is that
the process of technical discussion about a standard is inherently
going to entail frank discussion about technological issues. What this
means is that everyone is going to tell you that your baby is not only
ugly, but should have never been born in the first place. Further, now
that your baby is born, you really should hide it under a blanket so it
doesn't scare the rest of us with its hideous deformities that you find
charming and cute. This is the nature of technology, in that we all
get personally attached and invested in whatever it is we work on.
Certainly, I am no different. My children are just as ugly, misshapen
and horribly inadequate as everyone else's.
Having said that, I
want to make it clear that I will brook no arguments about the
superiority of "open source" work over other work. I would only point
out that OBR has predated a lot of the technology that is being
presented as "TEH ONE" and has just as much a claim to the mantle of
open source due to the seminal work of Richard Hall and Peter Kriens as
anything else. The fact that this is being done in the OSGi standards
body is because of the desire to make this an OSGi standard. If you
don't care about standards, then the process I'm presenting here won't
matter to you. Like all standards in OSGi which are not concerned with
the Core Framework, it will be an optional standard - just like the
Initial Provisioning Spec, the Configuration Administration Service,
etc. No one is going to force you to make any use of the OBR if you
don't like it, think it smells or is tainted by the very involvement of
House Harkonnen in its creation.
In conclusion, I would like to
point out that what I'm doing is rather unusual for the OSGi in that
we're reaching out to the open source community and those interested in
this standard and ensuring a high quality product. This does not mean
that the open source community gets to vote on the OSGi standard - that
is, after all - something that the OSGi controls. However, this does
mean you get to bitch to me directly, rather than having to sit in a
corner, sulking that your concerns were not addressed, or screaming at
the cage door flinging poo at me through the bars.
As such, I'm going host a copy of the current state of the RFP on this site:
OSGi RFP 122.
As the specification progresses, I'll be updating the link with the
current state. Right now, this link refers to the state of the
requirements after the last internal conference call we had. I
encourage you to read it and send me any comments you may have. My
email is in the document.
I will also continue to blog about
the issue as it develops. I currently need to blog about the latest
discussions I had at EclipseCon on the requirements for the OBR and my
thoughts on the matters at hand. However, this post is already way,
way too long and I need to get to that overflowing in box of things I
have left to do. Hopefully we can, together, produce an excellent spec
that the entire community can be proud of.