In association with heise online

A Long Path

HO: It's a long path evolving into a transparent organisation. Do you foresee anything that might be a problem?

PC: I think certain expert groups, or people who play spec lead roles, who feel that it's more efficient to do things in a less embracing manner. They may feel, and there is a certain amount of truth to this, that three or four people dedicated to the task, so long as they do the appropriate amount of consultation, can actually move things along, potentially faster. So it's a matter of striking a balance and perhaps convincing these guys. We certainly don't want to impose any particular working style on people, that's never been our philosophy. We've always said you are free to operate in any way you want, but I think we need to restrict a little more, say well you are not free to do it completely secretly. If you are more comfortable working in a tight knit group then OK, but there are certain things we will be requiring, beyond the publishing of a draft after nine months or whatever. So you need to let people know where you are, we should probably be encouraging many drafts rather than waiting until you are almost done ... The one thing I think we almost certainly will end up mandating is public issue tracking. I think if you do that, it solves a lot of other problems. If there is a public way for people to give their comments, if those comments are visible to all and if the expert group is obliged, as they are with OASIS and W3C, to respond publicly. That doesn't mean you have accept the criticism or the suggested change, but you have to respond to it in public. And I think if we adopt that, that will make a significant difference because it's much more difficult in that kind of environment for people to reject input or be exclusive.

HO: It's looking promising then if you can get that far.

PC: Yes, I think we can. There's very little dissension within the executive committee about these kind of things. We did that transparency survey last year and took it back to the community and said "This is what we've learned and these are the kinds of things we want to encourage people to do" and everybody just said "Yes, absolutely ... just do it". So actually we're in the process of making changes to the process document; we're doing a revision on the process document, which is kind of like the constitution of the organisation. Well that and the JSPA, which is the legal contract, but the JSPA is a big deal to change as it covers IP rights and so on and we're working on that but it takes much longer. The process document is about how the process works, what the timing is, what the obligations of the expert group are, and we're working on a maintenance release of that, to make some fairly minor changes and we'll incorporate a variety of these transparency things into those changes.

HO: Will there be an easy to read diff file?

PC: Yes. And I should point out that we are doing that work in an open and transparent manner and if you wish, you can look up JSR 215, and go to the community page (in theory every JSR is supposed to have one) you can see the process. But right now you have to be a member of the JCP to view those and I'm not sure we should do that. It's a difficult decision to make as to what should be reserved for members and what should be completely open. We do now have an observer alias for JSR 215 and a community page with diffs and the text of what we are proposing to work under. Similarly, we recently started publishing the minutes of the executive committee meetings. We always used to publish summaries which were very bland, very high level and very little detail. We switched and said the default should be everything is out in the open, including the presentations we do at the committee. From time to time we go into private session, but most of the stuff is now out in public. So we're moving slowly in that direction.

HO: It's always felt that the JCP process moves on it's own speed.

PC: I have to say, it's not fast, but to some extent that's OK. Taking three years or four years is not good, but you are building a spec and you are going to have to live with it for a while, you don't want to rush it. You want to make sure you get it right. I think if we can get it down to a year, year and a half, for many, maybe even most specs, that would be good.

HO: There's no facility at the moment to create hothouse specifications in the JCP, that is where a group of people want to get together to start doing the work for a future specification, without forming an expert group, but want to work in the open and do it in some way that it could more easily become a JSR. Are you looking at having an incubator?

PC: That's an interesting thought. We haven't used the term particularly, but one of the things we are looking at is ... the way the IP rights are granted in the organisation. Basically they don't vest till the work is completed, which makes it kind of hard to do the kind of thing you are talking about.

HO: But if the project was implicitly open source at the start, it would give open source projects a leg up into the JSR process.

PC: Yes, that's a really good idea. I'll look into that. Certainly one of the lessons, one of the conclusions that I've come to as we talk about open source is that ... it's often very dangerous to sit in a room and invent something just out of the air and then, much later, you try and implement it and discover it's either not implementable, or difficult to implement, or it's not actually what people want. So there is significant value in doing the work in a rapid iterative manner and testing it out first. So we're definitely encouraging that, but the notion of a formal incubator is not something we've considered. I think it's a really good idea and I'll take it back to the others and see if they agree. So thank you for that.

HO: Thank you.

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