What is the “Next Next LMS?”

There is a certain restlessness for any university using any LMS. Faculty and students generally love their LMS after they have used it for 3-4 years and are opposed the idea of switching to a new LMS, often the IT organization starts to get restless about that time and starts a “Next LMS” evaluation effort. Perhaps there is a new Chief Information Officer and they want to “make their mark”. Perhaps the IT organization has gotten tired of broken promises from their old commercial LMS vendor and are looking for a new vendor who will again tell them sweet little lies. Perhaps, it is just that the beginning of a new relationship is just “so exciting”. In many ways by changing LMS systems every 5-10 years IT gets a “do over”.

It seems as though as soon as any commercial LMS vendor reaches a threshold of market share, they slow down, begin to take their customers for granted, and prioritize “shareholder value” . There is always the ascendant “Shiny LMS” and the descending “Rusty LMS” and the inevitable transition from shiny to rusty to restart the process. There is an active consulting business to advise CIOs on the rusty to shiny transition. Here is a simple table of these commercial LMS’s over time:

Year Rusty        Shiny
1997 emacs        Blackboard
2001 Blackboard   WebCT
2006 WebCT        Angel
2008 Angel        MoodleRooms
2012 MoodleRooms  Canvas
2019 Canvas       Desire2Learn

By this analysis – everyone should just choose Desire2Learn as their “Next LMS”. At this point with Canvas and Blackboard owned by private equity and focused on paying off $1B+ loans through revenue and profits – both are in the “Rusty” category.

The shiny to rusty transition of Canvas was pretty quick. Two years ago, they announced that they had a lot of learner data and “AI was the future”, then they did a “hostile sale” to private equity to cash out, and then announced that “AI was not the future” – but the damage was done. I know of at least one school that had selected Canvas during this time and as Canvas rusted before our very eyes, they called their consultants back and asked them to hurry back and re-advise the school to go to Desire2Learn instead. Whew! Skipped one unnecessary commercial LMS switch!

It is kind of scary that Desire2Learn (with a 15% and growing marketshare) is the only major commercial LMS vendors with its founder(s) still involved and not owned by anonymous billionaires. I have liked working with and partnering with all of the commercial LMS systems over the past 15 years – when their founders were still part of the company. I loved working with Michael Chasen, Chris Vento, David Mills, Phil Miller, and Brian Whitmer. They are gone – their companies are gone or run by accountants. John Baker is the “last founder standing”. D2L is the last commercial LMS vendor with “values” that go beyond shareholder value. For the time being.

The problem is that the CIO sheep are going to run from rusty Canvas to shiny D2L like they have always done. When enough switch so D2L has a 40% market share, then D2L will begin to rust and as things start to nose down, someone will write a $2B check for D2L and at that point 85% of the higher education marketplace will be owned by soulless billionaires. They won’t make the mistake that Blackboard made and forced new “recruits” to switch software – they will slow innovation to a crawl and put skeleton maintenance crews on Blackboard, Canvas, and D2L and drain higher education dry for a decade to pay off their $6B of loans.

It is difficult to imagine a new Canvas-like startup in a garage somewhere in 2020 that has any chance of success. You get your version 0.1 wander into the marketplace fighting Blackboard, Canvas, and D2L. The open source lane is well covered by Sakai and Moodle. The K12 market is no longer available as Google Classroom and Microsoft Teams have won. Community colleges have little interest in anything other than using the same thing they have always used. And R1 schools in higher education – decided to “outsource it all” to the big-three commercial cloud-vendors.

This suggests that by around 2025, the commercial LMS market will start feel like the opening sequence to Joe Versus the Volcano.

