Governance Board Minutes: 2007/7/12

The ﬁrst meeting of the OpenJDK Governance Board took place via conference call on Thursday, 12 July 2007 at 16:00 UTC, with the following agenda:

1	Chair selection
2	Work plan and working style
3	Constitutional principles

All GB members were present: Doug Lea, Fabiane Nardon, Dalibor Topic, Simon Phipps, and Mark Reinhold.

The intent of these minutes is to capture the conversational ﬂow of the GB’s discussion and also to record agreed-upon resolutions. If you are interested only in the latter then search for the word “AGREED” throughout the text.

1 Chair selection

Doug immediately nominated Mark to chair the GB; Dalibor seconded the motion. Mark observed that the responsibilities of the position are primarily to coordinate and run meetings, take notes, and publish minutes. No other nominations were offered. The GB then unanimously

AGREED

Mark Reinhold will Chair this OpenJDK Governance Board.

2 Work plan and working style

The primary task of this interim GB, as set forth in the OpenJDK Charter, is to write the OpenJDK Constitution. Mark proposed that the GB should start by brainstorming on a set of abstract principles for that document. The idea is not to spend six months boiling the ocean but, rather, to get all the GB members onto the same page, more or less, as the ﬁrst step of the drafting process. The GB agreed to this plan.

Mark then observed that, since this Community is about open development, it follows that as much of the discussion as possible should happen in the open, on the gb-discuss mailing list. Simon agreed that anything less would be looked on “rather dimly.” Dalibor agreed, and wondered whether he should’ve asked people on IRC for input before this meeting. Mark said he thought this would’ve been ﬁne, and consistent with being open. He said he expected that publishing the minutes from this meeting would get the discussion going, both amongst the GB membership as well as with the wider community.

Simon noted that the OpenSolaris GB has published its conference-call number and arranged it so that anyone can call in and listen, though only GB members can speak. Mark added that he’d seen that they were posting mp3 ﬁles of their meetings, and asked: Should the OpenJDK GB should operate in the same way?

Simon said that this “scared the willies” out of him. Doug said that it sounds ﬁne; if anyone is crazy enough to listen to us, then more power to them. Simon replied that he’s generally found that these types of meetings go more smoothly if you don’t have to worry about being politically correct all the time, and that as long as the results are transparent then publishing mp3s is not all that helpful; Mark agreed.

Simon further proposed that the published minutes shouldn’t just be a list of agreed-upon resolutions but, additionally, a record of the conversational ﬂow so that observers can get a sense of the discussion. The general idea is that all results and the pathways to get to those results should be documented. Mark agreed that this seemed reasonable.

Dalibor said that from an extremist viewpoint opening everything up would be good, but on the other hand written, conversational minutes would be much more valuable than mp3s. Simon observed that a great way to prevent openness would be only to publish mp3s—who would have time to listen? Mark agreed, noting that he’d much rather read well-written minutes than listen to an hour-long mp3.

Dalibor suggested that if the issue is ever raised before the GB then it can consider publishing mp3s. Simon further suggested that it’s important to express a willingness to open up any aspect of the meeting that the community thinks appropriate, though practically what we’re going to do is have private group discussions that are then publicly documented. It was then generally agreed that the GB will try to have as much of its discussion in the open as possible.

Simon proposed an elaboration of this principle: All trafﬁc should, by default, go to the public gb-discuss list; if the GB decides to use the private list to discuss a speciﬁc issue then it should announce that fact beforehand on the public list. This way everything that happens on the private list has a “shadow” on the public list that people can track, which is useful not only to observers but also to future GBs that need to understand past decisions.

Mark agreed, but suggested that administrivia such as coordinating meetings doesn’t need to be on the open list. Simon said that could be handled by saying, just once on the public list, that administrivia will be handled on the private list.

