Page Comparison

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:

• Research and Development. This stage is where new ideas are generated and new technologies are tried. Many "contrib" projects in Sakai are essentially in this phase of the cycle for the purposes of this model. Other contrib projects are certainly much too mature to be considered R&D---they just choose to be independent of the Sakai release. The new model will allow this same sort of "independent" project.
• Incubation.  This stage is for projects that intend to end up in a Sakai release. The goal in the incubation stage is to prove the desirability to the community, formalize project requirements, assemble a cross-institutional development team that includes functional expertise, build a project & maintenance plan and reduce development risks.
• Product Development. Incubation should prove that a project is both desirable and feasible. The product development phase is essentially executing on that plan. It ends when the project becomes part of the Sakai release. We expect formal structures to ensure the reliable allocation of resources and that the operational decisions during the project are driven by end-user priorities.
• Maintenance. This phase is for bug fixes and feature enhancements to released product.
• End of Life. Sooner or later things need to be taken out of the product. Or a new version needs to be built.

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.

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:

• Is strongly influenced by functional experts
• Have a source of user experience, accessibility and internationalization expertise
• Have a project plan with scheduled milestones, opportunities for community input & contingency plans for major risks. This probably, but not necessarily, implies a project manager.
• Have a plan for maintenance & support
• Have a cross-institutional project team

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:

• User experience, including accessibility and usability
• Teaching and learning
• Research
• Software design and architectures
• Software production management

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:

• A broad understanding of the Sakai product
• The ability to advocate for the needs within his/her area of expertise and maintain a broad view of community and product needs
• Demonstrated commitment to engage with and contribute to the community
• Deep expertise in more than one aspect of the product

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.