Happy Birthday, Sakai Product Council!

After almost a year in existence, the Sakai Product Council that I was honored to join is completing a planned review of its configuration and activities. My answers to the common questions posed to Councilors and community reviewers are below, but before you dig in to those details—or maybe instead, if you’re pressed for time or interest—let me sum up my review here as briefly as I can.

First, let me stress again that the formation of the Council is a very important step in Sakai’s evolution and is part of what makes Sakai different from every other enterprise online learning platform available today. The Council represents a process for open, transparent, formal product governance by the community, for the community. This model is important both within the Sakai community, where we will benefit from the increased structure and governance, and externally, where potential adopters can see a community that truly controls its own destiny.

Second, I think the Council’s form and function are largely correct, but need some adjustment. Read on for further details.

Third, I am not satisfied with my own participation on the Council or the Council’s accomplishments generally. I think we can and should do better. I have made some suggestions below that may help make this happen, and have read other suggestions from other reviewers that may also help. This review is an appropriate and constructive step in the Council’s evolution.

State of Community Product Management Functions

What do you think of the product development lifecycle (have you looked at it)?

The product development lifecycle currently described for Sakai seems better tailored to Sakai 2 development than Sakai 3. If we are not going to make large interventions in the way Sakai 2 is developed, maintained, and released, than the lifecycle is probably adequate for Sakai 2. My hope is that Sakai 3 will follow a different path.

My main concerns around the lifecycle have always been around boundaries: I believe only a smaller, core Sakai release (which may be more than the kernel) should end up with “maintenance” status. I don’t think the community can or should assume full maintenance for all projects that reach a certain level of maturity and usage, but instead many ancillary tools/capabilities should follow their own independent lifecycles, living and dying according to the resources they attract on their own. The community might provide some guides to help adopters evaluate ancillary projects. Shepherding boundary definitions and stewarding boundary crossings should be part of the Product Council’s charge.

I also think we should change the name of the “maintenance” phase to something that conveys its true nature. Things in “maintenance” sound dead to me, but the maintenance phase comes across as our ultimate, living, production phase. Perhaps David Horwitz’s idea of differentiating “maintenance” from “production ready” is the right distinction. There has got to be a better name.

What are the critical functions that the community needs in the context of managing the product?

  • Coherence: Sakai should demonstrate overall coherence, including coherence across the Sakai 2 > 3 boundary.
  • Roadmap: Sakai should develop and work towards a roadmap that reflects aspirations as well as deeds.
  • Quality/standards: Sakai should publish and adhere to clear standards and standard practices for a wide variety of characteristics, including accessibility, documentation, internationalization, maintenance, security, technologies, and user experience.
  • Product governance: Sakai should have open, transparent, and effective governance processes.
  • Communication: Sakai as a community should clearly and regularly communicate on open channels about its qualities, activities, processes, and plans.
  • Distribution: Sakai should provide distribution mechanisms that make it easy to find and consume our products.
  • Security: Sakai should provide vigilant, credible, obvious processes to collect, review, address, and disseminate security issues.

For which of those critical functions, if any, do you think a product council is needed?

The Product Council should participate in shepherding the development and stewarding the maintenance of all the activities listed above. Yet the Council should understand itself to be most highly engaged in product governance, where it should be the most visible and active group. The Council should also be highly engaged in the stewardship of Sakai’s roadmap and the product’s coherence and quality as it travels along that path. While the bulk of communication in the Sakai community should not be the Council’s responsibility, it should take extra care to communicate its processes and activities clearly and regularly.

How does the product council relate to other groups working on these critical functions?

(the Maintenance Team, Release Management, i18n, and the kernel team, for example)

I do not believe the Council should direct the activities of these other key groups. These groups are filled with expert, dedicated professionals who are best positioned to direct their own work. The Council should be more aware of and engaged in the work of these other teams, perhaps even assigning its own members to serve tours of duty with these other groups, or incorporating representatives from other groups into itself. The Council itself and each of these groups continues to work out their identities and practices, as well as how and when they intersect. The interrelationships of these groups will probably always be in creative evolution. Ideally, the Council will assist these other groups by doing its own job and helping them resolve issues that call for product governance.

Which of those functions are missing from current activity or processes?

With the exception of Sakai’s distribution mechanisms and security, the Council engaged with every other category above during its first year, though sometimes in only very small ways. To be effective, the Council should be more active and more timely.

The Mission and Charter of the Product Council

When you heard about the product council, what did you hope the product council might achieve?

How close to your hopes did the product council charter come (have you read it)?

What would you change about the charter?

To be absolutely clear, the charter outlined here pertains almost exclusively the Product Council’s configuration, rather than to its mission/responsibilities.

