Issue #24 | March 2014

Welcome

Welcome

Welcome to the March edition of the OSS Watch newsletter!

This month Rowan takes a look at the implications of a serious security error emerging within the open source community, Scott identifies some areas where Open Educational Resources can learn additional lessons from Free Software and Open Source, and finally Scott asks whether popular editing format Markdown should become a standard.

We've been busy as always at OSS Watch this month. Scott did a talk in Dublin on procurement for the Irish libraries community, and we'll be following this up with a procurement workshop at the next IWMW conference in July.

We delivered a web-based training course for the Apereo Foundation for its new incubator mentors, and we have some more training dates in June with TYPO3 which we'll announce shortly. If your community, project or company is interested in training around open source community topics, let us know!

We're all off to Open Source Open Standards on the 3rd of April in London; so if you're going make sure to say hi!

If you want to work with OSS Watch - whether you're a company, a project, a consortium developing a project proposal, or working within the University of Oxford - take a look at our services page to find out what we can offer.

...
In this issue

What can we learn from security failures?

classroom

Rowan Wilson asks what we can learn from the recent story of a critical security bug in a well used open source library.

5 lessons for OER from Open Source and Free Software

What can the OER movement learn from the experience of Open Source and Free Software. Scott Wilson picks five key lessons.

Should Markdown become a standard?

gradient

Never mind ODF vs OOXML, what about Markdown for official documents?

...

From the Blog

What can we learn from security failures?

Published by Rowan Wilson on 20th March, 2014

After posting on the Apple goto fail bug, it is regrettable to have to talk about another serious, major bug in open source software so soon. This time it is more serious still, in that it has existed for over ten years, and is relied upon by many other pieces of standardly deployed open source software. The bug is strikingly similar to Apple’s, in that it happens as a result of code which is intended to signal an error but which through a subtle programming fault in fact fails to do so. This bug was found as a result of an audit commissioned by commercial Linux provider Red Hat, and the bug was discovered and publicised by its own author.

Read more… »

What can we learn from these two failures in security critical open source code? For a start, it might lead us to question the so-called ‘Linus’ Law‘, first recorded by Eric Raymond:

Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix will be obvious to someone.

This is sometimes referred to as the ‘many eyes’ principle, and is cited by some open source proponents as a reason why open source should be more secure than closed source. This conclusion is, however, controversial, and this particular bug shows one reason why. In discussing the reasons why this bug slipped through ten years worth of review, the reviewer/author says the following:

As this code was on a critical part of the library it was touched and thus read, very rarely.

A naive view – and certainly one I’ve subscribed to in the past – is that critical code must surely get reviewed more frequently than non-critical code. In practice though, It can be the subject of a lot of assumptions, for example that it must be sound, given its importance, or that it should not be tinkered with idly and so is not worth reviewing.

So must we abandon the idea that source code availability leads to better security? As I said in the previous post, I think not. We just have to accept that source code availability in itself has no effect. It facilitates code review and improvement, if there’s a will to undertake that work. It makes it easy to share exactly what a bug was once it was found, and in turn it makes it easier for maintainers of other code bases to examine their own source for similar issues. Finally it allows anyone who finds a problem to fix it for themselves, and to share that fix. What we must not do is assume that because it is open source someone has already reviewed it, and – if this incident teaches anything at all – we must not assume that old, critical code is necessarily free of dumb errors.


From the Blog

5 lessons for OER from Open Source and Free Software

Published by Scott Wilson on 19th March, 2014

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.

open education week 2014

Read more… »

1. Its not what you share, its 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 organisations. 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, its 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 its 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 organisations 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 organisation 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 optimised 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 artefacts but not the infrastructure for collaboratively creating artefacts 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)

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

For Free Software we have the Four Freedoms as defined by FSF:

  • Freedom 0: The freedom to run the program for any purpose.
  • Freedom 1: The freedom to study how the program works, and change it to make it do what you wish.
  • Freedom 2: The freedom to redistribute copies so you can help your neighbor.
  • Freedom 3: 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 some sort of “open software”. End of. There is no grey area.

Its 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 vs. 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 recognised 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 criticising 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, its 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.

Originally posted on Scott’s personal blog


From the Blog

Should Markdown become a standard?

Published by Scott Wilson on 8th March, 2014

We’re big fans of Markdown at OSS Watch; the lightweight format is how we create all the content for the OSS Watch website (thanks to the very nice Jekyll publishing engine).

Read more… »

Markdown is more or less a set of conventions for semi-structured plain text that can be fairly easily converted into HTML (or other formats). The idea is that its easy to read and write using text editors. This makes it great for wikis, and for source code documentation. Its the format used for most of the README files on Github, for example.

# This is a header

Some text with bits in **bold** or in *italics*.

> I'm a blockquote!

## Sub-header
* Bullet one
* Bullet two
* Bullet three

Markdown has flourished despite the fact it isn’t really an open standard as such. There are numerous “flavours” of Markdown, such as GitHub-Flavoured Markdown, and different processing engines have their own extensions, particularly in areas where there is no common agreement on how to represent things such as tables and definition lists.

Despite this lack of consistency, Markdown works very well without ever becoming a de jure standard. The closest its got to standardisation is a community site on GitHub following a call to action by Jeff Atwood.

What has brought this into focus for me is the discussion around open formats for the UK government. Putting the (huge) issue of ODF versus OOXML to one side, I would actually prefer it if more government content was in an easy to read plain text format rather than in any flavour of whopping great office-style documents. In fact, wouldn’t it be excellent if they were to use Markdown?

Which is where the problem lies – its difficult for government to mandate or even recognise “standards” that have no clear provenance or governance model arising out of some sort of recognisable standards organisation. This isn’t a problem when its just a case of “using whatever works” as an individual developer (which is how sort-of standards like Markdown and RSS take off), but seems to be a major barrier when trying to formulate policy.

So sadly, unless there is a new concerted effort to make some sort of standardised Markdown, I don’t think my dream of reading government documents in markdown using TextEdit or on GitHub are likely to become a reality.

This newsletter contains Creative Commons licensed photos by
promanex.