We're at QCon San Francisco and I am here today with the new chairman of the JCP program, Patrick Curran. Patrick, glad to have you today. Would you start out and tell the viewers a little bit about yourself and how you became involved in the JCP process?

I have been working at Sun for fifteen years or so. I have been doing Java work for about the past six or seven years. Basically I was running the team that has been responsible for developing the conformance test kits, the TCKs for Java SE and then also for Java ME. So it was all kind of conformance related, but I used to do policy stuff around conformance and compatibility, some legal stuff and so on. I guess when Onno decided that he wanted to do something else in the open source area, they thought I would be a good fit for this.

Along those lines I am sure when you came into the position you had a mental list of things you would like to accomplish and improve upon. Are there some of those that you would like to share? What are your hot button issues?

Well, I guess it is around openness and collaboration. And also just adjusting to change, I mean this is a new world, open source is changing everything and it is going to change the way we do our business. Historically, the JCP has changed over the last 5-6 years. It used to be that mostly the membership was corporate, big guys: Motorola, IBM, Nokia and so on. Of course, they are still all there and that is great, because we need them there. But I think there was a feeling among people that perhaps it was a little exclusive, a little closed, things were done kind of in secret. That wasn't always the case but there was probably a tendency that way. When you are dealing with intellectual property, which is what we are dealing with, and you are dealing with large corporations, they sometimes get a little cautious about the way they do their business. But over the years the JCP has loosened up and relaxed a little, we've encouraged more individual members, we've encouraged non-profits and open source groups to join us, and the way that business is done has changed and things are now much more open than they were. I think we could go further, I will be honest. W3C and Oasis, everything is done basically out in the open. And we still get people saying: "Why can't I see the full archive of the mailing list associated with a particular expert group?" The answer is because that's up to the expert group how they do their business. We don't mandate how they work, we don't tell them they have to do it secretly, and we don't tell them they have to do it out in the open. And I think increasingly they are doing things out in the open but we need to push to encourage just a little bit. That's probably the biggest thing that I would like to see happen in the next year or two.

One of the main things that comes out of the Java Community Process and these various JSRs is standards. Would you talk a little bit about why these standards matter in today's landscape of open source and some of these rapidly changing projects that maybe are officially standardized from a spec basis versus what comes out the JCP?

I am a big believer in standards. As I said in my talk today standards make the world go round, nothing in the world that we live in today would be here and would function if it wasn't for standards: transportation, communication, medicine, entertainment, nothing. In the software world they are equally important, particularly if you want, as I put it this afternoon, if you want to play with the big guys. If you want a government or a bank, or Federal Express or the navy to use your software -- a lot of open source guys may not -- but if you really want widespread adoption, then sooner or later you are going to have to standardize. And the reason is you have to define the interfaces between stuff, you had to find the protocols so that things could talk to each other, you have to document what those interfaces are, you have to have conformance test suits to verify that things that are implementing those specifications actually conform to the specs, and if you have all those things, then what you get is the opportunity for interchangeability, no vendor lock-in. If I were a buyer and I get to choose, I can buy from this vendor, I could buy from that vendor, I can mix and match and I have some hope that the pieces will fit together. And if I am a government or bank that is what I am going to insist on. So, I am all in favor of open source and all in favor of Agile development and all in favor of having fun building software. But if you want your software to run in a bank -- maybe you don't but if you do -- sooner or later you are going to have to standardize it and that is a good thing.

It is important to note that those things aren't mututally exclusive -- you can have open source and standards and they are very complimentary. But on the other side of that, a lot of developers recently are involved in a lot of popular open source projects, they don't start from the standard basis. You have got things like Spring, for instance, they tend to stay away from anything that is going to slow the process down. How do you balance the need for standards and yet not handcuffing innovation so to speak?