I think the Council’s configuration is very close to exactly right, representing broad perspectives and allowing for continuity and change. Given that the Council’s configuration to date has been successful, I would not rush to make changes. If I were to suggest any changes to the current Council configuration it would be as follows:

  • Ensure that there is representation of critical viewpoints (eg, maintenance team, internationalization). The Council itself might identify missing viewpoints and recommend adjustments to its membership. There might be more flexible mechanisms for such adjustments than currently provisioned.
  • Establish the role of the Product Manager as the Council’s chair to ensure Council engagement and timeliness.

As for the Council’s mission—which is more directly addressed here—I also think it is largely correct as laid out. I think of the Council’s primary role as crystalizing community scrutiny of the Sakai roadmap, and the coherence and quality of the product. Secondarily, the Council should foster the formation of community standards and practices, and help guide projects toward meeting those goals for coherence and quality. In essence, the Council should act and appear as if it were a microcosm of the larger community, but with the ability to make final decisions where community consensus has not brought closure.

What impression, if any, do you think the product council has on people looking at Sakai from outside the community?

While the Council’s role inside the Sakai community is crucial, its external role is perhaps even more important. One of the fundamental differences between Sakai and alternative platforms is Sakai’s transparent, structured governance. The Council is the clearest expression of Sakai’s different model. Community members who do not regularly communicate with the Sakai curious may underestimate the powerful signal the mere existence of the Council sends. Accordingly, the Council’s effective fulfillment of its internal role in turn demonstrates to the outside world that Sakai is produced under a different model. While the Council’s focus should be primarily internal on the Sakai product and community, it should always act with full recognition of the importance of its role to external audiences.


Have we got the membership right? What constitutes the right mix of people on the Council? How should members be selected?

It is crucial that the Council have balanced representation from key constituencies and reflect skills appropriate to its mission. Accordingly, I don’t think the Council should be elected. Given that the current Council seems to have the right balance, albeit not the right intensity, I don’t see a great reason to change the selection process.

Should Board members be on the Council?

Given that the Board’s focus should be on the legal requirements of the Foundation, I see no conflict of interest in Board members serving on the Council. It might send the wrong signal if the membership of the Board and the Council had significant overlap. Council selection should take balance with the Board into account and potential Board/Council candidates should consider which body might best enable them to realize their goals.

What expectations should there be on council members?

As a Council member, I was underwhelmed by my own ability to participate more actively in Council activities. I strongly doubt that any current Council member has been consistently able to participate the 4-8 hours/week envisioned in the charter. While I think the Council could have accomplished much more of its mandate with such a commitment, I question whether appropriate Councillors can really be expected to commit large amounts of time given their other likely responsibilities. Accordingly, to balance the diversity and stature of the Council with its expected activities, I think the Sakai Foundation staff (Product Manager, Executive Director) should take a more active role in ensuring the progress of Council activities. If a very active Council chair is not available, perhaps it would be more effective if the Product Manager chaired the Council. The Council might set up some more tangible expectations of its members and those who could not fulfill them step down. Councilors might also convene and lead workgroups with other community members to fulfill specific tasks.

What the Product Council Has Done

What do you think the product has focused its attention and energy on?

Given that the Council has had to feel its way as a new body with a somewhat vague charter, following a newly defined development cycle, in the context of a complex, evolving community working on two product lines, and given all the other pressures on its members, I’m sometimes impressed it has produced anything of value at all.

Given the very different development lifecycle stages of Sakai 2 and 3, the Council has unsurprisingly focused most of its attention on Sakai 2. As the Sakai 3 project continues to emerge, the Council will accordingly adjust its focus to incorporate greater attention to Sakai 3.

What do you see as the successes of the product council so far? What are the disappointments?

The greatest success of the Council was its formal evaluation and stewardship of major additions to the 2.7 release. Although incomplete and tardy, this process means that for the first time, the projects in the release were held accountable to formal product governance by the community. Now that it is established, the Council should work to make this pattern more fulsome, timely, and effective for both Sakai 2 and Sakai 3 releases.

Like many, I’m disappointed by the overall amount and depth of the Council’s activity. There are clear tasks for the Council to undertake—we need to focus on making more of them happen, inside and outside the Council.

What has been the net pay-off of the product council thus far. Is the Sakai 2 product better off? Sakai 3?

Both Sakai 2 and 3 are better off for the existence of the Product Council. For Sakai 2, there is now modest, but formal, tangible, open, and transparent governance of its release. For Sakai 3, the Council represents a body formed far earlier in the product’s history that can work to formalize better practices in its development and release. For both products, we can point to an evolving model for product governance that reflects the values and interests of the Sakai community.

Sakai’s New Maturity

Several recent developments signal a promising new level of maturity in the Sakai community and product. The Sakai Foundation (SF) has created two new staff positions that will together enable the SF to better coordinate and communicate our work in Sakai.

