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:
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.