That's the challenge that's what we got to figure out. And if we don't solve that we could... I don't want to say we'll lose, because people will always standardize, but we will lose, we will not do as well as we could have done. So we've got to figure out a way to allow people to innovate rapidly and then when the time is right, to standardize. And in practice that's the way things work, it's just that innovation often doesn't happen inside the JCP and that's perfectly ok. It happens outside, it happens in other communities, often in open source communities, people will build something like Spring and they will do it at their own pace, without feeling that they are obliged to follow some kind of process, and at some point either that thing or ideas from that thing will get folded back into the standards development process. For the JCP what we have to do is to understand and figure out how we can deal with the intellectual property issues around rapid development, around getting stuff out there soon so that people feel that it is possible to innovate and innovate rapidly within the JCP. We talked about Agile software development, I wish we could do Agile specifications standards development. It's a challenge but we've got to try and figure it out.

I think another area that people are particularly interested in with the Java Community Process, and the different JSRs more recently since Sun has announced the OpenJDK project and open source Java. It's assumed that a lot of these JSRs are going to basically guide where Java goes. Could you talk a little bit about where that's at today and where you see that going, and in the next year or two, as Java evolves from being something that was largely developed by Sun, it's now being largely developed by the community?

I'll try, we're still trying to figure that out. Maybe you touched on one aspect of it right there. In the past it was largely developed by Sun and now it is going to be, we hope, developed by Sun and a broader community. In one sense that is a major change, it's certainly a very big change for the guys inside Sun, who have up until now been responsible for developing Java SE. But from the JCP's perspective you could say it really doesn't make that much difference. What you have is a developer community out there developing and innovating, whether they all work for one company, whether they work for three or four companies collaborating, whether they are an open source community, doesn't make that much difference from the JCP's perspective. What we care about is that the ideas are good, that when you are ready you bring them to us and you work through the process to build a spec and a reference implementation and a conformance test suite. So, as I say, big change for the Java developers inside Sun. Probably the very fact that things are being done in an open source manner will change some aspects of the way things work in the JCP. Certainly it will put pressure on us to open up the JSR development process, it would make no sense to have the Java SE JSRs which are being done in an open source manner go through the JCP, when they go through the JCP in a proprietary closed manner, that would make no sense. In that sense it will put a little pressure on us which is a good thing. But overall I think that the structure of the organization and the processes that we follow are flexible enough that they can accommodate this without really major change.

Earlier you mentioned that you had been involved with some of the TCK activities primarily over the course of the last couple of years before your current position. Could you comment a little bit on the situation with the TCK that Sun uses for OpenJDK with respect to Apache Harmony? I guess I am assuming, being as well versed as you are with it, could you talk about some of the reasoning for some of the decisions that have been made with that?

Let's see. Sun is the spec lead for the platform, as the spec lead it is responsible for the specification, the reference implementation and the TCK. And the JCP's participation agreement, the constitution if you like, the legal agreement between members of the JCP and the organization itself, was drawn up by the members of the expert group, because we actually built our constitution through the Java Community Process itself. And when this was put together several years ago the decision was made -- and this is a little different from certain other standards organizations -- the decision was made that ownership of the intellectual property associated with a particular JSR would rest with the spec lead. And if you work with W3C you donate it and it ends up being owned by W3C that then gives it away to the world.

JCP was deliberately put together on a different model, it's a model that tries to protect the commercial interests or tries to balance the commercial interests of the participants, the participant organizations with the interests of the broader community and with that intent, and very deliberately, the constitution reserves to the rights of the spec lead, the right to how they should license stuff. Now it also says that you must make these materials available to people on non-discriminatory terms, you can't charge this person this much and that person that much. So, having said all of that, we end up in a situation where there is basically a dispute between Sun and other members of the organization about exactly what rights Sun has and exactly what obligations Sun has under this constitution - well, I shouldn't use constitution, it's an actual contract, legal contractual agreement between members and the organization. I am not a lawyer but I have been taught not to offer legal advice, so all I can say is Sun's lawyers believe that they have the right, under certain circumstances, to put certain terms into the licenses for their TCKs. Other people in the community think that they should not be doing that and some of them believe that they have no legal right to do that.

