This page is for information and comments on the changes to the Sakai Development Process. A PDF of this content (which contains some additional information) is also available.

There were several webinars presenting this process:

2009 Dev Process Webinar 1 on Wednesday March 25, 2009

2009 Dev Process Webinar 2 on Wednesday April 1, 2009

A recording of this session is available.

A presentation was also made at the 10th Sakai conference in Boston. The slides are available for download. There is also a brief video interview of Michael Korcuska after this presentation.

Executive Summary

In response to demand from the community for more formalized development processes and a roadmap for Sakai development, the Sakai Foundation will use its resources to encourage the creation of:

  1. Formal, structured development projects to deliver functionality prioritized by end-users;
  2. A product council to set the bar for the inclusion of functionality as part of the Sakai product and to accept the transfer of responsibility to the 'maintenance group'; and
  3. A 'maintenance' group within the Sakai community that ensures stability in production, performance, bug fixing, etcetera.

Not all of the elements are fully developed and this document focuses mainly on the overall process and the product council, but work is ongoing to develop the full scheme. We want to publicize this 'manifesto' to gather comments and gauge support. Comments that help improve the plan are extremely important, but we are beginning to implement this approach as we seek suggestions for improvement.

You can read more about the Sakai Product Council here.

Background - Sakai Product Definition

The recommendations here are best understood in the context of a common vision of what Sakai, as a product, aims to accomplish. We therefore offer the following draft Sakai product definition.

  1. Sakai is an enterprise friendly, service-oriented platform that enables the web-based support for various groups in educational institutions.
  2. Sakai implements open standards wherever possible and releases open source software with a liberal, commercial-friendly license. It supports open courseware and open educational resources.
  3. There is a strong Teaching and Learning community within Sakai that seeks to ensure sector-leading CMS/LMS/VLE features are available on the platform.
    1. Distance Learning is specifically supported
    2. Face-to-Face teaching is specifically supported
    3. Portfolio use cases are specifically supported
  4. There is a strong Research community within Sakai that seeks to ensure sector-leading VRE features are available on the platform. This includes inter-institutional research collaboration features
  5. There is also a strong community with interest in Content Management and Collaboration features for other education-related activities, such as Clubs, Societies and Administrative groups.
  6. Not all campuses will necessarily deploy all features, nevertheless:
    1. There is a desire for both a consistent user experience throughout the range of features and an open platform that allows ready integration of best of breed 3rd party applications. We recognize that this creates a challenging dilemma for user experience.
    2. There is a desire to create solutions with market-leading accessibility and usability

We welcome elaborations, clarifications and polishing of this definition.

Background: Development Model

The thinking behind the proposed approach uses a fairly conventional product lifecycle with the following stages:

Sakai, unlike some other open-source initiatives, has distinct user and developer groups. Rarely do you see a student, a professor, or a researcher write the lines of code necessary to make the product better. This particular challenge makes us wish to be more structured and creative in the way we manage the development of the platform. At the same time, the notion of a centralized organization controlling most aspects of Sakai development is also not appropriate for the Sakai community at this time.

The degree of process formality differs with each stage.  In Research & Development, for example, a distributed model is best-one that doesn't require approval or decision-making from a central authority. We call this way of working "organic". As ideas emerge from R&D that appear to have merit, it is crucial to increase communication about the project and begin to put together a more formal development team and plan. We call this "coordinated"-the idea is to bring together people who might want to work together to create a significant new capability in the Sakai release.  And once such a group of people is identified and their objectives clarified, a more traditional and formal project structure is beneficial. We call this "managed".

We also know that different institutions and individuals in Sakai will respond differently to each of these ways of getting work done. So the proposed model uses a different organizational strategy at each phase of development and therefore allows for different ways to engage in Sakai. While it keeps the ownership of Sakai's capabilities in the community, we believe it brings more oversight into the officially released product.
Finally, the Sakai Foundation's role in each of these phases will be different. The following table provides a summary of the style of work, the role of the foundation and the entry criteria for each stage.


