In this post I am not speaking for University of Michigan, Longsight Inc., or the IMS Global Learning Consortium.

It is always a great feeling for an open source community to finish a release. So much work goes into a release and so many volunteers are involved and work hard – so it is a proud moment for a lot of us. I tend to be involved in more of the up front development and working on crazy next gen stuff. So I am doubly grateful to those who put the finishing touches on these releases and then get them out to the public and put them into production.

Here is the official release notice for Sakai 10. There is a long list of great stuff in that link that I won’t replicate here.

As I said in the The Post-LMS LMS article in Inside Higher Education, the past year has seen a lot of incremental investment in all five of the major LMS systems in the marketplace. In a sense we were all reacting to changes in the market. As we gain experiences with larger sized classes that we hope to run at scale (i.e inspired by MOOCs) there are a number of MOOC-like features that are finding their way into products. Sakai-10’s peer-assessment and improvement of group-submitted are partially inspired by the MOOCs heavy use of peer features. It is not so much that MOOCs were the first to do peer-assessment – more that peer-assessment has gotten a lot of attention in the past two years.

If Sakai end-users feel strongly enough about a feature to bring funding or resources to the table, the features get built and added to the core product and are part of the next release surprisingly quickly. It is that simple – no product marketing layer or sales people to fight through. You find or hire the necessary resources and have a feature in the core product. There is no other product in the LMS marketplace where end-users personally know the core developers of the product on a first name basis.

Another big trend is making sure that LMS systems can function well in cloud environments (i.e. like Amazon). In the past two years, Amazon’s costs have dropped dramatically and their capabilities have grown significantly. The addition of Solid State Disk Drives in many of their offerings is a quantum leap forward in the ability to host “normal” applications in the cloud that was impractical a while back. Simply put, two years ago – you had to be pretty clever to move a large application into the cloud because of the subtle performance tuning that was required – but now Amazon’s cloud resources have very similar performance characteristics to locally-owned hardware – expecially if virtualization is used on that hardware.

Just a quick look at Amazon’s EC2 pricing is pretty amazing – especially the one and three year fixed contract pricing. A m3.medium instance with about 4G RAM, 4G SSD and one CPU is $172 for three years. A bit more capable two CPU, 8G RAM, 32G SSD m3.large server is $343 for three years. Why would I ever run a server under my desk at work with prices like that?

So there is a pull for both self-hosted schools and commercial companies that host LMSs in their own clouds to take advantage of these prices. This is true for all vendors. Based on my rumors and bar conversations, I think that Canvas is the only major hosting company that is mostly using Amazon – but all the other vendors are likely eyeing hosting new work and new expansion in the cloud and as servers get replaced in a company data center it is likely that there will be an urge to use Amazon instead.

But as we move the hosting of these systems into the Amazon cloud, we still want to spend as little money as possible. And if you look at what you are getting in Amazon, the most expensive element of the cost is the RAM followed by I/O. CPU is almost an insignificant concern on most LMS applications. So not surprisingly, if you want to optimize costs in a cloud version of Sakai, you find a way to trade CPU for RAM and database I/O. The solution of course for all applications is a shared cache like memcache or Reddis.

So not surprisingly in the above video you see three Sakai Commercial Affliliates (AshaiNet, Longsight, and Unicon) putting a lot of energy into cloud-tuning Sakai by reducing app server memory footprint and database I/O by adding a shared cache and switching to elastic search.

This kind of cloud tuning goes on for all of the LMS systems. For Moodle, Moodlerooms and RemoteLearner separately tune Moodle to scale for the cloud. Of course Instructure tunes Canvas for the cloud all the time but we never see the source code. Blackboard announced thair plans to host Learn on AWS at BBWorld14 – an impressive step – since I was not in Vegas, I had to settle for screen shots of slides in Twitter DMs.

But the essential difference in the Sakai community is that three competitors saw fit to pool their cloud tuning efforts and put their code into the community release. Even while the code was being built and tested, developers from AsahiNet, Longsight, and Unicon were communicating regularly, checking, testing, and fixing code written by one of their “competitors”. And when it was all done the code ends up in the open source trunk of Sakai. There are no secret repositories with the “magic sauce” – you don’t have to go to the bar and get a drawing on a napkin to find out the clever tuning tricks that are being done to make this possible. Just check out the source code and take a look.

Now while to a proprietary competitor, it might seem crazy to give away the “crown jewels”. But like many crazy plans, it is just so crazy that it might work. First, everyone is running the same code. Vendors don’t need a vendor fork for perfomance tweaks. Self-hosted schools can deploy the same solution as the commercial vendors if they like. If self-hosted schools are a little nervous about switching from the “app server” / “db server” architecture – they can just wait while the commercial Sakai vendors gain experience – but at any time – they have access to the exact same cloud code that the vendors are using in production when they are ready to start saving hardware costs.

The second and more important issue is that cloud performance tuning is a moving target. Amazon will continue to tweak their offerings and performance characteristics. You never really are sure how something will scale until you are running it at scale. Who knows if Unicon, LongSight, or AsahiNet will be the first one to encounter a little bit of code that needs a bit of tweaking as you add the millionth user. But as long as we avoid tweaks in vendor branches and keep the tweaks in the trunk, when the second vendor crosses that million user barrier – the code will be there for them – sitting in trunk and fully tested.

Again it might seem insane for one vendor to commit code that will allow other vendors to match their offerings in the marketplace or allow self-hosted schools to avoid out-sourcing their applications to a vendor because they have 100% access to the same code. But the reality is that it is far less risky to work together than to work separately. There is no single school or commercial vendor in the Sakai ecosystem that can go it alone and ignore everyone else. We are in this together. We sink or swim together.

We will all help each other find our way to the cloud together. That is the power of real open source. That is the magic of real open source.

Even if you run a commercial LMS at your University – you should join us and be part of Apereo. Apereo is not just about Sakai. Apereo is where the next generation of teaching and learning technology will be collectively defined and built. Because what is next will be even more exciting than getting an LMS ready for the cloud.