I am pleased to announce four new members elected to the Sakai Project Management Committee (PMC). Here are the new members and the nomination statements for each:

Wilma Hodges, Longsight
Wilma has been a long-time community supporter and Apereo Fellow. She leads the documentation effort, participates in the Apereo FARM effort, leads the Sakai Virtual Conference, and participates in the Sakai Marketing effort and other community activities.

Dede Hourican, Marist
A long term community member, Dede has most recently directed focus on quality assurance with participation in the Sakai QA committee bringing a team of Marist student employees to bear on the process and teaches them about open source software and global communities and building future sakaigers.

Diego del Blanco, Unicon
Diego has been very active in the Sakai community for some time now and Apereo Fellow. He has been a regular attendee of the weekly calls, made significant contributions to Sakai 11 and put in some large features for 12.

Shawn Foster, Western
Shawn is highly active on community calls, provides code contributions, and is tightly connected with the very important usability and accessibility efforts within the Sakai community.

PMC membership is reflective of significant contributions to the community and a dedication to the shared goals of the Sakai community.

In terms of what PMC membership “means”, the PMC members are already active members in the various groups in the Sakai/Apereo community (QA, Core Team, Marketing, FARM, Accessibility, Teaching and Learning, etc.). Most of the decisions about Sakai are made in those groups without any need for the PMC to take a vote or render an opinion because we believe that those closest to the actual work should make decisions regarding the work whenever possible.

The PMC[1] gets involved when there is a significant or broader issue or a decision needs to be made regarding Sakai’s direction or resource expenditure by Apereo[2] on behalf of Sakai [3]. The PMC does all of its work in full view of the community on a public list[4] except for votes on new PMC members.

Please join me in thanking these new PMC members for their past, present, and future contributions to Sakai and welcoming them as the newest members of the Sakai PMC[5].

Update: Title changed from “Committer” to “Contributor” based on a suggestion from Andrew Petro (see comments)

In Apereo/Sakai there is discussion of whether or not we need to doggedly require Individual Contributor License Agreements (ICLAs) from every person who sends in a simple github PR. It is generally agreed that if someone will be making significant contributions we need an ICLA – but many (myself included) feel that an ICLA is not necessary for a simple submitted patch. The issue is that this leaves a grey area and soe folks stay a bit conservative on this.

Andrew Petro did some research on this and here are his notes. I keep them here for my own reference.

Here is the thread where we discussed this:
https://groups.google.com/a/apereo.org/forum/#!topic/licensing-discuss/c1puG3RKZcA

Since this post, CLAs have come up a few times on Apache legal-discuss@, including in July when I brought up Apereo’s desire for a canonical position.

In February 2017, “it is considered good practice to collect individual CLAs even if the contributors are not committers. Strictly speaking this is unnecessary”. That is, Committers and Projects via their PMCs may require CLAs of Contributors rather than just only of Committers, and it may be a good practice for them to do this under some circumstances, but Apache does not strictly require this. Also, this post again confirmed that while it is a good practice for Committers to secure Corporate Contributor License Agreements of their employers, this is a judgment call on the part of the Contributor.

In December 2016, “our IP provenance relies on both our license, our ICLA/CCLAs, and the fact that we have written policies that define who can be a committer and how PMCs can make releases. It’s usually good if a code author (or someone who could otherwise legally sign an ICLA in terms of granting us the right licensing rights to that code) actually submits the work to some Apache project before we put it in a release.” That is, it’s sufficient that an ICLA-signatory Committer actually merges the code into the canonical codebase.

In August 2016, “To avoid the risk associated with clever or large contributions, most PMCs request a formal ICLA to be filed.” Which is to say that some do not, and that therefore Apache does not require that projects do so; individual PMCs get to locally decide when to go beyond requiring ICLAs of Committers to require it of a Contributor in the context of a given Contribution.

