From mr at sun.com  Thu Oct  4 12:05:56 2007
From: mr at sun.com (Mark Reinhold)
Date: Thu, 04 Oct 2007 12:05:56 -0700
Subject: OpenJDK GB Minutes: 2007/7/12
Message-ID: <20071004190556.11C3662F8@eggemoggin.niobe.net>

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]

From mr at sun.com  Thu Oct  4 12:06:20 2007
From: mr at sun.com (Mark Reinhold)
Date: Thu, 04 Oct 2007 12:06:20 -0700
Subject: OpenJDK GB Minutes: 2007/7/17
Message-ID: <20071004190620.266B662F8@eggemoggin.niobe.net>

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

    http://openjdk.java.net/groups/gb/2007-07-17.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/17
Mark Reinhold <mr at sun.com>

The second meeting of the OpenJDK Governance Board took place via conference
call on Tuesday, 17 July 2007 at 16:00 UTC, with the following agenda:

  1 Timeline for work
  2 Definition of quorum
  3 Constitutional principles (cont'd)
  4 Conclusion and administrivia
  5 Summary of 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 Timeline for work

  Mark opened this topic by observing that, according to the OpenJDK Charter,
  the Interim Governance Board will dissolve on 8 May 2008, one year after it
  was created.  This duration was intentionally written into the Charter so as
  to motivate the GB to complete its constitutional work in a timely fashion.
  The work could, theoretically, go on for longer than a year, but in order to
  get the Community fully up and running it'd be far better to finish sooner
  rather than later.

  Mark then suggested that the GB aim to have a draft Constitution by February
  or March of 2008, with a ratification election shortly thereafter, so that
  there's a good chance that the work can be finished before the GB dissolves.

  Simon proposed the more aggressive goal of having a draft document ready in
  December, saying that ratification is a very tricky problem, and we'll need
  plenty of time to discuss it and define the process.  Dalibor agreed, and
  said that November would be even better so that there would be six months for
  the discussion and the process.

  Simon elaborated on the OpenSolaris experience, in which that GB didn't
  publicly define and discuss the constitutional ratification process until
  after their Constitution was written.  The initial OpenSolaris GB, like the
  initial OpenJDK GB, was appointed rather than elected.  It had intended that
  the first elected OpenSolaris GB should review the Constitution and, if any
  mistakes were found, correct them and then re-ratify the resulting revised
  Constitution.  This intention was, however, not widely communicated, and as a
  result the ratification process was highly contentious because many people
  thought the initial Constitution was defective.

  Simon went on to say that, in terms of bootstrapping, the thinking in the
  OpenSolaris GB was that it first had to define freestanding rules by which
  the constitution could be changed, decree that they were in force, and then
  run the ratification process according to those rules.

  Reflecting on these experiences, Simon suggested that one of the first
  deliverables for this GB should be an initial definition of the ratification
  process.  That would allow plenty of time for open discussion and revision,
  so that by the time the ratification process actually begins it will be
  widely understood and trusted.

  Simon then proposed a high-level timeline, which after some discussion
  became:

          October 2007: Draft of ratification process
         December 2007: Draft of entire Constitution
    January-March 2008: Discussion period
            April 2008: Ratification vote

  It was then unanimously

    AGREED: To adopt the above timeline for the work of this GB.


2 Definition of quorum

  Mark stated that he'd prefer not to run these GB meetings using formal rules
  of order, but even so we should agree upon the definition of a quorum.  An
  easy answer would be to say that everyone must be present, but that could
  lead to intractable scheduling problems as we move from the summer vacation
  season into the busier parts of the year.

  Doug suggested that all-but-one might be a suitable compromise.  Fabiane
  agreed.  Dalibor agreed and proposed further distinguishing between
  decision-making meetings and brainstorming sessions, saying that all-but-one
  should be required for decision making but any number would be suitable for
  brainstorming.

  Simon argued against this proposal.  His view, based on past experience, is
  that when the total number of members is small then a formal vote should
  require that all members be present, though discussions need only require
  three.

  Mark observed that, although GB members are always free to speak with one
  another, if a brainstorming meeting is held then it should still be taken at
  least somewhat seriously, and in particular minutes should be generated even
  if no decisions are made.

  Dalibor suggested raising the discussion quorum back to four, on the basis
  that two members absent is nearly half the membership of this small group,
  and that it's easier to keep everyone in sync if most members are present for
  on-the-record discussions.

  The GB then unanimously

    AGREED: Formal votes shall require all members to be present.

    AGREED: On-the-record discussions shall require at least four
            members to be present.


3 Constitutional principles (cont'd)

  The constitutional principles discussion then resumed, with Mark proposing

    P8: The number of roles in the Community should be minimized.

  Mark observed that some open-source communities tend to create lots of
  structure with lots of different roles, usually with little tangible benefit.
  The OpenJDK Constitution should define as few roles as possible, and not
  allow new roles to be created gratuitously.  There was general agreement on
  this point.

  Mark then proposed his final principle:

    P9: Decisions at all levels should be made by informal consensus,
        calling votes only when absolutely necessary.

  Mark elaborated that this principle should apply not only to the GB but to
  all other bodies in the Community that need to make decisions.  He said that
  his proposal of this principle was driven partly by his perception of the
  decision-making practices of some other open-source communities, and in
  particular those of the Apache Software Foundation, to be overly formal and
  not all that conducive to constructive collaboration.

  Simon argued that Mark's perception was incorrect, saying that in fact the
  Apache model works quite well because, although it is precisely defined, it's
  treated as lazy consensus most of the time and, further, casting a negative
  (-1) vote is not seen as a blocking move but rather as volunteering to solve
  a problem that you've identified.  In actual use the Apache system is very
  relaxed and lightweight and, in Simon's opinion, about as close as possible
  to facilitating casual consensus while still having the rigor required to
  resolve difficult disputes.  He explained that this was consistent with Roy
  Fielding's view, expressed to the OpenSolaris GB, that the role of the
  constitution is to act as the boundary to acceptable behavior; most people
  operate far away from the boundary, but if you don't define the boundary then
  when boundary conditions occur you're left with no guidance.

  Simon went on to say that it's important that we not simply to adopt the
  voting rules of Apache, or indeed those of any other existing community, for
  use in OpenJDK, precisely because of this common kind of misperception.  It's
  difficult to understand how a community's decision-making rules work unless
  you've been part of that community, so the OpenJDK Community should develop
  and evolve its own set of rules, in accordance with its own needs and style.

  Mark replied that he was happy to have his perception of the Apache model
  corrected, and that he agreed that what Simon had said made sense.

  In turn Simon replied that he actually agrees with this proposed principle,
  it's just that it's important to recognize the need to have some rigor behind
  the notion of "informal consensus" so that when it fails there is something
  upon which to fall back.

  At this point Doug asked for clarification as to what kinds of decisions this
  principle is meant to apply.  Mark replied that it should be universally
  applicable, from low-level things like code reviews, to feature and release
  decisions, and on up to higher-level community-governance sorts of decisions
  such as recognizing new community members, creating new groups and projects,
  electing GB members, and ratifying and revising the Constitution.

  Simon gave the example of a recent vote in the Apache Harmony project which
  used the second-most relaxed style of that community's four voting styles to
  come to a decision on building a regression-testing framework.  A vote on a
  more serious issue in Apache, e.g., modifying the constitution, would use a
  more rigorous voting style that requires a longer review period and restricts
  whose votes are actually counted.  In an Apache discussion anyone who wants
  to can vote, and even though only some votes count it's unusual for a vote to
  complete without all of the negative votes having been discussed, regardless
  of who cast them.  Every kind of decision in the Apache community is made
  using one of their four voting styles, each of which has a different level of
  rigor and places different responsibilities upon voters.

  It was generally AGREED that this principle should be adopted, revised
  thusly:

    P9: Decisions at all levels should be made by informal consensus
        whenever possible, but there should also be rigorous voting
        rules upon which to fall back when informal consensus fails.

  The discussion then turned to Fabiane's proposals, the first of which was

    P10: Leaders of Community groups should participate in
         Community-wide decisions.

  Mark noted that this principle seems to imply that community-wide decisions
  would be made not by everyone in the community who has a vote but rather just
  by the leaders of the community's groups.  Fabiane indicated that having
  everyone vote could lead to problems of scale in a large community, and that
  it made sense to her to have group leaders with some sort of privileged vote.

  In reply Mark observed that identifying the leader, or leaders, of a group
  can actually be a bit of a problem.  The social dynamic within the Sun JDK
  team is that there's not a well-defined leader for every group, and in fact
  there are some groups whose social nature is such that if you tried to
  identify a leader then their members would get very upset.

  Doug agreed that trying to identify people as leaders does invite social
  friction, and it'd be nice to avoid that, but somebody has to be in charge of
  some things.

  Mark agreed, and explained further that this is why the interim rules for
  Groups and Projects use the concept of a Moderator rather than that of a
  leader.  A Moderator is more of a contact point and coordinator rather than
  someone with some extra kind of decision authority that goes beyond those of
  the members of the group.

  Dalibor asked Fabiane how this works in the java.net Tools Community, which
  she herself co-leads.  Fabiane replied that in java.net each community has a
  leader, or set of leaders.  When a java.net-wide decision needs to be made,
  e.g., on whether to approve the creation of a new community, the community
  leaders are the ones who vote.  Each community has its own rules on how to
  select its leaders.  People don't fight to be community leaders; usually it's
  a matter of finding someone who will accept the position.

  Mark suggested that this issue be tabled for now, suspecting that whether or
  not we need strong group leaders with special voting privileges will become
  clearer over time as we develop a better sense of the sorts of community-wide
  decisions that will be made.

  Fabiane agreed to this.  Doug noted that probably the best thing we can do is
  arrange things so that natural group leaders, or moderators, can emerge on
  their own and have the freedom of action they need in order to be effective.

    OPEN ISSUE: Should the Constitution grant special powers to identified
                leaders of community groups?  Should community-wide decisions
                be made by group leaders rather than by all participants
                with appropriate voting rights?

  Fabiane's next suggestion was that the Constitution will have to define
  processes for creating and dissolving groups, projects, and other kinds of
  Community entities.  It was agreed that this will be necessary.

  Fabiane's third suggestion had been discussed and agreed earlier, as P3.

  Fabiane's next proposed principle was

    P11: Participation in the Community shall be free of charge.

  She said that she thinks this idea is pretty obvious yet important to make
  clear, since some communities that she's worked in do require payment for
  participation.  Everyone agreed to this principle.

  Fabiane's final principle was:

    P12: All decision-making processes and discussions should be
         as transparent as possible.

  She clarified that she didn't mean to suggest that the entire community
  should be involved in every decision, but rather that it must be possible for
  everyone to see what decisions are being made at every level, and why, and be
  able to voice their opinions in order to try to influence them even if they
  don't themselves have a vote.  This principle was readily agreed to, given
  that it echoed the resolutions adopted earlier with regard to the working
  style of the GB itself.

  This concluded the GB's two-part discussion of constitutional principles.


4 Conclusion and administrivia

  To move forward, Mark suggested that a useful way to start thinking about the
  Constitution as a document would be to list all of the concepts that we think
  we need to define and then start drafting definitions so that we can consider
  the relationships between them.  This can largely be done in e-mail, with GB
  meetings called only as needed.

  After additional discussion, and confirmation in e-mail, it was

    AGREED: The GB members shall hold one hour open, at 0800 Pacific time
            every Thursday, for a potential GB conference call.  Any member
            may call an actual meeting during this hour by giving two days'
            notice to the membership.  If no such notice is given then no
            meeting will be held.

  At this point the GB adjourned.


5 Summary of principles

  In its first two meetings the GB membership AGREED to the following initial,
  though non-exhaustive, set of constitutional principles:

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

    P2: Community participants are individuals, not corporations.

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

    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.

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

    P6: Community privileges do not last forever.

    P7: Community governance is distinct from project governance.

    P8: The number of roles in the Community should be minimized.

    P9: Decisions at all levels should be made by informal consensus
        whenever possible, but there should also be rigorous voting
        rules upon which to fall back when informal consensus fails.

    P11: Participation in the Community shall be free of charge.

    P12: All decision-making processes and discussions should be
         as transparent as possible.

[end]

From robilad at kaffe.org  Sat Oct  6 08:23:54 2007
From: robilad at kaffe.org (Dalibor Topic)
Date: Sat, 06 Oct 2007 17:23:54 +0200
Subject: OpenJDK GB Minutes posted
In-Reply-To: <20071004190733.7235662F8@eggemoggin.niobe.net>
References: <20071004190733.7235662F8@eggemoggin.niobe.net>
Message-ID: <4707A88A.70401@kaffe.org>

Mark Reinhold wrote:
> The minutes of the first two OpenJDK GB meetings have been posted to the
> gb-discuss list [1] and to the web [2,3], with a summary in my blog [4].
> 
> Please direct comments and questions to the gb-discuss list.  You'll need
> to subscribe first if you haven't already; messages from non-subscribers
> are discarded in order to avoid spam.
> 

Thank you very much for posting the minutes, Mark, and for the extensive
write up of the discussion. They must have been a lot of work to make,
so a round of applause is in order.

I wanted to add that there is another set of minutes from an OpenJDK TCK
license related IGB phone conference forthcoming, where I had the chance
to ask Carla a lot of questions (and receive answers) about the legalese
and its practical effects.

I solicited the questions from Andrew Haley, Matthias Klose, Christian
Thalinger, and others, and did it on IRC/via the phone as the whole
OpenJDK TCK license happened rather quickly. I think the conference call
was announced to our regular slot two days before it happened. The
minutes for that call would provide a useful document for the public
discussing[1] the creation of the conformance group, so I hope that
we'll get them pushed out as soon as possible.

That's in particular related to the IGB, as per
http://openjdk.java.net/groups/ the IGB will need to vote on the
creation of the new group after Friday, the 12th October.

Since we'll have a face to face IGB meeting on Sunday, the 14th October,
I would like to make the

	PROPOSAL

that the IGB votes on the creation of the OpenJDK conformance group, and
that the IGB votes whether the OpenJDK conformance group has the power
to grant Membership at the face to face meeting of the OpenJDK IGB. [2]

cheers,
dalibor topic

[1] http://thread.gmane.org/gmane.comp.java.openjdk.general/425/focus=435
[2] Pardon my odd typography, I'm new at this. I also hope that this
format will be easier for mr to summarize in minutes.


From robilad at kaffe.org  Sat Oct  6 08:57:43 2007
From: robilad at kaffe.org (Dalibor Topic)
Date: Sat, 06 Oct 2007 17:57:43 +0200
Subject: OpenJDK GB Minutes posted
In-Reply-To: <4707A88A.70401@kaffe.org>
References: <20071004190733.7235662F8@eggemoggin.niobe.net>
	<4707A88A.70401@kaffe.org>
Message-ID: <4707B077.40702@kaffe.org>

Dalibor Topic wrote:
> I wanted to add that there is another set of minutes from an OpenJDK TCK
> license related IGB phone conference forthcoming, where I had the chance
> to ask Carla a lot of questions (and receive answers) about the legalese
> and its practical effects.

I was a bit imprecise there, so: the number of elements in that set is 1.

cheers,
dalibor topic


From mr at sun.com  Mon Oct  8 16:12:56 2007
From: mr at sun.com (Mark Reinhold)
Date: Mon, 08 Oct 2007 16:12:56 -0700
Subject: OpenJDK GB Minutes posted 
In-Reply-To: robilad@kaffe.org; Sat, 06 Oct 2007 17:23:54 +0200;
	<4707A88A.70401@kaffe.org> 
Message-ID: <20071008231256.ABEBF62F8@eggemoggin.niobe.net>

> Date: Sat, 06 Oct 2007 17:23:54 +0200
> From: Dalibor Topic <robilad at kaffe.org>

> ...
> 
> That's in particular related to the IGB, as per
> http://openjdk.java.net/groups/ the IGB will need to vote on the
> creation of the new group after Friday, the 12th October.
> 
> Since we'll have a face to face IGB meeting on Sunday, the 14th October,
> I would like to make the
> 
> 	PROPOSAL
> 
> that the IGB votes on the creation of the OpenJDK conformance group, and
> that the IGB votes whether the OpenJDK conformance group has the power
> to grant Membership at the face to face meeting of the OpenJDK IGB. [2]

Sounds good to me.  I suspect at least some of us will be traveling on
Friday 10/12 anyway, so there's not much point in starting an e-mail vote
that day.

- Mark


From robilad at kaffe.org  Tue Oct  9 05:32:38 2007
From: robilad at kaffe.org (Dalibor Topic)
Date: Tue, 09 Oct 2007 14:32:38 +0200
Subject: OpenJDK GB Minutes posted
In-Reply-To: <20071008231256.ABEBF62F8@eggemoggin.niobe.net>
References: <20071008231256.ABEBF62F8@eggemoggin.niobe.net>
Message-ID: <470B74E6.7040006@kaffe.org>

Mark Reinhold wrote:
>> Date: Sat, 06 Oct 2007 17:23:54 +0200
>> From: Dalibor Topic <robilad at kaffe.org>
> 
>> ...
>>
>> That's in particular related to the IGB, as per
>> http://openjdk.java.net/groups/ the IGB will need to vote on the
>> creation of the new group after Friday, the 12th October.
>>
>> Since we'll have a face to face IGB meeting on Sunday, the 14th October,
>> I would like to make the
>>
>> 	PROPOSAL
>>
>> that the IGB votes on the creation of the OpenJDK conformance group, and
>> that the IGB votes whether the OpenJDK conformance group has the power
>> to grant Membership at the face to face meeting of the OpenJDK IGB. [2]
> 
> Sounds good to me.  I suspect at least some of us will be traveling on
> Friday 10/12 anyway, so there's not much point in starting an e-mail vote
> that day.
> 

Yeah. But in order to have the necessary background for the discussion,
I'd like to see the TCK teleconference minutes published as soon as
possible.

Otherwise, I'd actually prefer delaying the vote until after those
minutes are published and the community has had a chance to take them as
input, as they are related to the proposed new group, touching on the
issue of what is actually considered 'confidential' in the scope of the
OpenJDK TCK license, for example.

I think having the minutes in published form is necessary for the
background of the discussion of potential implications of the creation
of the second mailing list in that proposal, which was the main
direction of the discussion so far, afaict.

cheers,
dalibor topic


From robilad at kaffe.org  Thu Oct 11 04:04:25 2007
From: robilad at kaffe.org (Dalibor Topic)
Date: Thu, 11 Oct 2007 13:04:25 +0200
Subject: issue list for face to face meeting on 14th from the published minutes
Message-ID: <470E0339.5090706@kaffe.org>

Hi all,

I've gone through the minutes and collected the things that were left
for discussion at the face to face meeting.

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

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

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

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

* OPEN ISSUE 	Should the Constitution grant special powers to identi?ed
leaders of community groups? Should community-wide decisions be made by
group leaders rather than by all participants with appropriate voting
rights?

cheers,
dalibor topic


From robilad at kaffe.org  Thu Oct 11 04:36:47 2007
From: robilad at kaffe.org (Dalibor Topic)
Date: Thu, 11 Oct 2007 13:36:47 +0200
Subject: issue list for face to face meeting on 14th from the published
	minutes
In-Reply-To: <470E0339.5090706@kaffe.org>
References: <470E0339.5090706@kaffe.org>
Message-ID: <470E0ACF.6010208@kaffe.org>

Dalibor Topic wrote:
> Hi all,
> 
> I've gone through the minutes and collected the things that were left
> for discussion at the face to face meeting.
> 

A bunch of further points:

* The time plan[1] in the published minutes calls for a draft of the
ratification process in October. So we should discuss how to go about
that efficiently.

* I've received some feedback in private about the quietness of some
OpenJDK mailing lists. While I believe that's a side effect of the
current infrastructure [2], that will vanish some time after the big
switch to mercurial, I'd like to bring this to the attention of the IGB
as something we should keep an eye on for now, and return to a month or
two after the mercurial switch to see if the situation has changed.

cheers,
dalibor topic

[1] http://openjdk.java.net/groups/gb/2007-07-17.html
[2] http://www.javalobby.org/java/forums/t101953.html?start=30#92175135


From dl at cs.oswego.edu  Fri Oct 12 05:37:09 2007
From: dl at cs.oswego.edu (Doug Lea)
Date: Fri, 12 Oct 2007 08:37:09 -0400
Subject: issue list for face to face meeting on 14th from the published
	minutes
In-Reply-To: <470E0339.5090706@kaffe.org>
References: <470E0339.5090706@kaffe.org>
Message-ID: <470F6A75.6000208@cs.oswego.edu>

Dalibor Topic wrote:

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

I did ask people from a few places from which we might expect
contributions. I'll report responses. Quick preview: There seem
to be some minor (and I think/hope easily addressable) concerns about
SCA and contribution process.

-Doug




From atripp at jazillian.com  Tue Oct 16 12:15:03 2007
From: atripp at jazillian.com (Andy Tripp)
Date: Tue, 16 Oct 2007 15:15:03 -0400
Subject: Some thoughts about OpenJDK Constitution
Message-ID: <47150DB7.6010407@jazillian.com>

Here are some random thoughts on the OpenJDK constitution.

I assume you're way ahead on this, but using the
OpenSolaris constitution as a starting point would make sense.

One thing that the constitution should be explicit about is the scope of
"the OpenJDK Community". From your first two meeting minutes, you seem to
be clearly headed towards covering just the OpenJDK implementation, not
other implementations or the Java development community in general.
Clarity on this in the constitution is needed so that later
you don't get stuck if confronted with
an issue where you have to decide between what's best for
the OpenJDK community and what's best for some larger community.

The constitution should specify the bounds of the JDK:
Is the TCK considered part of the OpenJDK?
Are licensing issues part of OpenJDK?
Is compatibility with other implementations considered part of the OpenJDK?

What will your relationship be with alternative implementations? For 
example,
should you be having any discussions about Harmony at all? At what point 
would IcedTea
be considered a part of the JDK? Will you support the interests of 
OpenJDK only,
or also other implementations? For example, suppose you need to handle a 
dispute or a
request that involves an alternate implementation; would it matter 
whether that alternate
is Harmony, Classpath, or (a not-yet-merged) IcedTea? Or suppose you 
need to choose
between two competing implementations for a new feature, say one from 
Sun and one
from IcedTea. What would be the guiding principles for choosing?

What will be your stance be on "Open Source" and "Free Software"? I 
noticed that
in your first two meetings, you often talked about "open source" but rarely
about "free". The OpenSolaris constitution mentions "Open source" and 
the OSI,
but never "free software" and the FSF. The easy answer is "we're both", but
what if some issue comes down to "that goes against what Free Software 
is all about"?
Is Freedom a goal? For that matter, assuming that "Open Source" a goal, 
should that
be stated in the constitution? And if stated, should you specify
that OSI compliance is a goal, do you say something about "Open Source 
principles",
or just leave it ambiguous? The reason I bring this up is that if you 
look at the current
TCK/Harmony issue, you might find that it comes down to whether to 
follow the
spirit or the letter of "open source". Better to get the GB all on the 
same page
of guiding principles right off the bat.

What will the relationship be between the GB (and OpenJDK in general) 
and Sun?
The OpenSolaris contitution simply says that their GB is the "official 
liaison" to Sun.
I think this may be too vague. For example, if OpenJDK decides on a 
change, but the
Sun employees can't or won't make the change, what happens? What's the 
relationship
between the GB/OpenJDK and the JCP?

Will there be any mechanism to avoid "ballot stuffing", for both the GB
and the groups, such as Microsoft just
did with OSI for OOXML? What's to stop one company from adding
a few hundred JCP members and controlling the JCP elections and the GB?

I'm surprised that the OpenSolaris constitution says nothing about 
overall principles.
I think it should state some guiding principles, such as:
* The ongoing maintenance, enhancement, and viability of OpenJDK
* Increased community participation in OpenJDK development
* Collaboration with alternative implementations (or not)
* Collaboration with ports of the reference implementation (or not)
* Adherence to principles of Open Source and/or Free Software (or not)

Finally, you say the GB will be both a legislative and a judicial "branch".
But I haven't seen what "laws" or rules the GB would be creating, so I 
don't
see how it's legislative. Will the GB have any role in creating rules, 
or is
it strictly for settling disputes?

I hope you find these thoughts useful.
Thanks for making the process open, and good luck with it.

Andy Tripp



From David.Herron at Sun.COM  Wed Oct 24 11:30:05 2007
From: David.Herron at Sun.COM (David Herron)
Date: Wed, 24 Oct 2007 11:30:05 -0700
Subject: Some thoughts about OpenJDK Constitution
In-Reply-To: <47150DB7.6010407@jazillian.com>
References: <47150DB7.6010407@jazillian.com>
Message-ID: <471F8F2D.2020404@sun.com>

Hi Andy, you've got some great questions and ideas here.

The core thing I see here is a matter of 'scope', what scope does the 
OpenJDK community encompass?

I know we at Sun in establishing the OpenJDK project intend the scope to 
be just the source code of Sun's JDK.

For example...

'Compatibility with other implementations': That's the job of the JCP.. 
because it's the JCP and JSR's and TCK's which define compatibility with 
the specification.  It's the joint compatibility with the specification 
which determines compatibility between Java implementations.

Um, as the Quality rep in this... I can say that we at Sun are doing 
testing of the jdk7 binary builds and are trusting that since the source 
for openjdk and jdk7 is almost entirely the same that jdk7 testing is 
enough to ensure the openjdk is good quality.  But we generally don't do 
specific testing of openjdk builds.

'TCK considered part of the OpenJDK': Um.. this raises some interesting 
questions for me, that are related to the proposed Conformance group.  
I'm thinking the Java TCK (JCK) belongs in the JCP scope rather than the 
OpenJDK scope.  All TCK's are defined as part of a JSR, and the JCK is 
no different.

Those are all the thoughts I have, and I wish to thank you for stirring 
up some good thinking on my part.  I hope to help stir others to discussion.

- David Herron



Andy Tripp wrote:
> Here are some random thoughts on the OpenJDK constitution.
>
> I assume you're way ahead on this, but using the
> OpenSolaris constitution as a starting point would make sense.
>
> One thing that the constitution should be explicit about is the scope of
> "the OpenJDK Community". From your first two meeting minutes, you seem to
> be clearly headed towards covering just the OpenJDK implementation, not
> other implementations or the Java development community in general.
> Clarity on this in the constitution is needed so that later
> you don't get stuck if confronted with
> an issue where you have to decide between what's best for
> the OpenJDK community and what's best for some larger community.
>
> The constitution should specify the bounds of the JDK:
> Is the TCK considered part of the OpenJDK?
> Are licensing issues part of OpenJDK?
> Is compatibility with other implementations considered part of the 
> OpenJDK?
>
> What will your relationship be with alternative implementations? For 
> example,
> should you be having any discussions about Harmony at all? At what 
> point would IcedTea
> be considered a part of the JDK? Will you support the interests of 
> OpenJDK only,
> or also other implementations? For example, suppose you need to handle 
> a dispute or a
> request that involves an alternate implementation; would it matter 
> whether that alternate
> is Harmony, Classpath, or (a not-yet-merged) IcedTea? Or suppose you 
> need to choose
> between two competing implementations for a new feature, say one from 
> Sun and one
> from IcedTea. What would be the guiding principles for choosing?
>
> What will be your stance be on "Open Source" and "Free Software"? I 
> noticed that
> in your first two meetings, you often talked about "open source" but 
> rarely
> about "free". The OpenSolaris constitution mentions "Open source" and 
> the OSI,
> but never "free software" and the FSF. The easy answer is "we're 
> both", but
> what if some issue comes down to "that goes against what Free Software 
> is all about"?
> Is Freedom a goal? For that matter, assuming that "Open Source" a 
> goal, should that
> be stated in the constitution? And if stated, should you specify
> that OSI compliance is a goal, do you say something about "Open Source 
> principles",
> or just leave it ambiguous? The reason I bring this up is that if you 
> look at the current
> TCK/Harmony issue, you might find that it comes down to whether to 
> follow the
> spirit or the letter of "open source". Better to get the GB all on the 
> same page
> of guiding principles right off the bat.
>
> What will the relationship be between the GB (and OpenJDK in general) 
> and Sun?
> The OpenSolaris contitution simply says that their GB is the "official 
> liaison" to Sun.
> I think this may be too vague. For example, if OpenJDK decides on a 
> change, but the
> Sun employees can't or won't make the change, what happens? What's the 
> relationship
> between the GB/OpenJDK and the JCP?
>
> Will there be any mechanism to avoid "ballot stuffing", for both the GB
> and the groups, such as Microsoft just
> did with OSI for OOXML? What's to stop one company from adding
> a few hundred JCP members and controlling the JCP elections and the GB?
>
> I'm surprised that the OpenSolaris constitution says nothing about 
> overall principles.
> I think it should state some guiding principles, such as:
> * The ongoing maintenance, enhancement, and viability of OpenJDK
> * Increased community participation in OpenJDK development
> * Collaboration with alternative implementations (or not)
> * Collaboration with ports of the reference implementation (or not)
> * Adherence to principles of Open Source and/or Free Software (or not)
>
> Finally, you say the GB will be both a legislative and a judicial 
> "branch".
> But I haven't seen what "laws" or rules the GB would be creating, so I 
> don't
> see how it's legislative. Will the GB have any role in creating rules, 
> or is
> it strictly for settling disputes?
>
> I hope you find these thoughts useful.
> Thanks for making the process open, and good luck with it.
>
> Andy Tripp
>



From robilad at kaffe.org  Wed Oct 24 16:54:56 2007
From: robilad at kaffe.org (Dalibor Topic)
Date: Thu, 25 Oct 2007 01:54:56 +0200
Subject: Some thoughts about OpenJDK Constitution
In-Reply-To: <47150DB7.6010407@jazillian.com>
References: <47150DB7.6010407@jazillian.com>
Message-ID: <471FDB50.6000106@kaffe.org>

Andy Tripp wrote:
> Here are some random thoughts on the OpenJDK constitution.

Thank you for posting them, Andy.

> One thing that the constitution should be explicit about is the scope of
> "the OpenJDK Community". From your first two meeting minutes, you seem to
> be clearly headed towards covering just the OpenJDK implementation, not
> other implementations or the Java development community in general.

It's a self-bootstrapping definition. We're starting with the simplest
definition of community we have, and as the OpenJDK project adds further
groups & projects, I believe the boundary of what constitutes the
OpenJDK community will become less and less OpenJDK implementation
specific, and expand to include hybrid implementations, for example.

> The constitution should specify the bounds of the JDK:
> Is the TCK considered part of the OpenJDK?

As long as its code is not published as part of OpenJDK, probably no.

But the proposed conformance group, otoh, would be part of the OpenJDK
community, even if some of the tools it uses aren't.

> Are licensing issues part of OpenJDK?

Licensing changes are out of reach of the (interim) governance board per
its charter, if that's what you mean.

> Is compatibility with other implementations considered part of the OpenJDK?

That's what we have the JCP, and the OpenJDK TCK license for.

> What will your relationship be with alternative implementations? 

Good, I hope!

> For
> example,
> should you be having any discussions about Harmony at all? 

As long as they relate to development on OpenJDK, sure, why not.

> At what point
> would IcedTea
> be considered a part of the JDK? 

s/JDK/OpenJDK.

Once there is an official group / project proposal and it's accepted.

> What will be your stance be on "Open Source" and "Free Software"?

To borrow a bit from Simon Phipps, I'd call OpenJDK "Free Software
developed in an Open Source fashion".

But to me, personally, both are rather interchangeable, and I use one
when I want to emphasize the liberties, and the other one when I want to
emphasize the process.

> The reason I bring this up is that if you
> look at the current
> TCK/Harmony issue, you might find that it comes down to whether to
> follow the
> spirit or the letter of "open source". Better to get the GB all on the
> same page
> of guiding principles right off the bat.

The TCK is orthogonal to OpenJDK's Free Software status. You don't need
the TCK in order to use, learn from, modify, or distribute OpenJDK, or
to contribute to it.

You need it if you want additional privileges and compatibility
guarantees (which are all very desirable things, of course).

> What will the relationship be between the GB (and OpenJDK in general)
> and Sun?

That remains to be formalized.

> What's the
> relationship
> between the GB/OpenJDK and the JCP?

Orthogonal. See http://www.sun.com/software/opensource/java/faq.jsp#l

I'd expect OpenJDK to have a bit of a halo effect on JSR RIs going into
it, as it makes sense to develop them with the OpenJDK community, rather
then behind closed doors.

But I don't expect OpenJDK or the GB to take (or even desire) a formal
role in the JCP as such.

> Will there be any mechanism to avoid "ballot stuffing", for both the GB
> and the groups, such as Microsoft just
> did with OSI for OOXML?

s/OSI/ISO.

OpenJDK != ISO, so paying a few thousand dollars here and there won't
get Microsoft influence. Coincidentally, We've discussed in our face to
face meeting how to avoid control of the GB by a single entity, and I
hope we'll get the minutes published soon.

> What's to stop one company from adding
> a few hundred JCP members and controlling the JCP elections and the GB?

JCP members != OpenJDK members.

In general, the interim rules, afair, require members to be approved by
their peers. That should suffice to avoid egregious stuffing, I hope.

> I think it should state some guiding principles, such as:
> * The ongoing maintenance, enhancement, and viability of OpenJDK
> * Increased community participation in OpenJDK development
> * Collaboration with alternative implementations (or not)
> * Collaboration with ports of the reference implementation (or not)
> * Adherence to principles of Open Source and/or Free Software (or not)

Thank you, those are all good suggestions, and I'd put them on the
agenda for the next call, with your approval.

> Finally, you say the GB will be both a legislative and a judicial "branch".
> But I haven't seen what "laws" or rules the GB would be creating, so I
> don't
> see how it's legislative. Will the GB have any role in creating rules,
> or is
> it strictly for settling disputes?

Legislative: changes to the constitution, charter, defining membership,
voting, etc.
Judical: actual dispute resolution.

There are some legislative necessities to be dealt with by the GB per
charter, but I am sure no one on the current IGB has legislative
ambitions that go far beyond that, as the minutes of the phone calls show.

We haven't really discussed a way to formalize dispute resolution yet.

> I hope you find these thoughts useful.
> Thanks for making the process open, and good luck with it.

Thanks, Andy, and thank you for contributing to make them better.

cheers,
dalibor topic


From atripp at jazillian.com  Fri Oct 26 11:30:57 2007
From: atripp at jazillian.com (Andy Tripp)
Date: Fri, 26 Oct 2007 14:30:57 -0400
Subject: Some thoughts about OpenJDK Constitution
In-Reply-To: <471FDB50.6000106@kaffe.org>
References: <47150DB7.6010407@jazillian.com> <471FDB50.6000106@kaffe.org>
Message-ID: <47223261.7030801@jazillian.com>

An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/gb-discuss/attachments/20071026/2988048c/attachment.html 

From robilad at kaffe.org  Mon Oct 29 06:06:14 2007
From: robilad at kaffe.org (Dalibor Topic)
Date: Mon, 29 Oct 2007 14:06:14 +0100
Subject: Some thoughts about OpenJDK Constitution
In-Reply-To: <47223261.7030801@jazillian.com>
References: <47150DB7.6010407@jazillian.com> <471FDB50.6000106@kaffe.org>
	<47223261.7030801@jazillian.com>
Message-ID: <4725DAC6.7090407@kaffe.org>

Andy Tripp wrote:
> Hi Dalibor,
> Thanks for responding. I was starting to wonder if anyone was out there :)
> Great responses, and great work so far on the GB.
Thanks, Andy.
> I just have a few responses.
>
>>   
>>> One thing that the constitution should be explicit about is the scope of
>>> "the OpenJDK Community". From your first two meeting minutes, you seem to
>>> be clearly headed towards covering just the OpenJDK implementation, not
>>> other implementations or the Java development community in general.
>>>     
>>
>> It's a self-bootstrapping definition. We're starting with the simplest
>> definition of community we have, and as the OpenJDK project adds further
>> groups & projects, I believe the boundary of what constitutes the
>> OpenJDK community will become less and less OpenJDK implementation
>> specific, and expand to include hybrid implementations, for example.
>>   
> Just to pick a hypothetical situation to help you think about the 
> scope of OpenJDK...
> suppose you end up with two implementations of the encumbered parts - 
> both IcedTea
> and Sun-developed code. If the GB constitution says that it's 
> concerned only
> with current OpenJDK projects, the GB would have no basis for doing 
> anything involving
> IcedTea (such as helping to figure out how some of their stuff might 
> be incorporated
> into OpenJDK or encourage them to become an OpenJDK project).

The GB has no way of faithfully micro-managing the projects inside 
OpenJDK: it is unlikely
that it would always have the necessary expertise to make informed 
choices about, for example,
the technical merits of alternative implementations.

That's something the groups/projects working with the code in question 
would decide on
autonomously.

Otoh, growing the OpenJDK community in a healthy fashion is something 
that's implied in
GB's charter, so I consider helping related projects find their way into 
becoming part
of the OpenJDK community to be an important part of the task.

>>> The constitution should specify the bounds of the JDK:
>>> Is the TCK considered part of the OpenJDK?
>>>     
>>
>> As long as its code is not published as part of OpenJDK, probably no.
>>
>> But the proposed conformance group, otoh, would be part of the OpenJDK
>> community, even if some of the tools it uses aren't.
>>   
> OK, so that says to me that the GB really shouldn't be concerned with 
> TCK issues and
> Harmony issues. Looking back at the meeting minutes from the first 
> meeting, there looked
> to be a non-trivial discussion on these.
The problems the Apache Harmony project has with getting the JSE 1.5 TCK 
under a license
acceptable to it are of interest to some OpenJDK (IGB) members, like 
myself.  But it's nothing
we can really aspire to 'fix' via the OpenJDK project governance, until 
either Apache Harmony
or the JSE TCK become parts of it in one way or another.
>>> What will your relationship be with alternative implementations? 
>>>     
>>
>> Good, I hope!
>>   
> Well, you need to choose between "good" and "nonexistant" :)
Wherever we can share code, a relationship will exist, and I'd work on 
making it a good one (though
my focus is on the Free Software implementations, personally).

