I have posted this also on my blog at http://xolotl.org.
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.