Monthly Archives: June 2015

How is Sakai faring in the face of competition from Canvas?

(This was originally an email sent to the Sakai developer list)

A member of an institution that uses Sakai recently heard an interesting comment from a Canvas LMS representative:

“Sakai is such a cool concept but I do wonder where it will end up in the future as most its founding schools (and the schools putting resources into developing it) have now left and come to Canvas (for example, University of Indiana, University of Michigan, Stanford University).”

I thought this deserved a public reply.

My first observation is that a salesperson spreading FUD (fear, uncertainty and doubt) about Sakai suggests to me that they may not have a strong positive feeling about their own product. Most salespeople will tell you that the best thing to do is focus on what makes your product strong without even talking about other products.

That aside, let me give my response to your question. Each year I do some analytics on the developer list activity:

This chart shows a trend that at this point is about five years old. In the beginning early adopters such as Michigan, Indiana, Stanford, and Cambridge were pulling a lot of load as the product was literally being built and rebuilt. Also in the earliest years, new schools were adopting Sakai continuously so a lot of the e-mail activity was helping new schools.

The early lead schools dropped in activity in 2009. In 2009 Michigan was still the #1 participant in the dev list but a lot of increased participation was also coming from companies like LongSight and Unicon; participation from the other commercial affiliates (often using gmail.com addresses) was increasing as well.

In some ways, 2009-2011 was Sakai’s period of greatest risk as a community. A lot of things were trending downward and near the end of 2011 there was a very good chance that Sakai 2.9 would never see the light of day and it would be “last one out turn off the lights”.

The future of Sakai was originally planned to be a ground-up rewrite known as Sakai 3, however, this didn’t work out as planned and instead a brand new product known as Apereo Open Academic Environment (OAE) was developed. (OAE became a new type of learning platform based on social networking principles: sharing, co-editing, discovery and commenting upon content.)

But in 2012-13, there was a big turnaround with a redesigned Sakai 2.9 which included the brand new Lesson Builder tool.

Following that came consolidation with the tool-rich and innovative Sakai 10. Those who were still in the community put in a lot of effort – Michigan and Longsight were in really strong leadership positions. Other schools like Rutgers, NYU, Columbia, Duke, UNC, and others don’t show up in this dev list graph but they provided much of the money and developer talent to get us through Sakai 2.9 and Sakai 10.

Interestingly in the 2013-14 timeframe we see a couple of factors at work. First the 2102-13 sprint was over – we had Sakai 10. Here is a SlideShare I did that celebrated that moment:

The upcoming Sakai 11 release is the most important release for several years, however, aside from the addition of a responsive design, it is unique in that we are not expanding functionality as much as in the past: we are actually removing more code than we are adding and doing a bunch of UI rework in tools like Lessons, Gradebook and Portal. These more design-oriented activities tend not to cause lots of traffic on the dev lists.

Another interesting trend is that now that we have weekly developer team and teaching and learning meetings with up to 20 people regularly attending: the community is coordinating verbally and collectively in these meetings therefore less email is needed.

As we emerge into 2015, activity and commitment is very strong. The commercial affiliates (large and small) are a very important part of the community. Indiana and Stanford are quite low compared to earlier levels of participation. But something interesting is happening – some of the code that was traditionally the exclusive domain of Stanford or Indiana is now being maintained by the whole community. The interesting result is that the pace of development in those areas of the code base is increasing because now the whole community can move the code forward.

More community members are stepping forward to help because they know that they no longer assume that Indiana, Stanford and Co. will pick up the slack.

During 2011-2014 as the founding institutions slowly backed away, patches and bug fixes started to pile up. Now that the community has inherited the code-base and collective responsibility, the outstanding issues are rapidly being addressed. This is not meant as a criticism of the original partners, they built the core codebase that we all have and without them, we would have nothing. We are very much in their debt.

Looking forward, our community is solid and making lots of progress every single week. We have the luxury of putting a lot of effort into the UI and catching up with applying a backlog of local improvements from places like Oxford, Dayton, Columbia, NYU, Duke, Notre Dame, and UNC. These improvements are enriching our product. In addition, schools like Valencia, Murcia, Rutgers, and UCT are continuing to make strong direct contributions to the code base.

As we see Sakai 11 coming out with its new Morpheus responsive mobile-friendly portal and all of the user interface and performance improvements, I can see why Canvas sales people might be getting a little nervous and use a bit of FUD to try to scare you to switch now.

Thanks to Adam Marshall of Oxford for his editing help on rewording this from an email to a blog post.

Annoucing the (very early) Sakai – Tsugi Bridge

In my previous post, I announced a Java implementation of my Tsugi library. Java Tsugi has as its goal to allow externally hosted LTI applications to be quickly developed and hosted.

But there is more….

I have been long positing that Tsugi would be a way to build portable applications that ran in any Java framework. Take a look at this slide set starting at slide 24 through the end. Pay particular attention to slide 28.

I claim that the same Tsugi application can run standalone in a Tomcat or in a Sakai-provisioned Tomcat as a Sakai tool with zero code changes. I see Tsugi as a great way to build the next generation of Sakai tools like XWiki – we can build an LTI capable XWiki to plug into Sakai or any other LMS.

I have made some really initial steps in this repo:

https://github.com/csev/tsugi-sakai

This is contains a Sakai implementation of the Tsugi APIs so that the Tsugi Java Servlet can be provisioned run in a Sakai Tomcat. The implementation is currently empty – but I have worked out the class loader issues that allow me to provision a Tsugi servlet with a different implementation without changing the servlet.

So this is very much a start – the README.md has a lot of steps – and at the end all you get is a 500 error as shown below – but it does show how we can eventually connect the Tsugi and Sakai worlds.

2015-06-15-Tsugi-Sakai-500

Annoucing the Tsugi Java Library for Building Interoperable Learning Applications

I have been focused on laying the technical groundwork for interoperable learning applications for the past ten years. Through my work on Sakai and IMS I have tried to help move the entire industry forward to enable innovative teaching and learning applications. While we have made great progress, there is much to do. My recent “State of Sakai” talk at the Apereo Conference alludes to the kind of work we still need to do.

I have been exploring the space where applications are both portable and interoperable through my Tsugi. Over the past year I have spent more time on Tsugi than I have on Sakai because I think that exploring future architecture is a very high priority task.

Last week I gave a workshop at the Apereo 2015 conference on Building Applications using IMS Learning Tools Interoperability using my PHP Tsugi. While the workshop went very well, it was clear that the folks that needed to build interoperable applications *right now* were not interested in programming in PHP. Also, I am well into my Summer of Sakai 2015 effort working with a number of students over the summer and it is clear that it is simply too difficult to teach new developers how to write Sakai applications.

All of this was a “perfect storm” that motivated me to drop everything and put in an all-out effort to port my Tsugi library to Java in the past week.

Announcing Tsugi Java 0.0.1

It has been a pretty crazy week – I coded day and night and pretty much ignored my inbox – but I am pretty pleased with the results. While Java Tsugi still needs some work – it is already quite competent to build LTI 1.0 applications in Java – and they feel very clean and elegant. Here are some documents:

This will continue to move and evolve but it is in good enough shape to share with others to start getting broader input.

I also recorded a short introductory video about Tsugi Java:

Conclusion

This is a great start and there is much still to do for Java Tsugi. I am hoping that others will help move this effort forwards and contribute to the project. For the next few weeks, I now need to sprint on finishing up a bunch of things for the Sakai 11 code freeze.

Please feel free to let me know if you have any questions or comments.