CASCADE PROJECT: CASE STUDY 2

Customizing open source software: benefits and pitfalls

Aimed at e-Learning developers, this case study draws on the JISC-funded Cascade project’s experience of customizing the Moodle assignment module, to highlight the benefits and pitfalls of working with open source software.

1.BACKGROUND & CONTEXT

The Department for Continuing Education1 is the University of Oxford’s largest department and each year enrols approximately 15,000 part-time students. It employs a core staff of 149 academic and support staff, as well as over 1,000 part-time tutors, to deliver its broad portfolio of over 700 courses, which range from one-day courses to six-year part-time DPhil programmes. Almost all the Department’s programmes are delivered in flexible formats to enable students to study alongside their work or other commitments and an increasing number of courses offer an element of distance learning. The online infrastructure and services to support distance learning are provided by the Department’s e-Learning unit, Technology-Assisted Lifelong Learning2 (TALL).

In November 2008, under its Transforming curriculum delivery through technology programme,3 JISC awarded the Department funding to undertake the Cascade4 project to investigate how technology could be used toimprove efficiency and enhance the quality of its curriculum deliveryservices. Following a process of consultation withstakeholders, development of an improved facility for online assignment submission was identified as a key focus area of the project. A review of online assignment-handling systems was undertaken and, as the Department was already using the Moodle open source Virtual Learning Environment (VLE) software to support a number of its courses, it was decided that the most appropriate solution would be to customize the standard Moodle assignmentmodule in order to meet the Department’s specific online assignment-handling requirements.

2.INTENDED OUTCOMES

The intention of this focus area of the Cascade project was to develop modifications to the Moodle code, running locally, to providethe additional assignment-handling functionality required by the Department, and to make the majority of the updated codeavailable for others to use by integrating it with the upstream project.[a]

3.THE CHALLENGE

This aspect of the Cascade project had two key challenges: (a) to specify requirements for the enhanced assignment-handling functionality in Moodle; and (b) to develop the code itself.

(a)Specification of online assignment-handling requirements

The initial specification5 seemed straightforward: starting with the known functionality of the Department’s legacy online assignment-handling system; identifying the required additional functionality; matching these with the functionality already present in Moodle, and identifying the shortfall and hence those features that needed to be developed. Although the 'normal' workflow of the required system was relatively easy to specify, difficulties were encountered with identifying, and specifying, all the non-standard situations that could potentially arise. This was exacerbated by the wide variety of assessment formats used by the Department’s courses.

(b)Development of Moodle code

The challenge regarding the actual coding involved designing and producing code that was acceptable to upstream for other users of Moodle to utilize (in terms of meeting their needs and coding standards), as well as integrating well with the established use of Moodle within the Department.

4.ESTABLISHED PRACTICE

At the start of the project, the following practice was in place:

(a)Online assignment-handling

The Department’s processes for online assignment-handing werefairly well established with a legacy online assignment-handling system (CASS), originally developed by its Department in the late 1990s to support its first online courses, being used by nine award-bearing programmes. The stand-alone CASS system offered facilities to supportthe following specific assignment-handling requirements of the Department:

  • Submission of files,by students, in a variety of formats;
  • Access to the system by a wide variety of tutors, many of whom are external to the Department, to mark assignments;
  • Separation of assignment files by tutor group, within a single course, according to who would be marking them;
  • Functionality for students to request extensions and for the relevant course director to grant/reject such requests;
  • Email notification of relevant actions to inform users and prompt them if further action was required on their part.

Set-up and technical support for the CASS system was provided by IT staff from the TALL unit and the assignment-handling process was overseen by the Department’s Registry (to ensure compliance with University regulations). Whilst the CASS system offered essential functionality, the legacy system was cumbersome for students and tutors to use and required high levels of IT support to operate it, which meant it was not scalable for wider adoption across the Department’s full range of courses.

(b)Moodle software development

Moodle development was undertaken by the Department’s TALL unit. Local modifications to code were managed initially via a set of “patch” files describing changes to upstream Moodle, and instructions on how to apply them. “Tickets” in a Trac6 issue management system (IMS) were used to document course and VLE development tasks, their progress, decisions, and completion.

  1. THE CURRICULUM DELIVERY ADVANTAGE

The Cascade project enabled the development of a new assignment-submission system that simplified the assignment-handling process and integrated it into Moodle, the VLEalready used by the Department to provide support online for many of itscourses. In terms of curriculum delivery, this offered a number of advantages including:

  • An improvement in the student experience by providing an online assignment submission system that is easier to use and seamlessly integrated within the VLE, rather thanaccessed as a separate stand-alone system;
  • Increased efficiency by reducing the amount of time needed for assignment-handling by Registry staff, course administrators and tutors, and IT support staff with opportunities for further savings across the Department by creating a robust online assignment-handling system that is suitable for use by more courses.
  1. KEY POINTS FOR EFFECTIVE PRACTICE

Outlined below are the key lessons learned during this element of the Cascade project:

(i)When planning a software development project, it is important to identify and separate the technological development tasks from the process tasks being modelled – often there are underlying process problems that cannot be solved by technology. To assist with specification:

  • Identify as many of the different administrative processes involved as possible, and the special cases (which will be numerous). Adapt these into specifications and illustrations of the software to be created;
  • Update the specifications and illustrations with the requirements of additional processes and special cases revealed as the project progresses.

