OpenJDK GB Minutes: 2007/7/12
mr at sun.com
Thu Oct 4 12:05:56 PDT 2007
Attached please find the minutes of the first meeting of the Governance
Board. The minutes are also available on the web:
To answer an obvious question: These meetings were held way back in July;
why are the minutes only being published today? Summer vacations, busy
schedules, and a series of unforeseeable non-work calamities conspired to
induce this delay. As Chair of the GB I will endeavor to produce minutes
in a more timely fashion going forward.
-------------- next part --------------
OpenJDK Governance Board Minutes: 2007/7/12
Mark Reinhold <mr at sun.com>
The first 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 flow 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 first 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 fine, 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 files of
their meetings, and asked: Should the OpenJDK GB should operate in the same
Simon said that this "scared the willies" out of him. Doug said that it
sounds fine; 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
flow 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
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
Simon proposed an elaboration of this principle: All traffic should, by
default, go to the public gb-discuss list; if the GB decides to use the
private list to discuss a specific 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
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 first 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 figure out what they
Simon suggested that the GB must actively resist falling into an executive
role when disputes arise. In such situations the GB should fix 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 fix the process
then people will keep finding 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 specific 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
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
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 figure
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 definition 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 inflamed the OpenSolaris GPLv3
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
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
flawed 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
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 difficult meta-topic. While
he doesn't find 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 reflect the long-term vision for the community.
You therefore have to make a difficult judgement call as to whether to
artificially 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 first face-to-face meeting,
OPEN ISSUE: Should the Constitution be blind as to the employers of
Fabiane then asked for clarification: 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 difficult to entice corporations to pay some of their
employees to work on OpenJDK. To ameliorate this she suggested that we find
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"
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 fix, and whatever structure we wind up with will be the
result of a compromise, though personally he prefers the employer-blind
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 definitely 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 flawed, and suggested that until and unless we find that they
are we should leave them as-is. The GB then
AGREED: The interim governance rules are fine for now.
Dalibor observed that they seem to be working so far, with one side project
(Iced Tea), and a flow of patches, and that we'll eventually need to figure
out the status of people and give them appropriate privileges.
Mark agreed that, as this effort moves along, it's particularly important to
figure 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 figure 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 figure
out the Apache/Sun conflict on the TCK issue since he's not a party to the
negotiations and hence hasn't read the contract. He would definitely 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 defined as a Free
Software community that's working on one particular compatible Java
implementation. Mark proposed that the definition and overall goals of the
Community should be discussed further in e-mail, and offered to initiate that
TODO: Mark: Initiate e-mail discussion of definition and goals for the
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 fix 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 specific 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 define 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 defines
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 OpenOffice 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 defined around it look silly.
Fabiane observed that an automatically-enforced policy has the advantage of
avoiding conflict; 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 fine. 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 confirmed 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 fixed 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 specific
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 final 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
specific 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 flexibility
in the system so that those involved in a project can figure out themselves
how to govern it in a way that's appropriate for the size and scope of what
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 sufficient flexibility. 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.
More information about the gb-discuss