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.
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.
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.
(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.
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.