(ii)Manage stakeholder expectations with clear communication:

  • Describe in detail what the completed system will do, and what it will not do. In the Cascade project, initial negative reactions to online assignment submission resulted from tutors conflating the processes of assignment submission by students and on-screen marking by tutors; their reservations about the latter marred their enthusiasm for the former. Careful consultation removed the confusion but, with forethought, this could have been avoided.
  • Provide clear updates when requirements/specifications/schedules change.
  • Communicate when different stakeholders have conflicting requirements. This usually needs resolution of the process, rather than a technological solution.
  • Where limits on time and/or resources mean that not all desired features can be developed within the given timeframe, implement a system of categorizing features as critical, essential, nice to have, not in this version, etc.

(iii)Be disciplined in use of an issue management system:

  • Use tickets for all issues and tasks from the start, providing support so all project members can use the system effectively;
  • Proper use of tickets provides a coherent way of tracking what work is required, and provides a history of reasoning and decisions for the project (which can be vital when later attempting to understand why the software behaves as it does);
  • A developer should not accept tasks without a ticket. The developer may create the tickets based on information provided by others, but this risks loss of information, duplication of effort and, more importantly, lack of team engagement with the IMS;
  • Make tickets actionable by limiting them to one task or issue, with a clear description of the problem and expected behaviour at completion.

(iv)Use a version control system to manage code, but don’t over-manage it:

  • To better manage the integration of our changes with those flowing from upstream, a version control system (“Git”)7 was adopted;
  • Moodle originally used “CVS”, but is gradually moving to Git;
  • Version control keeps a history of changes over the lifetime of the code;
  • Version control allows creation of linked copies (“branches”) of the upstream code which enables development of new features without disturbing the incorporation of new code from upstream;
  • “Merging” is a companion to branching which provides methods of combining changes from one branch into another;
  • Key to effective use of branching is knowing when to make branches. Too many branches or branches with overlapping features will be confusing and difficult to merge;
  • Use the version control system regularly, to get comfortable with using it, and so that progress is documented for later reference.

(v)Testing the modifications:

  • The developer needs to be rigorous in testing the system prior to its use by stakeholders in a pilot study;
  • Setting up multiple test users and checking the system's functionality from the aspect of each type of user ensures the correct integration of roles;
  • Retesting of correctly functioning features needs to be incorporated into later tests to identify any knock-on effects of further changes to the code when developing other functions;
  • Where possible, a unit testing framework should be created/used. This enables automatic testing of the code, on-demand and at regular intervals – e.g. every night. Although this will take additional time to set up and maintain, it should more than repay itself with time saved through early identification of problems;
  • Early on in the project, identify suitable opportunities for testing. In this project, having to tie in with known assignment deadlines for the courses taking part in pilot studies provided a time schedule for the development. Also having a limited number of opportunities for running pilot studies with real assignments became an issue when problems identified in one pilot study needed to be resolved then retested.

(vi)Working with an open source project:

  • Learn about, and join in with, the existing community8 and development culture;
  • Take the upstream development status into account, e.g. upstream is focusing on Moodle 2.0, which means that there is no chance of new features and code created for the Cascade project being incorporated into Moodle 1.9;
  • Continuing development away from the “bleeding edge” is the right thing to do if that is what your schedule requires;
  • Offer up your ideas and designs, and incorporate some of the comments you get in return;
  • Do not worry too much about including features that others want, as this may overcomplicate your initial development. Initially keep it as simple as possible and get your key requirements working;
  • Share your code; if it interests others, they will try it and give useful feedback.
  • CONCLUSIONS AND RECOMMENDATIONS

The experience of the Cascade project suggests that customizing open source software to meet the institution’s bespoke curriculum delivery requirements can result in the development of a robust system offering improved services to stakeholders. Key recommendations for other developers considering similar projects are:

  • Define the processes involved before working on the development of software; a broken or unclear process cannot have an effective technological solution;
  • Keep all stakeholders informed of what the final result will be, providing updates when the requirements/functionality change;
  • Have everyone concerned with functionality and bugs use an issue management system from the start of the project;
  • Use version control to manage code, but keep it simple;
  • Learn and work with the norms of the open source community for maximum wider benefit.
  • ADDITIONAL INFORMATION
  1. Department for Continuing Education website:
  2. Technology-Assisted Lifelong Learning (TALL) unit:
  3. JISC Transforming curriculum delivery through technology programme:
  4. Cascade project:
  5. The following online assignment-handling specification documents, developed during project, are available on the Cascade project website:
  • Wish list of assignment-handling features:
  • Comparison of CASS and Moodle:
  • Assignment handling flowchart:
  1. Trac is an issue management system (IMS) for software development projects (see:
  2. Git is a distributed version control system (see:
  3. Resources, including forums, documentation and open source code, from the Moodle developer community are available at:
  4. More detailed information about the work outlined in this case study is available in the Final Report of the Cascade project, which is available from:
  5. Moodle source code developed by the Cascade project is available to download from:

Project Contact:David Balch, Senior Web Developer

Technology-Assisted Lifelong Learning (TALL)

Department for Continuing Education

University of Oxford

Email:

1

[a]“Upstream” is the conventional name, used in open source development, for where software code originates from. Typically, software code flows from its primary developer(s), down to other developers, distributors, and users.