An OSS Watch for your wrist!

At OSS Watch, our name means we get a lot of spam offering to sell us watches, so I decided to find out if there really is an “OSS Watch”. It turns out there is, or at least, an “OS Watch” since it’s more about the watch being open than the software it runs.

The Open Source Watch website provides details of the components to buy, the tools you’ll need, and schematics for 3D-printing the casing. It then has detailed step-by-step guides with photos showing assembly of your own homebrew smartwatch.

The device as built on the site features a 1.3″ OLED screen (the site also suggests other options), bluetooth connectivity, vibration and LEDs for notifications. The whole thing is powered by an Arduino-compaitble microduino (underclocked to save power), and runs off a 500mAh battery with micro USB charging. You get 3 tactile push buttons, a power switch and a port for programming the arduino.

The site doesn’t provide dimensions for the finished device, but by my esimates the face is 40x60mm, and the casing is about 30mm deep. So it’s fairly chunky as you’d expect from a smartwatch, but doesn’t look over the top considering it’s a DIY job.

The software to run on the watch is in development and available on Github. There’s currently some code to display the “watch face” using the arduino, and the beginnings of an iOS app which will presumably send notifications and data via bluetooth.

VALS Semester of Code – FOSS Projects Wanted

The VALS Semester of Code is an upcoming project that will work with universities and FOSS communities to give students real-world experience working in software projects.  Unlike Google Summer of Code, Semester of Code students will be participating for academic credit as part of their degree courses, and we hope that after completion of their project will go on to be effective contributors to the FOSS community.

The VALS initiative is a partership of European universities and SMEs who have been working for several months to plan the pilot of Semester of Code, which will run during the next academic year.  We have now reached the stage where we are signing up FOSS projects who are willing to provide mentored projects of students. We have already seen interest from smaller, single-company projects to larger software foundations, and would like to see more.

If you are part of a FOSS project, large or small, that would be willing to provide one or more mentored projects, we’d love to talk to you about joining Semester of Code.  In return, you’ll get an enthusiastic student providing a valuable contribution to your project.  The VALS team will be on hand throughout the project to answer any questions and help unblock communication issues between mentors, students and academic supervisors.

If you’re interested in taking part, you can email me on, or you can sign up to our mailing list directly using this form.

More details about the Semester of Code are available on our FAQ page. If you have any other questions, don’t hesitate to ask on the mailing list, and one of the VALS team will get back to you!

Open source in education: where does the change need to happen?

In our recent survey on free and open source software in the UK education sectors, we asked colleges and universities for their main reasons for not selecting an open source solution according to 12 criteria. Below you can see how important each of the criteria were rated for software running on servers:

Interoperability and migration problems 80
Lack of support 71
Poor quality software 60
Not what users want 51
Lack of staff expertise, training needs 49
There is no open source solution for our needs 43
Legal issues including licensing 30
Time costs of identifying relevant software 29
Migration costs 25
Existing contractual obligations 18
Poor documentation 15
Solution does not scale 14

The question I’d like to pose today is – if we were to consider these as representing the barriers to greater adoption of free and open source software in education, are the barriers to be found within institutions, or are there issues with the available supply of software and services to the sectors?

To answer this I’ve split the criteria into two groups – supply-side and demand-side. Lets look at the supply-side first of all.

Supply Side Factors

Supply-side factors

Three of the top four criteria are supply-side considerations: lack of support, poor quality software, and not offering what users want.

We could also consider “There is no open source solution for our needs” as being largely the same thing as not offering what users want, which would place it as the top concern.

This would imply that, from the perspective of colleges and universities, the open source software community just isn’t offering the kind of software products the sectors need.

From our experience in compiling the Open Source Options for Education list, this would seem a bit curious. Perhaps the issue is one of awareness and marketing? Or are there significant niches in education where there really are no open source options? We also know that the procurement processes in many institutions would likely exclude open source from consideration – is this also a factor in this lack of awareness?

The second major issue on the supply side would then be the provision of services and support. As we’ve seen in the public sector, having commercial partners is a crucial factor in getting solutions adopted. (There is a chicken-and-egg issue here is that there has to be adoption to support a services market, but lack of services hampers adoption.)

