JXTA BOFs: Community and Implementationby 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 jxta.org, 1,900-plus messages on the email@example.com 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 jxta.org community:
- observers: those who download code and demos (may or may not be a registered users at jxta.org)
- contributors: members registered at jxta.org who can submit issues into the database for given projects
- committers: members who can submit changes directly into CVS
- projects owners: members who own projects and have the overriding authority on their given projects
- board members: the ultimate authority within jxta.org and the only roles that are achieved via a proposed formal nomination and voting process.
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 jxta.org. For a project to be hosted on jxta.org, 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 jxta.org should maintain a directory for JXTA projects hosted elsewhere due to philosophical or licensing issues (currently, projects hosted on jxta.org 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.
Get cracking on your JXTA code
Announcing the OpenP2P.com 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 jxta.org 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 jxta.org 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 jxta.org 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.
- Nelson Minar, formerly CTO of Popular Power, spoke briefly on adding proper debugging to the current JXTA Java binding so as to better allow developers to track what is occurring in the core. He also briefly mentioned a side project of adding synchronous method calls to the asynchronous core to allow better association between query and response messages.
- Mike Duigou, a project owner of the Java JXTA core, stood up to talk about his work in shortening the current IDs being used by the system. The many consecutive 0s in IDs may be easily truncated using some sort of shorthand. Also, he quickly spoke about his work in moving the ID from a URI to a URN.
- The author of this article, Raffi Krikorian, outlined the plans for adding expiration dates to JXTA advertisements so platforms may have a recommended time at which to stop caching and propagating those documents. He then mentioned a related project to allow the core caches to share information about the ages of documents so those even without timestamps may be expired properly.
- Jeff Schneider, the founder of Resilient Edge, talked about his plans to allow "back coupling" of peers to web services to create sets of "peer services." Unlike the others, Schneider mentioned plans to have formal procedures in identifying and creating his planned addition -- a network service model for JXTA.
- Ziad El Kurjie, director of engineering at Clip2, spoke of Clip2's current work in enhancing the ability to administer rendezvous, the "glue" of the JXTA network. "I thought that I wanted to run the rendezvous as a daemon process," El Kurjie mentioned, so Clip2 has started a project to let this happen.
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 OpenP2P.com.