Improving the Java Specification Request Process

The JSR process is know to take a lot of time produce an actual specification. On top of that, it often produce overly complex specifications that are way too overkill to solve the problems they intend to solve. It is also a process that is driven by the main vendors desire with little thoughts for developers.

We could probably shorten the process and increase the usefulness of JSR by bringing a bit more agility in the process. Here is what I think we could do to make things a bit better :

1. Create the reference implementation first. Then produce the specification. A working implementation offer greater value than just having a specification. It allows the community to use it and comment on real life issue. This is way better than commenting on a theoretical document.
   Groovy is a good example of creating a reference implementation before a specification. Granted, it took a lot of time (lack of resource availability) to achieve, but in the end, we have a better Groovy than if we produced a specification first and then implemented it. Once a specification is voted, there is little coming back (beside repeating the complete JSR process). Voting on a working implementation mean voting on the real thing!
   
2. Make the sponsors of the JSR provide full time resources to work on the reference implementation. There is nothing worse than only having resources working part time on a JSR. Things go slower and communication suffer when the team members have other responsibilities.
3. Make the reference implementation Open Source from day 1. Make the code public as soon as basic functionality is built in. This allow the community to participate early and provide early comments.
4. Make all communication related to the JSR public from day 1. Public forum and/or mailing list increase the diffusion of the information. Issue/feature tracking should be readily available and every decision made on issues/features should be made public. Having public communication will again increase the community involvement and at the same time decrease the sentiment that the JSR driven by the vendors secret agenda.
   
5. Have the JSR team produce workable software at regular intervals (every months for example). These content of each iteration should be determined at the beginning of the iteration based on the issue/feature backlog. Each iteration should have a specific goal to make sure that the team focus on the right thing for the iteration.
6. If the JSR address something that is already available in an Open Source project, it should review the project and base it's work on it. If something exists there is no reason to start from scratch.

Doing all of this will ensure that at even if the JSR is voted off,the community will gain working software. It will then be its choice to use it or not. But I believe that with these kind of changes, most JSR, will either fail early (which is good as less time will be spent on it) or either succeed when they attain the voting stage (aka version 1.0).