Simon further elaborated that if the result of a private discussion is private then the GB should say so publicly. This will help the GB to avoid developing a habit of using the private list for things that don’t really need to be private. If you have to announce beforehand that you’re going to use the private list then each time you do so you’re going to have to work out for yourself how good you feel about keeping something secret.

The GB unanimously agreed to the following resolutions:

AGREED	GB meetings, whether in person or via conference call, shall be private. Detailed conversational minutes shall be posted to the public gb-discuss mailing list after suitable review by the GB membership.
AGREED	Administrative tasks such as coordinating meetings, reviewing draft minutes, etc., shall be handled privately.
AGREED	By default all other GB discussions shall be in the open, on the gb-discuss list. If the GB would like to have a private discussion then a GB member shall ﬁrst announce, on the public list, that such a discussion is going to happen. Once the discussion is over the results shall be summarized to the public list, unless the results themselves are considered private.

3 Constitutional principles

The discussion was structured around two lists of draft principles prepared by Mark and Fabiane. The GB discussed most of the items in Mark’s list for the remainder of this meeting; the rest, and those in Fabiane’s list, were discussed in the following meeting. (For ease of reference the principles are labelled P1, P2, etc., in these minutes.)

Mark described his list as having been generated by discussions both inside and outside of Sun over the last year, and started with

P1	The Governance Board is a legislative and judiciary body; it is not an executive.

Mark elaborated that in his view the GB exists to manage the structure and operation of the community, and to settle disputes, but it doesn’t set technical direction and it doesn’t make technical decisions.

Doug asked for a pair of contrasting examples, observing that these issues are often intertwined. Simon answered that an example of executive action would be deciding that a particular release is ready to be shipped. A legislative action would be devising a process that members of the community could use to decide that a release is ready to be shipped; the GB would thereafter intervene only if the community couldn’t run that process. To summarize, he said that the GB exists “to create processes where none exist, to dispose of those that are redundant, and to resolve disputes that arise from faulty processes.”

Dalibor suggested that the GB amounts to a constitutional court, rather than an executive. Simon agreed, saying that in U.S. terms the GB is like the Senate, the House of Representatives, and the Supreme Court combined; it’s not the President or the Executive Branch. Mark agreed with this analogy.

Dalibor further observed that this is how projects like GCC work. The GCC Steering Committee doesn’t have the power to make technical decisions; it exists to resolve disputes between interests or members. They expect people to “behave like reasonable adults.” If people end up in a dispute then the committee makes a decision and then everyone tries to ﬁgure out what they meant.

Simon suggested that the GB must actively resist falling into an executive role when disputes arise. In such situations the GB should ﬁx the process by which the dispute arose and then put the decision back to the community rather than settle the dispute directly. If the GB doesn’t ﬁx the process then people will keep ﬁnding legalistic reasons to keep coming back to the GB and asking for decisions, thereby politicizing the GB.

Doug said that he found this hard to believe, at least based on his own experience. Simon replied with some speciﬁc examples which he had seen. Dalibor added that the GCC Steering Committee actively discourages people from calling on it to settle disputes. Doug answered that he now understood the distinction.

Simon further asserted that a truly successful GB should never need to meet, an idea that Mark, as Chair, found appealing. A successful GB will have created processes that work on their own, and will only be called upon when the outside world changes and some process change is required. Dalibor likened this to the GB being an “exception handler” that is activated only in exceptional situations.

Simon then described another kind of inappropriate executive role for the GB, namely as the intermediary between Sun and the Community. In Simon’s view, if a community group needs to engage with Sun for some reason then it should do so directly rather than via the GB. Fabiane agreed.

Mark asked how a community group that needs to engage with Sun would ﬁgure out what part of Sun to talk to. Simon replied that that’s a minor problem; they may well, e.g., ask the GB Chair to help them. What he wants to avoid is declaring the GB to be the intermediary to Sun, since by deﬁnition that means that no one else is. Dalibor added that even if a GB tries to monopolize that function, in practical terms it can’t. Sun can always establish additional contacts even if the GB declares itself to be the mediator; this was one of the issues that inﬂamed the OpenSolaris GPLv3 discussion.