Finally there is the quality issue – are open source solutions aimed at education really poor quality? Or is it that the kinds of solutions being considered are not mature?

Now lets look at the demand side.

Demand Side Factors

Demand side factors

The top issue is interoperability and migration problems – if we also add in the respondents who considered migration costs, then it is by far the most cited reason why open source isn’t selected.

We’ve noted before that there is no simple relationship between open source, open standards, and interoperability; while in principle open source affords the adoption of open standards and greater interoperability, the practice is a lot less clear cut.

However, what we haven’t untangled here is whether the issue is with open source options lacking interoperability features or standards compliance, or whether the issue lies with the incumbent systems they would replace.

The next ranked issue is lack of staff expertise; again we haven’t untangled whether this is a lack of expertise amongst the potential users of the software, the IT operations staff, or the staff involved in the procurement so its hard to interpret precisely. Given the question relates to server software it could be any of these groups.

It may also be the case that this issue goes hand-in-glove with that of lack of support from the supply side; often for server-side software the complexity of configuration and operations can be overcome by contracting a supplier to deal with it on your behalf. For  open source options, if there are no suppliers of services available then its up to the institution’s staff to figure it out.

Finally, the rest of the issues here fall under the category of contractual, legal and procedural issues with procurement itself. While each individual item is not ranked highly, taken together they suggest there are significant barriers still in place in procurement. This is something we’ve been looking into recently in more depth, for example in our Decision Factors for Procurement briefing.


Taken altogether, the demand side and supply side issues of open source adoption in education carry pretty much equal weight from the viewpoint of the institutions themselves. But what are we to make of it?

I think we can distill it into five challenges:

1. We need to tackle the interoperability question. Is lock-in a problem? Is lack of standards a problem? This is something our friends at CETIS could take a lead on.

2. We need to improve awareness of existing open source solutions available within the sector;  lists like our Open Source Options for Education are useful here, but projects also need to be more proactive in raising awareness, and may need a higher profile at events such as the UCISA and ALT conferences.

3. Institutions need to improve software procurement processes so that they can consider open source solutions effectively and equally with closed source.

4. We need to build up the open source services market for education. ULCC have been very effective with their Moodle hosting, but companies supporting other major open source software solutions don’t seem to have much of a presence in the education sector. (As I mentioned earlier though, this is a bit of a chicken-and-egg problem)

5. Bootstrap projects in areas where there are no existing open source solutions. Of course there are well known problems with funded projects, but there are alternative approaches, for example the Jisc Co-Design programme could play a role here.

Open source lecture capture at The University of Manchester

We received an excellent contribution to our Open Source Options for Education list this week, in the shape of a real-world usage example of Opencast Matterhorn at the University of Manchester.  The previous examples of Matterhorn usage we’ve had on the list have been documentation of pilot projects, so it’s great to have such an in-depth look at a full scale deployment to refer to.

Cervino (Matterhorn) by Eider Palmou (CC-By)

Cervino (Matterhorn) by Eider Palmou. CC-BY

The case study looks at the University’s movement from a pilot project, with 10 machines and the proprietary Podcast Producer 2 software, to a deployment across 120 rooms using Opencast Matterhorn.  During the roll-out, the University adopted an opt-out policy meaning all lectures are captured by default, collecting around 1000 hours of media per week.

The University has no policy to preferentially select open source or proprietary software.   However, Matterhorn gave the University some specific advantages.  The lack of licensing or compulsory support costs kept the costs down, and combined with the system’s modularity allowed them to scale the solution from an initial roll-out to institution wide solution in a flexible way.  The open nature also allowed for customisations (such as connecting to the University timetable system) to be added and modified as requirements developed, without additional permissions being sought.  These advantages combined to provide a cost-effective solution within a tight timescale.

If your institution uses an open source solution for an educational application or service, let us know about it and we’ll include it in the Open Source Options for Education list.

If all bugs are shallow, why was Heartbleed only just fixed?

This week the Internet’s been ablaze with news of another security flaw in a widely used open source project, this time a bug in OpenSSL dubbed “Heartbleed”.

This is the third high-profile security issue in as many months. In each case the code was not only open but being used by thousands of people including some of the world’s largest technology companies, and had been in place for a significant length of time.

