Participants Include:
Edward Burns - Consulting Member of the Technical Staff, Oracle
Patrick Curran - Director, JCP PMO, Oracle
Mike DeNicola - Director, Industry Relations, Fujitsu America, Inc.
Pete Muir - Principal Software Engineer, Red Hat, Inc.
Bruno Souza - Founder and Coordinator of SouJava in Brazil, one of the world's largest Java User Groups (JUGs)
Martijn Verburg - London Java Community

Edward Burns: I'm happy to report that as far back as 2004, JSF was doing some of the transparency things called for in JCP 2.8. But there is another benefit to moving to 2.8, and it is outside of anything in the 2.8 process itself. As transparency becomes the norm for JCP, more people will take advantage of it. I expect that the most important impact of changing to 2.8 will be the network effect created by all of the specs moving to it.

Mike DeNicola: I believe the requirement to make all EG communications publicly visible and to all the public to provide feedback that the EG must respond to, are the key items to increased transparency.

Bruno Souza: I think the biggest change will be in the Java SE JSR. In the past, this extremely important JSR was run with some level of secrecy, because it was the stage for a lot of (mostly positive!) disagreement about the future of the platform. With OpenJDK and more transparency on the JSR, the future of Java becomes a lot more participative.

Martijn Verburg: The mandatory change to Expert Group (EG) transparency was the big win here. That means all significant Expert Group business is to be carried out on public mailing lists, issues and comments are to be tracked through a publicly viewable issue-tracking mechanism, and EGs are required to respond publicly to all comments.

Edward Burns: I love it. Firstly, it validates everything we do as stewards of JCP specifications. The most concrete manifestation is the increased traffic on the public issue trackers for the specification and our implementation. Less concrete, but more perceptible to the public is having the ability to speak confidently at conferences knowing that everything we are doing is in the open. I don't have to censor myself to watch out for what is public and what is private, because it's all public. This also means I can throw urls up there and people can get started right away. Really, it's the best of both worlds, we have the approachability of an open source project with the dependability and backward compatibility guarantees of an industry standard.

Pete Muir: I think that we were running the CDI EG in a pretty transparent and open way already - we essentially modeled the process on an open source project. There actually weren't many changes we had to make to run the CDI EG for the JSR transparency changes, which for me validated the fact that the transparency changes were definitely on the right track. It's great to have the transparent open approach validated!

Of course, it's also helped that other EGs are becoming more transparent, this allows much better and more efficient communication between EGs, and allows a CDI EG member who has a cross-over interest to directly approach the other EG.

Bruno Souza: The two main benefits are that now transparency is mandatory, and developers now know it is mandatory. So, it is a lot easier to go after information, and to actually get answers. It is even easier for the Spec Lead, who now does not need to justify that things should be done in the clear.

Martijn Verburg" A *lot* more feedback from the developer community and not just flippant, negative feedback, but genuinely useful "I tried the RI out and I think X, Y and Z need some tweaking" type feedback. This means that Specs, RIs and TCKs are all being changed for the better, earlier than before.

Edward Burns: I would like to see more traffic on the "users" list, which anyone can browse and subscribe to. As with all JSRs for which Oracle is the steward, this list is a mirror of the actual Expert/Volunteer Group mailing list, but with the additional capability that anyone can read and write to it. Mails sent to this list stay just at that list and *do not* go to the actual Expert/Volunteer Group list. This strikes a balance between JCP members right to IP protection, and the public's right to transparency.

Mike DeNicola: The public can now raise concerns/questions to the EGs throughout the JSR process without having to wait for either the next JSR milestone or ballot.

Pete Muir: The absolutely critical thing is to increase community participation in EGs. These are the guys who are the early adopters of our technology, and can provide excellent feedback about whether we are going the right way or not. But, these guys are busy - and it's our job (spec leads and JCP) to make it trivial for them to participate.

Bruno Souza: Immediately what looks more transparent is the desire of a lot of people to not make things transparent. On the other hand, it made clear that this desire seldom comes from the EG or Spec Lead, but is usually old ways of seeing the world as managers and lawyers.

Martijn Verburg: Assumptions. Assumptions have to be made by Spec Leads and Expert Groups, but these assumptions weren't always as rigorously examined as they could be (due to time and resource constraints). This is now starting to change.

