On this page
Are you interested in contributing to the Sakai project as part of Google Summer of Code 2013? Then this page is for you!
Scroll down for an introduction to Sakai, project ideas proposed by our mentors, and tips on making your application. Sakai has applied as a mentor organization again this year; please check the GSoC 2013 site for program schedule dates.
Sakai Collaboration and Learning Environment (CLE) is a powerful Learning Management System / Virtual Learning Environment (pick your preferred term), used by over 350 educational organisations and actively maintained and developed for. Sakai Open Academic Environment (OAE) is a first-principles redesign which is currently in active development and pilots in our community. Sakai CLE's ecosystem is very healthy and OAE is a completely new codebase, so expect the two to co-exist for some time.
The original Sakai project is very widely used every day and has over 4 million educational users. Usually deployed for a whole institution, users create 'sites' for learning management (e.g. associated with lecture courses), research collaboration (e.g. on a particular research project or research group), project collaboration (e.g. for course designers or final-year projects) or e-Portfolios (for learners to assemble portfolios of work they can use to reflect on and evidence their skills). Each site is a shared space for its members, and its creator chooses a suite of 'tools' to use within the site. Users work in one tool at a time. There are many built-in tools, e.g. file sharing, announcements, wiki, forum; and even more contrib tools, e.g. opensyllabus.
You can learn more about Sakai CLE on the official information page.
Sakai OAE embodies a complete new design philosophy. It aims to 'unsilo' the tools concept by simply making them content to be embedded in the site. It also aims to complement the outward-looking experience of learners and researchers by by being more social and more 'permeable', being part of the web as well as being part of the institution. OAE offers
You can learn more about Sakai OAE: read an early proposal, or check out the official information page.
Most people working on Sakai work at educational institutions using it, so in effect it is developed by universities and colleges for universities and colleges. The community is still run on open source principles, but this is a bit different from archetypal OSS projects where people contribute in their spare time, so we sometimes make a distinction by calling it "community source" rather than "open source". We use the Educational Community Licence 2.0 (FAQ), which is OSI certified and is a minor variant of Apache 2. The Sakai community organises itself and its work using a typical suite of OSS tools:
CLE is developed and a series of standard Java web applications (usually called tools) running in a Java servlet container (commonly Apache Tomcat). It uses the Spring Framework as a base for the Sakai CLE Kernel and Component Manager which manages the Sakai services and allows the Sakai tools (webapps) to communicate.
Individual tools (webapps) use a variety of technologies (e.g. Spring MVC, RSF, JSF, Velocity, etc.) but plug in to the CLE Kernel to access core services.
This list is currently building, while we recruit mentors. Each mentor gets to propose their own project ideas.
Once you've got to grips with Sakai yourself you might find you've thought of an idea you'd love to work on. That hasn't happened very often in the past but we love it when it does. You'll still need a Sakai mentor though so you'll need to get on the Sakai-dev mailing list as early as possible, whip up some enthusiasm and recruit yourself a mentor.
Mentors: please enter your proposals here. Proposals should summarise what the project is about, provide some motivation for it, briefly outline important technologies and skills, and if necessary a short description of the kind of candidate you think the project would suit. Also, a little advice on getting started can help candidates make a good application.
Mentor: Zach Thomas
A demo install of Sakai 2.9.1 weighs in at over 800Mb. This makes for long startup times, high memory demands, and a slow feedback loop for developers. The cause of this is redundancy of the included dependencies (there are 139 complete copies of sakai-kernel-util-1.3.0.jar, for just one example!) and an everything-but-the-kitchen-sink approach to the makeup of the basic system. The solution is better modularity and a good package management system. It should be possible to start with just authentication, authorization, and sessions and add everything over and above that a la carte, using package management. It should be just as easy to update Sakai as it is a smartphone.
Mentor: Zach Thomas
When you run a cluster of Sakai application servers, every user session "sticks" to one particular server (i.e. each of their requests comes back to the same machine). This causes problems for elasticity (being able to add and remove cluster nodes according to demand), failover, and rolling updates. The solution is not to store any state on an application server (with the exception of some caches, which can be thrown away at any time with no trouble). User session state should be kept as small as possible and then clustered with something like Redis, Riak, or memcached.
Mentor: Zach Thomas
Mentor: Zach Thomas
From the very beginning of the servlet specification, servlet containers have used a single thread per request. The problem with this approach is that it's possible for the thread to be idle while it's waiting for some time-consuming part of the request to be fulfilled (such as a web service call or an expensive database query). Furthermore, the overhead required for threads means that beyond a few hundred, performance falls through the floor. This places a significant constraint on concurrency when we want a service to scale to hundreds of thousands or even millions of users. The solution to this is a combination of a pool of threads for performing processing-intensive operations along with non-blocking threads using asynchronous callbacks. See Akka and vert.x for implementations of this approach.
Mentor: Carl Hall, Seth Theriault
If you have questions or want to discuss your ideas, try sakai-dev list, then the project mentor directly (unless you don't have one yet). We will always try our best to respond and give advice, but please be patient as sometimes we have a lot of questions to answer.