To the larger point, Dalibor mentioned that at JavaOne he’d talked with people both inside and outside Sun who assumed that, since he was a GB member, he could answer questions that were really either internal Sun management issues or else issues of direction that the GB wouldn’t have any business making.

Simon added that he’d had the same experience; people assume that since you’re on the GB you have executive power. He suggested that if someone asks the GB to exercise executive authority then that’s really an indication of a ﬂawed or missing process that the GB needs to address. If someone in the OpenJDK Community wants to propose that Sun be asked to change the license from GPL to BSD, e.g., it’s not for the GB to say yes or no but rather to create an open process that the community can use to come to a consensus.

There was general agreement on the conclusions to this point, though Doug reiterated his sense of disillusionment. Simon, tongue in cheek, asked Doug if he was disillusioned because he was hoping to be king. Doug replied that that is the next-to-last thing he wants to do.

Doug went on to say that the very last thing he wants to do is write any sort of governance document, not because he dislikes doing so per se but rather because he’s been frustrated too many times by writing such documents only to have them be transformed into unreadable legalese by lawyers. Simon asserted that this is Mark’s job, to which Mark agreed. Simon further noted that the Sun legal team made hardly any changes to the OpenSolaris Constitution, and that this was perhaps in large part due to the fact that it was written exclusively by one person, Stephen Hahn, based upon a detailed draft written by another, Roy Fielding, with extensive guidance and review by the rest of the OpenSolaris GB.

Dalibor asked whether it’d be okay for him to raise the various questions he was asked at JavaOne on the gb-discuss list, just to make sure that they get aired. Mark said he thought this’d be a good idea, though perhaps best timed to appear right after these minutes are published so that observers see the context.

Mark then proposed the next principle:

P2	Community participants are individuals, not corporations.

He said that, in other words, there should be no such thing as corporate members of the OpenJDK Community that have powers beyond those of the individuals who happen to be employed by those organizations.

Simon observed that he thinks this is part of a difﬁcult meta-topic. While he doesn’t ﬁnd the principle controversial, in the past he’s found that it leads to the question of whether the community’s governance structure should be completely blind as to the employers of the community’s participants. When a new community is created around an existing body of code owned by a single organization then the vast majority of the initial committers will be employed by that organization. If you want committer-led governance, which Simon believes is the correct model, then there’s a strong risk that the initial elected GB will not reﬂect the long-term vision for the community. You therefore have to make a difﬁcult judgement call as to whether to artiﬁcially bias the GB membership to force non-Sun (in this case) members to be elected to it, or if you’re just going to hope that people are going to elect non-Sun people.

Dalibor noted that the GDB Steering Committee uses the rule that no one organization can have more than half the membership of the SC. They came up with this rule after a massive civil war in which factions within single companies were arguing with each other within the context of the SC.

Simon replied that he had proposed something similar to the OpenSolaris GB, but the non-Sun members of that board strongly argued that it should not matter at all who the employers of community participants are; the only thing that should matter is individual merit. The OpenSolaris Constitution is hence completely blind as to who employs whom on the GB or in other positions of elected responsibility.

Simon suggested that this GB should, at its ﬁrst face-to-face meeting, discuss the

OPEN ISSUE

Should the Constitution be blind as to the employers of community participants?

Fabiane then asked for clariﬁcation: If participants are individuals rather then corporations then does that mean that if I’m a member and I change jobs then I’ll retain my privileges even though I’m working somewhere else?

Mark and Simon both agreed that yes, you would retain your privileges. Simon elaborated further that this principle implies that if a company is investing heavily in Java, and a key participant employed by that company quits, then the company can no longer be represented in a manner proportional to its investment since it’s unlikely it’ll be able to hire someone new who’ll have the same standing in the community.

