Creating a distributed OER App Store

For those following the ELMS distribution’s progress, you’ll probably note that I’ve been talking about Features, Kit, and Feature Server A LOT.  For those that don’t know about these concepts or need to care (most people) here’s a brief overview.

Image Provided by Development Seed

Image from Development Seed

Features in Drupal are the key to the creation and sustainability of LARGE scale systems.  These platforms, like Open Atrium or ELMS, can almost take on a life of their own yet still, at their core, are Drupal.

Features allows developers to not only package code but package configuration.  Configuration, while still drastically easier to work with then code, is still difficult because of the high knowledge barrier Drupal has.

Feature Server and Kit allow for the creation of larger ecosystems to crop-up around platforms built on Features. Feature Server is a Drupal site that can allow other Drupal sites to ask it if they are up to date.  Whenever you download a module from your drupal module can tell you if its out of date or not.  Feature Server essentially allows you to run your own

Distributed Feature Server

Visualization of a Drupal ecosystem

So what’s the big deal with that? Well, imagine if different universities across the globe setup their own feature servers.  You would start to get a picture of Drupal more like what you see on the right.  Instead of code being required to live on, code can live and be upgradable (and ultimately sustainable) from sources external to (like

Here’s the big “so what”: let’s take this concept one step further.  Let’s say we have a platform that makes it easier to assemble learning materials and interaction.  This empowers learning designers and instructor communities to (hopefully) build better materials and interactions.  Create better tools, dedicate more time to the resource generation and less time fighting the technology.  That platform will be built on Drupal Features and Feature server, if you can think of what it might be…

So we have sustainable code and configuration changes, but let’s not stop there.

We’ve already packaged code and configuration at a Drupal level, What’s the next thing to package then? Open Educational Resources.  OER has sputtered in recent years because of a lack of sustainability planning with great press but little “what’s in it for me” factor for faculty.  This is where ELMS and Features come in. ELMS could be packaged with a “Feature server”-like functionality for broadcasting what OER packages it has on it.

Again though, who cares? Oh, I forgot to mention that Features can package content too!  SO, if we map all of these concepts to OER, we now have a sustainable method of passing OER between not just institutions, but directly to distributed learners.

ELMS App Store visual

ELMS App Store Visual at a University

Build something like the Aquia Stack Installer for a one-click installation of ELMS on local machines and suddenly you have a completely distributed system of knowledge produces and consumers.  Producers could even broadcast from their local machine if they wanted that they are producing knowledge for consumption (like Kahn Academy).  Consumers could go to their favorite knowledge producers and download any OER materials they have to their local ELMS instances.

btopro's OER Hub

btopro's OER Hub

This will start to create an “App Store” model for OER content or for-pay content for that matter with limited alteration.  These ELMS Hubs could be thought of much in the same way you think of TV stations or major aggregator websites of today.  All they’re doing is being produced by an individual or group of individuals and you are choosing to consume their content (channels or blog posts or articles or whatever).  This way not only major university bodies could pull together a listing of their resources and share them with others, but individuals have a seat at the table as well.

I believe very much in Connectivism knowledge creation and I’d be curious to see what others thoughts are about this concept.  Drupal is no longer just some neat tool that you should look into for education, I fully believe this is a major component to saving it.  Hopefully when the next release of the platform comes out you’ll start to believe too.

Decoupling for maximal impact

I apologize for not writing much recently.  It’s not that there isn’t momentum behind the ideas I’m typically talking about here, it’s that development has accelerated.  Right now I’m in the process of decoupling ELMS for the next release of the platform.  This is critical to the success of the platform because:

  • Any time you use a system that you know is open and it has Feature XYZ; you immediately get irritated if you can’t have that functionality without hacking it back out
  • ELMS support and sustainability model is very decentralized (as it always will be)
  • Most of the functionality of elms can be applicable to any Drupal site / system (and should be)
  • I am treating ELMS as a consumer of Drupal, not the author of a new Drupal (huh?)

What am I referring to?  Here are the five modules released in the last week:

ELMS Decoupling

Reusable components

Any time you use a system that you know is open and it has Feature XYZ; you immediately get irritated if you can’t have that functionality without hacking it back out
Yesterday I released four modules to the Drupal community by simply packaging the code differently.  I also wrote an API (Regions) which will be implemented by ELMS three times.  This abstraction will allow other developers to dissect the code more easily and a lot of times simply be able to download the associated module.

ELMS support and sustainability model is very decentralized (as it always will be)
This allows far more sites / users / systems to utilize these components as they are things I’ve found lacking from the current Drupal community code base.  It also improves the long term sustainability of the project as the level of transparency has always proven to lead to better / improved solutions.  If I can get 100 sites using the Spaces Theme module (outside of the scope of ELMS) that’s potentially 100 extra sets of eyes on the code or people that could potentially help out.  While I understand the levels of participation are always less then that we will have paid nothing for that additional help if just 1 person helps audit code by proxy.

Most of the functionality of elms can be applicable to any Drupal site / system (and should be)
I’ve been writing everything to NOT be course centric.  Functionality has been packaged into many Features.  Features are sustainable code development packages which package code and configuration together.  This way when someone says “How did you build that Commenting engine?” I can point them to our Feature-Server to download the Reactions Feature.  They turn Reactions on in their site (and Regions if they want it to look and feel the same way) and now their system has all that functionality.

This is following something called the Kit specification, though I might be going a bit overboard with it.  There are 4 Features currently (you can think of them as modules if you want) that should be compatible or nearly compatible with Open Atrium, EduGlu, AtriumED, Open Scholar and any other platform that follows the Kit specification.  I keep talking about the reusability a lot but that’s because I can see ahead of where the community is now to where it will be in the near future; this is going to be the norm soon.

I am treating ELMS as a consumer of Drupal, not the author of a new Drupal (huh?)
While ELMS is a platform being developed for a singular purpose (support the e-Learning Institute’s Course Delivery and Authoring needs); it has been designed unit agnostic.  This follows my personal philosophy of why we chose to build on Drupal instead of Moodle.  Don’t force the technology to define your context and don’t allow your context to define the tech.  At the end of the day we are still “just building webpages” and as such all language and infrastructure decision should reflect that.

Don’t interpret that incorrectly, this will meet all the needs we currently have (actually it’s going to create an innovation fast track but that’s for another time); it just isn’t being driven by code specificity.  As an example, user import from a proprietary point of integration has been written using the Feeds module.  This sticks to Drupal best practices and allows for the creation of minor helper modules (Feeds RID Map) which simply extend existing infrastructure to meet needs.
ELMS will meet our requirements but we will effectively be taking a “finished” platform and then extending it to meet our specific needs, not the other way around.

Too often ideas are written for a specific context and then point 1 is reached through hacking functionality back out and the cycle starts again.
If you treat the project as just a website engine (under the hood) but present it as a course management engine on the surface you have a far more robust and flexible platform.  This is mirroring what we’ve done with Drupal in the first place as many people never need to know or care that they are using Drupal.  Change a few pieces of language in a settings page (Thank you String Overrides Module) and only imagine what you can make this platform do. Think in terms of solving problems with “a thing that has many websites associated to it” and suddenly we don’t just have 1 platform, we have an ecosystem of platforms.

No more global success, global failure; this is Structured Anarchy in practice, you create an unstoppable innovation pipeline that can never be shut off.  This will ultimately lead to a lower cost of development (far less time to build new solutions, thanks virtual servers) of any website management framework.  Then it’s 80% experience design, 20% specific integration point.  This isn’t a utopian fantasy, this is starting to happen as of last month.