A "Fragmentation Program Office"?
The MEDD conference was exactly what I thought it would be: learning about cool stuff (SunSPOTS!), meeting old friends and making new ones. And it turned out that one topic stood out above the rest - confronting fragmentation in the mobile space.
Looking at the lightning talk feedback we find the most highly rated lightning talk was possibly Terrence Barr's "Do We Need a Mobile Developer Alliance"? Were the ratings also votes for making such an alliance a reality?
The direction of the last sessions of both days suggests that the answer is "yes". The technical session feedback shows that among the highest rated sessions were the panel on "Developing and Deploying Content in the Real World", and the "Fish Bowl" on the last day, both of which dove into the topic of fragmentation and never left it.
Undoubtedly, the current java.net poll was inspired by this theme. As of this writing, by far, voters believe that the two greatest sources of fragmentation relief are the manufacturers, and Sun. Why aren't operators, who could team together to coordinate signing and certification requirements, considered a group that can solve this major point of fragmentation?
One answer lies in the Fish Bowl conversation. One developer spoke about how fragmentation was really a problem, but what was really killing him was all the signing and certification hurdles they had to face. In other words, we have different perceptions as to what constitutes fragmentation and what doesn't.
The point is that it is really hard to discuss fragmentation when we don't even have a common language to describe it or can agree on its scope.
This came up again in an open discussion on fragmentation at Sun's offices on Friday. (More to come on that once the meeting notes are written up.) One of the participants mentioned that their company actually had a comprehensive glossary of fragmentation-related terms, but nobody else in the meeting was aware of it.
Even the discussion of fragmentation is fragmented, with major corporations in this space aware of it, but discussing it, raising it as an issue, or actively pursuing programs to address it in relative isolation. Some of that work has been effective (such as JSR-248, in pulling together many JSRs under one umbrella), but other work has been duplicative or has not happened at all. It is kind of like building a wheel with a some good spokes, some broken spokes, some missing spokes, and no hub.
Part of the reason that industry collaboration does not exist in many areas is that when people do want to collaborate with their competitors to solve a joint problem, their managers only hear the word "competitor" and big caution flags come out.
There are many aspects of fragmentation that need to be addressed, and it will require work by ALL of the parties listed in the java.net poll. There are several crucial things that must happen for this to occur:
- A common definition and understanding of the problem must occur (hub)
- The problem needs to be divided into pieces that can be easily described (spokes)
- Environments that bring competitors together to address each piece need to be created (spokes)
- Coordination must occur to avoid duplication and enable communication between groups tackling different areas of the problem (hub), yet
- There must be enough freedom for ad-hoc groups that have the support of the community to run with whatever part of the problem they want to (spokes)
I have considered the JCP to be a good place to center a "Fragmentation Program Office" to lead? manage? keep track of? launch? different fragmentation reduction efforts. But judging from the response to the java.net survey and the apparent call for a Developer Alliance at the MEDD conference, a hub for defragmentation activity could spring from anywhere the community will accept it to be.