Published on (
 See this if you're having trouble printing code examples

JXTA BOFs: Community and Implementation

by Raffi Krikorian

Leading a JXTA BoF on community at JavaOne, Juan Carlos Soto, playing the dual role of community manager and the group product manager, proudly displayed the statistics of Project JXTA, with over 50,000 downloads of the source and binaries, over 3,500 registered users on, 1,900-plus messages on the mailing list, and more than 15 active projects.

According to Soto, there is an active community that is "building a set of protocols that will stick and be used in the next generation of P2P applications." But as with any community, a governance system needs to be in place for situations when disputes need to be handled.

To address this, Soto flipped the display to show a slide containing the current project roles in the community:

Soto then opened the discussion up to the crowd, and immediately soomeone noted that the "organization seems highly code-centric." As JXTA is meant to be a protocol specification, where does protocol design fall into this setting? What space are pure designers meant to take up? Soto, along with members of the Java binding team, responded that there have been conversations to split off the protocols into a separate project away from the implementations and platforms.

Another question came up on the approval process for projects to appear on For a project to be hosted on, the project must first be approved by Soto and other people he may consult with. To date, no project has been rejected, but in at least one case he asked a proposed project to talk to a similar project that had already been approved, in the hopes they would combine their efforts. This was met with a flurry of different responses ranging from "Maybe we should just approve every project" to a proposal for a two- to three-day cooling-off period to be sure the proposer is still interested in the project.

Taking Apache as a model

Soto called upon Brian Behlendorf, president of the Apache Software Foundation, to explain how Apache manages their hosted projects. He responded that Apache usually hosts projects when two or three organizations are interested in that one project. Projects with only one interested party can host the project anywhere, but those with more than one usually need a neutral space. The group reached consensus that should maintain a directory for JXTA projects hosted elsewhere due to philosophical or licensing issues (currently, projects hosted on must comply with the Apache software license). This would allow many JXTA projects to get exposure even if they are not residing on the main web site.

Related articles:

Li Gong: JXTA All About Community

Learning the JXTA Shell

The JuxtaNet

JXTA Takes Its Position

JXTA Chat, Sans Server

JXTA Search: A look at the future of searching

Comment on this article
Post your comments


Get cracking on your JXTA code

Announcing the Project JXTA Developer Contest. Enter your hot JXTA code and win a pass to the O'Reilly P2P and Web Services Conference in Washington, D.C., this September, and a Yopy PDA. Deadline is July 15

Truelove called for some very clear rules about the structure and the bylaws for as well as a reiteration of Sun's involvement in JXTA, as it may not be clear for many of the JXTA members. "At the end of the day," he stated, "it is controlled by Sun entirely." JXTA is an "effort" by Sun, it is not its own legal entity. The audience definitely agreed with this statement, but one member did reiterate that Sun does need to maintain some technical control so JXTA does not go down the path of CORBA where the "community infuses every single idea it wants" instead of distilling core ideas, a process that caused major bloat.

The conversation soon wandered into the community voting process for JXTA with respect to resolving disputes and voting people onto the JXTA board. "The spirit of is to be a meritocracy," not a democracy, said Soto. According to Soto, the voting process, although it has not been fully determined, is intended to allow people with committer status and higher to vote. This mimics the Apache framework with the reasoning that those who are committing have the best idea of where the project is headed and are most vitally interested in the longevity of the project. Some of the audience dissented and wished for even contributors, or perhaps even observers, to have a vote in the process; this sentiment is mostly attributable to the fact that currently most project committers and owners work for Sun. Soto said that even the voting process will have to go through some discussion.

As the meeting came to a close, Soto asked what people thought needed to do to help out and the calls were unanimous for more documentation, a better tutorial project, and to factor out the mailing list (one that is carrying over 50 messages a day) into more specialized sub-lists. Soto apologized for the chaotic nature of the first meeting, and asked all to attend the virtual JXTA meeting that he will create later in the summer so that those that could not make it to JavaOne could still make their voices heard.


After a hour break, the community reconvened for a BoF entitled "Project JXTA: Implementations." Led by Bernard Traversat, the engineering manager of the JXTA Core, the session covered the basic architecture of JXTA from peer groups to services to pipes. Traversat also emphasized the need for a knowledge transfer from Sun to the community: "We are going to find out what parts we need to uncover for the community."

To demonstrate the porting effort to small devices, Mohamed Abdelaziz, an early Project JXTA developer at Sun, was asked to show off his Yopi Linux-based PDA running the JXTA shell. Using the experience he gained in getting a JXTA implementation on a small device, Abdelaziz expects to help out in the more formal J2ME and other mini-implementations.

"We pushed out a proof of concept in Java last month and we got into very long discussions on the alias," said Traversat with pleasure. From these discussions, Traversat pulled in a few members of the community to talk about what they are involved in.

Traversat had time to take one question from the audience before he had to close the session -- "What will make this as successful as Napster?" But he did not have a chance to respond, as another one from the audience piped up, "This technology is not supposed to be as successful as Napster, it is supposed to be as successful as TCP/IP."

Raffi Krikorian makes a career of hacking everything and anything. Professionally, he is the founding partner at Synthesis Studios: a technological design and consulting firm that orchestrates his disjointed train of thought.

Return to

Copyright © 2009 O'Reilly Media, Inc.