John Norman 2008 Thoughts

Sakai is open-source software for its members. Currently that means Higher Education. It can be used in other educational settings, but it is not a primary goal to create universal education solutions.

At early 2007, the community contains both institutions that see Sakai as purely a course management system (and therefore an alternative to Moodle) and institutions that want to serve research communities in innovative ways as much as serving course management needs (which sets Sakai apart from Moodle). The ability of Sakai to be used as more general purpose software also creates confusion with u-Portal which has been administration oriented but is increasingly research oriented. Arguably, Sakai represents a solution akin to u-Portal plus Moodle, but the key ingredient of Sakai is that there are community members with resources to commit to developing research solutions - i.e. Sakai is a community as well as a code base. The continued interest of Sakai in research and teaching to the exclusion of administration tends to prevent closer co-operation with u-Portal in spite of considerable overlap in community membership. (it is worth reflecting whether it is the respective boards that prevent closer collaboration rather than distinct community needs in the light of recent common code (Pluto 1.1) in u-Portal 3.0 and Sakai 2.4)

Sakai is maturing software in terms of toolset or convenience to users. Much of the strength of Sakai is in work that is invisible to users and the part which is visible is not always intuitive. Moodle is 2 years older than Sakai and has benefited from the additional refinement time. However, the Sakai platform is stabilizing and time is beginning to be devoted to user oriented aspects of the code. Because of this state of the software, I believe we still primarily want to attract members and institutions that are able to contributeto improving the code. We should expect adoption to rise when we have a world-class solution and we can devote more time to a carefully developed communication plan and building easy to use installers. For some of this later non-contributing market, too close an engagement with Sakai too early may be counter productive. OTOH there is a window for attracting WebCT users who do not want to adopt Bb and this may be worth some targeted effort (if we can afford the resource). In general, institution-wide adoptions will be a slow decision making process with long lead times since the switching costs are so high.

We have a choice of competing with Moodle and other open source solutions, or collaborating. I would prefer collaborating. We should also promote standards for interoperability with commercial solutions.

Sakai offers value to members because collaborative development of open-source solutions allows freedom to create local custom solutions, while sharing the costof 'standard' code. Sakai aspires to scalable, robust, reliable code and avoids content lock-in. In addition, Sakai is an implementation of service oriented architecture goals and aims for useful services to reduce new development time and 'pluggable' components that can be added and removed to create local implementations according to local needs.

Sustainability for Sakai depends on deploying institutions deciding to commit resource to the community. This can range from reporting innovative teaching or research use and organizing meetings thought to testing and bug reporting and contributing skilled design or development resource. A reasonable expectation might be that production institutions devote a proportion of the savings in the license fees of commercial alternatives to participation in the community. Currently, Sakai has the model of a modest additional subscription, which primarily pays for subsidized conferences, and staff to co-ordinate effort, manage QA and introduce new institutions to the community and the code base.

Finally, Sakai is 'commercial friendly' where it strengthens community objectives, but not 'commercial dependent'.

Board Responsibility

• Ensure code is safe and available to all
• Comply with legal requirements for incorporated entity and protect tax-free status
• Comply with articles (run free and fair elections, etc.)
• Set membership dues and allocate resulting funds to further the purposes of the Foundation
• Report on above to community

Member Responsibility

• Pay dues promptly
• Act in the interests of community as well as self. At a minimum do not act to harm the community.
• Encourage development staff to collaborate
• Share information

Community Responsibility

• Improve the code, but take due care of interests of institutions in production
• Share information

One way in which Sakai suffers is that we do not have a clear articulation of that vision and an account of our path to reach the current position with a projection of where we are going. In this situation, our membership can be easily drawn to other projects that offer a clearer proposition. I think we should expect to keep membership stable for 1 or 2 years and then have a plan for targeted growth.

In terms of community behavior, enlightened self interest will provide the sustainable motivation. I would like to see developments supported by developers from multiple institutions for sustainability. That will require investment and encouragement from the institutional leadership.