Sakai is open source. So yeah, many open source softwares come and go.
But other open source softwares embed into your infrastructure, are constantly maintained and improved and evolving. Examples: Apache webserver, Central Auth Service, Git, Linux, and Sakai.
Don’t believe me? Monitor the commits on github. Look at contributions from Western Ontario, University of Virginia and Longsight (a commercial affiliate). Oh, and globally? Check out Flying Kite of Australia (busy enough that they don’t bother with a website but use LinkedIN (https://www.linkedin.com/company/flying-kite-au ) and Entornos de Formación of Spain (big enough to have an English language website: https://www.edf.global/ ).
So let’s see where Sakai compares with overall caveats proposed by Sam Saltis in his recent blogpost on Core dna:
#1. Cost. Sam says, “Open software providers are also increasingly charging for extras like add-ons, integration, and additional services, which can negate any cost-saving advantages in some cases. In the end, rather than being free, you are still paying for a service with open source software.”
And he’s right. This is happening. But not with Sakai. Sakai is community-based and community maintained. It can be hosted anywhere you like, including by a commercial hosting provider or in your own institutional AWS, Google or Azure cloud. It can also be multi-tenanted, so that you could share costs of an instance. With Sakai you control the cost by controlling your choices.
#2. Service. Sam says, “Open source software relies on a loyal and engaged online user community to deliver support via forums and blogs, but this support often fails to deliver the high level of response that many consumers expect (and can receive with proprietary software).”
And he’s right. But it’s also a strength. Sakai has a loyal and engaged online user community which is highly responsive. I dare you to engage with us on our lists. You’ll get an answer within 24 hours for sure, but often within minutes(!)
#3. Innovation. Sam says, “Open source software provides a large amount of flexibility and freedom to change the software without restriction. This innovation, however, may not be passed on to all users and it is debated whether customized changes to the original source code can limit the future support and growth of the software. Once more, open source software providers often struggle to attract large-scale research and development.”
I have to answer this one for the Sakai community in parts: a) Yes, you are able to change Sakai without restriction. Truthfully, we like that control. b) Don’t do it in a vacuum. Engage with the community to innovate in a direction we all can use. That’s what we do. c) The Sakai community is a member of a larger open source umbrella organization, Apereo. This has been a good move for us spurring even more innovation. The Apereo Foundation is like a ‘braintrust’ for higher ed open source software projects. Check it out.
#4. Usability. Sam says, “Usability is often a major area of criticism for open source software because the technology is generally not reviewed by usability experts and caters to developers rather than the vast majority of layperson users. User guides are not required by law and are therefore often ignored. When manuals are written, they are often filled with jargon that is difficult to follow.”
And he’s right. And admittedly, in the past this has plagued Sakai software as well. We reached a tipping point in community involvement about 3 years ago when we held a little “Sakai Camp” for the first time and discovered those who came were about half developers and half instructional designers, LMS Admins, and those representing accessibility and usability concerns. More and more instructional designers and faculty are being heard from on the lists. Even the formerly predominantly developer list, firstname.lastname@example.org , now has regular members who are NOT developers but again are peoople who care about usability.
Sakai is now reviewed by usability and accessibility experts.
Sakai has robust user guides created by users, not developers.
#5. Security. And finally, Sam says, “With individual users all around the world developing the software, there is a lack of continuity and common direction that prevents effective communication. Once more, the software is not always peer-reviewed or validated, meaning that a programmer can embed a backdoor Trojan into the software while the user is none the wiser.”
This is just plain bogus. This is not how many of the most popular open source softwares are maintained. Maybe it was back in the days of the wild west, but today I think the majority of open source software has nailed this one. I’d like to think Sakai was among the first.
I’m not a developer. But I care about the software I am administering for Notre Dame. So I know those who run Sakai and develop Sakai keep current on exploits and test Sakai for those. I know when an exploit is identified, a patch comes out very quickly. It becomes part of the main branch from which anyone who implements Sakai can pull.
Finally, “continuity and common direction” – well, let’s let the comment section by my Sakai peers speak to this.