Paper 9

Governance Comments

It seems to us that the initial stages of the Sakai project initiative have been generally well-organized and well-managed. Good information has been disseminated, and bulletin boards have helped different participants with differing interests and needs stay connected to colleagues with similar concerns. The major meetings and conferences have served a similar positive value.

One area that we would like to see more clarity on is how other parties that are developing (or have existing) open source software can work with Sakai without in fact being overly blended. While we are a "neutral" party on the issue of branding, we are aware of some other initiatives that have their own branding (and the funding that may go with it) and a justified sense of accomplishment; we and the leaders of those initiatives want to ensure they are "Sakai-ready" and want to engage in the substantive discussions that allow them to effectively inter-operate. In some cases, if Sakai is developing specific capabilities, they may be able (or need) to remove those capabilities from their own tools and create a more streamlined version. Our understanding right now is that the Sakai team is not quite ready to engage in discussions of this sort. To summarize: How do other tools that are innovative, yet overlap in some ways with Sakai, best integrate into a Sakai environment without losing their own unique identify? What information is out there that informs the community of the timeline for having such discussions, if not now, and the mechanisms for entering into them?

Some folks at **** have suggested that they are concerned about adopting / implementing Sakai tools if there is risk that they may not be properly supported in the future - i.e., if a tool is developed and endorsed as part of the Sakai project, and then there is no further commitment to its support or future development. As one of our colleagues put it: "Whatever the ultimate governance structure, I'd favor some stern tests for getting a module accepted and then also some agreement that if the initial developer(s) abandoned the software that it would be picked up by others in the community." To some extent, this is why a large number of higher educational institutions are willing to invest precious and limited resources in commercial courseware tools and systems - many are not very good, but they are generally supported, sustainable, and scalable. We at **** understand and strongly embrace the open source principles and values...at the same time, we are aware of the risk that "if everybody has responsibility, then no one has responsibility."

So, while not directly addressing your governance question, perhaps we're discussing what we don't want governance to look like. We are not interested in a Sakai on "automatic autopilot." We welcome sharing responsibility as SEPP partners, and we believe that steering committees focused on specific portions of the project, coordinated by a rotating Board of Directors (comprised of representatives from partner institutions: one or two each from major research universities, smaller liberal arts colleges, public institutions, private institutions, community colleges, etc.), and managed by a paid administrative team accountable to the Board - would provide organization, inclusion, and accountability. We are comfortable with a financial model where member institutions share in the cost of keeping and growing the initiative, and where these resources are supplemented by grant proposals aimed at advancing Sakai tools and services to education.