Edward Burns: The so-called "ivory tower" of spec design has been toppled, or at least is toppleable. I really hope that this transparency inspires others to file JSRs or at least participate in them.

Mike DeNicola: Because of the requirement to make EG membership decisions public, we no longer hear complaints that a JCP Member has been excluded from an EG because of his company or the fact that he/she has different technical opinions regarding the JSR from the Spec Lead.

Martijn Verburg: Less smoke-filled room type decisions are being made. Some JSRs that were poorly thought out or were thinly veiled wrappers around a vendor product are now exposed early and rejected with some velocity.

Edward Burns: This blog is great because it lets me devote more energy to working on the spec with the Volunteer/Expert Group, while resting assured that there is at least *some* level of digestification going on that explains the changes to the public. We've tried to designate a role in the Volunteer/Expert Group that is responsible for producing such digestified reports but no one has been able to maintain it diligently enough to be worthwhile.

Mike DeNicola: EG work was required to be "Confidential" prior to 2.8 by earlier versions of the JCP. (We are now addressing the JSPA aspect of this in JSR 358.) JCP 2.8 encourages Open Source for the RI and TCK.

Martijn Verburg: Heck, I hadn't even seen that blog post - it's brilliant! As readers can tell by the in depth analysis that Arjan made, that s/he had to have full access to the Spec, RI, TCK including all of the source code. This wasn't always mandated in the past.

The fact the readers can go directly from the blog post and comment on issues/features either in the issue tracker or on the mailing list is already a great start. In addition since they can download the source code and the binary and try it out means that the API/RI and TCK will be developer friendly, have less bugs and support the features that developers really want.

You only have to look at the trackbacks and comments to see the extra participation it caused.

Edward Burns: Personally, I don't see any benefit in my case, but that is no reason to conclude others will not see a benefit. I think that is more a function of the volunteer nature of the entire present day JCP. While it is true that Corporate Members are the backbone of JCP, every single one of those corporate members has a "day job", such that every minute they spend working on a JSR is a minute they are not spending on that day job. In this sense, JSR members really are volunteers, even if they are getting paid to be on the JSR. As for individual members of the JSR, they are true volunteers. If they happen to be getting paid as a result of the JSR it is because they are working with it in a product they produce or working on consulting gigs that use the product of the JSR.

Mike DeNicola: JCP 2.8 mandates an expedited timeline for JSR work. If these milestones are not met, the PMO can initiate a JSR Renewal Ballot.

Martijn Verburg: I think the speed to market is unchanged (for now), but a higher quality spec is produced. We're hopeful that with increased community participation that time to market will improve as well.

Edward Burns: I'm a big fan of free markets and enlightened self interest. Every person from the community who contributes to our JSR, or to any JSR, is doing so because they see a benefit to themselves. I like to take Adam Bien and Jacob Hookom as examples. Both of these individuals were able to leverage their participation and contribution in JSRs to advance their career goals. Without the potential for benefit, there is no reason to participate. My challenge as Spec Lead is to not do anything to spoil that goodwill and intention.

I look to Proverbs 15:22 for inspiration: "Plans fail when there is no counsel, but they succeed when counselors are many."

As with all such truisms, though, there is much more to it. In this case, it's especially important to avoid the well-known perils of "design-by-committee." Looking at JSF over its lifetime, I'm aware there is some of that in there. It's a balancing act.

Mike DeNicola: Now that the community knows what is going on, it can provide feedback and, as importantly, its feedback cannot be ignored by the EG, must be responded to. Also, it is now easier to become a member of the EG.

Martijn Verburg: Community participation is now effectively unbounded. Already global programs like the Java User Group Adopt-a-JSR are taking place and the amount of traffic on the JSR mailing lists and issue trackers has certainly increased.

It's changed the JCP itself - more members are signing up, the elections are hotly contended.

Mike DeNicola: There have not been any unintended consequences of the new EC rules. Several EC have lost their seats because of the rules and some others have participated in EC meetings just to avoid either losing their vote or losing their seat. Overall, the active EC Members are very pleased with these changes. They no longer have to rehash items covered in earlier meetings in order to bring errant Members up-to-date on matters being discussed. This allows things to move along at a much brisker pace.

