Craig Counterman - Sakai Vision

Sakai Vision

Original contribution by Craig Counterman

How is Sakai special? What is unique about the space Sakai occupies?

Sakai is only indirectly about technology. Technology should not be the focus. Most of the problems Sakai wants to solve are general and shared by other products and projects and we should learn from and work with them.

Things that are unique or at least special about the space of Sakai:

1. The variety of institutional infrastructures, range of vendors and home grown systems which Sakai needs to interact with and which Sakai end-users will also be using.
2. Strong Annual cycle, more like a toy manufacturer driven by Christmas sales than a normal open source project.
3. Distributed administration in a deep hierarchy. People have a variety of roles and are godlike within one domain and nonentities in others; the organization overall has little or no control over them and much must be enforced through technology enforcing policy (gently).
4. Special legal constraints on accessibility, privacy, records, etc.
5. Need to communicate with variety of other services (e.g. restricted access repositories and information databases)
6. Variety in adopting institutions, their local support and development resources, their willingness or eagerness to incorporate commercial products into their Sakai installation.

What is Sakai?

The original vision of Sakai, from the proposal, led quickly to an abstract architecture to support that vision.

That architecture includes a framework, service implementations, and tools.

The tools are modular and may be developed independently from one another.

The tools are dependent on the services and potentially on UI components provided by Sakai.

Service implementations may be developed for different needs and for integration into different institutional infrastructures.

Therefore, there is a 'core' consisting of the framework, APIs, default implementations of all APIs, and some minimal set of administrative tools and auxiliary applications.

Tool development requires a stable core with functionality to support the requirements of the tool, that is, with capabilities needed by the tool for the tool to meet its end-user requirements.

Therefore, the 'core' technology development needs to be driven by the need to meet the demands of the tool developers.

Because the 'core' is the key dependency, and because changes in the core can require changes in all the tools, the management of the core is key. It must be professionally managed, developed, and delivered on time.

QA to avoid failures and lost work is also critical, though relatively more straightforward. Loss of data, server downtime, or random bugs cause users to lose confidence in the system and ultimately causes them to avoid using it.

But, the non-core tools and service implementations are different. They can be close to the Sakai organization, totally independent, or coordinated through the Sakai organization but not so close. "Close" tools can be donated to the Sakai organization, QAed by the organization, and offered in a packaged release along with the core. Other tools can be offered and advertised through Sakai in a
"use-at-your-own-risk" 'contrib' category.

Tools grow out of ideas and requirements from DGs. Some will be developed by single users or groups at an institution, others will be collaborative developments spanning multiple institutions. Successful tools will incorporate the suggestions and needs from as many as possible, as they've been explored in the DG.

Therefore, the governance should focus on: release definition and management, ensuring that the core development goes well, making sure that the QA process completes, overseeing documentation writing, and facilitating tool development and communication, and approving the promotion of a tool into the 'close tool' category for distribution with the core.

Part of facilitating the tool development is providing the forums and supporting the technology for collaborative tool development, of tools in any category. This includes providing discussion forums and email lists, the wiki, distribution, and bug reporting and tracking for core, 'close' tools, and 'community' / 'contrib' tools.

Another, and key, part of Sakai is UI guideline development, usability testing and expertise, and encouraging tool best-practices.

The importance of the user interface cannot be overstated. It is an absolute requirement for the long term success of Sakai that the user interface be high quality, accessible, user-centered, and well tested. Any tool distributed with Sakai must meet these guidelines. It must be possible for institutions to use other tools, which do not meet the guidelines or are not as mature, but the brand of Sakai must be quality.

The 'apache incubator' approach may be suitable for the tool development process. Tools can be incubated through Sakai resources. When it is deemed stable by its developers, it may be reviewed for promotion to 'contrib' (security and stability should be key considerations in this review). A tool may stay in 'contrib' for as
long as it wants, or it may be on track to become included in the distribution. When the stability, security, UI, and basic quality are approved, it may be promoted from 'incubator' to be QAed and packaged and documented, and included in base distributions of Sakai.

Sakai as an OEM

The Sakai organization is really an OEM (original equipment manufacturer). Organizations which support Sakai at their institutions are Value Added Resellers. The ultimate consumers are the end users: students, staff, instructors, researchers, administrators, etc.

If the end users are unhappy, they will complain directly or indirectly to the organization and their management (and funders). The organization must then pass their user unhappiness on to the Sakai central organization.

End user confusion which leads to a support call costs real money for the organization. Worse still, it's lost productivity for the users, who are either being paid by the institution or who are effectively paying the institution by the hour and resent wasting that money.

This is why a quality UI is so important. A small problem, or a small improvement, is multiplied by that large number of end users into a large cost or big gain.

The technical underpinnings, the server requirements, the difficulty of installation, are considerations, but only a few people at an institution need to install and provide care and feeding to the server. One day of their time, if there are 2000 users of the system each day, is equal to 15 seconds for each user. It's easy to gain or lose that time through the user interface.

The user interface is traditionally the weak part of an open source product. Sakai needs to actively combat that trend, and provide a counterexample.

From this perspective, the 'advocacy' half of 'strategy and advocacy' is VAR relations. VAR relations is identifying their needs and meeting them, and then communicating this to attract more VARs. It also involves encouraging them to participate in discussion groups and expert groups, and to contribute to tool development, evaluation, and testing, according to their abilities.

A quality UI and a reliable delivered product, combined with a lively community contributing components, is what Sakai should strive to achieve.