Fabiane observed that such a strong separation between individuals and their employers could make it difﬁcult to entice corporations to pay some of their employees to work on OpenJDK. To ameliorate this she suggested that we ﬁnd a way to acknowledge the investments made by corporations, or other types of organizations, even though such entities don’t have any special powers.

P3	The investments made by the employers of Community participants should be acknowledged publicly.

On a similar note, Simon described how he’d been asked repeatedly by the press why this OpenJDK Interim GB didn’t include representatives from IBM or Oracle. At the very least there’s a perception issue here. The problem, of course, is that granting status to anonymous representatives of industry players immediately gets you into a “really dodgy piece of territory” governance-wise.

Simon went on to observe that there are a large number of ways to try to address this problem. The Eclipse Foundation, e.g., handles this tension with a dual governance structure: There’s an advisory board composed of anonymous members of paying corporations and a separate meritocratic, committer-led governance board for the code. The OpenSolaris Community, as noted earlier, decided simply to be blind to participants’ employers. Other organizations have tried yet other ways to address this issue.

In the end Simon believes that this problem is pretty well intractable. There’s no perfect ﬁx, and whatever structure we wind up with will be the result of a compromise, though personally he prefers the employer-blind option.

Doug said that he likes the purity of Simon’s preference, but he’s unsure as to exactly how it would work out. Making the community employer-blind could wind up discouraging contributors if their employers are just too afraid to go along with it. He suggested that it’d be helpful to ask potential contributors from various corporations (e.g., Google) whether they’d be allowed to contribute to such a community, and then agreed to go do so and report back to the GB.

TODO	Doug: Ask potential contributors from various corporations whether they’d be allowed to contribute to an employer-blind community, and report back with the results.

Mark proposed the next principle, which is closely related to, but distinct from, the previous one:

P4	Community privileges are granted on the basis of proven merit, as judged by peers; they are not granted on the basis of one’s employer.

Dalibor indicated agreement. Simon observed that this principle leads to a bootstrapping problem, and Dalibor in turn noted that there are two ways to bootstrap a community like this: One is to get people from outside to become members, while the other is to accept whole projects into the community.

Mark agreed, and observed that we already have a set of interim governance rules for expanding the OpenJDK Community by recognizing new Members, Groups, and Projects. The goal is deﬁnitely to get to a point where many Members of the Community are from outside Sun, and hopefully to get to that point before we get to ratifying the Constitution.

Mark asked whether the GB is comfortable with the interim governance rules for bootstrapping the OpenJDK Community. Doug said he thinks they’re not fundamentally ﬂawed, and suggested that until and unless we ﬁnd that they are we should leave them as-is. The GB then

AGREED

The interim governance rules are ﬁne for now.

Dalibor observed that they seem to be working so far, with one side project (Iced Tea), and a ﬂow of patches, and that we’ll eventually need to ﬁgure out the status of people and give them appropriate privileges.

Mark agreed that, as this effort moves along, it’s particularly important to ﬁgure out how the Iced Tea project relates to all of this. Dalibor replied that his long-term goal is to make sure that “the whole structure of the Classpath Community kind of merges into the structure of OpenJDK.” Mark noted that the developers hacking on Iced Tea in some sense obviously ought to be members of the OpenJDK Community, and there’s a way in the interim governance rules to make that happen, we just need to make it happen when the time is appropriate. Dalibor agreed, saying that this applies to most of the Classpath VMs as well, since they’re starting to integrate class libraries from OpenJDK. In other words, the community is already migrating; we just have to ﬁgure out how to make that formal.

At this point Doug took the opportunity to ask: What does this have to do with the Apache Harmony project, and is there anything this GB should do about Harmony’s “current stances on just about everything?”

