Is "open from the start" the right way to develop a JSR?

So how should a JSR work anyways? More and more, this is becoming a hot topic for everyday Java developers, who want their concerns and desires incorporated early in the process, not late in the game when the final draft is being routinely approved, or after the fact. As the ideas for JDK 7 come together, we've already seen vigorous debate about proposed concepts like closures, properties, a module system, type inference (which we'll get back to in a minute), and more. For some, it may be "buyer's remorse" over generics, a feature still somewhat controversial two versions after its release, and the better part of a decade after its initial proposal. Whatever the reason, more and more developers are learning to get involved early.

And maybe that's part of the reason we're also seeing a questioning of how a JSR expert group carries out its work. We ran a blog several months back -- sorry, I can't find the link right now -- that decried the model of an expert group doing both its original research into a problem domain, in private, and then proposing a Java standard for it, all in the scope of one JSR. Would bad JSR's have been headed off sooner if there had been more public visibility into the expert groups' work earlier, while they were working the problem and before the early draft review? Should the experimentation in a field precede even the filing of a JSR and the assembly of an expert group?

One of the goals of JSR 306 is to "further improve the transparency of the process". Its original request has this to say on the topic:

Since the introduction of JCP 2.5 in October 2002 which regulated the right to build independent implementations, the Java community at large has grown accustomed not only to open source software methodologies and business models but on average expects that specification development happens in a similar spirit. The JSR plans to explore what steps can be taken, both mandatory through the process document, as well as voluntary or desired behavior through the Spec Lead Guide and facilities provided by the JCP.org web site.

Some JSR's are already being developed in this spirit, and some of them are doing their pre-spec experimentation and implementation work here on java.net. Two examples are the Beans Binding project (JSR 295) and the Swing Application Framework (JSR 296). Patrick Wright praises both in asking the JavaLobby audience Should JSRs be developed in the open?

In my experience, many JSRs are developed in secret, by which I mean the expert group does not allow outsiders to follow either the work in progress (code or APIs, if there are any), active discussions or records of discussions. The JCP, to my knowledge, does not require opening up the process, but seeing the high-quality feedback on JSR 296 (and how well Hans fields and incorporates it), I'm tempted to say that the default should be to require open access to mailing lists and code, even if read-only.

He also notes the downside of the traditional, closed approach:

I think one of the biggest downsides of having a closed, opaque and private process is that those of us who end up as users of the specification lose sight of the reasons why it ended up the way it did. There are reasons why generics were implemented using erasure; IMO, those reasons are something any educated user of Java generics needs to understand before entering into debate about them. Making the discussion behind those decisions public enables us to understand, or as necessary research, the reasons why we have what we have. It informs and deepens the debate.

But is this really a good idea? If you're an expert in some topic area, do you really want that many eyes on your work, that many people offering opinions (of varying levels of competence), when you need to focus on delivering a solid JSR draft? There are two sides to this story; will the kind of open process being used by JSR 295 and 296 groups work for everyone?