cle's handling of the JCP. Doug Lea wrote an open letter why he did not want another term on the JCP and Stephen Colebourne, a JCP specification leader and Apache Software Foundation member, is rallying against the JCP. Obviously the lawsuit against Google and the change of heart concerning the Apache Harmony field of use restriction did not win Oracle many new friends. Neil Bartlett even blogs about OSGi taking over the role of the JCP for the Java Community ... LOLHmm ...
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.
Peter Kriens
Given the age we live in, it seems a bit crazy that "travel" is such an important component of being able to write specifications. I'm sure there are plenty of individuals out there with a lot of good stuff to contribute and who don't mind spending the "time" but can't afford the "travel". Email, Document Collaboration, WIKIs, Video Conferencing, VOIP, etc; all these things make "travel" redundant.
ReplyDeleteI have to agree with Chris. The idea that the same small group of people have to meet up regularly in Boston, SF, London, Tokyo etc is right out of the 1980s. It also drives away some of the more talented individuals (e.g. Hal?) who may be dedicated to the work but not enough to put up with the ridiculous travel...
ReplyDeleteHi,
ReplyDeletewhere do I find details about the process to obtain access to the TCKs for open source projects? Do Eclipse projects have to apply individually?
I wish travel was irrelevant but after doing this for more than ten years I can testify wholeheartedly that it is not. I've seen over and over that in the long run things become very hairy over email, telephone, Skype video, and other collaborative tools only to be solved in 10 minutes on a whiteboard standing next to each other.
ReplyDeleteRealize that writing specifications is much more abstract than collaborating on implementations where it is easier to carve out a piece and where the compiler verifies much of the work.
However, probably the most important part of travel is that you get uninterrupted time to work on the specifications. It is always amazing how much work gets done before and during a meeting. It is also interesting that the meetings for the hosts and locals are usually less productive because they generally have to leave early or are interrupted by their colleagues.
And last but not least, it is team building. When you meet face to face it is a lot harder to dislike people you've had dinner with and a lot easier to relate to them during the harder parts of specification work.
Anyway, the travel cost is dwarfed by the cost of the employees and the commitments the company need to make. So what are we talking about here? Doing it by volunteers that can come and go at will? I think that having real companies that commit people to the work so they can do it in day time is the crucially important for the quality of the specifications.
@lemmster.de
ReplyDeleteSend a mail to help@osgi.org and I will make sure someone sends you the conditions.