Only 15% regularly publish JSR schedule updates, and a similar number (18%) publish regular drafts of their specification (in many cases as frequently as monthly). Only 10% of Expert Groups publish the names (as opposed to the company affiliations) of their members.

While it's clear that many Expert Groups are trying hard to communicate openly with the developer community, there is obviously much room for improvement. Also, despite the fact that the JCP website provides "observer aliases" and "community update pages" to enable Expert Groups to communicate with the membership, only 18% of the respondents are actually using these facilities. In other words, many Expert Groups are operating transparently, but are not telling visitors to jcp.org that they are doing so.

The PMO, with the support of the JCP's Executive Committees (ECs), intends to promote a variety of Expert Group Best Practices, including the use of public aliases, forums and Wikis, regular publication of JSR schedules, public issue-tracking, a formal process for submitting comments, and the use of collaborative and open source development processes. We will ensure that the Community Update pages at jcp.org accurately inform the public of all these mechanisms, so that visitors to the website will always know where they can learn more, and how they can get involved. We will make these changes by shining the spotlight on those who do well and by encouraging others to follow their example. The JCP's Process Document may also be revised to require some specific transparency processes. (Currently it simply encourages transparency and leaves the choice of processes up to the Expert Group.)

If all Expert Groups operate in an open and transparent manner, that will be a great improvement. However, this is not enough. At the most recent meeting of the JCP's Executive Committees, we decided that we too need to be more open. Historically the proceedings of the ECs have been kept mostly private, with high-level "public summaries" published on the JCP website where JCP members - but not the general public - can read them. We decided to make two changes. First, the default records of our meetings will be those that are open to the public rather than those that we keep private. (We reserve the right to go into "private session" from time to time, but we don't expect this to happen very often.) Second, we will enable everyone - not just JCP members - to access our meeting summaries. (It didn't seem right to require a password to access a document called a "public summary.") If you're interested to know what we discuss during our monthly meetings, check us out at http://jcp.org/en/resources/EC_summaries.

This Month's Active JSRs
Full details of this month's active JSRs, as always, can be found in the Focus on JSRs section on the JCP homepage or by subscribing to our mailing list. Here's a summary.

JSR 311: JAX-RS: The Java API for RESTful Web Services, led by Sun, made its final release. Not only was this JSR open and transparent - as I reported in my previous column - but it was also very agile, completing development in only 20 months. JSR 327: Dynamic Contents Delivery Service API for Java ME, led by SK Telecom, is the latest JSR to win approval for development. This JSR will provide a generic interface to Dynamic Content Delivery clients in Java ME-enabled devices, and will support the Open Mobile Alliance DCD standard.

JSR 309: Media Server Control API, led by HP and Oracle, is in Public Review Ballot as I write this. The JSR will define APIs for accessing external Media Servers, supporting rich applications with Interactive Voice Response, Conferencing, Speech Recognition, Text To Speech Services, and similar features.

Finally, two JSRs reached the Proposed Final Draft stage this month. JSR 300: DRM API for Java ME (led by LG Electronics) defines generalized mechanisms for handling Digital Rights Management (DRM)-protected content. JSR 318: Enterprise JavaBeans 3.1, led by Sun, is the latest update to the venerable JavaBeans specification (now more than 10 years old).