Dalibor replied that he’s long been a strong advocate of open-source TCKs as well as reference implementations, and that having an open-source TCK would solve a lot of the problems that the Harmony project faces. He can’t ﬁgure out the Apache/Sun conﬂict on the TCK issue since he’s not a party to the negotiations and hence hasn’t read the contract. He would deﬁnitely like to make sure that anyone distributing OpenJDK can get the TCK and be able to run it as part of their build process. Harmony could, in theory, get access in the same way as everybody else, though of course there are licensing issues and it seems unlikely that Harmony would move over to OpenJDK.

Doug strongly agreed that Harmony would not move over to OpenJDK. Dalibor replied that they wouldn’t have to move the project, they’d just have to become eligible for the TCK on the same terms as everyone else. Dalibor’s long-term plan to move the TCK issue forward is to come at it from the distribution and engineering sides of things, and to try to ensure that the JCP in the future acts in ways that are consistent with both the JSPA and with open-source ideals.

Doug stated that he very much doesn’t want OpenJDK to become another “cold war proxy battleground” between large, heavily-competing corporations, which is how he currently views the JCP. After some discussion of this concern, Mark and Simon suggested that the OpenJDK Community be deﬁned as a Free Software community that’s working on one particular compatible Java implementation. Mark proposed that the deﬁnition and overall goals of the Community should be discussed further in e-mail, and offered to initiate that conversation.

TODO	Mark: Initiate e-mail discussion of deﬁnition and goals for the OpenJDK Community.

Mark then suggested the next principle:

P5	One need not have proven merit in order to start participating in the Community.

Put another way, a newcomer to the Community should not only be able to exchange e-mail with existing participants but also subscribe to the mailing lists and make code contributions, perhaps though a sponsorship mechanism like what’s already in place.

Simon observed that OpenSolaris started with a sponsor-request process. It was initially motivated by the lack of a public source-code management system, but it turns out to be a good way to get people engaged with a very large code base. A newcomer with a bug ﬁx to contribute has no idea whom to talk to, so they send a message to the sponsor-request list in order to get a sponsor. It’d been assumed that this mechanism would go away once a public SCM becomes available, but it’s worked well as a mentoring process whereby people can gain experience, prove their merit, and eventually be recognized as committers, and even sponsors.

Mark replied that the interim contribution-sponsorship process for OpenJDK is quite similar, the main difference being that there’s no speciﬁc list for requesting a sponsor. He’d always assumed that this process would persist as a way to grow new OpenJDK contributors.

The next principle:

P6	Community privileges do not last forever.

Mark observed that in some open-source communities it’s possible for someone to gain privileges that persist long after one’s involvement in the community ends, which allows for some kinds of bad behaviors. He suggested that the OpenJDK Constitution should deﬁne a way to downgrade the status of someone who hasn’t actually done any work for, say, a year or two.

Dalibor noted that status is persistent in the Debian community, and this creates tension by allowing people to hang on to packages without doing any work. He suggested that an “emeritus” role would be useful; he was unsure, however, as to whether it should be enforced by the Constitution or, rather, as part of a social contract, i.e., a status that inactive people would be encouraged but not forced to accept, with the option of returning to active status if they come back.

Mark noted that the OpenSolaris Constitution does formalize an emeritus role, which is an honorary title without commit or voting rights. It also deﬁnes a process by which members “time out” after a while and are forcibly declared to be “emeritus.”

Simon gave the example of his own status, which will expire in two years, as a “core contributor” in the OpenSolaris Governance Community Group. If at that time he’s still seen as active then his status will be renewed; if not, then it will be downgraded to emeritus.

Simon supported the idea of expiring privileges, but suggested further that it must be enforced automatically. The OpenOfﬁce Community has a rule that commit privileges expire if you don’t use them for some time, but it was never enforced until one faction used it to revoke the privileges of another in the middle of a debate over the direction of a particular project.

Doug expressed concern about this sort of rule, noting that a lot of people, including himself, might be very active for a few months and then inactive for six months, and then become active again. They’re not irresponsible, they’re just busy doing something else for six months.