Long-time Sakai community member Clay Fenlason is the new Sakai Product Manager. Clay is an excellent choice to coordinate our community’s already successful work to further develop Sakai as a coherent, reliable product with a meaningful roadmap. Pieter Hartsook joins our community as Sakai Communications Manager. I don’t know Pieter well yet, but was impressed by his experience and intelligence at the recent Sakai Boston 2009 conference and expect him to become an enormously valuable participant in our efforts to tell the Sakai story more effectively internally and externally. Read more about these new positions in SF Executive Director (ED) Michael Korcuska’s blog.

This new maturity is further demonstrated by the formation of a community-based Sakai Product Council (SPC), which will “ensure exceptional quality and cohesiveness of Sakai product releases in support of varied teaching, research and collaboration needs” in the words of SF ED Michael Korcuska.

I’m honored to be named to the SPC along with key community contributors Noah Botimer, Eli Cochran, Michael Feldstein, David Goodrum, John Lewis, Stephen Marquard, John Norman, and Max Whitney, along with the new Sakai Product Manager, Clay Fenlason. As the SF ED, Michael Korcuska will also serve on the council as a non-voting, ex officio member. You can read more about the formation and ongoing activities of the SPC on the Sakai wiki.

In Boston, the SPC had our second ever and first face-to-face meeting and we began to sketch out some of our attitudes, roles, and processes. There was also significant discussion about the SPC in the product coordination meetings held just before and just after the conference, as well as during the various conference BOFs focused on further defining the shape Sakai 3. It’s still very early, but we appear to have settled on some shared understanding of how we will undertake our charge to shepherd Sakai’s integrity as a product. Here’s my own personal take on some early SPC thinking, but I invite other councilors and the community at large to weigh in and further develop and critique these thoughts.

First, we agree that we share two basic attitudes toward our work on the SPC. We agree to carry out our work and deliberations as publicly and transparently as we can, using existing Sakai community communications channels (primarily the Sakai mailing lists). We also agree that although each of us represents specific constituencies and institutions within the community, as councilors, we will be informed by our specific viewpoints, but attempt as best as we are able to act for the good of the community and product as a whole.

Second, we discussed three basic roles we expect the SPC to play. 1) To consider the coherence and completeness of the whole Sakai product and advise in the formation of the product roadmap. 2) To evaluate the status of new product development projects against characteristics established by the community. 3) To resolve significant issues blocking timely product release.

Third, we began to outline some of the processes we might follow in our evaluation of project status. We agree that the community should shift to work using the product development process already proposed. We see an immediate task to work with the community to define a series of specific characteristics that we will ask projects to demonstrate in order to move to the what the process above calls “Product Development” status in the community product. We expect to collaborate with the community to develop those characteristics using existing models as a starting point (eg, the Sakai tool “scorecard”, the portfolio community procedure for feature requests). We expect that projects will produce their own demonstrations that they meet these specific characteristics for community and SPC review. We expect to help provide guidance to projects on how they can develop and demonstrate these specific characteristics.

We also began to outline what role the SPC will play in the Sakai release process, where we will be focused primarily on evaluating the status of new capabilities. We identified that we may have two evaluation processes, one more lightweight, to use when new features are added to existing Sakai capabilities (eg, new features for a Sakai 2 tool already in the product), and another, heavier process, to use when whole new clusters of capabilities are added (eg, a whole new Sakai 2.x tool, everything in Sakai 3). We are thinking that in a given release cycle, the Sakai Product Manager (Clay Fenlason) will be the primary shepherd of new capabilities up to code freeze, ensuring they are considered by the SPC. While from code freeze to formal release, the release/QA/security teams will be the primary shepherds of those new capabilities along with the entire product. During the release process, if the Product Manager and release/QA/security teams agree that an issue is blocking release that can’t be resolved via typical community collaboration, they will then bring the issue to the SPC for resolution.

We understand that we may have to think differently about Sakai 2 and Sakai 3, given their very different architectures and maturity. We also agree that we are open to helping the community shift to different product release practices. For example, there might be a separation between a slimmer, core Sakai product and a number of Sakai extensions that might follow independent release cycles. Any such changes would obviously take place only after full community deliberation.

Last, but not least, we agreed that while we do not necessarily think that the SPC formation process was ideal, we do agree that the outcome was sound. We think the current SPC represents a good balance of different experiences, skills and viewpoints and that we will be able to work together effectively. We agree with our basic outline of structure and governance that it will be best if the community revisits the SPC formation process only after the current SPC shepherds at least one complete product release cycle, so we can establish and evaluate core practices before we make substantial changes.

As a councilor and community member, I look forward to working with all to demonstrate that the SPC, the new SF staff positions, and the new processes we are initiating will indeed combine to raise Sakai to a new level of maturity as a product and as a community.