Welcome to the January edition of the JCP column. In the time-honored New Year's tradition of offering a perspective of the past year, I have written a different column on the JCP than in other months. Driven partly by the fifth anniversary milestone and partly by some interesting trends happening around us, I'm taking this opportunity to chat with you about this past year and about what may lie ahead for the Java community in 2004.

A Look Back
To start with the technology side of things: 2003 saw the J2EE 1.4 JSRs go final. The Executive Committee voted unanimously in favor, thus giving a strong endorsement to this new release of the J2EE technology. This version took about six months longer to complete than planned due to the community's request to wait for the completion of the WS-I Basic Profile and include it in the J2EE 1.4 technology release.

The milestone event for the J2ME technology was that JSR 185 (Java Technology for the Wireless Industry) went final in July. This year also saw the submittal of new JSRs that will introduce various new features to the Java programming language and new JSRs that aim to ease the development of J2EE-based applications.

While the year is not yet over as I'm writing this, 35 new JSRs were submitted during 2003. This brings the annual average of new JSRs to 47 per year. Of the total 237 submitted JSRs, Sun is leading with 44% with the majority of JSRs being led by other members of the community. With the completion of J2EE 1.4, 84 JSRs have finished, meaning that the JCP members completed over a third of all the initiatives they started. Out of 237, 24 JSRs were withdrawn by their submitters or rejected by the Executive Committee.

Late October 2002, JCP 2.5 was launched, which was accompanied by a new membership agreement, aka JSPA 2. This new agreement gave open source an official standing within the JCP and required that TCKs be available free of charge to nonprofits and qualified individuals (among many other things). Since then the individual membership within the JCP has been on the rise (although the abolishment of the fee may have had something to do with it), so much so that now there is an equal number of corporate and individual members.

Also noteworthy are Richard Monson-Haefel's election to the Executive Committee, so now there are two individuals serving on that body; JBoss Group's joining of the JCP as well as MySQL and even Alan Williamson. The ApacheCon attendees singing "Happy Birthday" was memorable as well!

A Look Ahead
Early in the new year you can look forward to the launch of JCP 2.6, which focuses on making expert groups more accessible and the overall process more transparent, and achieving a higher uniform quality of TCKs. The JCP.org will be revamped in the area of support, providing among other things a place for community members to find early drafts, notes, and observer aliases for the JSRs operating under this new version.

Let's take a closer look at the individual membership for a moment. By JavaOne 2004 it's likely there will be more individuals who have signed the JSPA than companies. One potential consequence could already be observed during this year's EC elections: eight of the nine candidates for the SE/EE EC were individuals. Most spec leads I talk to highly value having individual members on their expert groups. These developers are often very motivated to have the results of the JSR because they are committing personal time. However, while this provides opportunity it can also bring risk with it. Other organizations have failed in the past over not properly balancing individual interests versus corporate interests.

A current discussion among EC members is the flexibility that the process provides to spec leads in choosing a licensing model for the output of a JSR. Historically, this flexibility was built in to encourage JCP members to take up the role (and the burden) of spec lead so that many shoulders would carry the load, if you will. This appeared to have succeeded in that about 55 different JCP members lead one or more JSRs. However, this flexibility can lead to some complexity on the side of the implementer where multiple JSRs are often combined into one product. Can a different balance be found between flexibility for the spec lead versus flexibility for the implementer that still maintains the spec lead role as an affordable one while also ensuring ample choice for the implementer in selecting a business model for its products?

Speaking of business models and licenses, I want to bring the Creative Commons (www.creativecommons.org) to your attention. This initiative was started by Lawrence Lessig and others. The principle on which it is based is very similar to our key principle with the Java technology. Creative Commons attempts to explore the space between the typical copyright statement of "all rights reserved" and the public domain that says "no rights reserved." In other words it is about "some rights reserved." This is very similar to how the JCP manages the Java technology; you get to benefit from the efforts of the community provided that you promise to do so in a compatible manner. Visit the Web site and explore this notion for yourself. It is one of the things I'll be doing in 2004.

That's it for this month. I'm very interested in your feedback. Please e-mail me with your comments, questions, and suggestions.