Tag Archives: open source

Sakai is alive and well and on the move

Like Sakai, this tiger is alive, staring directly at you, and ready to spring

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, sakai-dev@apereo.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.

Sam Saltis’ full article.

 

Advertisements

What I Didn’t Know About Using Community Source Software (Sakai) in Higher Ed

“How to set expectations for change management,” – that’s it. That’s what I didn’t know.

Consider the kinds of changes one habitually takes from a vendor of proprietary software which you maintain in your own higher ed Data Center.

The hypothetical change is

New cool features advertised to you, or…

  • Bug fixes (you’d found them or you hadn’t, in other words, you cared deeply or not at all), or …
  • Enhancements.

Qualities of the change:

  • The change has already been deployed and tested many times over by the software vendor in environments, with data, very similar to yours.
  • You schedule when you want to accept/install the change and make it available to your users, usually based on your academic schedule.

What your users expect-

  • Won’t get it before the regular schedule break, even if they knew about it.
  • Didn’t know about it anyway because the vendor doesn’t market to them but to the people who manage the system for them.
  • The vendor is an uncaring large collection of cogs anyway, so no point in asking for an enhancement.

What your users do-

  • Blog, tweet and facebook their complaints vociferously but without expecting more than a good venting session.
  • Write you emails about how your vendor doesn’t care.
  • Login after upgrades and harumpf that that the thing that used to annoy them so greatly is finally fixed.

 

Contrast this with open/community source:

What your users expect-

  • They will be heard if they connect with the community.
  • You are connecting with the community on their behalf and that will be meaningful in the community because it must be small.
  • The developers working on their behalf will automatically do a better job than the vendor because they work for higher ed institutions.

What your users do-

  • Demand bug fixes and enhancements.
  • Expect them to be applied frequently.
  • Suggest enhancements and expect them to be executed in amazingly beautiful ways.