An Interview with Patrick Curran, Chair of the JCP

Before Patrick Curran became Chair of the Java Community process in 2007, he headed up the Java Conformance Engineering team in Sun's Client Software Group, and in that capacity was responsible for the Java SE TCK. A Sun employee for more than fifteen years, Curran represented the company on several standards organizations, such as the W3C's Quality Assurance Working Group and OASIS.

In this interview with Artima, Patrick Curran talks about the importance of standards in the software creation process, shares his vision for the JCP, and explains how the JCP adapts to the changing reality of open-source development.

Interchangeable Parts

Frank Sommers: What is your vision for the future of the JCP?

Patrick Curran: I'm a big believer in standards. I think standards are really important: standards make the world go 'round. The world wouldn't function without standards. You wouldn't be able to mail out a letter or send an email or take a train or watch a movie or go to a hospital without standards. None those would really be possible without standards. People sort of understand that, but it bears repeating that standards help define the way in which processes work, in which industry works.

Standards are particularly important in the software industry. We all understand the importance of the protocol-like standards, XML and HTML and so on. The Internet would not exist without standards. But there are other kinds of standards we work on in the JCP that are not so much about protocols, but about what you might call interchangeable parts.

In the 19th century, the Industrial Revolution was all about routinizing the industrial process, going from a process whereby things were created one-off, by hand, to a process whereby things became well-defined and standardized. You knew that you can buy parts from multiple suppliers, and replace a piece of a machine with parts from someone else. That was revolutionary.

We are at the beginning of such a revolution in the software industry. We like to call ourselves engineers. But, in my opinion, in most cases, we are still at the artisan stage. People are hand-crafting stuff. There is not a lot of reuse, there is not a lot of pluggability, there is not a lot of assembling things out of components. But that is beginning to happen.

People putting systems together now want to create systems by taking pieces and components off the shelves, and plugging them together. They want the freedom and choice to be able to go to a supplier, and to know that there is a second choice as well. They don't want to be dependent on some skilled artisan and programmer who could quit tomorrow and go to work for someone else, and suddenly, you don't know who would be maintaining your system. It's time to make all of that possible.

Java has driven a lot of this. Java is founded on the notion of standards, standards that were created in an open and collaborative manner, through community involvement, through the involvement of those who will be implementors of the standards and those who will be consumers of them.

Standards are important with regard to the JCP itself. I think one of the most important things we have to look for is to increase the membership, and to do our work in a more open and more collaborative manner. We call ourselves the Java Community Process, and we do so for a reason. We believe that it is important to involve the community in the work we do. In the past, there was some truth to the claim that the work of the JCP had been done, if not in a secretive manner, at least in a manner not as open as it could have been. Obviously, these days, with the whole open-source trend, there is a very strong current of opinion that there is value in doing things out in the open, and involving people in collaborating in a community.

I would like the JCP to evolve further in that direction. We are already doing that. Many JSRs are already being done in a completely open-source manner. There is nothing in our documents that prohibits a spec lead from doing things in an open manner. In fact, just to the contrary: the process document gives the spec lead virtually complete freedom as to how they should operate. If they want to put a spec together with themselves and their two buddies in a back room, they're free to do so, although that's clearly not the best way to guarantee that the spec is going to succeed. On the other hand, if you want to do it in a completely open-source manner, if you want to create an open-source project where anyone who wishes to join can participate, they're free to do it that way.

In addition, it's also going to be necessary for the JCP to recognize that no standard is an island. We always build on other standards, and many of those standards are created outside of the JCP. The entire HTML and XML set of standards are coming primarily out of the W3C, and Java has gladly embraced them and built on top of them. We need to do more of that.

Frank Sommers: What are the ways in which you would like developers to participate in the JCP more?

Patrick Curran: The first thing is, join if you're not a member. It's free: for individuals there is no charge. If you're the sort of person who has been involved, or is thinking about getting involved, in an open-source project, then you're probably the sort of developer we'd like to have in the JCP. If you have some passions or interests in a particular area of technology, join the JCP.

You don't have to join an expert group, if you don't wish to. We have mechanisms—for example, observer aliases—in which you can participate without formally joining an expert group. We do encourage you to join an expert group, of course, particularly for JSRs conducted in a more open manner. In those JSRs, you'll have opportunities at several stages of a JSR to join its development. That may be just to read the specification and comment on it, and provide some feedback. Many expert groups provide early access to their JSR reference implementations, and that's a great way to provide feedback. If you have the skills and the interests, there are always ways to participate with documentation-type work, with developing and executing tests and so on.

So there are many ways, but primarily, join the JCP, choose an area that interests you, find one of the expert groups that's working on something important to you. Don't waste your time on something that you're not interested in. Once you find something of interest, go and talk to the spec lead and ask how you might be able to help.

