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

Markus Eisele
4
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.

Post a Comment

4Comments

  1. I think the JCP has worked pretty well in this case. I do agree that it is too early to standardize on Social. Also I don't think it is necessary to standardize everything. There are Open Source libraries around - what is wrong with using them? The tow citations are also valid for such Open Source projects - you can get involved and you get a foundation to build upon.

    I clearly prefer a clear "No" and no standard over a crappy standard.

    ReplyDelete
    Replies
    1. Thanks for your comment Eberhard!

      Delete
    2. This opinion isn't too surprising from the former SpringSource spokesperson for Germany who still seems to prefer Spring over e.g. CDI. One is a widely accepted, Pseudo-standard, the other one a Java standard based on at least 2 JSRs. If a majority of JCP Members think, it's better to prefer Pseudo-standards over JCP Standards, the JCP as such may become less relevant, but given all I heard from leading SpringSource colleagues that is pretty much what at least vmware also prefers.

      Delete
  2. Woow thats a nice article on the JSR debate :) Hail Markus.

    I see JCP is a nice platform for ideas.. ideas which needs to come true we all need to work with it. if you feel a idea (JSR) is good give opportunity to get it come up, in this time make it grow better and in the end see how far it can help and then decide do the idea come up what we expect. Its not just EG members its the community work.

    I feel that Social Media is growing very rapidly, i know its early but as Markus pointing about HTML, Cloud etc. What the problem of trying it and see how it comes ?

    ReplyDelete
Post a Comment