I'm looking at the JCP 2.8 and I am encouraged by what I'm reading. For instance, in "Changes for Specification and Maintenance Leads" it states "You are responsible to provide a public communication channel for posting and archiving all Expert Group nominations and your deliberations on them (1.2.1), all Expert Group communications (1.1.1), and all Expert Group documents (1.1.1)." and too "You are responsible to provide and maintain an Issue Tracker visible to the public and a mechanism for the public to log issues in that tracker (1.1.2). ". My favorite is "The Specification license you provide at JSR Proposal may not change (1.1.3). ".
That stated, I am let down that I see no reference to compatibility kits and any requirements upon their openness. Does anyone have more information on this? To me, this is one big thing which caused rifts in the Java community. Too, I feel there should be something in the JCP about JSRs openness as well. How open and freely usable the specifications are determines how they will be used for innovation to move the Java ecosystem forward.
In my opinion, there should at a minimum be a statement that the Java Community Process favors more open and free JSRs. That doesn't mean implementations, except for the reference implementation, need to be free. The reference implementation should always be free, and if not in the JCP, that needs to be added. The reason for such a requirement should be obvious, but how does one create a specification known to work without an actual proof of concept? Experience tells me if one does it will be mostly flawed, and to have the right to create a specification and market it through the JCP process, one should have to prove it.
It may be the concerns I raise have already been addressed, and I just do not see them. If so, that's awesome, and thank you to anyone who points them out. If not, then I believe there is still more to do before the JCP can live up to its potential. Here's to hoping it does!
No comments:
Post a Comment