Update on the Jini developer community
Jini technology is an experiment in cooperative distributed computing. It is meant to destroy the idea of a monolithic application and enable the delivery of distributed services to clients everywhere on the network.
For the technology to succeed, it needs a strong developer community. A strong community can give Jini technology the critical mass it needs to establish ubiquity while accelerating the development of innovative Jini services. Just as Jini’s core strength lies in spontaneous assembly of distributed networks of clients and services, Sun hopes a core strength of the Jini community will be similar self-assembly around mutually beneficial development projects.
The Jini technology development community
Under the process being jointly defined by community members, interested developers can join discussions, review and exchange source code, and become involved in working groups by registering on the Jini Community Web site (see Resources). In order to register, you must agree to the terms of the Sun Community Source License (SCSL), which is used to protect secured areas of the community site. This protection is put in place so that community members can be free to share their innovations in a nonthreatening forum while also ensuring the value to the community of the Jini trademark is preserved.
Note that when you “click through” the license on the Jini Web site, you’re asked whether you represent yourself or your company. If you accept on behalf of your company, all other employees of your company are subject to the license terms and conditions you agree to. Make sure to read through the license carefully and check with management if you have any doubt about whether you’re qualified to act on behalf of the company.
To empower the community and enable rapid growth and acceptance of Jini, Sun is making core Jini technology, including the source code for Sun’s implementation, available for download from the community site. The SCSL is an amalgam of open source principles and for-profit licensing models of the past. It has been crafted in the spirit of openness avowed in Eric Raymond’s now-famous article, “The Cathedral and the Bazaar” (see Resources for the URL for this article as well as related open source resources).
Support for the Jini community
In order to help developers better understand the nascent Jini community, its processes and procedures, and the SCSL license and its implications, Sun hosted a Jini community birds-of-feather (BOF) session at JavaOne. Prominent jini-user mailing list members and Sun representatives Ken Arnold and Jimmy Torres outlined Sun’s notions of how the community might structure and run itself, then answered questions from attendees.
Arnold explained that the supporting framework for the Jini community is comprised of:
- SCSL for Jini
- Jini community process being developed by community members
- jini.org Web site
- Jini development team at Sun, acting as “shepherds” for new projects and working groups
- Jini trademark and logo
What, you might ask, is meant by defining the Jini development team as shepherds? The idea is that Sun wants to help Jini projects run by other members of the community, for instance the printer working group organized by a number of prominent printer manufacturers. Sun provides assistance by having one or more experts on the Jini technology assist the working group with any Jini technology-specific questions they might have. This allows the working group to focus on domain-specific issues (in this example, the details of distributed printing) which they and their companies know much better than does Sun. In the end, shepherds are meant to foster the rapid development of sets of standard interfaces for various network services (like printing, storage, etc.) that the entire community can agree upon and from which everyone can benefit.
Example of a Jini project lifecycle
There are three basic models under which community members can choose to run Jini development projects within the community.
You may
- Share the project with all members, using freely available Web space on the jini.org site. The project is jointly developed with other interested members of the Jini development community as a public project. Code is protected by the SCSL and site login, but developed interfaces are returned to the community. Vendors can build their own commercial implementations if they so choose.
- Develop the project without community input, but publish the design and code after completion for others to use. Sometimes referred to as cut and run, this model allows a community member to contribute something that he developed on his own but believes might be more generally applicable. The developer has the option to contribute only the design and interfaces without implementation.
- Build a Jini-based project completely internal to one’s own organization, not sharing the design or code with the community. Sometimes called the microcosm approach. If the project is shared with any other Jini community member organization, however, it must be shared with all others as per the SCSL.
Assuming a project is developed under the first model, publicly codeveloped with all interested members, the lifecycle might be something like this:
- Initially, a small group develops early codebase. This may be developed within a private jini.org area, hidden for the initial 60 days from community-wide view by the infancy provision available for new projects.
-
Group posts the alpha design to the licensee-protected Jini community site. Code is protected by SCSL license, or by another licensing mechanism if the group so chooses.
- Group solicits feedback and new developers, then iterates on the design-release cycle.
- Release candidate is tested for compatibility using the Jini testing kit. This ensures interoperability with the Jini core technology, and thus protects the value of the Jini brand for all community members. The kit currently tests Jini services only, but the next release will also include client and lookup service tests as well.
- Project is released publicly for all to use. If individual community members want to market their particular implementations, they may do so.
The Jini licensing model is deliberately more liberal than the Java SCSL licensing model. If a Java licensee breaks compatibility with core technologies (the Java Virtual Machine specification, for instance), interoperability is destroyed for all other licensees in a fundamental, damaging way. If a Jini licensee specifies a poorly designed interface, however, this will not directly injure other community members: The market will simply not use the interface and that licensee will suffer the consequences alone. So, the Jini development model encourages good, cooperative design that works well with other Jini services and clients.
Conclusions
The Jini technology community is rapidly consolidating around an open and cooperative development model. Working groups are forming to define Jini interfaces for different types of clients and services, and the Jini community processes is solidifying.
Jini technology will succeed to the extent that this new technology, combined with the new community model of development, succeeds. Join the community today and let’s make it happen!
