Variability Analysis

In the previous essays we focused on analysing the vision of the Open edX project along with some of its architectural patterns and investigated the overall quality of the system. In this essay we will deepen our analysis by looking into the variability modeling, management and implementation mechanisms that are relevant to Open edX. More specifically, we will build a feature model and determine how variability is managed and implemented in the system we analyse.

First we provide some context and explain the underlying principles regarding the notion of variability. If we think about our daily lives and activities, we quickly realise that we encounter variability on a daily basis. An example comes to mind if we think about the numerous cars driving on the road or the vast number of mobile phones being used. This is a perfect example of variability and to be more precise we give a definition for it:

Software variability is the ability of a software system or artefact to be efficiently extended, changed, customised or configured for use in a particular context.¹

We now focus on what variability entails in the context of software. When talking about software products, variability can be supported in terms of bundles, command line parameters, plugins, configuration files or even microservices to name a few examples. The problem that quickly arises is how to properly manage and implement variability in a software product. In the following sections we are going to investigate how Open edX does this and to this end we will build two feature models, one for describing the variability of setting up the platform and another one related to variability in terms of configuring the platform.

Feature models

In this section we present the two feature models we built for analysing the variability of the Open edX software. In the first model we look at the variability in the context of installing and setting up the Open edX platform while the second one presents the different services and plugins that can be enabled/disabled in the platform (once this is installed). In the second diagram, one can observe the XBlock features. The XBlocks represent the main point of extensibility for the Open edX platform as we will later discuss in the following sections.

Management of variability mechanisms

The Open edX platform has a number of different distributions each one with its own unique features. As Open edx is used by very different groups of people and for various purposes, the open edX team provides different sources of information for the stakeholders to consult allowing them to choose the right product. An installation should be based on the following questions, how do you wish to use the platform, which version would you like, and which method of installation.

Different stakeholders consist also of different types of users and should therefore consider different versions and installation methods of open-edx dependent on their use cases. If the user has no intention of contributing to the software then he should install a release version of open-edx, if the user does intend to contribute then the master should be installed. People with technical knowledge, can get explicit information regarding the different versions and features of the platform from the documentation provided by the Open edX team ². A contributor should use the dev-stack installation method which can be found on this repo ³. If a contributor is also interested in the [different Analytics functionality that is provided ] then he could also install the Analytics Destack alongside it. The installations require knowledge of:

• Basic Terminal usage
  • Diagnosing and fixing failures skills
  • Basic knowledge of python web applications regarding build, installation and deployment.
  • Managing a Linux system.
  • Basics of configuration management and automation, using Ansible.
• Software prerequisites
  • make
  • Docker 17.06 CE or later

The dev-stack installation allows for a complete configurable installation, the complete overview can be found here ⁴. Potential configurations include site configurations, where urls and api endpoints are set. It is also possible to configure to run multiple sites in an open-edx installation and give each of these sites their own configurations as well. Another configuration is the appearance themes of the site, every front facing component of the open-edx platform has a configurable theme. Created themes need to be referenced from the file system of the component they are coupled with. Tens of other features that can be turned on and off depending on the use cases of the installer.

A non contributor user should install an officially released version of open-edx, a list of the open-edx releases can be found here ⁵. These are stable releases that have been tested for wide use. A company or institution that wished to extend a stable release should then still use the dev stack installation. A non contributor user that does not wish to extend open-edx or a user that does not seek to use open edx complete configuration options can install the so called “Native Installation”. This is a simple installation that requires minimal technical skill that can be run on both the cloud or a local linux machine. The instructions for this installation can be found here ⁶.

There are two other distributions that are worthwhile to mention[], these include the bitnami distribution, which offers an even simpler one click install and can also very easily be run on a cloud (such as Google Cloud , Amazon web services or Azure). Another distribution exists called “tutor”, which is also open source but uses a completely different code base than the open-edx platform. And beside those there are services that offer complete managing of the platform which can be found here ⁷

All these different options make it possible for different stakeholders to use the software differently based on different technical resources, and different use cases. A large University or Institution for instance that has the resources could run a more customized and extendable form of the platform while a smaller less resourceful education provider could run a simpler distribution of the platform.

Implementation of variability mechanisms

From the previous sections, we saw that the Open edX system can be set up in various ways, depending on the use case of the end user. We’ve tried to model this variability using feature models. In this section, a deeper dive is done into how the variability is managed on the implementation level. For this analysis, 2 particular features were chosen, namely: Credentials and XBlocks.

Credentials

In Open edX, credentials are stored in a MySQL database. 3rd party authentication is an option, but is disabled by default. For 3rd party authentication, the following options are available ⁸:

• OAuth
• SAML
• LTI

Limited support for additional providers is available, but these “tend to be older and less robustly tested, and have a much more limited feature set” ⁹.

