Lessons open education resources can glean from free software

While the OER community owes some of its genesis to the open source and free software movements, there are some aspects of how and why these movements work that I think are missing or need greater emphasis.

1. It's not what you share, it's how you create it

One of the distinctive elements of the open source software movement are open development projects. These are the projects where software is developed cooperatively (not collaboratively, necessarily) in public, often by people contributing from multiple organizations. All the processes that lead to the creation and release of software—design, development, testing, planning—happen using publicly visible tools. Projects also actively try to grow their contributor base.

When a project has open and transparent governance, it's much easier to encourage people to voluntarily provide effort free of charge that far exceeds what you could afford to pay for within a closed in-house project. (Of course, you have to give up a lot of control, but really, what was that worth?)

While there are some cooperative projects in the OER space, for example some of the open textbook projects, for the most part the act of creating the resources tends to be private. Either the resources are created and released by individuals working alone, or developed by media teams privately within universities.

Also, in the open source world, it's very common for multiple companies to put effort into the same software projects as a way of reducing their development costs and improving the quality and sustainability of the software. I can't think offhand of any examples of education organizations collaborating on designing materials on a larger scale—for example, cooperating to build a complete course.

Generally, the kind of open source activity OER most often resembles is the "code dump" where an organization sticks an open license on something it has essentially abandoned. Instead, OER needs to be about open cooperation and open process right from the moment an idea for a resource occurs.

Admittedly, the most popular forms of OER today tend to be things like individual photos, PowerPoint slides, and podcasts. That may partly be because there is not an open content creation culture that makes bigger pieces easier to produce.

2. Always provide "source code"

Many OERs are distributed without any sort of "source code." In this respect, license aside, they don't resemble open source software so much as "freeware" distributed as executables you can't easily pick apart and modify.

Distributing the original components of a resource makes it much easier to modify and improve. For example, where the resource is in a composite format such as a PDF, eBook or slideshow, provide all the embedded images separately too, in their original resolution, or in their original editable forms for illustrations. For documents, provide the original layout files from the DPT software used to produce them (but see also point 5).

Even where an OER is a single photo, it doesn't hurt to distribute the original raw image as well as the final optimized version. Likewise for a podcast or video the original lossless recordings can be made available, as individual clips suitable for re-editing.

Without "source code," resources are hard to modify and improve upon.

3. Have an infrastructure to support the processes, not just the outputs

So far, OER infrastructure has mostly been about building repositories of finished artifacts but not the infrastructure for collaboratively creating artifacts in the open (wikis being an obvious exception).

I think a good starting point would be to promote GitHub as the go-to tool for managing the OER production process. I'm not the only one to suggest this; Audrey Watters also blogged this idea.

It's such an easy way to create projects that are open from the outset, and has a built in mechanism for creating derivative works and contributing back improvements. It may not be the most obvious thing to use from the point of view of educators, but I think it would make it much clearer how to create OERs as an open process.

There have also been initiatives to do a sort of "GitHub for education" such as CourseFork that may fill the gap.

4. Have some clear principles that define what it is, and what it isn't

There has been a lot written about OER (perhaps too much), however what there isn't is a clear set of criteria that something must meet to be considered OER.

Freedom 2: The freedom to study how the program works, and change it to make it do what you wish.

Freedom 3: The freedom to redistribute copies so you can help your neighbor.

Freedom 4: The freedom to improve the program, and release your improvements (and modified versions in general) to the public, so that the whole community benefits.

If a piece of software doesn't support all of these freedoms, it cannot be called free software. And there is a whole army of people out there who will make your life miserable if it doesn't and you try to pass it off as such.

Likewise, to be "open source" means to support the complete open source definition published by OSI. Again, if you try to pass off a project as being open source when it doesn't support all of the points of the definition, there are a lot of people who will be happy to point out the error of your ways. And quite possibly sue you if you misuse one of the licenses.

If it isn't open source according to the OSI definition, or free software according to the FSF definition, it isn't "open software." End of discussion. There is no grey area.

It's also worth pointing out that while there is a lot of overlap between free software and open source at a functional level, how the criteria are expressed are also fundamentally important to their respective cultures and viewpoints.

The same distinctive viewpoints or cultures that underlie free software versus open source are also present within what might be called the "OER movement," and there has been some discussion of the differences between what might broadly be called "open," "free," and "gratis" OERs which could be a starting point.

However, while there are a lot of definitions of OER floating around, there hasn't emerged any of these kind of recognized definitions and labels—no banners to rally to for those espousing these distinctions.

Now it may seem odd to suggest splitting into factions would be a way forward for a movement, but the tension between the free software and open source camps has I think been a net positive (of course those in each camp might disagree). By aligning yourself with one or the other group you are making it clear what you stand for. You'll probably also spend more of your time criticizing the other group, and less time on infighting within your group!

Until some clear lines are drawn about what it really stands for, OER will continue to be whatever you want to make of it according to any of the dozens of competing definitions, leaving it vulnerable to openwashing.

5. Don't make OERs that require proprietary software

OK, so most teachers and students still use Microsoft Office, and many designers use Adobe. However, it's not that hard to develop resources that can be opened with and edited using free or open source software.

The key to this is to develop resources using open standards that allow interoperability with a wider range of tools.

This could become more of an issue if (or rather when) MOOC platforms start to "embrace and extend" common formats for authors to make use of their platform features. Again, there are open standards (such as IMS LTI and the Experience API) that mitigate against this. This is of course where CETIS comes in!

Is that it?

As I mentioned at the beginning of this post, OER to some extent is inspired by open source and free software, so it already incorporates many of the important lessons learned, such as building on (and to some extent simplifying and improving) the concept of free and open licenses. However, its about more than just licensing!

There may be other useful lessons to be learned and parallels drawn—add your own in the comments.

Scott Wilson has worked in both the software industry and public sector, particularly in the areas of interoperability and open standards. Scott has a great deal of practical experience of open development; he is a committer on several projects at the Apache Software Foundation, and is chair of the Apache Wookie project. He is also co-chair of several W3C groups. Scott has also been involved with numerous European-funded collaborative ICT projects, leading work packages and developing

The opinions expressed on this website are those of each author, not of the author's employer or of Red Hat.

Opensource.com aspires to publish all content under a Creative Commons license but may not be able to do so in all cases. You are responsible for ensuring that you have the necessary permission to reuse any work on this site. Red Hat and the Shadowman logo are trademarks of Red Hat, Inc., registered in the United States and other countries.