It's much harder to build a web of relationships without any code to share,
in particular as OpenJDK is very code-centric.

>>> For
>>> example,
>>> should you be having any discussions about Harmony at all? 
>>>     
>>
>> As long as they relate to development on OpenJDK, sure, why not.
>>   
> Yes, that makes sense. Again, I ask because it sounded like the 
> discussion of Harmony
> in the first meeting went beyond that. I don't mean to sound paranoid 
> about any discussion
> of Harmony, it's just that I think it could be very easy to make 
> decisions based on
> Harmony. I could imagine a discussion on some OpenJDK feature containing
> the argument "...but we should do X because that would benefit Harmony 
> and other
> implementations". To which the appropriate response (IMO) would be "But we
> have never established whether helping other implementations is a good 
> thing or not".
I wouldn't want to see the GB to make decisions on features.

If other implementations start using and contributing to OpenJDK's code 
base, I'd expect their
developers to become members of the parts they contribute to, and to 
influence such decisions on
the appropriate level.

>>> At what point
>>> would IcedTea
>>> be considered a part of the JDK? 
>>>     
>>
>> s/JDK/OpenJDK.
>>
>> Once there is an official group / project proposal and it's accepted.
>>   
> So if the constitution says something along the lines of "...current 
> OpenJDK projects...", then
> discussions like "how can we encourage IcedTea to become an OpenJDK 
> project?" might
> be technically out of bounds.
As long as there is no constitution, there are no bounds, technically. :)