Simon asked Doug if a timeout period of two or three years would be acceptable. Doug replied that any timeout period that people could agree to would probably be so long as to make a policy deﬁned around it look silly.

Fabiane observed that an automatically-enforced policy has the advantage of avoiding conﬂict; without a deadline then the people enforcing the policy have to decide when to confront apparently-inactive people about their lack of participation, and it can get fairly nasty. The deadline should, however, be long enough that people can go on vacation for three or four months.

Doug suggested that downgrading a participant’s status after a year of inactivity would probably be ﬁne. Simon countered that two years would be a better duration, arguing that the main problem you’re trying to address here is that of a participant who returns after a long period of inactivity and is no longer well-known to the current set of participants yet still has the ability to commit changes to the code. That kind of scenario is more likely to play out over two years than one. A two-year period also means that status renewals come around less frequently than if they were yearly, so they interfere a bit less with the regular activity of the community.

Dalibor asked if the two-year period would be measured from the time of a participant’s last commit, or from the last release that the participant worked on, or something else?

Simon explained that in the OpenSolaris Community the timeout is based upon the date on which a participant’s status was granted. His own status, e.g., will expire three years after its grant date, at which point the system will notify the appropriate community leader that his status is expiring.

Dalibor observed that, under that rule, if he gets enough people to join OpenSolaris in the next year and a half then they would get to decide whether Simon gets his status renewed. Simon conﬁrmed that yes, the system is gameable in that way, and that for OpenJDK he’d suggest that we instead use a rolling status grant, based upon a ﬁxed period from a participant’s last use of that status. This would avoid the hairy bureaucratic problem, which OpenSolaris will face in about three years, of nearly everyone in the community coming up for renewal at the same time.

Dalibor then suggested that if status expiry is to be tied to a speciﬁc action then perhaps the action should be that of voting, whether in GB elections, release decisions, technical decisions, etc. It’s probably safe to declare inactive anyone who doesn’t use their voting rights for two or three years, and doing it this way would avoid the “re-bootstrapping” problem that OpenSolaris is going to have. Mark agreed that this seems like a good idea to explore further as another

OPEN ISSUE

Should status expiry be based on the date on which status was granted, or the date of the most recent use of some right associated with that status, or something else?

Mark then moved the conversation on to the ﬁnal principle of the day:

P7	Community governance is distinct from project governance.

In other words, the social structure of the community is distinct from the structures used to govern projects within the community. Many open-source communities don’t make this distinction, which tends to lead to a narrow kind of community that’s really only oriented around the code as opposed to the code as well as other valuable things that are worth doing, e.g., marketing, documentation, operations, or administration.

Mark elaborated, explaining that in his view there are two orthogonal axes of governance. The governance of the community decides things like participant roles, processes for granting status and taking it away, for creating new community groups, etc.; as noted earlier in the P1 discussion, however, it doesn’t have direct control over actions related to bodies of code or other speciﬁc artifacts. The governance of projects, by contrast, is about actions related to those artifacts; as such it is fundamentally different from community governance and needs a different set of rules.

Mark suggested that a uniform set of rules for all projects would probably be a mistake. He expects there to be many different kinds of projects, ranging from little one-off research efforts that only a few people work on to fairly large ones such as JDK 7 itself. There should be some amount of ﬂexibility in the system so that those involved in a project can ﬁgure out themselves how to govern it in a way that’s appropriate for the size and scope of what they’re doing.

Fabiane said she agreed with this idea, but suggested further that perhaps there should be a set of common rules, or principles, in order to avoid undue complexity in the community. Mark agreed that that would be good, as long as they allow sufﬁcient ﬂexibility. Dalibor also agreed, noting that it seems likely that project governance of JDK 7 will likely be quite different from that of, say, the Kaffe VM project, assuming that the latter were to migrate into the OpenJDK Community.

At this point the GB adjourned until its next meeting on 2007/7/17.