In association with heise online

An Open Process

HO: Looking ahead, you are looking for a more transparent or at least less opaque process, so in two years time, where do you hope to be?

PC: By then I would hope it would be just routine to do things in the open. It's just the right way to do things. I expect that many JSRs by then, probably the majority, will be done as open source projects. We're already are around close to fifty percent; it's pretty much the default for Java EE, becoming so for Java SE but not so much for Java ME where there's a different mindset, a different business model there. But I think we have a lot of lessons to learn from the open source movement in terms of collaboration, openness and broad participation and I think that's the direction we need to move in. There will always be the dedicated standards wonks who do a lot of the work, that's just the way it is. A lot of the work is very tedious, just dotting the i's, crossing the t's and big discussions about whether the meaning of the word "is" is and stuff like that and it's important that you get that stuff right when nailing down a specification. People are going to be using it for years to come.

But there is great value is in having a lot of people touching the work, testing it out as you go through the process, that helps to improve it. It's just a better process. So I'd like not just the specification but the RI and the TCK, the three deliverables, [in the open process]. I think there's value in having more people involved reviewing the specification, not necessarily writing it; I don't think a thousand people can produce a good document if they work on it collectively. Probably three of four people are going to draft it, but if you can get two hundred people to read it and comment then that is great. But when it comes to building the reference implementation, I think there's great value in having many people involved in that. And similarly for the test suites.

HO: Would it be in your interest to flag the fully open JSRs ... flag for people which JSRs have an open process?

PC: We're still exploring how to shine the spotlight on the guys who are doing things right. But yes, actually labelling them is quite a good idea. We've done something similar around agility, trying to do things faster. We did a survey to try and figure out which JSRs are moving best through the process, moving faster and we have started labelling certain JSRs as inactive if they haven't actually done anything in the last eighteen months. That's sort of a negative label, but it's flushed a lot of people out of the wood-work ... Spec leads have come to us and said "But we are actually working on it" so then we ask them "Why aren't you telling people? There's no indication from that much is happening here". But yes, actually labelling those projects which are really done in an open manner would be a good approach. The other thing we are thinking of doing, which we probably will do, is that we do awards at JavaOne every year and we are going to factor transparency into that. We probably won't create a separate award for this, but whoever gets JSR of the year, this will be a significant factor in that decision.

HO: You mentioned you are looking at inactivity. Are you going to flag projects with velocity; ones moving through the process quickly?

PC: Yes, we will. We've started doing a regular series of debriefings as people complete [JSRs], and at earlier stages, asking what worked for you, what didn't work for you. We've started publishing a series of articles on this on and are just trying to learn the lessons. If somebody manages to get through the process in 12-18 months, as opposed to three or four years, we'd like to know what are the factors that helped there. It's too soon to say yet, but we're trying all these things.

Next: A Long Path

Print Version | Permalink:
  • Twitter
  • Facebook
  • submit to slashdot
  • StumbleUpon
  • submit to reddit

  • July's Community Calendar

The H Open

The H Security

The H Developer

The H Internet Toolkit