heartbleedIn his 1999 essay The Cathedral and The Bazaar, Eric Raymond stated that “Given enough eyeballs, all bugs are shallow.”  If this rule (dubbed Linus’s Law by Raymond, for Linus Torvalds) still holds true, then how can these flaws exist for such a long time before being fixed?

Let’s start by looking at what we mean by a “bug”.  Generally speaking the term “bug” refers to any defect in the code of a program, whereby it doesn’t function as required.  That definition certainly applies in all these cases, but for a bug to be reported, it has to affect people in a noticeable way.  The particular variety of bugs we’re talking about here, security flaws in encryption libraries, don’t affect the general population of users, even where we’re talking about users on the scale we see here.  It’s only when people try and use the software in a way other than it’s intended, or specifically audit code looking for such issues, that these bugs become apparent.

When Raymond talks about bugs being shallow, he’s really talking about how many people looking at a given problem will find the cause and solution more quickly than one person looking at that problem.  In the essay, Raymond quotes Torvalds saying “I’ll go on record as saying that finding [the bug] is the bigger challenge.”

So the problem we’ve been seeing here isn’t the the bugs took a long time to diagnose and fix, instead it’s that their lack of impact on the intended use of the software means they’ve taken a long time to be noticed.  Linus’s Law still holds true, but it’s not a panacea for security. The recent events affirm that neither open or closed code is inherently more secure.

For more about security in open source software, check out our briefing on the subject.

Software Freedom and Frontline Services

There are many reasons why organisations choose open source software. Sometimes Total Cost of Ownership (TCO) is a key factor. Sometimes the FOSS offering is the market leader in its niche (such as Hadoop for Big Data, or WordPress for blogs). Sometimes its the particular features and qualities of the software.

However, one of the other key characteristics of FOSS is freedom, and this is emerging as an important consideration when using software to deliver key user-facing services.

"If you want to achieve greatness, stop asking for permission"

At the Open Source Open Standards conference in London on April 3rd, James Stewart from the UK Government Digital Service (GDS) stressed the importance of the permissionless character of FOSS. This enables GDS to modify government frontline services whenever there is need, or whenever an improvement can be identified. This means that services can innovate and improve continually without requiring cycles of negotiation with suppliers.

Businesses are also identifying the importance of “delivering constant value and incremental improvement” that can be delivered through participation in FOSS projects, and through permissionless modification.

While it may seem at odds with typical procurement and deployment practices, where software is used for delivering key services to customers, organisations can choose to devote resources to continual innovation and improvement (using agile processes and continuous testing) rather than more traditional models of sparse planned service upgrades. This can make the difference in crowded markets; or for public sector, react to public demand. With FOSS, continual service improvement processes can be implemented in an agile manner.

Free and Open Source Software is an enabler of permissionless innovation, so when evaluating software for frontline services, bear this in mind.

Image by Thomas Hawk used under CC-BY-NC. Please note that the NC clause may be incompatible with reuse of the text of this blog post, which is CC-BY-SA. For avoidance of doubt, syndicate this article using another image.

What can we learn from security failures?

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

5 lessons for OER from Open Source and 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.

open education week 2014

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

Open Source Open Standards 2014

The Open Source, Open Standards conference is in London on the 3rd of April 2014, and this year OSS Watch has joined the list of supporters for the event.

open source open standards 2014 conference logo

I attended the conference in 2013, which was well attended from across the public sector and from open source companies and organisations. You can read my post on that event here.

Given how closely aligned open standards and open source software are in the view of policy makers (though we do like to point out that its not quite that simple), its perhaps odd that so few events explicitly cover both bases.

The event is also interesting in that there are as many – more perhaps – talks from the customer point of view as from suppliers. This means it is much more about sharing experiences than the sales-oriented events that are commonly targeted at the public sector, and this is why we decided to be associated with the event this year.

Public sector organisations need to share experiences with each other, not just engage with suppliers, if they are to take advantage of the opportunities of open source software and open standards, and events like this are one place to do just that. (Of course, this applies equally to educational institutions such as universities and colleges – and the organisers are keen this year to open up the scope to include them.)

If you attend the event, feel free to say hello – one of us at least will be there on the day.

Should Markdown become a standard?

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

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.