These are the final results of the JSR Review Ballot for JSR #357. The Executive Committee for SE/EE has not approved this ballot.
JSR357
StageJSR Review Ballot
Ballot durationMar 6, 2012 to Mar 19, 2012
Votes

SE/EE

Azul Systems, Inc.
Credit Suisse
Eclipse Foundation, Inc
Ericsson AB
Fujitsu Limited
Goldman Sachs & Co.
Google Inc.
Hewlett-Packard
IBM
Intel Corp.
London Java Community
Oracle
Red Hat
SAP SE
SouJava
Twitter, Inc.
Vote Log

SE/EE

On 2012-03-16 SAP SE voted No with the following comment:
After careful consideration, SAP has come to the conclusion that JSR 357, in its current form, should not proceed.  Our rationale is that the scope, as stated, is too broad and imprecise to establish an Expert Group that could efficiently produce a specification which would be generally useful to the Java Community.  
------------------------------------------------------------------------------
On 2012-03-19 Credit Suisse voted Yes with the following comment:
As Credit Suisse represents the customers point of view in the Executive Committee, we are interested in converging the various industry standards (Open Social and others) and pushing the standardization for Social Network Technologies also from the JCP. We are concerned about two points: the broad scope mentioned in the request and security. Consequently, we suggest that security implications of the features of the API have to be clearly investigated and appropriate guidelines to securely use and implement the API have to be given.
------------------------------------------------------------------------------
On 2012-03-19 Hewlett-Packard voted No with the following comment:
HP agrees with the comments from other EC members regarding the overly broad scope of this JSR.  We also believe this JSR should be voted on by both ECs, if it is to begin work at this time.  We understand the ECs will merge later this year, but that will be around the time of public review based on the schedule in the JSR.
------------------------------------------------------------------------------
On 2012-03-19 Twitter, Inc. voted Abstain with the following comment:
While we were initially excited about this proposal, we think it's a bit too early to start standardizing on social and encourage folks to look at third party libraries for support to connect to the myriad of social networks available.
------------------------------------------------------------------------------
On 2012-03-19 Goldman Sachs & Co. voted Yes with the following comment:
We believe that Social Network technology space will benefit from standardization of API's as it will provide greater opportunity for competition,   especially in the client space. That said, we agree with many members that the scope of the initial JSR is very broad and a more narrow scoping is likely to lead to success.

The Spec leads did address this in a communication to the EC with a comment below.  

'... 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"' 

With that restriction, we are inclined to support this JSR at this stage and will revise our opinion as the JSR progresses. We urge the JSR WG and Spec Leads to consider Security and Identity related JSR's within the context of this work.
------------------------------------------------------------------------------
On 2012-03-19 Eclipse Foundation, Inc voted No with the following comment:
The Eclipse Foundation is a firm believer that technology should be standardized only after sufficient experimentation and implementation has happened in the industry. Social media is still quite new, and we tend to agree with those others who have stated that it is too early to begin a standardization process for it.
------------------------------------------------------------------------------
On 2012-03-19 Fujitsu Limited voted Abstain with the following comment:
Fujitsu agrees with comments from other EC members.

------------------------------------------------------------------------------
On 2012-03-19 Oracle voted Yes with the following comment:
Like others, we also have concerns regarding the rapidly changing social media environment, but have decided to withhold judgement for now and reexamine this issue at the next state of the JSR
------------------------------------------------------------------------------
On 2012-03-19 Azul Systems, Inc. voted No with the following comment:
Azul agrees with comments by other EC members concerning the broad scope of the JSR proposal. We think that much of what the JSR is trying to model should be solidified outside of the JCP and JSR process, and in wider-reaching bodies that would also be concerned with non-Java-platform aspects. We agree with IBM's note about the space having many still-moving parts, and support LJC's suggestion that a smaller scope JSR would be more appropriate, assuming that such a JSR would focus on specific, semi-stable, and well understood aspects of the Social Media space. 
------------------------------------------------------------------------------
On 2012-03-19 Google Inc. voted No with the following comment:
Google has little to add to what has already been said by the others who are concerned about the scope and direction of this JSR.
------------------------------------------------------------------------------
On 2012-03-06 IBM voted No with the following comment:
IBM has looked carefully at the JSR 357 proposal, and believes the scope of the proposed JSR is far too wide to result in a workable specification that could be broadly adopted by the Java community.  At present, the environment around social media programming models is characterized by very rapid evolution in open standards communities like the OpenSocial Foundation, and open source communities such as Apache Shindig, Abdera2 and Rave. JSR 357 would attempt to place an overarching API structure onto a set of those moving parts.  IBM believes it is too early in the life cycle of the social media environment to put a JSR 357 Java API into the marketplace which would - at best - cause confusion and potentially impede the development of the current broad based work being done.  IBM believes the correct approach is to allow the marketplace to coalesce around the evolving social media models, and as they mature, provide robust Java APIs bindings to provide the Java community with useful "on-ramps" to social applications that provide value to our customers.  When the time is right, and the Java community's understanding of Social Media APIs for our customers is more mature, a set of more specific JSR proposals, each addressing a specific area of customer need in Social Media APIs, is the approach IBM would like to see develop.

IBM's vote is based on the technical merits of this JSR and is not a vote on the licensing terms.  IBM supports licensing models that create an open and level playing field by allowing third parties to create independent implementations of Java Specifications and that do not allow individuals or companies to exercise unnecessary control for proprietary advantage.  We support open source as a licensing model for contributions in the JCP, and would hope others will support this direction. This comment is not necessarily directed at the current business or license terms for this JSR, however, it is a statement of IBM's preferred licensing model.
------------------------------------------------------------------------------
On 2012-03-19 SouJava voted Yes with the following comment:
SouJava understands the concerns raised by other EC members. We also understand that the spec lead is sensible to those issues, and has offered more detailed information during the past few days. We urge the spec lead to take actions to address the issues raised, so this JSR can succeed. That said, we also believe that there is enough experimentation in the market in the projects presented in the JSR, and that it is possible to create a specification that is specific enough to deal with the issues raised, and broad enough to be valuable for the Java community. We also note that engagement from developers of existing projects is fundamental to bring the current knowledge in social-media-integration APIs to this JSR, and we would like to see strong efforts done by the spec lead in this regard. With these comments, we vote to move forward with this JSR.
------------------------------------------------------------------------------
On 2012-03-09 Red Hat voted Yes with no comment.
------------------------------------------------------------------------------
On 2012-03-16 London Java Community voted No with the following comment:
Whilst the LJC applauds the efforts to build a consensus around the social media space, we feel that this proposal has significant shortcomings and as such, we are unable to support it at this time. The key problem that we see is that the API contains a high degree of domain modelling which is too inflexible to easily accommodate the evolving space. The lack of focus on mobile is also a significant drawback - in 2012, social media is increasingly being driven by mobile applications - it makes no sense to have a social JSR which is not co-ordinated with the ME standards process. The LJC would welcome the withdrawal of this proposal, and its replacement with smaller JSRs which target specific parts of this space instead. 
------------------------------------------------------------------------------
On 2012-03-19 Ericsson AB voted No with the following comment:
We agree with the concerns raised by other EC members.
------------------------------------------------------------------------------