Enabling 3rd party auth is done by setting a feature flag in a local LMS json file. When this is done similar alterations to this json file are necessary to enable a specific identity provider. Additionally, API keys and secrets need to be fetched from the identity provider themselve ¹⁰. After this configuration is done, the LMS server needs to be restarted. This means that this variability is binded during load-time.

 from django.conf import settings

    return configuration_helpers.get_value(
        "ENABLE_THIRD_PARTY_AUTH",
        settings.FEATURES.get("ENABLE_THIRD_PARTY_AUTH")
    )

common/djangoapps/third_party_auth/__init__.py

The implementation mechanism used for various 3rd party auth providers is the Template Method design pattern ¹¹. If your particular identity provider backend is not supported, implementing it is as simple as extending a base class and overriding a few methods. Open edX uses the python-social-auth ¹² package for most of its 3rd party authentication handling. Although some slight alterations are made to some backends, for example, the SAML backend ¹³ has been customized somewhat to fit within the architecture.

from social_core.backends.oauth import BaseOAuth2

class GitHubOAuth2(BaseOAuth2):
    """GitHub OAuth authentication backend"""
    name = 'github'
    AUTHORIZATION_URL = 'https://github.com/login/oauth/authorize'
    ACCESS_TOKEN_URL = 'https://github.com/login/oauth/access_token'
    ACCESS_TOKEN_METHOD = 'POST'
    SCOPE_SEPARATOR = ','
    EXTRA_DATA = [
        ('id', 'id'),
        ('expires', 'expires')
    ]

    def get_user_details(self, response):
        """Return user details from GitHub account"""
        return {'username': response.get('login'),
                'email': response.get('email') or '',
                'first_name': response.get('name')}

    def user_data(self, access_token, *args, **kwargs):
        """Loads user data from service"""
        url = 'https://api.github.com/user?' + urlencode({
            'access_token': access_token
        })
        return self.get_json(url)

An example of how the Template Method design pattern is implemented in python-social-auth.

XBlocks

XBlocks are the extensibility platform for the Open edX system. Adding functionality like in-video quizzes to courses is done by creating a XBlock. The binding of XBlocks is twofold, namely: load-time and run-time. As such, 2 implementation mechanisms are used.

Installing an XBlock involves installing the package itself into 2 containers. One for the LMS and CMS respectively, this is done using the python package manager pip ¹⁴. After this is done, both the LMS and CMS need to be restarted. So the variability in installed XBlocks is binded at load-time. The mechanism used for this is composition. For collections of XBlocks, so called “library XBlocks” are created which can store any amount of XBlocks. These libraries can then be used to give individual courses the access to specific collections of XBlocks.

@python_2_unicode_compatible
class LibraryRoot(XBlock):
    """
    The LibraryRoot is the root XBlock of a content library. All other  blocks in
    the library are its children. It contains metadata such as the library's
    display_name.
    """

Library XBlocks

During run-time, however, one can choose what XBlocks are available on their platform. So it is possible to install a bunch of XBlocks, and then decide at runtime the availability of them. This is done per course using the frontend of the CMS (often called Studio) ¹⁵.

Future proof?

We’ve seen the ways in which Open edX handles variability for 2 specific features on the implementation level. When handling variability on the implementation level, one has to take in account not only the current context regarding the variability, but also the future context. How is the variability expected to change. Is the implementation mechanism used future proof? If these considerations are taken lightly, developers could introduce significant technical debt into the system.

The 3rd party authentication is binded at load-time, which means that whenever a new identity provider needs to be added, the server needs to restart. This results in downtime, which can be significant for large educational institutions.

For XBlocks, the management and scalability is actually quite good, as XBlocks are independent from each other. The only real downside comes with the fact that XBlocks can’t be installed at runtime. This can be partly remedied by installing a bunch of XBlocks beforehand, and letting individual course designers choose for themselves which functionality they want to include.

Conclusions

In this essay, we’ve tried to analyse the variability in the Open edX system and how it is managed on different levels. We found that there is a lot of variability possible, which is also necessary, as Open edX is a system that is used by universities world wide. Most of the variability is captured in partnered 3rd party distributions, which is good, as it makes it easier for universities to get a particular “flavor” of the base Open edX release, without too much technical hassle. Besides this, variability exists in the base distribution as well. The various ways in which these variabilities are managed were hard to ascertain, and did not seem very uniform. Indicating that there is no universal framework for incorporating variability in place. This could be improved by getting developers on the same page on how to handle variability within the project. Recommendations include:

• Listing common types of variability within the project and what design patterns could be useful to tackle them.
• Giving developers the tools (e.g. FeatureIDE) to create feature models for their own components.

In all, the Open edX platform is a great tool for universities worldwide in creating engaging and tailored educational experiences. Variability is a key component to this, and we hope that Open edX realizes this as well.