As I say, I am not a lawyer I don't want to jump into the middle of that. Now, with regard to licensing to the open source community, Sun has also made a choice to go open source and has chosen a particular license, the license is GPL V2. And they have chosen to license the TCKs to members of the OpenJDK community and people working from Sun's source base on terms that are different to the commercial terms that they offered to everybody else. The point about those commercial terms is those are the same terms that they offer both to Apache, except they say to Apache they won't charge you any money, for Apache it would be free, and to IBM and everybody else who wants to license that TCK. It's complicated, it's a legal issue, and to be honest I would rather that we didn't spend our time having legal disputes within the organization but maybe I should say this, it's the essence of a standards organization, not that you will fight but it's like a family in one sense, there's no family where people don't fight. And in fact the point about a standards organization is a place where people with different interests come together and, despite the fact that they may not always agree with each other, they all recognize that the benefits of collaborating outweigh the problems and the hassles that they have when they try to get on with everybody else. I believe that everybody who is currently participating in the JCP believes in it and understands its importance and one way or another we'll figure this out.

It seems like a lot of the app server vendors have become less interested in what was traditionally JEE and they moved on to other areas like SOA. How has that shift affected the JCP process?

I don't know that it affects the process itself that much. I think it's an illustrational demonstration of the fact that the process actually worked, we now have a situation where a set of technologies have become ubiquitous. You just kind of take it for granted. That's what standardization is all about, right? That's what it is supposed to do. Now if you are a manufacturer of a particular device and you used to have a monopoly on this and suddenly everybody is using it and it becomes standardized and it does become a commodity, then yes, I am sorry you are probably not going to make so much money out if it as you used to. However the fact that it has become standardized, the fact that everybody can rely on this base, just means that there are more opportunities for innovation. So yes the guys are going to move up the stack into SOA or whatever it is. The innovation doesn't stop, the standardization doesn't stop; it just shifts.

Given your experience with standards, what segment of Java technology do you think needs to be standardized next, just because the market is driving in that direction? Any one in particular you are pointing to?

Following up on what I was saying a moment ago about commoditization, SE is pretty stable. You can just rely on a Java runtime, you know it is going to do what it is supposed to do, we are not perfect with write once run everywhere but it's pretty good. And the amount of fragmentation in that market is minimal. We were just talking about the EE market and saying that to some extent those have become commoditized too. It's kind of like, there's an app server there, you know it is going to do these kinds of things. ME is different, in ME we have these fragmentation problems, we have perhaps a little too much optionality in the specifications, it's a combination of things. We have too much fuzziness in some of the specifications, you have differences in the implementations themselves, you have variability in the hardware platforms, and the result is we haven't achieved that commoditization which we were talking about in the EE space and the kind of ubiquity which you see in the SE space. So I would say that's where the most work needs to be done.

A lot of times we hear about JSRs and things in the community process that people don't like. So you hear all the bad side of the world so to speak. Is there a particular JSR that went through development or in process now that you hold up as a shining example of "Hey this is how things are supposed to work"?

When you say how things are supposed to work you mean in terms of how the process is supposed to work? Or in terms of technology that's interesting?

I think I would say in terms of success. We talked about some of the traditional things that people think about in terms of the standards for Java EE for instance. But there is a whole list of JSRs. Is there any one in particular that you would hold up as an example?

Well this isn't glamorous stuff but there is a group called OSS/J who basically have pushed an enormous number of JSRs through. They are kind of the big telco guys, they do all the infrastructure stuff and this is about not what happens when you pick up your phone, but what sits behind it, how do they do the billing and the identity management, and keep the networks running and so on. This is like plumbing and it's kind of esoteric and the only people who really understand it or care about it are the big telco guys. It affects everybody of course, because that's why your cell phone system works. That's a good example of people just working away, these are all the big guys in the industry and they have just said "This is the only sensible way to do this". You cannot do this stuff separately, it doesn't make any sense. It's not possible because we have interoperability issues and so on. I would throw that out as an example of something where the process just works, and yet it's not exciting and glamorous and most people probably don't even understand that stuff but it's just there and it just works.

