Moodle

The Summer of Code application process is underway. Along with some good folks at The Oregon State Open Source Labs, we have put together a proposal to share content between Moodle and Drupal.

In combination with the recently developed functionality to author and export content from Drupal in IMS LOM format, you could author courses in Drupal or Moodle, and use those courses interchangeably in Drupal, Moodle, or any other LMS that imported IMS LOM.

The IMS code, and a detailed writeup, is freely available.

The Summer of Code is open to all college students. If you're interested, apply.

David Wiley recently posted on what some folks are calling Open Educational Resources, or OER’s. This post extends my comment left on David’s original post.

In his post, David starts by examining the difference between producers and consumers of Open Educational Resources, with an emphasis that Good Things ™ start happening when the Consumers become the Producers through the magic of wiki-style group editing.

He suggests that one of the impediments to broader re-use of OER’s results from the original R living in a strict context -- ie, the R came into existence because of a specific educational need in a specific educational place, and reusing the R will be difficult in part because no two contexts are alike.

This leads to a comparison of OER development to Open Source development, particularly the notion that OER creators, like Open Source developers, are people who develop resources to “scratch” a personal “itch.”

It’s an interesting and thought provoking conversation, but one that breaks in a few places. Wiley is right on when he speaks of context being a limiting factor in reusing open content. However, he concludes:

Perhaps instead of sharing watered-down, decontextualized, 'professional' versions of our educational materials we should share context-rich, personality-laden ones.

This conclusion sidesteps the issue.

If content is going to be reused in a different context, then it actually needs to be reused in a different context. This context shift cannot occur when the resource remains locked in the originating site, firmly within its original context. A resource only becomes reusable when the next user can pick it up and take it with them (The analogy that comes to mind is taking a kid to a sports store and showing them a soccer ball on display in a window, and then telling them to have a great match, but that they need to play the match with the ball remaining off-limits behind the glass). Pointing to a resource on the web, and even editing a currently existing resource, only accomplishes part of the task. While it’s great that we have a growing body of freely accessible content, we’d be foolish to pretend that it couldn’t be better.

And this brings us to the Open Source comparison, and why Open Source development is thriving: with open source, you can take it with you. I can download Apache, MySQL, and PHP and install them on my computer. I can build a Mediawiki site, and install Drupal, and install Moodle. As I do this, the little mice in my brain start moving and spinning their wheels, and when I have questions, I can look into the code, or change the config settings, on my machine, in my own context. If I have an idea that makes sense, I can bring it back to the community. If it makes sense to enough people there, then the idea gets picked up. If it doesn’t, then so be it. But I can still use my resource, in my way, and connect back to the community as needed.

This portability is the missing piece in creating widely re-used Open Content. There are some initial forays into moving content between sites -- Mediawiki has an excellent xml import/export feature; Moodle has the ability to back up pieces of courses, and Drupal has an array of import/export options. RSS import also provides the means to move content between sites. However, all of these methods require a comfort level with technology that stretches many users. Personally, I haven’t met many people inside or outside education who are particularly comfortable cutting and pasting an xml file.

For Open Content to work, moving content needs to be simple. A user should be able to select anything from a page in a lesson to an entire chapter, and the selected contents should be exportable from one site and importable to another via a web UI.

It’s also worth noting that the obstacles here are not technical. As RSS demonstrates, a lightweight solution does a great job moving large amounts of content between sites. However, until someone proposes a general spec, nothing will move.

So, here goes:

1. Use the native solutions already under development or in use in Moodle, Drupal, and Mediawiki. For Moodle, this would be the backup/restore feature; in Drupal, the Import/Export API , and in Mediawiki, the XML import/export functionality. For what it’s worth, the Mediawiki import/export seems to work with the fewest hitches.
2. Code a central filter to convert content from one site into an appropriate format for the other. This process would likely need to include some choices about supported and unsupported markup. This filter would need to ship as an included library with the import/export block/module/extension for each application
3. For each application, build a form that managed the import into each application; ie, a web UI that exposed the import/export functionality. Our target for reuse is not the technically proficient user, but a more general audience. Exporting and importing content -- from a single page to an entire course -- needs to be as complex as downloading an attachment from email, and subsequently re-sending that attachment in another email. Think of all the forwarded jokes you have received in the last week. It needs to be that simple.

In an earlier blog post, Sean Lancaster asked the following question:

i appreciate the effort that is being undertaken to create a terrific online learning environment that brings various resources together seamlessly; however, i am curious to better understand how Drupal and Moodle are different in what they provide. i mean, why would a person use both tools at the same time?

The short answer is that the best option is a subjective determination -- kind of like Mac vs PC, etc, etc.

A slightly longer answer is that the choice of tool for the learning environment will be determined by the relationship between learners' needs, instructors' needs, and institutional needs.

A still longer answer is that making an across the board choice is no longer necessary, and we are at a place where it's possible to match the tool to teaching/learning style. It's possible for an institution to provide these tools side by side to support learners and teachers in the classroom.

Moving outside the classroom, Drupal is a pretty flexible tool that can be used to create intranets for different academic departments, club sites, a public facing school site, an alumni forum -- and within each of these contexts, Drupal can be customized and focused to meet the specific needs of the site users. Some people have also used Moodle to meet these needs. The need for a "one size fits all" approach no longer exists, as we have options.