It seems inevitable – :(

Abstract: Pedagogy and Privacy in a Pandemic

This presentation will look at how teaching and educational technology has and will continue to change during the Pandemic. When the pandemic hit, there was very little time to prepare for the move toward increasing use of technology. In many ways the world did not have the luxury of being concerned about impacts to pedagogy or privacy – we just dove in and started solving problems. As the pandemic continues it has brought a lot of focus on concerns for student privacy and ways to improve pedagogy. The speakers will discuss issues of pedagogy, privacy and technology in light of the pandemic.

Laura Gibbs is a long-time online instructor at the University of Oklahoma teaching Gen. Ed. Humanities courses. She is the author of Aesop’s Fables: A New Translation (Oxford World’s Classics) and the Tiny Tales book series; you can find out more at TinyTales.LauraGibbs.net.

Charles is a Clinical Professor and teaches in the School of Information at the University of Michigan. He is the Chair of the Sakai Project Management Committee (PMC). Previously he was the Executive Director of the Sakai Foundation and the Chief Architect of the Sakai Project and worked with the IMS Global Learning Consortium promoting and developing standards for teaching and learning technology. He teaches 21 popular MOOCs and three specializations to students worldwide on the Coursera, edX, and FutureLearn platforms and is a long-time advocate of open educational resources to empower teachers.

This abstract was for the 2020 Sakai Virtual Conference – Recorded Video

Email Answer: Can you help me with my learning or one of your free / open classes that I am taking?

I get a number of messages per week from students who take my courses online.  I have well over a half million online students so I don’t have time to individually respond to all the messages I get via Twitter, Email, or LinkedIn.

I do skim all the messages I get – but only reply to a few.

Before I talk about the messages that I don’t answer, let me talk about the messages that I *do* answer like the following:

  • I am using an auto-grader in your course and it is broken.  If you have a screen shot where my code has an error message – I want to know about it and want to fix it.  I will bug you and ask you to keep testing the problem until I verify it is fixed.
  • If you find a typo or mistake in one of my web sites or books – I would like to hear about it.  I like to fix little things so the quality of the materials is kept high.
  • If you want to translate some of my course material to a new language – that is really cool and I want to hear about that.
  • You are a teacher and want to adopt or have used my materials for a course you are teaching.  I love that and want to hear about it.

The following types of messages are read – but I rarely reply to them:

  • Can you write a recommendation for me?  I only write recommendations for students I work with outside of class.  I don’t even write recommendations for students who take my courses on-campus at University of Michigan.   I *understand* that recommendations are difficult to get.  I just feel really bad writing a recommendation that says “I had Tony in class, and because he did not cause any trouble I would not even recognize Tony if he came up to me.”   I love writing recommendations for students when there is real collaboration.
  • Could you design a plan of study for me? Could you give me career advice?   I have some videos about career advice in some of my courses but don’t have time to be an individual career counselor.
  • Can you be my mentor?  I only mentor about 2-4 students per year – and I work with students because their interests (i.e. educational technology, open source, and open content) align with my interests and I get help from the students on my work.
  • Any question about Coursera, edX, or FutureLearn payments, dates, sessions, etc.   I provide my material to these MOOC platforms and they run the courses.  I don’t have veto power over what the platforms do or when the courses run or what the due dates are for each assignment.
  • Could you sign a certificate of attendance so I can get reimbursement?  This is an issue with the MOOC providers – I do not check ID nor take attendance in these courses so I can not and certify anything.
  • Any message about an honor code violation where you “mistakenly” uploaded something that was not your own work and you got caught.  These messages usually weave some long intricate story and want “one more chance” – I ignore these messages.   Read the assignments, do your own work and don’t take short cuts.
  • Can we connect on LinkedIn?  I only connect on LinkedIn to people I know professionally.  I don’t connect to students at all until I have worked with them on a project.

As I said above – I do see virtually every message and skim them all.  Sometimes something in a message will jump out at me.  Skimming a message is pretty quick but writing a reply takes a lot of time that I just don’t have.

It does not make me happy to ignore these messages – I wish I had time to reply to them all.  If I replied to every message it would take more time than I have in a day and I would get nothing done :(

So I apologize in advance.






How to build a JSR-168 Portlet in Sakai

Using JSR-168 portlets is the only way to have a page (like Overview) with multiple tools on the page rendered without iframes.  The portal only removes iframes when a page has one tool.  If there are > 1 tools – it uses iframes.   But JSR-168 tools never use iframes no matter how many there are on the page.

It is pretty easy to convert a servlet-style tool to portlet-style – in particular if the tool uses either JSP or Velocity templates, t is pretty simple.

Here is an example of a tool that uses Velocity:



This was a direct conversion from an old iframe+servlet style tool used in earlier versions of Sakai:


If you want to use JSP as your templating language, the following is a sample JSR-168 portlet:



The portlet model sends GETs go to “view” methods and POSTs to “action” methods.  Our Velocity tools have the same concept of action and view – but they are hand-layered on top of a servlet using convention and classes like VelocityPortletPaneledAction so the pattern will be familiar for those who wander through old Sakai code.

Another interesting bit of Portlets is that they have view “modes” like “Help” and “Edit” that are part of the spec.  Velocity “portlets” have panels but they are not as formally defined.

For example if you see a JSR-168  portlet in Sakai (image)  (Home Information is a portlet) , there is a “Edit” button that comes from the *portal* in the portal title line.  That edit is not part of the portlet’s markup – the portlet simply declares one of its views as “the edit view” and Sakai puts up the button and wires it up.

For an old-school Velocity servlet pretending to be a portlet in an iframe (like Message of the in the image) the “edit mode” is just another panel in the tool and the tool puts out markup with a link to its “edit view” in “Options” below.

It is surprisingly easy to convert from the old to the new because the view/panel and action patterns already are pretty parallel – the velocity servlet that is a fake portlet was one of the inspirations for  JSR-168 so the similarity is not random.  Both were “cool” MVC approaches in 2001-2003.

I love the JSR-168 pattern for multiple independent rectangles on a page.  There is a clever pattern that allows all of the rectangles to handle the back button and refresh in a consistent manner for all three rectangles simultaneously.  I would love it if all the Sakai tools were rewritten as portlets – but with the magic iframe inlining since Sakai 11 – it is only really beneficial for synoptic tools.

Beyond an Accessible LMS – An Accessible LMS Community

TL;DR: Chris Knapp’s Post about two weeks of his experiences in the Sakai community

For over 15 years, the Sakai Learning Management System has been committed to building a product that not only meets the legal requirements of accessibility – but has the higher goal of making the Sakai user experience “excellent” for visually impaired learners.   We feel that an LMS must take that extra step because access to a good education is not a luxury – it is a fundamental human right.

Sakai greatly benefited from having Jutta Treviranus on our board during our early days.   Jutta helped us understand that accessibility for an LMS was not just a “checkbox”.  She not only inspired us to make Sakai a great product for visually impaired learners (i.e. all of us), she shared her research and innovation (i.e. https://idrc.ocadu.ca/ )  with us to give us the tools to achieve those goals.

Sakai is beginning an effort to take the next steps in becoming an accessible community.  Our goal is to make special efforts to being visually impaired contributors in as regular members of the community.  Our goal is for VI members to participate in all aspects of Sakai from development, to quality assurance and community leadership.  Of course one of their contributions will help us maintain the high standard for accessibility in the Sakai product – but our goals are broader than that.

My company (Learning Experiences) has retained Chris Knapp of Knapp Strategic to be embedded in the community and help us improve the accessibility of all of our processes and tools.   He will be integrated as part of the Sakai QA team (Chris is not a coder) and help us adapt all aspects of our human processes and/or tool chains to make them more accessible.

Once Chris works through how to be a visually impaired Sakai contributor, we will begin to recruit and Learning Experiences will pay other visually impaired people to be Sakai contributors.  We are just getting started with this but we have high hopes for the effort.

Chris wrote a blog post that summarizes his first few weeks of his involvement as a VI contributor in Sakai.

I will just say that it has been only a few weeks but has been great fun for me.  So far one of my favorite eye-opening moments was when Chris attended our weekly Marketing meeting.  We got to talking about an upcoming social media launch and we were talking about how images of the Sakaiger might be best used in the campaign.

Sitting in the Zoom meeting, I realized that Chris had absolutely no idea what the Sakaiger looked like.  And he had no idea even what the “rings of water” Sakai logo looked like.   So I sent him a stuffed Sakaiger and several knit caps with the Sakai “Jewel” logo on them.

A stuffed Sakaiger is an accessible three-dimensional version of a mascot image!  I never would have thought of that – except that once Chris was in a meeting with us – it was immediately obvious. Pretty cool.




Enabling a Just Education and Educational Technology Future

Enabling a Just Education and Educational Technology Future
PI: Dr. Charles R. Severance, University of Michigan School of Information
Unsolicited Funding Proposal – 2020-09

The Andrew W. Mellon Foundation support for the $2.4 million dollar Sakai Project to the University of Michigan and others in 2004, is probably the most impactful philanthropic investment in educational technology of all time.  The Sakai Project set out to solve the problems of software interoperability and data portability by developing an open source Learning Management system that would implement and demonstrate best practices to the educational technology industry.

In 2004 and 2005, by leveraging its Andrew W. Mellon Foundation support, Sakai quickly delivered on all three of its core goals.  We released four versions of Sakai (1.0, 1.5, 2.0, and 2.1). In late 2004, Sakai worked with IMS to form the IMS Tools Interoperability working group and in mid-2005, Sakai worked with IMS to form the IMS Common Cartridge Working Group.

Fifteen years later, these efforts have matured into an LMS market place committed to standards and interoperability.  When the latest version of IMS Learning Tools Interoperability (LTI Advantage) was released in 2019, five leading LMS vendors (Sakai, Moodle,  D2L,  Blackboard, and Canvas) announced support for the standard on the same day.

While the software interoperability efforts created by Sakai are a great success, there are larger concerns in the LMS and educational technology market that must be addressed to assure fair,  safe, and just access to education – particularly students in at-risk populations and for students outside the US/Europe:

  • At this point, 60% of the LMS marketplace is using proprietary cloud-only solutions owned by private-equity companies.  While these solutions are convenient for higher education, handing sensitive and private student activity data to these third parties who treat it as an asset is a concerning trend.
  • The lack of an open-source and standards-based learning object repository (LOR) continues to leave high quality material stuck in LMS systems.  When we reduce barriers to content reuse, we can broaden access to education regardless of geography or economic situation.
  • The lack of a MOOC platform that is interoperable, easy-to-use, and based on standards restricts MOOC-like approaches to the privileged, wealthy and proprietary.  None of the current MOOC platforms participate in educational technology standards activities.

The Sakai, Tsugi, and Apereo open source efforts will be able to achieve these goals with a reasonable level of investment.  Sakai is a mature LMS with some of the highest satisfaction ratings in the market, Tsugi is a simple, standards based learning object repository (LOR) and Massively Open Online Course (MOOC) hosting platform.  Tsugi has many technical aspects of LOR and LMS integration solved but so far has not had enough UI/UX investment to be used directly by a non-technical teacher.

Our open-source efforts are already working on these goals as fast as we can.  This proposal seeks funds to greatly accelerate efforts to (1) maximum protection of private student activity data, (2) standards and open source infrastructure to support reusable learning content, and (3) a MOOC platform that makes the creation and teaching of free and open educational experiences available to every teacher and student in the world.  It is a bold vision and we are well positioned to achieve these goals with sufficient resources.

Note: I wrote this as a response to an RFI with a goal of ensuring a Just Educational Future from an unnamed funding agency.  The RFI turned out to be aimed at an audience that did not include me so I  made it a blog post.  If any funding agency is interested in funding the work – let me know.  I am looking for about $5M over a three years period.

Infrastructure – Spring / Hibernate / Ignite for Sakai-21

For those who have been around a long time – or those who read my book about the founding of Sakai, you know how strongly I feel about addressing technical debt in a project like Sakai.

Sakai-21 is coming out in a quicker time scale than usual so we can target a release by the end of the year. This has meant that some things like the all new Lessons got pushed to Sakai-22 – even though Dave Bauer gave us a nice facelift of the existing Lessons at the last minute.

But even in that short time scale some really amazing work has been done on technical debt inside the Sakai code base. Java is still a great choice for web applications – and Java just keeps improving – but we need to keep up to build better features using the latest that Java has to offer.

There are two major things in Sakai-21 that no user will ever see – but are critical to us from an infrastructure perspective:

– Spring and Hibernate have been upgraded to the latest versions – this is the first time we have not been running a “back-level” version of these libraries. It is a lot of work to upgrade these libraries and when it is all done – you just see the exact same Sakai UI as before. But they are essential to give us a strong platform to build upon.

– The cluster coordination has been replaced with Apache Ignite – which is a Redis-like product that does not require a separate server. When a school moves from one to many app servers, somehow these servers need to coordinate things through distributed “caches” – Hibernate uses these caches and things like the authorization service (who can do what to which object?) uses caching as well for performance. Back in 2005 we used the database as a distributed cache – which severely limited our ability to scale. Ignite is fast, efficient, open source and does not require any additional server deployment. (We do need to get it to quiet down in the logs a bit :) ).

Both of these things are very challenging technical efforts that take effort away from things that users see. But these investments are essential to keep our product performing well, based on supported libraries, and make new developments much easier.

As an example, I am adding a cluster-wide cache for the keys used to generate and check OAuth tokens for the LTI Advantage API (SAK-44195) for Sakai-21. This is essential (a) for performance, and (b) so that API calls can be spread across a Sakai cluster for larger schools.

Because of the amazing Ignite work that Earle has done, the following is how you create and use a cluster-wide cache in Sakai:

Ignite ignite = (Ignite) ComponentManager.get(“org.sakaiproject.ignite.SakaiIgnite”);
IgniteCache<String, String> igniteCache = ignite.getOrCreateCache(“blisCache”);

igniteCache.put(“42”, “HHGTG”);

Literally in two lines of Java I create or connect to a scalable distributed key value store in Sakai that just works. This is the magic of what Earle has done in his Ignite project. Take something very complex inside of our code base and reduce it to two lines of code.

Adding this new infrastructure will allow us to remove a lot of cruft from the Sakai code base over the years and really improve the performance and scalability of Sakai going forward and gets us one step closer to our goals for the Sakai infrastructure.

So thanks to Earle and others who built and tested these great contributions to Sakai-21.

Thinking about a license change to GPL for Tsugi

I have been rolling around an idea a switch to GPL as the core license of Tsugi and am curious as to what you think.
This is definitely a switch in direction – the Apereo Foundation (and Sakai Foundation before that) – has historically been very pro Apache (and its second cousin once removed ECL).
I have done some writing over the years that is not particular friendly to GPL:
But I have been GPL-curious for a long time:
Here is my 2020 summary of how we got here and where we might go from here:
– In 2003, GPL felt a lot more like an “infection” – commercial companies were scared to go near it in case the the GPL infection might spread to their proprietary products (i.e. like in the Ring movie – if you look at GPL code you are forever marked).   IBM built staffing firewalls where those who touched GPL code never interacted with “real” IBM engineers.
– Because of this, there was a notion that if you did GPL, companies would neither adopt nor help you.  Hence Sakai was militant pro Apache in 2004.
– In the by 2008, we kind of understood that modern companies were not afraid of GPL.  And frankly if a company was afraid of GPL – perhaps that was an indication that the company had a slightly different set of values w.r.t. open source.   And it turns out that one company back in 2004 that was the most vocal against GPL *did* have some big plans that were not entirely shared with us.  Thankfully that company is no longer in existence – due in part because their strategy was not as profitable as they had hoped :)
– In the early days, when we spent a lot of time “transferring copyright ownership” to the Foundation, using the Apache / ECL license felt better to a lot of folks.  But for “organically grown” code like Tsugi – and the new github world where collaborators flow in – it really does not matter.
If you look at my most blistering attack on GPL:
It is less an attack on GPL per se and more an attack on “who owns copyright”.
What has happened in the past decade is a change in approach to copyright “ownership”.  In the old days, Apache and Sakai/Apereo transferred “ownership” of the code to the Foundation.  And for the early part of Moodle – Martin Dougiamas owned all the code and any contributions were given to him.
Things are different today.  The Apache Foundation and Moodle lets contributors keep the copyright on their contributions and simply provide a non-expiring no limitations right to use.
This means that Moodle is no longer 100% owned by Martin.  It might be 80% owned by Martin (legacy) but 20% is owned but other people.  It is 100% *licensed* to the Moodle community and those licenses cannot be revoked.
This is a super important distinction as it has to do with the danger of someone like Martin or the Apereo Foundation going evil and selling their interest to some third party.   Yes this is unlikely that Apereo will go evil – but if there was a complete turnover of the board – we Apereo could quit-claim their interest to some proprietary company.
But with multiple “owners” like Moodle has, Martin can only “quit claim” 80% of the code.   The other 100 or so contributors also need to quit claim.  This effectively insures Martin can’t really do a meaningful quit claim.
Once the “who owns the code” and “who works on the code” is resolved – the difference between GPL and Apache is that GPL is harder to fork and go proprietary.  It is trivial to fork and go open source.
And the key *advantage* of GPL is that GPL is seen as an “activist” open source license.  Apache is pretty passive – there is little brand value to being Apache.  The Apache brand is about being very boring.  There *is* brand value being GPL because of the Free Software Foundation’s promotion of your product:
Sakai and Tsugi are not “open enough” to qualify as software that protects user freedom.
This might seem insignificant – but if by switching to GPL – we gain marketing and lose nothing – then why not.
Thoughts welcome.

Styling Tsugi / Koseu Lessons

I am developing a version of Lessons that can be heavily tweaked through CSS.  To do this I am revising the HTML output of Lessons to be more basic and semantic and therefore more easily tweaked by CSS.  The new default look and feel of Lessons looks like this (go into a lesson):
You can see some examples of how you can tweak the look and feel here (go into a lesson):
First you will notice that the carousel is gone.  It is actually not exactly gone – but if you put “videos” in a module it renders like the above two sites.  You can go back to the carousel by changing all of the “videos” keys in your lessons.json to “carousel” and poof the carousel will reappear.
There are two new features in lessons.json – take a look:
"headers": [
    "<link href=\"{apphome}/css/lessons.css\" rel=\"stylesheet\">"
"settings": {
    "prev-next": "right"
The headers is an array of text lines to add the the <head> part of lessons pages.  The {apphome} expands to the top URL for the site.  You can do a bunch of fun stuff here.  I load up some CSS.
You can see that I have added some classes to the tags in the Lessons module output that should let you get a handle on the markup and tweak it.
In my lessons.css I add a image based icon and a fontawesome based icon as well as tweak the list styles.
There is also a new settings area that allows us to tweak the UI here and there.  The first setting is whether you want the prev/next aligned right or full width.  The useful values for this are “right” and “full” – the default is “full” as you can see on WA4E.
This is a start to provide more options and a lot of flexibility without requiring a bunch of code changes every time folks want things to look different.

Django For Everybody – Autograder Server Outage

We are just over a week into the Django for Everybody Specialization and we have a server outage. This server outage affects all of the autograders which run on a server outside Coursera – (www.dj4e.com). This is *not* a problem with the Coursera servers this is my server.  Coursera servers are doing just great.

The outage may last as long as Sunday 5PM Eastern United States Time.

When I saw the server down today Friday at 5PM, I figured that it was because the crush of students in DJ4E had overrun it with all of their enthusiastic load. And then I realized that it has plenty of performance to spare – but instead it was in a server room where the electric company is re-doing the power into the building this weekend. So it will be a while.

Once the server comes back up – I will move this server to our Amazon hosted systems. These systems are still University of Michigan operated and professionally maintained and care deeply about protecting your private data.

When I taught this material on campus, it was fine to run this course using our on-campus resources, but before we released this as a world-wide MOOC – I should have moved the server from UM on campus resources to UM Amazon resources. Once the server comes back up I can do that move in less than an hour and with no loss of data. I won’t do that right away – when it comes back up – I will just leave it alone for a bit and then migrate to a new server room after things settle down.

So I apologize personally for this outage and will make sure to keep such an outage from happening in the future and once this comes back up we can all get back to learning Django.

While you are waiting, you can binge-watch all of my office hours or my car racing playlist on YouTube:



Thanks for being part of the first week of Django for Everybody.