I think that putting in a preamble that the GB's mandate is to work 
(among other things) to help the
OpenJDK community grow and prosper would cover 'community building' efforts.
>>> What will be your stance be on "Open Source" and "Free Software"?
>>>     
>>
>> To borrow a bit from Simon Phipps, I'd call OpenJDK "Free Software
>> developed in an Open Source fashion".
>>
>> But to me, personally, both are rather interchangeable, and I use one
>> when I want to emphasize the liberties, and the other one when I want to
>> emphasize the process.
>>   
> The question I'm raising here is, suppose in your discussions on some 
> issue you say "...we should
> do X because it's in the spirit of FOSS". Unless you've established 
> that the "spirit of FOSS"
> is a goal, the argument holds no weight. So I guess I'm just 
> suggesting a simple
> "we support the principles of Free Software and Open Source Software" 
> type of statement
> somewhere. 

Sounds good to me.

>>> What's to stop one company from adding
>>> a few hundred JCP members and controlling the JCP elections and the GB?
>>>     
>>
>> JCP members != OpenJDK members.
>>
>> In general, the interim rules, afair, require members to be approved by
>> their peers. That should suffice to avoid egregious stuffing, I hope.
>>   
> Yes, OK. I guess this comes down to how the GB is elected, which to be 
> defined in the constitution.
>
> Putting on my paranoid-of-Microsoft hat, I picture a new OpenJDK group 
> getting formed that
> happens to have a MS or MS-friendly expert group lead. He puts 1000 MS 
> employees on the
> expert group in an attempt to influence all elections. I know that 
> sounds paranoid, but hey,
> just look at what they've actually done :) Alternatively, IBM could do 
> something similar
> with a group who attempts to give Harmony an advantage.
Different election models make sense for different communities. :)