The Benefits of JCP Membership

Frank Sommers: Writing tests, documentation type work, and working on the spec are investments of someone's time. What would the payback be for the individual?

Patrick Curran: I would turn the question around and ask why would hundreds of thousands of developers spend their time working on open-source projects? They do it for a variety of reasons. They do it because they have a passion for that kind of work, they do it because they actually enjoy it. But it's not all altruistic. Often, people do this kind of work because they gain recognition within the community, among their peers, and, let's be honest, among potential employers.

As you look at the Web 2.0 world, there are a lot of social networking sites out there, and many of them are about recognition: Here I am, this is me. Why do people post things on the Web about their dog or their cat, or the vacation they went on last year? In part, they want the recognition, to say, here I am.

But, also, you become part of a community and, if you participate, you get kudos from within the community, your peers will recognize you. In the case of the JCP and the communities formed around Java standards, getting involved doesn't hurt on your resume either. If you can point to a piece of open-source software that you were responsible for developing, many people have parlayed that kind of work into good jobs at big, well-paying corporations.

Frank Sommers: While most Java developers readily admit the value the JCP has brought to the community, some point out that in certain cases, a small, more nimble, de facto standard may be preferable to an all-encompassing JCP standard that would result in large, complex software. To what extent do you see the JCP being able to produce simple solutions as opposed to taking a comprehensive approach to an issue that would result in large specifications?

Patrick Curran: There is nothing in the JCP, or in any other standards process, that prohibits people from doing something simple. There is nothing that says that you can't focus on a small problem rather than on a big one. Having said that, there are certain tendencies and attributes of the standards development process that might make it more difficult to do that. That you're trying to get a broad industry consensus means that sometimes you can over-stretch. You can try to balance what appear to be competing interests, or competing perspectives, and just go too far. You'll end up with something that tries to satisfy everybody, and ultimately, does not satisfy anybody.

In general, that's just a matter of good design. At the end, we're designing software. You can design good software, and you can design bad software. There is nothing inherent in a standards-based approach that says you'll end with something that is not simple and elegant.

Some of the best JSRs are those that didn't try to go too far. And you'll see that when you actually read the specs. The spec leads are often very conscious of this. They will say right up-front that don't try to solve the broadest possible case, but something that is useful and more constrained. I was reading the telematics JSR [Telematics API for Java ME, JSR 298] the other day, and saw a comment from someone, complaining that the JSR was trying to solve a limited problem, which is telematics in automobiles. They want to make it possible to do things like check your fuel from your cell phone, or start the engine or the alarm or unlock your car, or change the air-conditioning settings, and things of that nature. The comment was that that was a shame, because they should want to do all that with home appliances, and anything else. That JSR is a good example of an expert group that understands that while they could try to solve an enormous problem, but if we did so, they may never get there, and may end up with something that just doesn't work so well. Instead, decided to start small and they can always try to build on that later.

New Priorities

Frank Sommers: What are your top priorities for the next year?

Patrick Curran: At a basic level, we have to make sure the JSR process flows smoothly, and that people get the services they need from the PMO [Project Management Office]. Looking a bit beyond that, I'd say that outreach is very high on the list, as are openness and collaboration. We will have to try to find new ways to do the work that we're doing, to do it a bit more efficiently, more effectively, and in a more open and collaborative manner.

Also, we'll need to do our work in a more agile manner. People talk a lot about agile development in terms of software, but you can think of that in terms developing standards and specifications as well. Most people think of the latter as something that tends to be very slow and time-consuming, and people sometimes say that that's an inhibition to innovation. There's some truth in that, and there's some value to that as well. You don't want a standard that's been knocked out in two weeks by a few people without broad consultation, because you're going to built on the standard for years to come. Instead, you want to figure out how to strike that balance, trying to make it possible to encourage innovation, to have people innovating. And that innovation may be inside or outside the JCP, that doesn't matter. But, in the end, we'd want people to bring that innovation into the JCP.

Another goal is to come to terms with the whole open-source development model. That's here to stay and is increasingly popular within the JCP. Some of our processes and practices are going to have to adapt in order to facilitate that. To summarize, openness, collaboration, involvement, and growth are my main priorities.

Resources

Patrick Curran's Blog:
http://blogs.sun.com/pcurran/

The JCP Home page
http://www.jcp.org

What do you think about Curran's observations about artisans versus engineers and the standards process?

Talk back!

Have an opinion? Be the first to post a comment about this article.

About the author

Frank Sommers is a Senior Editor with Artima Developer. He also serves as chief editor of the IEEE Technical Committee on Scalable Computing's newsletter, and is an elected member of the Jini Community's Technical Advisory Committee. Prior to joining Artima, Frank wrote the Jiniology and Web services columns for JavaWorld.