If you think about, the OSGi is the only other organization that makes specifications for the Java community. And in many ways the OSGi Alliance has an arguably much better structure for Java specifications than JCP ever had:
- Copyrights - In the JCP the specification lead together with Sun (now Oracle) have a special status. They're not even a bit more equal than others, they are on a whole different plane concerning ownership of the created Intellectual Property (IP). The contributions of other members in the expert groups are gladly taken for free but do not provide any rights in return.
The OSGi is different. A member is a member, regardless if this member has 100.000 employees or 3. All created IP is licensed forever to all members under exactly the same conditions. Additionally, the specifications are completely free to implement by non-members. Simple, and more important, it is fair.
- Patents -The OSGi Alliance and some of its key members have pledged not to assert any patents that are necessary to implement the specifications. During the specification process great care is taken that no submarine patents slip in.
- Process - In the JCP the process is more or less in the hands of the specification leads. Having been a member of a number of JSRs I can assure you the process differs significantly. JSR 291 was run quick and efficiently, and I guess we all know what happened to JSR 277 and JSR 294, not to forget my 2 years in JSR 198, the most futile JSR of all.
In the OSGi there is a much more standardized process that focuses on requirements first, API later. Over the past 30 years I've worked with oh so many developers developing APIs. It is a lot easier to get an agreement on requirements than on an implementation proposal. Therefore, the OSGi EGs always first work on an Request For Proposal (RFP); a document focused on requirements. Maybe those documents are not always perfect requirement documents but the process of making this requirements provides the opportunity for the EG members to create a common vocabulary. This collaborative mood helps tremendously when it is time to create the Request For Comments (RFC).
- Reference Implementations (RI) - In the OSGi process a Reference Implementation is mandated before a specification can be published. For the previous releases the OSGi worked with several open source groups to provide the RI. However, the OSGi also has their own RIs when no group steps up.
- Compatibility Tests (CT) - Every specification requires a CT that runs on the OSGi test harness. These CTs are free for the members and can be obtained free of cost for qualifying open source projects.
- Architecture - The quality and architectural aspects of JSRs differs wildly because there is no central gating function. The running of a JSR is more less up to the specification leads and they can basically deliver what they want.
In the OSGi Alliance all APIs have to go through the CPEG, which acts as an architecture board. Though this can be a bottleneck and a pain, it ensures consistency between specifications which is a big benefit for the users.
- Quality Specifications - Again, in the JCP the specification is more or less what the specification lead wants to make of it. Some are excellent, other are a bit less. In contrast, all OSGi specifications are written as data sheets in the same template. Overall releases pack up a number specifications and bundle them together in a high quality book.
- Opennes - Though the OSGi has been releasing RFCs ahead of the specifications the name lingers that the OSGi is very closed. I do think the OSGi Alliance should try to open up more but I also believe that the EG should have a period to get their act together before they have to publish. Specification writing is hard and agreeing within an EG is even harder. Anyway, so far there has been surprisingly little feedback on our released RFCs.
- OSGi is Expensive - Today, the OSGi Alliance subscription fee is $25k or (€18k). They are currently trying to change our bylaws so they can actually have different tiers that will allow the subscription cost to go down for many companies. And they have invited researchers for qualifying academics. However, a bit of a reality check here. If you want to work on specifications it will cost you time and travel; both are highly expensive. If you want to do a good job, these costs dwarf the cost of the subscription fee. If the fee is the problem, should you really be wanting to work on these specifications anyway?
The biggest advantage of the fees is that the organization is independent of the big guys and can thus be truly democratic for its members. With different tiers the big guys will pay significantly more but will require to become more equal. And was that not one of the problems with the JCP?
- Not everyone uses the OSGi Framework - True, our specifications take the framework into account but most service specifications are written for pure POJOs. For architectural consistency it would be necessary to consider the framework in new specifications but that would not influence their usage outside a framework.
In practice, this means ensuring the specifications are properly cohesive and uncoupled. For example, instead of putting the Factory and Provider classes inside the package, they would have to be kept in a separate packages, but that is also good modular practice in non-OSGi Java.