Another question would be: how do you stop the JCP from being a marketing vehicle? Some people have complained that with different JSRs whether it is Groovy for instance or maybe the recent Web Bean specification that's been primarily championed by JBoss that it's largely there to satisfy self-interests in a sense.

To some extent you can't stop that and I am not sure that we should. This is supposed to be a community organization, it is a community organization, and ultimately it works on a collaboration process not a consensus process. Yes, if you've got the muscle, you may be able to persuade people to vote for you, but at the end of the day, even if you are successful, let's say that you get something through and it is done by muscle, by leaning on people, rather than because this idea has technical merits, well guess what? It is not going to go anywhere. We can all think of examples of technologies that, whether through a standard process or some other way, they make it out into the market, some people look at it and go "Ah, it doesn't do it for me. It actually is not very helpful, not very useful, I don't want it". So, that doesn't worry me, it really doesn't. There are JSRs that get partway through and they just stop and sometimes we get asked: "Oh, isn't this a problem? There are JSRs that fail, there are JSRs that never get finished", I say "No, that's fine". There are good reasons -- people lose interest, business interest change -- so sometimes occasionally people will manage to push something partway through the process. Can you get it all the way through if it has no technical merit and is of no interest to the broader Java community? I am not so sure that you can.

A second ago we talked about a JSR from the example perspective, of being a shining example-type JSR. But there are a lot of JSRs out there, what do you think is the most interesting JSR?

There are couple of ones recently, ones that have just started, I don't remember the number to tell you the truth, but it's telemetry for automobiles, which I think is kind of cool. So basically if this goes forward you will be able to do things like check the fuel level of your car from your cell phone, set and unset your car alarm and stuff like that. I think that is kind of interesting but one that really does interest me is 242, they call it 'On Ramp to OCAP'. Basically it's the TV industry. And this is the first step. They have this whole set of standards for the TV industry around interactive TV and cable TV and so on. This is what everybody has been talking about for years, eventually we are going to have real interactive TV, you will be able to watch something, you will be able to buy the shirt off your football player's back just by punching in some numbers on your cell phone or a keyboard or whatever.

That's beginning, you probably know that Java is moving into Hollywood for the Blu-ray specifications which themselves are built on similar stuff as the TV. So we are seeing a convergence here, or the beginning of a convergence, between TV and the Internet and Hollywood. And this particular JSR, the OCAP one, it's not that ambitious, basically what it is an attempt to do is to take a subset of the full OCAP spec, cut it down into a profile that can be installed in all of the existing set-top boxes that are out there. It's baby steps but the industry needs it because they can't just go and tell everyone, "throw away all of the existing set-top boxes". But the thing that interests me is this entirely new market. We've done enterprise servers, we've done desktops, we've done laptops, we've done cell phones, we haven't really done TV and movies, and these are just the beginning of Java moving into those areas. That's great for it.

Finishing our conversation here today what types of changes would you like to see in the JCP either in terms of the process or the community, interacting with it over the course of the next couple of years?

I already talked about openness and that is really important. We want to do things out in the open. Openness... Sometimes maybe transparency is a better way of describing that because then you don't mix it up with open in open source. A lot of what we do will be done in open source, but probably not everything, because we do have a lot of big commercial players there, and they don't all want to work in an open source manner and we shouldn't force them to do so. Increase transparency, more collaboration and better relations between the JCP and other standards bodies. There is no such a thing as a standard that stands alone. If you create such a thing you've probably done the wrong thing. You should go out there, reuse something, build on top of something else. The majority of JSRs that I look at are calling on, building on, expanding on, have some relationship to some other JSR or some other standard that came out of some other organization. So the JCP has to become more open in that sense in terms of reaching out to other organizations. And then I would say, finally, more open and inclusive in terms of its membership. We have tended to be somewhat corporate-heavy in the past. We've certainly made a lot of changes and we're now more than 50%, I think, individual and non-profit membership. But we could bump that even further and I would like to see the individual members and the non-profits actually having more influence in terms of governance and policy and process. Right now the ECs are still mostly corporate and that's understandable, we do have a few individual members but I think over time we are going to see more of that and that can only be healthy.