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.