We have discussed how to avoid the problem of a single company
having the majority on the GB. I think one could limit the number of GB 
members per
group/project to two, maximally, if stuffing the groups with members 
turns out to be a
problem or introduce a staged election process, where each group can 
propose up to two
candidates for the GB elections, for example.

I'm not sure that concern is warranted, though, given the current size 
of the community,
and given that the GB can dissolve groups, if it turns out that a group 
acts to harm the
OpenJDK project, for example.

>>> Finally, you say the GB will be both a legislative and a judicial "branch".
>>> But I haven't seen what "laws" or rules the GB would be creating, so I
>>> don't
>>> see how it's legislative. Will the GB have any role in creating rules,
>>> or is
>>> it strictly for settling disputes?
>>>     
>>
>> Legislative: changes to the constitution, charter, defining membership,
>> voting, etc.
>> Judical: actual dispute resolution.
>>
>> There are some legislative necessities to be dealt with by the GB per
>> charter, but I am sure no one on the current IGB has legislative
>> ambitions that go far beyond that, as the minutes of the phone calls show.
>>   
> OK. Clearly absent from your "Legislative" list above is "passing new 
> laws" - you might want to
> be explicit about that in the constitution, because I always think of 
> a constitution as mainly about
> how new laws are formed and bounded.
I'd prefer to avoid adding more layers of pseudo-legalese, so I'd be 
quite happy if the only 'law' the
IGB ever gets to deal with is the constitution. Later GBs can change the 
constitution accordingly.
>> We haven't really discussed a way to formalize dispute resolution yet.
>>   
> That seems like the easy part to me :) Have a hearing and simple 
> majority rules.

The way it works in gcc is that the 'GB' politely and repeatedly reminds 
people that they should
behave as reasonable adults, and figure out for themselves how to solve 
the dispute, until they
start behaving as reasonable adults. That may take some time, in some 
cases, as can be expected,
and in general results in people not liking the lazy governance body too 
much. :)

A process that makes it easy to obtain fast decisions can have a 
counter-productive effect of
encouraging people to drag conflicts to the decision body, rather than 
cooling off, and solving
them themselves. So I'd like to give the GB ample time to deal with 
disputes, say 6-12 months,
before coming to a decision. If an issue really persists over the course 
of 12 months without
a solution, then it is probably something that the GB needs to deal 
with, one way or another.

cheers,
dalibor topic