Work Style

Foundation Role

Entry Criteria

Research and Development


Infrastructure (svn, jira, confluence), communication and encouragement.

None. Anyone can have an R&D project.



Infrastructure, communication & potential direct support from foundation resources; particularly in matchmaking institutional resources and communicating requirements of later stages.

Low. Anyone can declare that they would like their project to enter incubation. Foundation resources will not be able to support every project & a method will need to be established for any such prioritization.

Product Development


Infrastructure, communication & potential direct support from foundation resources. Facilitation of the decision to include project outputs in a release.

Moderate: A strong plan & adequate resources. Transition to next phase has high barriers, so plan to attain those criteria is important.



Managed or Coordinated (TBD)

Infrastructure, communication & potential support from foundation resources. Possible management of a centralized maintenance team.

Product Council. A small group that will decide if a project is ready be in the release. See below for details.

End of Life

Coordinated or Managed

Infrastructure, communication & potential support from foundation resources.

Product Council decision.

We feel strongly that this model is achievable by the Sakai community and will lead to the desired outcomes of an end-user driven set of development priorities, a more predictable and efficient development process and a useful roadmap of Sakai development. However, it will only work with the enthusiastic engagement of the community - we need your help.

The product council will act primarily as a gatekeeper around the Sakai release and the maintenance phase (entry and exit), but will also offer coaching and guidance at other stages. Gate-keeping decisions by the product council will be transparent. That means criteria will be public and open to community development and decisions will be explained openly.

The Sakai Foundation will facilitate the work of the Product Council and will try to help projects with communication, resource recruiting and a variety of other things. But Foundation staff resources are limited and the projects themselves have a responsibility to provide documentation, updated schedules and other information.

The Product Development Phase

The Product Development Phase is a crucial phase in the new process and, so, we are giving it a bit more attention in this document. For project outputs to exit this phase and be incorporated into the release they will need to meet the community criteria and fit well with the existing product. The Product Council will make the formal decision. (The existing provisional/core criteria represent a starting point for these criteria).

We expect successful projects will have formal management arrangements. While the Sakai Foundation is not dictating to the community how projects in this phase must be organized, we are encouraging the formation of development teams that:

Not every project will need the same resources, of course. But overall we are looking for projects to adopt more formal organizational structures (become "managed") as they move from R&D to the release.

The Role of the Product Council

The formation of the Product Council is a significant addition to the Sakai development process. Without some oversight of what goes into the Sakai CLE, we feel that the coherence of the release is at risk.
The ultimate role of the product council is to determine which projects are incorporated into the formal product release. That is their only formal authority. The product council will use a transparent process for decision-making. Where possible, decisions will be evaluated against defined and objective criteria. Certain decisions will require more subjective standards and, in these cases, the reasons for any decisions will be clearly and openly communicated. The product council will also seek expert review from persons not on the council.
We anticipate that projects will want some indication from the product council that their project is a good candidate for the release. Therefore, even though its only formal authority is to evaluate a projects readiness for release, we believe it will need to advise incubation projects about their readiness to enter the product development phase.

Note that while the Product Council may be consulted for advice during the project, the product council will not direct project resources or tell projects how to conduct their business. They will tell them if the work itself is ready for release.

The Membership of the Product Council

The council will be made-up of a group that brings the different areas of expertise required to effectively fill the product council function. We expect our understanding of the skills required to evolve over time, but the initial view is that the following areas of expertise are required:

The product council will also include the Executive Director of the Sakai Foundation and a Sakai Product Manager, who will facilitate the group.

In addition to these areas of expertise, all product council members should also have the following:

To form the product council, the Sakai Board will communicate the role and desired contribution of the council. The Board will be open to suggestions and nominations from the community, but will seek to quickly identify the initial product council members. The product council and the Board will together identify a process to evolve council membership over time.

You can read more about the Product Council here.