Why I think the EC is wrong about JSR 357 and innovation

As of yesterday the newly proposed JSR 357 (Social Media API) was declined by the JCP Executive Committee for SE/EE. With eight clear "NO" votes, two abstain, five "YES" and one not voted member this is a clear result.

If you are examining the voting comments, you see two obvious reasons for this to happen. One is the scope of the proposed JSR which "is far too wide" (IBM) and the second is "it's a bit too early to start standardizing on social" (Twitter). While the first has some additional aspects around having to specify relevant domain objects (which is very similar to what the Java Identity API, JSR 351 will have to solve) the second one is surprising.

When should Standardization happen?
Have you ever thought about standardization? When exactly should it happen? And why? First of all you have to look into what standards provide. For a German like me it feels normal to look at what German DIN institute has to say about this:

"Standardization is a strategic instrument for economic success. By becoming involved in standards work, businesses can gain a competitive lead through timely access to information and knowledge. They can use this to their own advantage, reducing the risks and costs involved in R & D as well as greatly reducing transaction costs."
(Source: din.de)

Further on the relation to the field of innovation is expressed as follows:

"Standards serve as a knowledge base and catalyst for innovation. [...] Standards help researchers in various ways: They lay down terminology in new technological areas, set quality and safety norms at an early stage of development, and introduce the necessary standardized, compatible interfaces. [...] Carrying out standardization at an early phase of development helps establish high tech innovations on the market."
(Source: din.de)

This expresses what I have seen in the wild a lot. Take a look at what happened with HTML, WebSockets or NoSQL. Or compare some open source projects. If you start putting a lot effort into something you have a high interest in spreading the word. Even if it only is a small spin off and you don't have too much common sense you start putting your thoughts and code into a sandbox or at least a wiki. To me standardization is the key to innovation because it simply is a short term which means nothing else than "put all players at a table together".

Documenting the status quo?
This is exactly the opposite of what the EC members had to say about the JSR 357. Reading through the lengthy comment section gives you the impression, that there should be standards if some kind of solution is mature enough to be used by a majority already. In other words: We wait for the unofficial reference implementation which drove enough companies into a vendor-lock-in situation (closed- or open-source) and start standardizing afterwards. If you followed the JCP long enough you might have seen this before. Doesn't it sound like Seam 2/Spring for CDI or Guice for JSR 330? I for myself am not sure if this is the right way to go with the JCP in general. If it is common sense to only adopt what is already out there the JCP will fall behind recent developments and trends even faster than it already did in the past. And it always will follow some kind of documenting the status quo approach. Is that, why we need all the "big names" in the JCP? Because having them agreeing to a standards guarantees for their adoption? I don't think it was meant that way.
I would love to call on the EC members to accept their commitment for developing the Java ecosystem and take this more seriously in the future.

Other Aspects
Let's finish this little angry excursion with the still open issues with 357. Yes. It finally is too broadly scoped. The spec leads have accepted this before and addressed it with a direct communication with the EC members.

"... the scope of the JSR primarily is Connecting to Social Media Services and Providers, so similar to the first JSON JSR one could see it as Java Social Media Client API"
(Source: Goldman Sachs & Co voting comments, jcp.org)

This obviously should have been more clear upfront and the spec leads and the designated EG should have taken some action to address those issues earlier.
Further on it might be a bit risky to rely on things that don't exist yet in the standard. Namely REST client API and JSON processing. But this shouldn't have been a major issue and it happened before to other JSRs.

Bottom Line
It was obviously too early for this JSR. At least for the JCP as it is today. And it showed very clearly what it takes to successfully pass a review ballot. You need a hell lot of support among the EC to move stuff forward. As of today the combination of simply technical voting members like the LJC and the political voting members like SAP and IBM leads to a very easy and fast rejection of a JSR. Maybe it would be a good idea to think about different review ballots for technical and business impacts and define different constraints on JSRs if they are rejected by one or the other ballot. A JSR which was rejected by a business ballot could still be formed and have an active EG which could start developing on it's standard. All under the wings of the JCP. This is exactly what it should be to me. A community process. Not a documentation tool.