Bruno Souza: It made participation easier, and this should help increase participation from developers. It clearly made the work of JUGs a lot easier.

Martijn Verburg: The JCP has gained more credibility. Policing oneself with no exceptions sends a strong message to the Java community. Only those who are willing to put the effort in are welcome to have a seat at the table.

Mike DeNicola: A JSR becomes "inactive" when it misses the time-out deadlines for JSR development - publishing an Early Draft, a Public Draft, and a Final Draft. The PMO can declare a JSR "Dormant" if it determines that the JSR no longer has a Spec Lead or a Maintenance Lead and "no further development is anticipated." The time-out deadlines for a JSR have shortened the JSR publishing times and kept JSRs more timely. The Dormant declaration has allowed the PMO to remove dozens of old JSRs that were just sitting there with nothing happening.

Bruno Souza: We're purging JSRs that the Spec Lead and EG really don't care for anymore. It is a needed thing. Sometimes a JSR will lose its timing, its momentum, and even its reason to exist - because of market changes or lack of interest. Being able to take those JSRs out of the way is important, without having a huge effect on the process or on the technology.

Martijn Verburg: Quoting directly from the JCP Process Document 2.9:

Dormant Specification: A Specification that the PMO has determined has no assigned Specification Lead or Maintenance Lead, or that is not being actively developed and on which no further development is anticipated.

Inactive JSR: JSRs that have both not posted a Final Release and have not posted a JCP milestone draft for the last 12 months.

The rules governing this (paraphrased from the same resource): If a JSR does not begin Early Draft Review within 9 months of completing its JSR Approval Ballot, or does not begin Public Review within 12 months of first submitting an Early Draft, or does not reach Final Release within 12 months of commencing Public Review, then the EC should initiate a JSR Renewal Ballot - in other words this JSR is dormant/inactive.

Mike DeNicola: A smaller EC should be more efficient. There are few Boards of Directors that number 32. A smaller EC makes each seat more valuable, because it is harder to become a member of the EC. A smaller EC increases the number of EC Member companies that can host an EC meeting; finding space for a meeting of 35-40 people is extremely difficult.

In addition to the above comments, reducing the size of the EC eliminates the problem of not having quorum at a meeting - something that happened often for the ME EC. This allows decisions to be made at every meeting and it also allows the EC do conduct its business more efficiently because the EC no longer has to rehash items covered in earlier meetings in order to bring errant Members up-to-date on matters being discussed.

The merger of the two ECs into one has already begun with the 2012 EC Elections -- the two ECs meet as one twenty four member EC. All JSR ballots are now being voted on by the one EC. In 2013, three Ratified Seats and two Elected Seats will be eliminated, resulting in an EC size of up to 25 seats. Since there are currently several open EC seats, it is not expected that anyone will lose their seats due to the reduction in EC size. Based on the 2013 election results, the 50% receiving the most votes (Ratified and Elected) will hold their terms for two years, the others will serve one-year terms and have to run again in 2014. Starting in 2014, all terms will become two years.

Bruno Souza: We're trying to come back to a manageable size for the EC, and breaking a fake wall that divided Java ME from the rest of the platform. As far as I can remember, the separate ECs met together and discussed things as one, but the votes were conducted separately. EC Merge solves that discrepancy.

There is a risk that with that the device-interested companies will have less space in the JCP, but I think this is a manageable risk, that the ratified seats can easily help keep the right balance.

Martijn Verburg: A smaller more focused committee will move faster - this is a good thing!

The problem that needed to be solved was two-fold. There was a growing recognition that Java is one platform from Micro Edition to Enterprise Edition. With Java ME being re-baselined off a version of Java 7 SE, this was even more apparent. A second issue was that simply the Java ME Executive Committee did not have a great attendance or participation record and was effectively not a functioning body.

The merger has been taking place through the natural elimination of seats due to poor attendance, some duplicate seats and the annual elections. As it's happened to work out, no one has been forced out due to the natural attrition.

This year all seats will be up for voting to make a fresh start.

Edward Burns: I'm seeing small benefits, but I expect if we stay the course we'll see more, and in more place.

Pete Muir: Cautiously optimistic ;-)



Back to JCP.next: Where Are We and How Are We Doing?