In August 2016, on this very topic, “I don’t see that there’s a ‘canonical position’ that can exist.” and “Stating my understanding of the Apache policy – Apache requires ICLAs of its committers, uses ICLAs or a software license (https://www.apache.org/licenses/software-grant.txt) for exceptional contributions from contributors and generally relies on clause 5 of theApache License 2.0 for other contributions from contributors.”

There have been opportunities for someone to argue that ICLAs are required of all Contributors, and that position has not been argued on legal-discuss@.

I think it’s also looking likely that this is as canonical a position as one can get from Apache on this matter.

I am exploring the Silex framework. I am trying to gently evolve a very nice app from “old school PHP” to “new school PHP”. I have chosen Silex (atop Symfony) as my first framework to try. I like Silex so far because it helps me without lecturing me. I cannot rewrite my whole app overnight – I need to evolve to a Silex App, one feature at a time.

This code uses the Symfony PhpBridgeSessionStorage – and it makes me very happy.

<?php

// http://localhost:8888/silex/hello/bob

use Symfony\Component\HttpFoundation\Session\Session;
use Symfony\Component\HttpFoundation\Session\Storage\PhpBridgeSessionStorage;

require_once "vendor/autoload.php";

session_start();
$session = new Session(new PhpBridgeSessionStorage());
$session->start();
$app = new Silex\Application();
$app['session'] = $session;

$app->get('/hello/{name}', function ($name) use ($app) {
    echo("<pre>\n");
    // New Session
    if ( $app['session']->has('y') ) {
        $app['session']->set('y', $app['session']->get('y')+1);
    } else {
        $app['session']->set('y', 20);
    }
    print_r($app['session']->all());

    // Read and write old session
    if ( isset($_SESSION['x'])) {
        $_SESSION['x']++;
    } else {
        $_SESSION['x'] = 42;
    }
    print_r($_SESSION);

    echo("</pre>\n");
    return "<p>Hello $name</p>\n";
});

$app->run();

As the Sakai community discuss the timing for the release of Sakai 12, Matt Jones of LongSight went back into history and summarized Sakai release activity for the past 5 years to help inform our plans for the Sakai 12 schedule.

I would add to the information that Matt shares below that Sakai 2.9 and Sakai 11 made a lot of forward progress with new/revised UI/UX features and Sakai 2.8, 10, and 12 put a lot of effort into performance, reliability, and scalability and contained less new UI/UX.

I am recording Matt’s notes it here so I don’t lose them. He did a lot of work to get these details. It also shows how much community effort (and Matt Jones work) work goes into Sakai releases.

From Matt Jones:

I looked at all of the past releases, some takeaways from below

• The branch to release for the previous two releases (10 and 11) was about the same, 5 months. 10 cut earlier and was released earlier than 11.
• Even though no release has done branch to (actual) release faster than 5 months, we have planned 2 months for 12
• The time from .0 to .1 for 11 was 1 month, but for previous releases previously was longer, about 3 months (which is our ideal)
• The longest time from branch to release was 2.9, almost 13 months
  Sakai 2.8 actually had a Q1 release with Q4 branch. 2.9 was on track for the same but delayed significantly (And ended up with a Q4 release)

Historically there looks to be about a 1-2 month delay from plan to release
Sakai release history 2.8 – 12

Sakai 12
Branch cut: Earliest possible seems 2017-03-22
Release planned: 2017-05-19
Actual release: ???

Sakai 11
Branch cut: 2016-02-17
Release planned: 2016-06-24
Actual released: 2016-07-23
.1 release 2016-08-13

Sakai 10
Branch cut: 2014-01-30
Release planned: 2014-04-30
Actual release: 2014-06-27
.1 release 2014-08-21

Sakai 2.9
Branch cut: 2011-10-17
Release planned: 2012-06-15 (This may have been planned for earlier)
Actual release: 2012-11-09
.1 release 2013-02-07

Sakai 2.8
Branch cut: 2010-09-25
Release planned: 2011-03-01
Actual release: 2011-04-18
.1 release 2011-10-12

Tsugi is open source software that makes it practical to quickly build and deploy learning sites, tools, and content that is seamlessly integrated into Learning Management Systems using the latest interoperability standards. Tsugi makes it possible for publishers of educational software or content to implement integration with major learning management systems with a relatively low level of developer effort when compared with researching and implementing interoperability standards from scratch.

Who might benefit from Tsugi?

• Campus IT staff can deploy an extensible local “App Store” integrated into their local learning management system. The App Store can host Tsugi tools developed locally or install and host Tsugi tools from a wide range of sources including free / open source tools provided by the Tsugi project.
• A faculty member can find and integrate content and tools from their local App Stores and/or other Tsugi-based Learning Object Repositories anywhere on the Internet into their courses.
• For faculty or campuses producing Open Educational Resources (OER) Tsugi allows easy publishing of reusable and remixable OER content and tools that can seamlessly be imported and/or integrated into learning management systems.
• For book authors, it is possible to produce a web site for the book that includes supporting materials, quizzes, interactive exercises, and other learning content. Content hosted in the Tsugi Learning Object Repository can be seamlessly integrated into LMS systems, giving independent book authors a way to provide their additional materials and software in a form that is as good or better than integrations provided by the (very expensive) publishers.
• Instructional designers can work with local developers to quickly develop interoperable learning tools that meet the pedagogical needs of faculty and students. With the productivity gains of the Tsugi library it is feasible to develop unique applications down to the granularity of a particular course. Developer effort goes into building the tool and not developing and debugging low-level code to support interoperability standards.
• Tsugi is a stand-alone MOOC platform. For a school, individual or even professional society, Tsugi can be deployed on inexpensive hardware to support 100K+ users around the world per course. Tsugi has a built in login, grade-book, badging, and other facilities that allow the quick development and deployment that make it quite simple to share content MOOC-style.
• Edtech startups can save resources and quickly develop a Minimum Viable Product (MVP) using Tsugi, put it in production and begin showing it to their customers and investors. WHile they may chose to ultimately build their own ground up implementation of IMS standards, since Tsugi is open source they have a nice roadmap and test harness for their own implementation.
• For a mainstream LMS vendor, encouraging their customers to use Tsugi means that locally developed code at each of their institutions will be consistent, secure, and reliable. LMS vendors will not each have to separately develop “How to make an LTI Tool” documentation – they can just promote the use of Tsugi and leave all the developer training to Tsugi.

What is Tsugi?

Tsugi is a set of flexible “Lego blocks” that work very well together. To meet all of the use cases of Tsugi described above, adopters just pick and choose the elements of Tsugi that are needed.

The primary elements of Tsugi are as follows:

• A set of library routines that implement standards like IMS Learning Tools Interoperability, IMS Common Cartridge, IMS Content Item, and other standards as they become available. The Tsugi library is broken into three layers:
• The lowest layer is a direct implementation of each of the standards.
• The second layer is an “opinionated” API layer that prescribes a relational database model, conventions for the use of session data, compensation for slight differences in LMS implementations of various standards, performance improvements, and reliability improvements taking advantage of the underlying data model.
• The third layer provides an “UI API” that implements the Tsugi style guide so all Tsugi modules look and function similarly from a UI perspective. As we move from 10’s to 1000’s of independently developed tools, consistency in look and feel across tools from multiple sources will be important.
• Tsugi has a management console that supports the Tsugi App Store use cases including Tsugi Module installation, providing facilities for API key management as well as the ability to take incoming requests for access keys to hosted Tsugi modules. The management console also makes it so all of the installed modules can be integrated into an LMS using LTI 1.x, LTI 2, or IMS Content Item.
• A faculty member can develop their course content and host it using Tsugi and then simply import that content into their course shell at the beginning of each semester.
• Tsugi can also be embedded into a public-facing web site providing learning management system functionality for the web site. When Tsugi is embedded into a web site, it can publish the content and tools hosted on the site as a set of interoperable learning objects using the IMS Common Cartridge or IMS Content Item specifications. Tsugi can transform a static educational content web site into an interoperable Learning Object Repository and a learning community.
• Tsugi can be further configured to turn a web site into a stand-alone MOOC by supporting login, activity tracking, tool launching, a map of students who are part of the course, and a flexible automated badging system that automatically issues badges that contain the necessary meta data and validation to comply with the Open Badge Initiative (OBI). Examples of this use case include: Web Applications for Everybody and Python for Everybody.

Getting Started with Tsugi

We are developing a free online course (a.k.a. MOOC) to train Tsugi developers and adopters at www.tsugi.org. The training will be a series of modules with assignments, quizzes and peer-graded activities. As developers complete their training they will be automatically awarded OBI compliant badges showing their progress and accomplishments.

And yes, this is kind of “meta” since we are using Tsugi to build a web site that will train Tsugi developers. Why not? Tsugi is the simplest way to build a stand alone training web site. Oh and of course, since Tsugi is also a Learning Object Repository, anyone can integrate the Tsugi training materials into their local LMS and teach their own Tsugi course. It is indeed “Turtles all the way down” with Tsugi.

There is already a set of exercises with sample code and sample implementations suitable for a workshop or short course on Tsugi.

Example Tsugi Tools

There is already an effort within the Apereo foundation to build, review, and share open source Tsugi tools. A number of simple tools are already available in the TsugiTools github repository:

• A simple attendance tool – This is kept simple so it can be used used as an example of how to build a Tsugi tool
• A quizzing tool that supports the GIFT format pioneered by Moodle. GIFT is a way to author quizzes using a simple plaintext syntax.
• A course map that allows students in a class to place themselves on a map an optionally release information about themselves on the map.
• A peer-grading application the implements a “more social” approach to peer grading. This is quite useful for assessments in MOOCs or social learning situations where there are flexible deadlines and participants are experiencing course material at their own pace.
• A simple way to create Slack channels for a class and invite all the students to the Slack channel.

These tools from the TsugiTools repository can be automatically installed into a Tsugi instance using the Tsugi application management console.

Another set of Tsugi tools are autograders – but these are generally narrowly focused on one topic and not part of the tsugitools repository.

What Tsugi “Is Not”?

Tsugi is not an enterprise Learning Management System like Sakai, Moodle, Blackboard, Canvas or Desire2Learn. Tsugi works with and enhances all of those LMS’s.

An Enterprise LMS is a “walled garden” shielding course material from anyone except those students and faculty associated with a particular course session. An important use case for an Enterprise LMS is to create a “course shell” for every course section that is taught on a campus. Those course shells are important while the class is in session but become archival as soon as the session is completed. Many schools “clean out” course shells that are older than a certain date. All the courses in an Enterprise LMS are at the same URL – the courses exist “within” the LMS. Faculty / instructional designers must design their student experience using whatever limited facilities the LMS has in terms of content authoring.

When Tsugi is embedded into a web site the use cases are quite different. With Tsugi, each course or set of learning content has its own URL and can be separately hosted (this is why a single Tsugi course can easily scale to >100K users). While Tsugi is highly opinionated as to how tools look and feel, when Tsugi is embedded into a web site, the core content of the web site that surrounds Tsugi is simply web content and can be authored and styled in any way that the owner likes. The web site can “inject” style into Tsugi tools hosted by and used by the web site. It means learning content web sites can be beautiful, engaging, and easily searched. The web site can make use of any of the latest HTML/CSS/JavaScript technologies. Tsugi merely “plugs into” and adds value to the beautiful educational content on the web site.

A Tsugi web site is intended to make its materials available “forever” – long after the end of one semester. A Tsugi web site becomes a source of materials that might be in use in hundreds of classes around the world. Search engines can “find” Tsugi learning content sites.

Programming Languages Supported

Given that Tsugi is intended to level the playing field and make it possible for thousands of new developers to learn to build sophisticated learning tools without requiring a lot of programming experience, Tsugi implements most functionality in PHP first. Choosing PHP also allows small to medium Tsugi installations to run in the commonly available low-cost hosting plans with minimum hardware requirements. Choosing PHP also broadens the developer community that can contribute to, understand and/or expand the core functionality of Tsugi.

But PHP is less popular among professional programmers so there are Tsugi implementations that support multiple programming languages and web environments. Each of these is at a different level of functionality and will be expanded as there is interest.

• Tsugi Java shares its low-level API implementation with Sakai. It supports LTI 1.x and IMS Content Item. Tsugi Java also has the second-level “opinionated API” implemented for LTI 1.x launches.
• Tsugi Node has support for the LTI launches with much of the the LTI 1.x standard implemented at both the low level and the “opinionated level”.
• There is a simple bridge to allow one to use the Tsugi PHP libraries in Laravel applications.

All these implementations depend on the PHP-based management console for services beyond LTI 1.x launches. If there is interest we can build management consoles for other languages.

There is emerging interest and discussions in developing versions of Tsugi for Python/Tornado, Python/Flask, and Rails but these projects have not yet started.

Where is Tsugi Going Next?

Tsugi is still a relatively small open source project and so the roadmap is defined by those who are using Tsugi as they have new needs and interests. That means that those who join the project early will have the ability to influence the early directions of the project. At the same time, Tsugi is continuing to evolve to meet those needs so adopters will need to stay in touch with the Tsugi project to know the latest news about changes, bug fixes, and improvements to the project.

Some of the general areas that Tsugi is likely to expand include:

• Better support for analytics standards like IMS Caliper and xAPI.
• More tools like (a) YouTube view tracking, (b) simple scalable threaded discussion tool, (c) a markdown authoring tool for “pages”, (d) a simple “clicker” tool to allow quick polls during a live class, (e) a video quizzing application, (f) a collaborative paper reading / commenting tool, …
• Of course the support for languages beyond PHP needs to be improved and more programming languages need to be supported.

Tsugi is an Instance of the Next Generation Digital Learning Environment (NGDLE)

The core principles of Tsugi are openness, interoperability, and modularity. Tsugi is not a single product or a single library. It is a set of building blocks that can be composed in a myriad of ways to allow us to take a more flexible, distributed, and engaging approach to building and using learning resources.

Tsugi is trying to build the underlying infrastructure to enable teaching and learning innovation to happen many places independently as part of an ecosystem rather than looking for the “one product” that will solve every problem. While Tsugi is a “learning management system”, a “learning object repository” and an “app store” it takes a distributed approach to all these use cases. This makes it possible to have as many learning-oriented web sites, MOOCs, learning object repositories, and app stores as we like.

Ov course once we make it possible to have thousands of sources of outstanding and easily integrated learning content, we will need to solve the problem of searching and discovery. Which will be a good problem to solve.

This weekend I got an email from a leading university that is planning to leave Blackboard and wanted some advice as to how Sakai might fit into their future.

For the past few years, when I get these “What LMS to choose after Blackboard/ANGEL/WebCT…?” emails from folks, I usually send a short note that effectively says, “You have my permission to go to Canvas – everybody is doing it. At least Canvas will be better than Blackboard.” (i.e. Canvas is the new Black)

But this particular morning, with a cup of fresh coffee in hand, I wrote and sent the following note that evolved into an open letter to Blackboard customers who are getting a “little nervous”. The note was to a school outside the US – so you see my focus on privacy issues.

Subject: What LMS to Choose After Blackboard?

Thanks for the note and thanks to your colleague for the reference. I have spent almost 15 years in the LMS market now and know the products and systems very well. As you might well imagine I am very excited about Sakai and believe it to be the best solution in the marketplace for the present and the future.

To me the most important dimensions of an LMS are: (a) an LMS must continuously evolve to meet the needs of on-campus, distance, and education at scale (i.e. MOOCs) as experienced by a modern world-class university, (b) for a university outside the US having 100% control over all student data is a must, and (c) over the next decade while the LMS will continue to be the backbone resource for teaching, increasingly innovation must happen outside the LMS and be seamlessly integrated into the LMS – this allows the LMS to focus on stability, scalability, and consistency while freeing local instructors, instructional designers and IT staff to explore innovative pedagogies freely without compromising the stability of the LMS.

With this context, for a leading institution that is looking forward to innovating in their approach to teaching and learning I feel that Sakai is simply the best LMS in the market. Sakai is the only “100% open source” product and that matters. In a truly open source product, we have no shareholders and no product managers – our shareholders and product managers are our adopters and community – that means you. The schools, companies, and individuals that invest time and resources are the ones that set Sakai’s direction.

Sakai is part of the Apereo Foundation and works with other open source projects that support the academic mission. Perhaps you use CAS as your single signon on your campus. Of particular interest to me is the Tsugi (www.tsugi.org) project that is an open source framework that allows the agile development of a wide range of pedagogically innovative learning tools that are easily and seamlessly integrated into LMSs like Sakai and Canvas using the latest IMS Standards like Learning Tools Interoperability, Common Cartridge, and IMS Content Item.

This is my short assessment of the vendors in the LMS marketplace:

• Sakai is by far the best LMS for a strong institution that wants to “move forward” and sees the learning technology space as needing further innovation over the next decade. The combination of Sakai and Tsugi is simply the best solution in the marketplace of the notion of a more ecosystem-oriented “Next Generation Digital Learning Environment” (NGDLE). If you want to be part of the community who will define the NGDLE, Apereo Open Source is the answer.
• Canvas is my second choice as an LMS as it is a leader (like Sakai) in allowing external tools to seamlessly integrate into the product. If you are a school that is interested in being a “fast follower” or have a weak IT team, Canvas is an excellent choice. Canvas is a good choice for second-tier schools or community colleges that want to be innovative but don’t want to be a core influencer in the next generation architecture. Interestingly Tsugi also works very well with Canvas because Sakai and Canvas implement the same IMS standards in very similar ways. Canvas is not “100% open source”. They release portions of their source but the intention is not to have you run your own instance of the software. That of course means that you are putting your data in the cloud in the hands of a US company. I personally think it is important to control one’s own data.
• Moodle is a fine LMS and it is certainly Open Source – but it is not participative open source like Sakai. End-user adopters have very little influence in the direction of the product. But if you are a small school with a weak IT department, you probably don’t have that much interest in changing the features of your LMS. Moodle generally trails the market in terms of implementing the latest interoperability standards but they get there eventually. Self-hosted Moodle at a small school takes very low levels of developer resources as long as you *never* customize the code base or upgrades quickly become almost impossible. Cloud hosting Moodle with a company in your country is probably sufficient to assuage your data concerns. I would not recommend cloud-hosting *any* LMS with a US-based company at this point.
• Blackboard has been effectively frozen for the past four years because of their grand rewrite they call “Ultra” that has not gone well. The primary reason for the failure of Ultra is some very bad architectural decisions that make it challenging to make an application as complex as an LMS highly reliable. The result of over-investment in Ultra leaves Learn as a pretty clunky piece of antique software, lagging in implementing the latest interoperability specifications, and a future that will be a very painful upgrade as the gulf between Learn and Ultra widens. I am glad to hear that you are considering leaving Blackboard.
• Desire2Learn/BrightSpace is a clever company and their customers seem to like the product very much. My experience is that they are the best product for a heavily multi-tenant architecture. Many of their most successful customers are state K12 systems in the US that want to purchase a single product to be used by 100+ small schools. D2L has historically been a laggard in implementing interoperability standards but in the past year or so – they have realized the importance of interoperability and are working to be on par with Sakai and Canvas although it will take some time.

In summary, if you are leaving Blackboard, if you are bold and want to be part of an effort to take on the next decade of challenges in teaching and learning you should choose Sakai. If you have a weak IT organization but want to appear to be “innovative” with less risk and can tolerate the privacy consequences of cloud-hosting with a US company, choose Canvas with my blessing. If you are a smaller school with a weak IT organization, and just want something solid that will work, choose Moodle – either self host it and *never change a single line of code*, or out source hosting to a non-US company.

I use all three of these LMS’s. Sakai is amazing and working with a thriving and robust community of like-minded innovators is even more amazing. Building Tsugi in this same community is the most fun thing I have ever done. Canvas is a good workhorse – it has fewer features but does a solid job on those features and has an industry-leading interoperability strategy. When I have to install and administer my own LMS in my spare time for small-scale applications, I use Moodle. But I have changed 50 lines in my Moodle installation and so I have not upgraded my Moodle for 3 years because I don’t have time to re-debug and re-implement my changes in the latest release.

If you do choose to move from Blackboard to Sakai, there are companies that will help you through the conversion. There are local Sakai hosting companies that we can put you in touch with. There are also Sakai commercial companies that will maintain your Sakai installation on your campus using your hardware so you have 100% control of your data but leave someone else to deal with patches and upgrades. True “100% open source” leads to a diverse, international, rich and innovative commercial provider community.

I am happy to talk more and I expect to be in in your area next month and might be able to swing by your campus to give a presentation on Tsugi, Sakai, and Apereo. Even if you choose Canvas or Moodle – you should join Apereo so you can work with us on Tsugi.

This presentation will describe and demonstrate the latest use of Tsugi to build a standalone web site that combines Open Educational Materials, Cloud Hosted LTI Tools, a single-course LMS, auto-graders, Open Badges and a learning object repository providing resources for import into other LMS systems. I call all of this combined together “A MOOC Of My Own” (MOOCOMO). I have created two of these MOOCOMO sites that I use in both my on-campus teaching as well as my current and upcoming Coursera (and possibly edX) courses.

This presentation will describe and demonstrate the latest use of Tsugi to build a standalone web site that combines Open Educational Materials, Cloud Hosted LTI Tools, a single-course LMS, auto-graders, Open Badges and a learning object repository providing resources for import into other LMS systems. I call all of this combined together “A MOOC Of My Own” (www.moocomo.org). I have created two of these MOOCOMO sites that I use in both my on-campus teaching as well as my current and upcoming Coursera (and possibly edX) courses.

Submitted to: Sakai Virtual Conference 2016.

If open educational resources are to truly compete with commercial publishers, we must provide a full set of open capabilities that support a book. Publishers provide learning resources in a learning object repository (LOR) that allows remixing and easy integration into learning management systems using protocols like LTI. Publishers provide learning resources like slides, assignment, and interactive software to help those who use the book. Every open book should also have a truly free and open MOOC associated with the book that does not depend on any institutional LMS or MOOC hosting provider. We need the ability to have a OER website for a book, a “LOR of my Own”, an “LMS of my Own” and a “MOOC of my Own” using only our locally owned and controlled resources. The tsugi.org project in effect is the WordPress for Open Education. By downloading, configuring, and hosting a simple PHP application augmented by free content delivery networks, it is possible to deploy a scalable worldwide MOOC with surprisingly low cost. This presentation will introduce the tsugi.org software and show how it is used to build sites like www.py4e.com.

Submitted to: Open Textbook Summit 2017 – May 24-25, 2017 at SFU Harbour Centre in Vancouver, British Columbia (Canada)

The past year has been very eventful for Sakai. The Sakai-11 release was completed with the new frameless (Morpheus) portal, new Grade Book, responsive design, and many other game changing features to bring Sakai very much in line with the best LMS systems in the marketplace. A large number of Sakai sites are moving their production to Sakai 11 and we are working on a Sakai-12 release. This presentation will will give a brief summary of the Sakai project to date as well as expectations for the next year. The presentation will also feature a question and answer session with members of the Sakai Project Management Committee (PMC).

Submitted to: Open Apereo 2017 – Sheraton Philadelphia Society Hill Hotel, PA | June 4-June 8, 2017

The past year has brought a lot of progress and adoption in the Tsugi project. A NodeJS version of Tsugi has been developed in addition of the existing PHP and Java implementations. The library code has been refactored to focus on providing the Tsugi libraries using the Composer dependency management system. Support for IMS Common Cartridge and IMS Content Item has been added so as to allow Tsugi to function as a Learning Object Repository in addition to an Application Store. These new functions have been combined together to produce a truly “next generation” Learning Management System that enables an “indie” publisher to deploy a topic-oriented, LMS, MOOC, LOR, and App Store using low-cost readily available hosting infrastructure. This presentation will provide an over view of the current status and plans for Tsugi going forward.

Submitted to: Open Apereo 2017 – Sheraton Philadelphia Society Hill Hotel, PA | June 4-June 8, 2017