OpenJDK GB Minutes: 2007/7/12

[Mark Reinhold]

Attached please find the minutes of the first meeting of the Governance
Board.  The minutes are also available on the web:

    http://openjdk.java.net/groups/gb/2007-07-12.html

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.

Respectfully submitted,
- Mark

-------------- 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
  way?

  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
  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 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
	    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 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
  meant.

  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
  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 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
  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
  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
  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 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,
  discuss the

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

  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"
  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 fix, 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 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
  conversation.

    TODO: Mark: Initiate e-mail discussion of definition 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 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
  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 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.

[end]