Tag: systems

technical debt for OER

Me trying to find a book on technical debt. Photo credit: LTW, University of Edinburgh CC-BY
Me trying to find a book on technical debt. Photo credit: LTW, University of Edinburgh CC-BY

Three weeks ago,  while preparing  my presentation for e-learningforum@ed conference I was musing on the similarities between ‘technical debt’ and what one might call ‘ copyright debt’.

I was thinking about institutional risks of not being open. Institutional risks are sometimes legal, sometimes reputational, sometimes financial.  Mostly, at IT directors’ meetings we talk about the need to mitigate risks early on, and avoid risks in the future.

Generally,  the risks of not engaging with open practice are reputational: Other institutions are doing it; we might miss out on this good thing; we should be seen to be bold in digital education and leading edge in our open research. There is a risk to our reputation if colleagues do not seem to be up to-date-on licensing and refer to online materials or data as ‘open’ when they are not. But most of those risks are easily hidden under a smear of open-washing and a vagueness about the definition of open in different contexts.

These are not risks which will ever convince a VP Finance and Resources to invest.

If you want to convince an IT director or a CIO to invest in systems which have built-in  open-licensing workflows,  protecting the institution against the risk of expensive copyright debt may be the way forward.

My definition of ‘copyright debt’ is based on my understanding of ‘technical debt’. Technical debt is a metaphor often used in IT to explain why it costs so much to replace IT systems. I  use it to explain why rather than spending my budget on new exciting learning and teaching functionality, I am having to spend it to replace something we thought we already had.

You can ready about technical debt on Wikipedia. It’s the cost of not doing something properly in the first place. From the moment you build a system poorly, without due attention to software code rigour and process, you begin to accrue debt and then interest on that debt. From the moment you don’t fix, patch and maintain the code, the same thing happens. At some point you are going to have to go back and fix it, and the longer you leave it the more expensive it will be*.

From the moment a colleague tells you that they don’t have time, or don’t care about the copyright licensing and metadata on their teaching materials and load them up into a VLE, online course environment, departmental website, online course-pack, lecture power-point slides, whatever, you start to accrue ‘copyright debt’.

Someone will have to go back to those materials at some point to check them, figure out who made them and when and check for 3rd party content. The longer time passes (or staff change) between the original materials   being uploaded in to the VLE the harder it will be to find the original source.

The cost will hit at the moment that you migrate from one VLE to another, or from one website to another, or from one media asset management system to another.  At that point lecturers and departmental administrators will be asked to confirm that they have copyright permission for the materials they are migrating, and they will say ‘ I have no idea, in fact I don’t even remember/know where all the bits came from’.

They will suggest that someone in a central service (usually the library) should do the checking, and that is where the cost hits. No-one in the library is super-human enough ( unless you pay them a lot)  to check all the hundreds of teaching and learning materials in your VLE, so most of it will just be binned and colleagues will be outraged that they have to make it all again.

I’d suggest the common causes of copyright debt include (a combination of):

  • Business pressures, where the business considers getting something released sooner before all of the necessary copyright searches are complete.
  • Lack of process or understanding, where the businesse is blind to the concept of copyright debt, and make decisions without considering the implications.
  • Lack of flexible components, where materials are not openly licensed, the re-use permissions are  not flexible enough to adapt to changes in course content.
  • Lack of time, which encourages colleagues  to do quick  google searches and take materials they find without checking the license.
  • Lack of metadata, where content is created without necessary supporting metadata. That work to create the supporting metadata represents a debt that must be paid.
  • Lack of collaboration, where knowledge of open practice isn’t shared around the organization and business efficiency suffers, or junior learning technologists  are not properly mentored.
  • Parallel development at the same time on two or more VLEs  can cause the build up of copyright debt because of the work that will eventually be required to move content from one to another. The more content developed in isolation without clear licensing , the more debt that is piled up.
  • Delayed reformatting – the  formats which were used for creating learning objects quickly becomes obsolete. Without clear permission to make adaptations it is hard for older TEL materials to be converted to new formats.  The longer that reformatting is delayed, and the more content is written to use the older format, the more debt that piles up that must be paid at the time the conversion is finally done.
  • Lack of alignment to standards, where industry standard features, frameworks, open technologies are ignored. Eventually, integration with standards will come, doing it sooner will cost less.
  • Lack of knowledge, when the content creator simply doesn’t know how or why to use open materials.

The challenge in all this of course, is that the individual academics making the materials don’t care about the longer term cost to the central services of this debt. This argument won’t persuade them to take the time to change their practice, so we must build rigour for open practice  into the workflows of our enterprise-wide systems and services as soon as we possibly can, making it easy for colleagues to make positive choices.

Or else we risk a whole heap of copyright debt.

*Basically it is the software equivalent of ‘ a stitch in time saves nine’.

(While I was doing this thinking, I bumped into  a session at #OER15 called  ‘the cost of not going open‘ by Viv Rolfe which also looked to quantify costs. Viv’s approach is to look at costs and savings around academic time spent creating materials, which complements my thinking rather nicely.)