All of these elements (and others ) will factor into the decision. It's possible to set up OpenAcademic without Drupal, or without Moodle. The solution is, by design, flexible and scalable. However, it's necessary to stress that the choice of tool to use is just that: a choice. The user has options. The institution has options. The sysadmin has options. People and institutions do similar things in different ways. The work we're doing at OpenAcademic is intended to provide a flexible, adaptable toolkit. Using the tools within OpenAcademic, you can create a simple web presence, or a learning network that connects learners and institutions on different sides of the world. You can choose to use the tools -- in any combination -- to meet your needs in your way.

If you're still awake and reading at this point, I've written more about ideas related to this topic here and here and here.

OpenID provides a method of Single Sign On (SSO) between multiple web sites. OpenID allows users to "claim" a specific url; this url identifies the user as they browse and join different web sites.

Other SSO options exist, including Shibboleth, SXIP, Pubcookie, and JA-SIG's Central Authentication Service. OpenID differs from other methods in a few ways, but the purpose of this post is not to compare or contrast the pros and cons of the different SSO options. This post is also intended as an overview to demonstrate some possibilities, not as the final word on what OpenID can or can't do.

Far too frequently, conversations that set out to compare and contrast different standards end up denigrating one standard in order to elevate another. This type of conversation seems counterproductive; as with any technological solution, the best solution will be dictated by the specific needs of the institution or organization. While OpenID will not be the perfect choice for every situation, it combines flexibility, security, simplicity, and scalability. These traits make OpenID an attractive choice in a wide range of scenarios.

Background:

Two things are required to use OpenID: an OpenID server, and an OpenID-enabled client site. The OpenID server is the site where users claim their unique url. An OpenID url looks exactly like a web address; for example, if an OpenID server is set up at elgg.net, a user's OpenID url would be http://elgg.net/username -- more to come on this later. Then, using their unique url, the user can log into any site that is set up to accept OpenIDs. Among open source projects, several applications are already OpenID enabled. There are also libraries available to simplify the process of OpenID-enabling other applications.

This page provides links to OpenID providers (to get your own OpenID) and downloadable OpenID servers (to set up your own server). Within an organization you can set up one OpenID server that serves as the central authority for managing SSO to selected resources. OpenID servers can also be incorporated into existing applications, so that any site member also receives an OpenID. For example, an OpenID server can be incorporated into Elgg, which creates some interesting possibilities -- more to come on this later.

It is also important to note that OpenID is both an open standard, and that many of the applications that use OpenID are released under open source licenses.

OpenID is also gaining traction among larger companies. Verisign recently rolled out an OpenID implementation with their Personal Identity Provider service.

OpenID Features:

Single Sign On (SSO): OpenID allows for SSO between sites that are OpenID enabled.

User management: an OpenID server can authenticate against a wide variety of data sources, from a .pwd file to user data in a legacy system via LDAP. So, an OpenID server does not require an institution to maintain and synchronize multiple sets of user data. OpenID servers have been set up to allow pluggable authentication against a broad range of data sources to allow for maximum flexibility.

Whitelist/Blacklist sites: OpenID client sites can be configured to whitelist and blacklist sites. To demonstrate how this works, consider the following scenario:

Johnny is a sixth grader at Neighborhood Middle School, where they have an OpenID server. Using his OpenID, Johnny logs into his class web site, the chess club web site, and his personal learning space. Because all these sites are OpenID enabled, he only logs in once to do work in these different areas. However, because these are all different sites, Johnny can be a student within the class site, and a content moderator in the chess club site.

Within this same school, all client sites have been configured to only accept logins from the school's OpenID users. So, any logins with an OpenID from outside the school community will be rejected. As with all other security systems, a user needs to have a valid username and password.

The whitelisting and blacklisting feature can also be used to support safe, secure online collaboration between different schools. If the Neighborhood Middle School developed a relationship with the Far Away Middle School, the two schools could set up a web site to allow logins only from each school's individual OpenID server. So, members of the two school communities could have access to the site, and the rest of the internet would have no access.

Elgg as an OpenID server: Using Elgg as the front end for the OpenID server creates additional benefits. Elgg's user profiles allow for flexible display of profile information, as the OpenID url points directly back to a user's profile. For example, my Elgg profile is visible at http://elgg.net/bfitzgerald. If elgg.net was enabled as an OpenID server, my OpenID url would be the same as my Elgg profile. The long term roadmap for Elgg will allow for searching across different Elgg sites. The combination of whitelisted logins between different OpenID servers, searching across Elgg sites, and OpenID urls that point directly to a user's profile will simplify collaboration between and across organizations.

Taking this a step further, OpenID could also simplify the process of allowing students from different schools to take the same class in a single Moodle install. If Moodle was OpenID enabled, it would be possible to whitelist OpenID servers from multiple schools. This has the potential to create a truly distributed learning environment: students from different institutions interacting in a more formal class structure (Moodle), and in an informal learning space (Elgg).

Where things stand now:

Kevin Jardine is actively working to OpenID enable Elgg as an OpenID server and client. Drupal 4.7 and 4.6 are OpenID enabled, and we are creating an admin screen to simplify whitelisting/blacklisting sites. A Mediawiki extension is under active development in the Mediawiki subversion repository. There is also some preliminary interest in OpenID enabling Moodle, with at least one developer expressing an interest in writing the code to make this happen.