Conference Consensus

Governance Agenda

Ground rules
What and who are the Sakai community (membership)?
What is included in the Sakai project?
What should be funded "centrally"?
Who "owns" the code (IP and risk mitigation)?
What's the Board and what does the Board do?

John's 4 Tests

• Do we agree?
• Do we need to decide now?
• Can we decide later?
• Can we agree to disagree?

Resolved:

1. There will be a strong central board!
2. All organizational members have one vote (TBD what's a member)
3. The Sakai Foundation will be formed to "own" the code to account for IP and risk mitigation purposes. The Educational Community License will be used for licensing purposes. (Do it like Apache!)

Proposed:

The board is accountable for general direction and vision, cultivate the community and define the core set of deliverables around a set of principles and values (tbd)

Governance Discussion-Marathon Map

A great many things were said, and the conversation folded back on itself many times. What appears below represents not the chronology of the discussion, nor the minutes, since established points of consensus were few in number. It seemed best to try and simply map out the discussion space, and try to give representation to every point raised. My apologies for the extent to which this was limited by my typing speed and required my paraphrases, but the end result seems a reasonably fair representation of the diversity of opinions. That said, this is still a work in progress - some of the points more difficult to categorize are not in yet, and some that are there should be grouped in more readable ways.

Items appearing in red are clarifying remarks from a sitting Board member or discussion leader.

Joseph's Brief History of Time

The Initial Grant

• Four schools realized they needed a next-generation system for various reasons (standards and innovation, collaboration, etc.)
• Mellon had all four schools commit at provost level to run Sakai
• Codebase came from all over: Chef, Samigo, Stellar, etc.

The Project Thus Far

• More than just a closed project: donating a piece of software to the community, but many things compartmentalized to date.
• The mission statement for the grant phase : get the software out.
• SEPP created in part to insulate core developers from too much communication (which was off-loaded to Mark and Jim)

Notes about current resources and expenditures:

• SCAs pay $10,000 on a yearly basis
• Some flexibility for smaller schools
• Decision was made not to go back for another Mellon grant, because we wanted to focus on Sakai community
• Current costs: staff and conferences. Summer conference, for example, cost $90,000.
• Staff requirements really more than $1 million a year, so SEPP fees aren't going to cover everything
• Seconding of staff - need this to go on
• Could go after grants, could go after larger contributions, corporate partners to contribute more
• The board will be posting an annual report of expenditures: for education as much as transparency.

Current task for Governance

• End of Mellon near
• Mellon grant stated that core would morph into SEPP - but how? What we need to decide.
• This discussion need not assume the same assumptions that the core has held to date.
• Tentative idea is to become a corporation or foundation.

Chuck and John : The Goal for the Day

We are at a crossroads. In January one model ends, and we're here today to talk about what a new model will look like. We are not pressing for a binding vote, but we would like to find key decision points, and shake out agreements and disagreements about how we will govern ourselves in the future.

Many schools are trying to make decisions about how much commitment they should make. We don't want to commit until we know that there's a stable organization there.

Membership and Voting

General

• We should be careful not to conflate who can be a member and what a member can do.
• We're just talking about institutions so far, but that should be opened up further.
• Don't want the organization to get too complex. Simplicity buys you both scalability and flexibility for the future.
• Number of votes should not scale with funding levels.
• Can't discuss members intelligently without knowing what membership confers.
• Can't discuss membership intelligently without being clear about what Sakai is.
• Members should be basically just voting on electing board members, or ratifying a board slate.
• Membership is not about democratic representation. Motivation is more important here: commitment and "skin in the game."
• Democracy a bad model for building vibrant communities. Motivation and the question of whether interests are being met.
• Keep it simple: let all members vote, and leave a little flexibility for the board to decide what makes a member, if it needs to handle special cases.
• Membership does not mean community participation. We're talking about votes for the board. It doesn't exclude someone from community participation to not have a vote for board elections.
• Should we have two classes of citizenship? That's the impact of the voting question, however we may rationalize it.
• Does membership mean a vote only? A vote hardly seems worth $10,000.
• Fee was to support a cause, not to get something back in return. Or if it was a payment for something, that changes the calculus.
• Membership doesn't mean a commitment to deploy. Do we want the uncommitted to have the same voice?
• The goal is the stakes of the higher education community, which is bigger than just higher education institutions.
• We shouldn't just tilt this toward R1s.
• Proposal: two levels of participation, like a security council.
• Peoplesoft example : open membership vote. If you've paid to go to a conference, you get to vote.

Commercial Affiliates

• (Board background) Vendor questions came up early for Sakai. Rough cut was made simply based on whether they submitted written proposals. Commercial affiliates are being vetted, however.
• (Brian Behlendorf) Mozilla example: does have paid staff of about 24. Money comes from AOL, IBM and Sun, individual donations. Expectation on corporate sponsors is that this doesnt give them special privileges on direction of software. They form a technical advisory board instead. Consider a bicameral setup: some degree of access for paying members, opinions that get reflected. But don't gateway access to development.
• A commercial organization which is all about higher education has as much a place in SEPP as a full member as a higher education institution.
• Commercial affiliates have more "skin in the game" than institutions, since they would not survive a failure of Sakai.
• It's not that commercial affiliates aren't valued, it's that we need to keep Sakai from being overwhelmed by corporate voices.
• OSPI offers an example of a project which could not have succeeded without a commercial affiliate. Their contributions are enormous and committed. We would be ill-served to eliminate that voice.
• No significant danger of commercial interests overwhelming a project with numbers. Any market has a limited size, and customers always vastly outnumber vendors. uPortal an example here.
• If we're doing our job as voting members we're not going to get overwhelmed by corporate interests. Just a question of vigilance.
• Useful to see commercial affiliates as members, because it indicates which businesses are deeply engaged in the project.
• Commercial affiliates can be deeply engaged in technical development, but board guidance is another matter. Overall direction is something best left to institutions.
• Why should some paying members be excluded from voting?
• Key to financial sustainability is commercial support.
• The health of diversity: an ecosystem of varied contributions, all of which may be valuable.
• Commercial affiliates may be put off from participation if they don't get to vote.
• a commercial entity chooses to participate because there's a market, not because they get a vote or not.
• Commercial affiliates are vetted before being approved. They're not dangerous, and they aren't going to take us by surprise.
• If corporate dominance is a concern, there are better ways to handle that. Membership restrictions are not a good mechanism.
• How you elect the board isn't going to steer the project, it's more of a safety net for the institutions. Why does the commercial vendor need a vote?
• Excluding commercial affiliates is simply rude community behavior.

Individuals

• Individuals need not vote for the board. They influence technical areas, etc.
• Individuals are ruled out by a membership fee.
• There are individual consultants who may wish to participate as individual commercial affiliates. They should be included, too.
• "Member" is an important word for community, and should be available to individuals.
• Individuals should rise to any level of authority in the organization, even though votes should be institutional.

Institutions of Higher Education

• Institution not so simple a category: consortia institutions, mega-institutions, research centers, University of Phoenix. Do we need to distinguish between legitimate education institutions and others?
• Lots of plausible criteria for distinguishing different institutions and kinds of institutions, but it's not something you can really write legislation for. Criteria will be often changing, so just stick to a simple mechanism: trust the people, and leave a safety valve (membership vote).
• The software foundation will be for higher education, that's a primary characteristic, and it makes sense to have them set the agenda.
• Keep vote to higher ed institutions to prevent long-term creep of organization somewhere you don't want to go. K-12 dwarfs higher ed, and could overwhelm us.
• K-12 doesn't have programmers or an extra $10,000 in the computing budget. They are no danger, and it's just adding extra words to say "higher ed"
• "by higher ed for higher ed" has more to do with functionality.
• "Higher Ed" is undergoing a transformation. We should be helping to lead that transformation, not be reactionary against other influences.
• "Higher Ed" has a different meaning in the UK, and cuts out lifelong learning.

The Board

• (Board clarification) Board does currently manage resources that are building the product. The future is probably going to be different.
• (Board clarification) Sakai is a grant-driven project now, and a grant is a contract. We can't continue on the same terms.
• (Board clarification) Board so far to try and expand to include expertise it lacked.
• (Board clarification) DGs work out functionality right now, while Board makes other decisions, e.g. product releases.
• (Board clarification) Board discusses political things, and if you have questions, the minutes are published (on Confluence).
• Proposal: almighty Board that delegates authority. institutional members should vote for board, but people who can sit on the board should be able to come from anywhere.
• At some point I became satisfied with a board which has extensive delegative power, and then I only care about who gets to elect that board. Only alternative to a strong board is constant polling.
• How long does it take to read all the emails and stay informed on all the Sakai issues? If voting for most issues goes beyond board, it's not going to be an informed vote.
• Alternative to an elected board: a self-perpetuating board.
• Elected board can propose a slate. Membership vote is mainly a check or safety valve against board going wrong direction.
• Most boards have latitude to bring other members on
• If code is in open source development model, and board merely does day-to-day administration, hard to know what to say about board.
• How does the board represent the community? How is the board accountable to the community?
• Should some of the board be elected by development groups, discussion groups?
• The future is beyond us. Educause example: board which has committees. May be where we end up.
• FTE devoted to the project is worth more than votes. If the board is responsible for non-controversial administration issues, the question is simpler.
• A board does 4 things: holds the vision, guides the process, delivers the product, ensures vitality of ongoing organization. Democracy has a bad history of ensuring mandate for a board. The common challenge of those four things is continuity. The Board needs control of the chaos or the fragility of the project will show itself.
• Do we need to change the Board right now? And if so, why? The project's gone pretty well so far. So maybe we should continue longer with the same Board.
  • (Board clarification) Grant contract coming to an end. Change is unavoidable. Board will change itself if we don't act to change it.
• Sakai will be defined by how the board guides and acts. Sakai will flow from those decisions.
• (Brian Behlendorf) - Need transparency to address FUD. Apache allows members to call in to board conferences.

Software Governance

General

• Domain-wide governance vs. project governance. makes us think about the product, and what it is - is there a project space?
• separate what different entities are doing. For example, motivation for developing the code is not motivation for organizing a conference. We need to define software mission a little better.
• Two interests: Sakai as a framework vs. Sakai delivers a piece of software. What is Sakai?
• The project includes both the code and the community. An ecology for higher ed software development.
• Software is really two things: platform for innovation, and a bundle.
• Should we think of it as something to deploy, or a framework for allowing distributed deployments? This should be a matter of governance.
• Key governance issue here is the set of ground rules for software to be included in core bundle.
• Board should set the principles.

The Board and the Product

• Need to be careful of resourcing problem. External layers of the project are not the responsibility of the board, though they need to enable communications. User design not a governance matter.
• Setting general product definition the province of the board. Not merely governing communications.
• Trying to shape a proposition for a vote: The board will set the general direction and define the core set of deliverables, and should cultivate the community - including style guide and usability standards.
  • Defining the deliverables - do you really want that from a board? what about defining the process instead? The Board should be accountable for principles more than the product.
  • The board should be accountable for a core set of deliverables.
  • Need tight integration of tools. Board should oversee this.
• Let's not just think of the central organization as the Board. More to the Sakai Foundation than the Board.
• Board needs to be responsible for coordination mechanisms for external contributions.
• Dangerous to frame things too broadly - not enough to merely enable collaborative development. We need focus, and Board should focus vision.
• We're talking about too much board responsibility for bundle. Usability is something decided by member effort in DGs and other projects, not the Board.
• There is a base level of usability that a basic bundle needs, so that niche development can focus on other things. A reference implementation.
• Board needs to delegate the decision for what's in the bundle.
• (Board clarification) An example of the Board's influence on issues like usability: re-examining the style guide. Separate rendering from tool structure, so that hackers don't have to worry about usability. This is a legitimate place for Board leadership.

Project vs. Product

• (Board background) Distinction made in the past to try to make it clear that we're not an alternative vendor. "Project" helps emphasize the community.
• product and project shouldn't merge. responsibility for sustainable product not in this room. need to sustain community and structure, not a product.
• The product is the primary interest. Otherwise it's just an academic exercise.
• It's not harmful to think of the product you're putting out as an alternative. Sakai must hold its own as a product. This is essential when it comes to schools considering migrations.
• Sakai is a project unlike commercial CMS products, so it's important to emphasize that distinction. They are not a platform for innovation.
• Stupid to worry about one or the other: of course it's both, and of course you can't do without either.
• The project is about higher ed getting in the business of producing its own product.
• Board needs to be responsible for more than just code development. If the accountability is for the whole product, it includes user issues.
• One reason to get people in the door, but it's other reasons that keep them in the room, and that's more than the product.

Functionality

• concern that we restrict ourselves to education, tools have far more flexible potential.
• End-user type products change the rules. Not just for techies.
• Functionality must be superior to CMS alternatives.
• Need to define the product in order to have accountability to users.
• User experience design is lightly represented thus far, and changing that requires a strong effort.
• Board needs to set the standard for tools, repositories for tool sharing, etc.

"Core" Bundle (we're trying to avoid this word, but I'm still waiting for a better one)

• (Board background) core bundle: framework+tools that works out of the box. What QA is about. Been an assumption of the board to date.
• There is a resource problem. Scale of software is limited, need to be concerned about security and quality. Need some basic feature set.
• Should not be an IP-controlled piece in the core bundle .
• another criteria for bundle: all code in the system having ECL license. provide a distribution, or multiple distributions. kernel, framework, environment.
• It's QA and its associated costs that will define the bundle, not the Board.
• How much work do you want to put into generic tools? Usability questions really hard. More important to set up basic standards that subsequent development can follow.
• Board needs to delegate to a group the task of setting up these standards for the community.

Sharing "non-bundle" software

• An important role for Sakai governance is sharing code not in the core. Project must support idea of sharing code outside the core.
• Need practical mechanisms, not just an encouragement to innovation.

Harnessing Contributions

• Not every contribution needs to come from members. We should find more ways to encourage inputs.

Defining the Sakai Mission

• Sustainability in the product one of the main goals.
• A key interest is a set of ideals or principles, even before the product is considered.
• Building an ecology for ongoing collaborative development.
• We need to explicitly state our values. What distinguishes Sakai is its university values. should be part of mission statement.
• Sakai is also a brand that stands for something, and defining that is important.