By Patrick Curran on Jan 26, 2011
Simon Phipps recently commented in his blog about the nomination of SouJava for a ratified seat on the JCP's Executive Committee. In that entry and in a follow-on email discussion with me he expressed the hope that this nomination would help "fix the JCP" by eliminating secrecy and confidentiality requirements. I thought his concerns were important enough that I should respond publicly.
The belief that the JCP is a secretive organization is widespread. I often hear it when I meet with Java developers. People sometimes tell me that they are unwilling to join the JCP or to participate in an Expert Group because if they did so they would be prohibited from discussing the group's work with anybody else. Not true! This belief probably originates with the language in the JSPA concerning confidentiality. At first reading this is indeed scary:
Confidential Information is defined as "information exchanged between You and Oracle, or among You, Oracle and other Members, during the term of this Agreement concerning the development of Output or other activities under the Process (defined below) that: (i) if disclosed in tangible form (which may include information made available over the Internet), is clearly labeled as confidential or proprietary at the time of disclosure; or (ii) if disclosed orally, is identified as confidential (or words of similar import) at the time of disclosure and is confirmed in a writing delivered to such receiving party within thirty (30) days after disclosure."
The JSPA later states that Confidential Information must not be disclosed prior to the spec's Public Review or for a period of three years if such information is not incorporated into the spec.
If you read this language closely, however, you'll see that it simply says that if information is classified as confidential then (and only then) must it be kept secret. In practice Expert Groups almost never do so. (During a recent Executive Committee meeting members were able to provide only one example - where an Expert Group had considered some business-sensitive market research in deciding what features to include in the specification.)
In order to discourage confidentiality restrictions we inserted the following words into last year's revision of the Process Document: "The use of JSPA Confidential materials (as defined in the JSPA) by Expert Groups limits transparency and is strongly discouraged." In the next revision of the JSPA we expect to prohibit confidentiality entirely.
A second misconception is that the Executive Committee meets secretly, and does not publish its proceedings for all to read. In fact, since September 2008 the full minutes and meeting materials have been public by default. (You can access them at jcp.org.) Admittedly, as it says on that page, "the EC reserved the right to go into Private Session from time to time when sensitive matters are discussed." However, we don't do this very often, and if you browse our meeting minutes and materials I think you'll agree that we are quite open and transparent. (For example the full minutes of the recent meeting in Bonn, during which the Apache/Field of Use dispute came to a head, are published there.)
Finally, it's often claimed that the work of Expert Groups is hidden from outsiders. While this is sometimes true it should be noted that about half of all currently active JSRs are being run as open-source projects, while others use public mailing lists, public issue-tracking mechanisms, and similar transparency techniques. Last year's Process Document changes introduced language to strongly encourage transparency, and also required Spec Leads to publish the transparency techniques that they use. Again, we expect to make transparency mandatory in the next revision of the Process Document.
I don't disagree that there is much about the organization we need to fix. However, it's disappointing when the progress we have made in recent years is not understood. Obviously we need to be even more transparent, and to tell people what we're doing. I hope that this blog entry is a start.