Sakai is an open source, web-based, collaboration learning environment (CLE) that is focused primarily on higher education. It supports the activities of students, teachers, researchers, and Sakai administrators. Sakai is flexible and enables users to configure it for their own specialized audiences.
Sakai is mainly a courseware management platform that provides users with learning, portfolio, library, and project tools. Teachers can create course sites and add chat, forums, blogs, wikis, and many other tools. Students can, among other things, upload assignments, use the tools, and interact with instructors and classmates. Finally, researchers and groups of peers can create project sites for sharing materials and ad hoc interactions. Sakai is flexible by design and has a set of frameworks (internal structures) that makes it easier for those who want to build tools.
Sakai scales to even the largest and most demanding environments! For example, Indiana University maintains a deployment for at least 100,000 students and that number keeps rising. The University of Michigan deploys for 70,000 students.
The basic concept behind the functionality of a CLE is that users control their own sites; for example, they can choose which tools to include in the sites they create. The application treats users as adults and enables flexibility through choice. The tools include chat, forums, wiki, polls, Google-like search capabilities, and others—with more tool options with every new version of Sakai. Numerous tools enhance group formation, allowing for intuitive interaction (hence the word "collaboration" in Collaboration Learning Environment).
The range of tools is rich indeed, especially if you include all those contributed by the energetic and motivated Sakai community. Many local deployments have specialized tools for which they develop their own enhancements. They then contribute these extra tools, software for connections to external systems, and various other new features back to the community. As Sakai grows in strength, the number of extras is increasing explosively. The Sakai Foundation web site mentions at least 20 extras and the Foundation's source code repository has around 120 contributed directories.
Sakai was designed with a framework that significantly simplifies the creation of tools. Developers do not have to reinvent the wheel for fundamental services like finding a user's name, managing a site's look and feel, or internationalization. There are strong, well-established lines of support for developers, including style guides, best practices, a programmer's café, workshops, and central quality assurance (QA), throughout a development project's full life cycle.
To help organizations decide which tools to deploy in their production environments (for example, a college campus), which tools to start looking at for future use, and which to retire, each tool is assigned a status:
Core—Tools with which the community has a great deal of experience and is confident about their robustness, stability, and scalability.
Provisional—Tools with which the community has less experience or which are becoming obsolete. They are disabled by default.
Contrib—Tools with which the community has little experience and which the QA work group does not recommend for broad usage in a production environment. Contrib tools are available, separately from the release, in the Contrib area of Sakai's source repository.
Watching the codebase over time, you see a convection effect where contrib tools move to provisional, are thoroughly tested, and move to core; and then older core tools move down to either provisional or are pensioned off. As time progresses, there is a quality convergence—the software gets thoroughly debugged first by a team of dedicated testers and then by real-life high-scale deployments. In the end, the user has more choices and sophistication in the toolset. The extra choice of tools costs more server effort. Luckily, due to the trend known as Moore's law, servers double in computational power roughly every eighteen months. The end user thus directly benefits from a scalable framework, an increasingly functional-rich toolset, and ever-improving server specifications.
The basic concept behind the functionality of a CLE is that users control their own sites; for example, they can choose which tools to include in the sites they create. The application treats users as adults and enables flexibility through choice. The tools include chat, forums, wiki, polls, Google-like search capabilities, and others—with more tool options with every new version of Sakai. Numerous tools enhance group formation, allowing for intuitive interaction (hence the word "collaboration" in Collaboration Learning Environment).
The range of tools is rich indeed, especially if you include all those contributed by the energetic and motivated Sakai community. Many local deployments have specialized tools for which they develop their own enhancements. They then contribute these extra tools, software for connections to external systems, and various other new features back to the community. As Sakai grows in strength, the number of extras is increasing explosively. The Sakai Foundation web site mentions at least 20 extras and the Foundation's source code repository has around 120 contributed directories.
Sakai was designed with a framework that significantly simplifies the creation of tools. Developers do not have to reinvent the wheel for fundamental services like finding a user's name, managing a site's look and feel, or internationalization. There are strong, well-established lines of support for developers, including style guides, best practices, a programmer's café, workshops, and central quality assurance (QA), throughout a development project's full life cycle.
To help organizations decide which tools to deploy in their production environments (for example, a college campus), which tools to start looking at for future use, and which to retire, each tool is assigned a status:
Core—Tools with which the community has a great deal of experience and is confident about their robustness, stability, and scalability.
Provisional—Tools with which the community has less experience or which are becoming obsolete. They are disabled by default.
Contrib—Tools with which the community has little experience and which the QA work group does not recommend for broad usage in a production environment. Contrib tools are available, separately from the release, in the Contrib area of Sakai's source repository.
Watching the codebase over time, you see a convection effect where contrib tools move to provisional, are thoroughly tested, and move to core; and then older core tools move down to either provisional or are pensioned off. As time progresses, there is a quality convergence—the software gets thoroughly debugged first by a team of dedicated testers and then by real-life high-scale deployments. In the end, the user has more choices and sophistication in the toolset. The extra choice of tools costs more server effort. Luckily, due to the trend known as Moore's law, servers double in computational power roughly every eighteen months. The end user thus directly benefits from a scalable framework, an increasingly functional-rich toolset, and ever-improving server specifications.
The Sakai Foundation is a not-for-profit organization that was set up in late 2005 to encourage community building between academic institutions, nonprofits, and commercial organizations. It coordinates the release cycle and stimulates the ongoing health of the Sakai community by organizing and sponsoring conferences and fellowships. It manages the software creation life cycle, from development, through testing and quality assurance, to polishing the user experience.
Recognizing the need for best practices and a methodology for decreasing the learning curve for new tool developers, the Sakai Foundation, with the help of Aaron Zeckoski (http://aaronz-sakai.blogspot.com), set up the programmer's café.
The programmer's café is a set of lectures and hands-on programming labs focused on building new Sakai tools. By the end of the café, the programmers have learned enough to create their own masterpieces. The programmer's café is also about best practices and how to use the Eclipse programmers' IDE effectively.
Sakai conference organizers traditionally schedule the café for the day before the main conference presentations, and occasionally, a trainer delivers the café as a separate set of planned events. See http://bugs.sakaiproject.org/confluence/display/BOOT/home.
You can find the most up-to-date information on the Foundation's web site (http://sakaiproject.org), shown below. Notice the links to documentation and downloads. Foundation members work to ensure that the most current information possible is online.
Note
The motto: collaboration and learning for educators, by educators, free and open source, is not accidental. Much care has gone into creating an educationally supportive infrastructure that is free to download, change, and use as you like, with a clear vision of keeping this true for all time. The all-too common nightmare of IP trolls attacking your organization for licensing dues has no role here.
The development of the Sakai CLE has been date-driven with aggressive milestones and a transparent requirements process. The implication is that by the time you read this chapter, the next version of Sakai will be out. There will be more tools for users to choose from, many minor enhancements and performance improvements, numerous bugs spotted and removed, and much honest discussion at local and international conferences and especially in the mail lists.
There is a positive, intelligent, and constructive business-like atmosphere that surrounds the open, but sometimes difficult, discussions within the community.
The next figure shows a generic Sakai worksite for a newly-created user who has logged on for the first time. On the left side are links to the default set of tools. The main area is for expressing the tools' functionality, and the tabs at the top of the screen enable you to move between sites of which you are a member.
By default, a new user owns a worksite with only a basic set of tools enabled, including a few for self-administration purposes. If the user wants, he or she can request a project, course, or portfolio site:
Project—A project site has two main types of users: the site maintainer and those who can use and share the resources and tools. Typical users of a project site include researchers working on the same study, teachers who wish to compare notes, and ad hoc groups of users who wish to interact together online.
Course—A course site is a virtual online expression of a real course. The target audience are teachers who maintain the site with teaching assistants and students who use the site. Teachers can post exams, send announcements, upload syllabi and grade book results, and choose which tools the students can use to interact. Teaching assistants have less power, but can maintain forums and help maintain processes such as the ebb and flow of marking assignments. Students can chat, take tests, upload files, and send mail to others in the course.
Portfolio—Portfolio sites are places where students store evidence of their work in a structured format. As a student progresses through his or her education or course, that evidence builds up within an online structure set of links and web pages. This can be helpful for finding employment later because potential employers can make judgments based on the evidence presented.
Note
Where have the tools gone?
The demo has more tools to choose from than are normally seen in production; the provisional tools are active to give you an opportunity to play with the technology and judge the tools' value before the next release.
Later chapters cover these three types of sites in more detail, beginning with Chapter 4, My First Project Site. For the administrator, a special admin site includes tools for daily business, such as sending "messages of the day" to the entire user base, managing sites and users, scheduling tasks, and generally tweaking the whole environment. Chapter 10, The Administration Workspace, provides extensive information about this site.
In a wider sense, Sakai is not only an application, but also an active community of educational institutions working together to solve common problems and share best practices. The professional development and cross-institutional knowledge sharing are benefits that are hard to find elsewhere.
The vibrant, open source community has structured management and strong commercial support. The central pillar is the Sakai Foundation (http://sakaiproject.org/portal/site/sakai-Foundation).
Sakai is open sourced under the Educational Community License, currently version 2 (http://opensource.org/licenses/ecl2.php). This allows commercial partners to provide hosting, support, and custom modifications, and lets developers work with the full code base. A proprietary license would have slowed down deployment and held back development and wider support.
The benefit of open source for the assessment of quality is profound. You can handle and manipulate the code without having to worry about accidentally violating any commercial license, advanced developers can learn through review, and issues and bugs are more amenable to resolution locally.
The Sakai open source community is confident, open, and not afraid to show the good, the bad, or the ugly. An Amsterdam University-based QA server automatically tests the main parts of the source code for bugs three times a day and publishes at the end of each test a report (http://qa1-nl.sakaiproject.org/codereview) that is viewable by the whole universe and a couple of parallel ones as well. Anyone can download the source code and send modifications to a branch manager.
Different organizations have different timelines for patching and updating their production servers. The source code of Sakai is evolving fast and, once or twice a year, the Foundation releases a new version of Sakai. Some organizations do not have the time or resources to upgrade, but do want to patch their servers for known bugs and security issues. To achieve this, the branch manager copies the source code into another part of the source code repository (this is called branching). The branch manager for the older code is responsible for updating with patches, leaving the newer code in a different branch to evolve.
Being a branch manager is quite a lot of work and it is easy to make mistakes. If you see one of this endangered species at a conference, pat him or her on the back, make encouraging noises, and try not to look at his or her greying hair and the stress lines in his or her face.
Workgroups are factions of similarly interested parties that gather information and requirements on Confluence and share advice and best practices with the community. Visit the main page of the Sakai Confluence (http://confluence.sakaiproject.org/confluence/dashboard.action) and you will see a list of workgroups mixed in with other links on the left side. The workgroups meet online and, usually at conferences, in person. Workgroups exist for developers, quality assurance, management of the software life cycle, the user experience, teaching practices, and so on.
The email lists from the various workgroups are also viewable to the world and there are no limits on who can subscribe. A wiki is in place with a large number of contributors changing content without central editorial control. In general, the community responds quickly.
Note
A full list of workgroups with descriptions is given as part of Chapter 17.
Note
The official Sakai FAQ
http://confluence.sakaiproject.org/confluence/pages/viewpage.action?pageId=27807 is very readable and is a good jumping off point for further study. It contains many useful and up-to-date links as well.
The architects have not just designed Sakai to be a place for excellent online learning experiences; it is also a platform for easy development, especially of tools. At least 100 developers are actively enhancing Sakai directly or through contributions for local deployments right now. That's a rather large number, so you can expect rapid evolution of the product base.
Tool creation is straightforward; most developers within the Sakai community use the industrial standard Eclipse IDE (http://www.eclipse.org) to bash away at their code.
For tool builders, at first development may seem daunting. However, the basic skills needed to create a tool are the same as those for building a standard web application. Thankfully, there is a wide range of supportive material in the wild.
It is beyond the scope of this book to go into the detail of setting up your development environment.
Note
Tool creation
For those of you who are interested in tool creation, the online Development Environment Setup document (http://bugs.sakaiproject.org/confluence/display/BOOT/Development+Environment+Setup+Walkthrough) is a necessary read.
Sakai has deep academic roots and, at the time of writing, is deployed or in pilot in more than two hundred large organizations—mostly universities—around the world. Volunteers have meticulously translated the application into an ever-increasing number of languages. In the worksite profile, the user can choose his or her language preference.
Although its roots are American, Sakai's presence is at the tipping point of rapidly spreading. The following figure shows a Google map of current Sakai deployment locations.
The sites include Australia, South Africa, France, England, Holland, China, Japan, and Egypt and many other countries. Sakai is a world traveler, capable of speaking multiple languages and supporting various learning modalities.
Sakai is relatively young, but has multiple strong roots and has grown fast.
In late 2003, four universities—MIT, Michigan, Stanford, and Indiana—saw a common cause to jointly develop an Open Source Virtual Learning Environment. They agreed to contribute labor to the tune of $4.4 million, and slightly later that year the Andrew W. Mellon Foundation (http://mellon.org) seeded another $2.2 million.
The project did not need to start from scratch; the University of Michigan already had a significant code base and, just as importantly, a conceptual framework and essential experience from the creation of its own set of tools called CHEF. The Java-based CHEF tools encompassed a subset of the Sakai functionality and were mature, with first deployments as early as 2001. The original Sakai code base also included code from the other universities (including coursework and assessments from Stanford) and OSIDs (a set of standard coding APIs and architecture for educational purposes based on Service Oriented Architecture) from the OKI project (http://okiproject.org).
The first phase of Sakai was the so-called "best of refactoring", during which the code was unified and the main framework put into place.
The newly formed team officially announced the Sakai project at Educause (http://educause.edu) in November 2003, and in June 2004 the team released Sakai 1.0. Date-driven development cycles resulted in a high evolution rate and both Michigan and Indiana rolled out Sakai to their student and instructor audience at the end of 2004 and during 2005.
For the Sakai project to survive beyond the first two years, it needed to move away from potential grant addiction toward a model in which the community and project were self-sustaining. The vehicle for this transition was the Sakai Foundation, to which, in a fit of good judgment and self-interest, individual organizations transferred copyrights and resources.
A separate project, the Open Source Portfolio (OSP) initiative, was later merged into the code base and it improved both the overall value of Sakai and OSP products by enriching functionality and allowing a combined use of resources for quality assurance and tool building.
Sakai membership costs an organization $5,000 $10,000 per year. The members channel the money to fund the Foundation, which then helps manage the evolution of the software and stimulates the health of the community.
Recognizing early the significant role that commercial support can play in helping academic organizations deploy, the Foundation created its Sakai Commercial Affiliates (SCA) program to foster commercial partnerships.
Currently there is a healthy biosphere with commercial partners providing a variety of support, from hosting to customizations and tool building. Selling Sakai to local management becomes that much easier. For a relatively few bucks, management can buy commercial support of a known quality to support any new deployments or personalizations. There are small start-up companies that specialize in training or turnkey solutions such as Edia (http://edia.nl) and Airplane (http://aeroplanesoftware.com), and large more established players such as rSmart (http://www.rsmart.com) or Unicon (http://aeroplanesoftware.com). Management is not stuck to a choice of one and competition has the strong tendency to lower costs.
The goals of the Foundation include measuring and understanding the needs of the user, sponsoring inter-organizational collaboration, supporting the growth of the community, and keeping decision-making processes as transparent and accessible as possible.
In the next chapter, you will discover how easy it is to install and use the demonstration version of Sakai on any modern desktop computer, be it Windows, Mac, or Linux. However, why would you deploy Sakai in the larger organizational context in the first place?
No man is an island and no learning system lives outside the context of the organization it supports. Here are some key points for why an organization can be comfortable choosing Sakai:
Educators and software engineers have designed the application from the bottom up and top down to be an effective and flexible learning environment.
An active community is adding useful tools to the mix all the time.
The Sakai Foundation stimulates the growth and good order of the community and is the contact point for project coordination and life-cycle management.
There is a strong central quality-assurance process with many early adopters of new releases. This makes it much less likely that you will have to wake up a system administrator in the middle of the night to deal for the fourth time with an unexpected crash.
There is a commercial partnership program, which means you can buy in support or outsource when you need to.
With standard hardware such as load balancers and Oracle or MySQL databases, Sakai has been deployed for individual organizations past the 170,000-user mark and is relatively simple to set up for even the smallest of pilot programs.
Sakai is a Java-based application using technologies such as Tomcat (http://tomcat.apache.org) as its application server and Spring (http://springframework.org/about) for managing the way it interacts with databases and injects services into tools and other well-known and widely understood frameworks. Java plays well when developed in distributed teams, and the use of mainstream technologies makes it easier to find developers or support in the marketplace.
Sakai supports web services for loosely couple Service Oriented Architectures (SOAs). SOAs are the structure of choice for many organizations' internal administration.
To create, modify, or delete users, courses, and groups externally, this learning environment has integration points called providers that allow relatively easy incorporation into your own administration systems.
Sakai is not going away at any time soon. It has easily passed the critical user-base mass for long-term growth.
Note
Leon Raijmann, an educationalist and top-level manager at the University of Amsterdam, further discusses management buy-in factors in Chapter 16, A Crib Sheet for Selling Sakai to Traditional Management.
Note
Long URLs and Confluence
An approximate description of Confluence is that it is an enhanced wiki. The Sakai community uses one (http://confluence.sakaiproject.org/confluence) as a place to quickly build up documentation and expand ideas. However, the URLs of content are not always particularly readable, and some of the links may be difficult to copy into your web browser. If you get stuck or content has moved, search adding key terms in the search bar found at the top of any Confluence web page.
Sakai is a Java-based open source Collaboration Learning Environment that is flexible, easy to use, and highly scalable. It has an active community of educational institutions working together to solve common problems and share best practices.
The Sakai Foundation supports the community and helps form a coherent project management structure around the life cycle.
The Sakai CLE is not only an application but also a framework for easing the burden of tool creation. Sakai is evolving fast and many developers are busy enhancing frameworks and tools.
The next chapter explains how to install a demo version of the Sakai CLE. One way to approach understanding the content of this book is to have the demo running while reading the chapters on specific toolsets.
