Today it’s been announced that Mozilla will transition development of Open Badges to the IMS Global Learning Consortium, a non-profit that maintains and develops technology standards in education. Alongside this announcement comes the long-awaited refresh of openbadges.org, the dissolution of the Badge Alliance, and the continued harmonisation with the work of the W3C Open Credentials work.
Having had this news previewed to me a couple of weeks ago, I can’t say it’s a huge surprise. Mozilla, with financial backing from the MacArthur Foundation incubated Open Badges and ensured that it was kept going. However, it’s been the enthusiasm and dedication of the community that has ensured its success.
Although I couldn’t make it to Bologna for the ePIC conference this week, I am at the Mozilla Festival this weekend. Both there, and over the next few months, I’m looking forward to working with the community to ensure that there’s a ‘human’ side to badges, to complement Open Badges as a technological standard.
This is a new dawn for Open Badges, a new chapter in its successful, history. There’s so many people who have been, and continue to be, part of the story — certainly far too many to list here. But you know who you are, and today, as we celebrate the continued viability of a movement built upon a technical standard, I’m raising a glass to you all.
This post is me thinking out loud about Nate’s proposed questions:
What type of evidence are people collecting for badges today?
What are challenges and barriers to effectively using evidence with badges?
What services and capabilities could be solutions to these challenges?
Who should hold and control badge evidence? Issuers? Earners?
I’m going to answer these in two sections rather than point by point.
Problems with badge evidence
The claim I/we often make about Open Badges is that, unlike LinkedIn profiles or CV’s, they’re a bunch of evidence rather than a bunch of claims. I think we mean a couple of things by that.
First, we mean that we’ve got something to show for the experience we claimed to have had. In other words, even if the badge issuer doesn’t use the (optional) ‘evidence’ metadata field, there is still some kind of social proof to back up our claims.
The second thing we mean by badges being a bunch of evidence rather than being a bunch of claims is pointing to those that do in fact use the ‘evidence’ metadata field. At this point these seem few and far between. I think this is because:
Organisations are still largely using badges in a ‘command and control’ top-down kind of way. In other words, creating one badge that is issued to many different individuals. This makes adding evidence onerous.
Badges are being issued for relatively low-level things such as participation in workshops and conferences, rather than credentialing more high-stakes knowledge/skills/behaviours.
People are misusing the criteria field as they are inexperienced (as we are all are, initially) in badge system design.
There’s a lack of understanding about the best ways to deal with the evidence that sits behind badges. Whether due to privacy concerns, fears around cost or compliance, or institutional policies, adding evidence is seen as a burden rather than a gamechanger.
Most of the clients I deal with have some sort of background in education, and many have experience in designing assessment systems. However, because Open Badges are open, distributed, and put the learner in control, they need assistance in how to think differently.
Here are some suggestions that I’ve made several times to organisations large and small:
1. Provide appropriate levels of credibility
As I’ve learned during my long-term consultancy with City & Guilds, credibility comes through the triangulation of validity, reliability, and viability. If you’re issuing a PhD-level badge, for example, the amount of ‘social proof’ required will be an order of magnitude greater than those badges issued for participation in an event.
2. Put learners/users at the centre of your system
One of the greatest barriers in terms of pushback issuers are likely to get from users of their badging system is privacy. Granular permissions around the evidence that sits behind a badge are important, especially if that evidence happens to be visual in nature (e.g. photos/videos).
There are ways around this using existing systems such as YouTube, Google Docs, and Flickr, but perhaps an extension to the Open Badges specification could provide a standard on which badge issuers could build?
3. Ask employers what they want
Open Badges aren’t only for helping people into a job, on the job, and onto the next job, but this is a common use case. Given this, if you’re a badge issuer, it’s probably worth thinking through in detail who is likely to be the viewer/consumer of your badges. Talking to them about what they would consider sufficient evidence is likely to be an interesting and enlightening conversation.
Being able to provide trusted evidence is a gamechanger when it comes to credentialing. One of the main reasons that Alan found it difficult to find ‘evidence of evidence’ is that we’re still using the same old metaphors and structures for issuing credentials.
As I argued in my Open Badges in Higher Education keynote and afterwards in the Q&A part of Serge Ravet‘s session, if we find more useful metaphors for people that ‘certificates’ then we’re likely to see different kinds of credentials — and hopefully with many more pointing to evidence than we have now!
However, Mozilla is still involved with the Open Badges project: Mark Surman, Executive Director of the Mozilla Foundation, sits on the board of the Badge Alliance. Mozilla also pays for contractors to work on the Open Badges backpack and there were badges earned at the Mozilla Festival a few months ago.
Although it may seem strange for those used to corporates interested purely in profit, Mozilla creates what the open web needs at any given time. Like any organisation, sometimes it gets these wrong, either because the concept was flawed, or because the execution was poor. Other times, I’d argue, Mozilla doesn’t give ideas and concepts enough time to gain traction.
The end of Persona at Mozilla
Open Badges, at its very essence, is a technical specification. It allows credentials with metadata hard-coded into them to be issued, exchanged, and displayed. This is done in a secure, standardised manner.
For users to be able to access their ‘backpack’ (i.e. the place they store badges) they needed a secure login system.Back in 2011 at the start of the Open Badges project it made sense to make use of Mozilla’s nascent Persona project. This aimed to provide a way for users to easily sign into sites around the web without using their Facebook/Google logins. These ‘social’ sign-in methods mean that users are tracked around the web — something that Mozilla was obviously against.
By 2014, Persona wasn’t seen to be having the kind of ‘growth trajectory’ that Mozilla wanted. The project was transferred to community ownership and most of the team left Mozilla in 2015. It was announced that Persona would be shutting down as a Mozilla service in November 2016. While Persona will exist as an open source project, it won’t be hosted by Mozilla.
What this means for Open Badges
Although I’m not aware of an official announcement from the Badge Alliance, I think it’s worth making three points here.
1. You can still use Persona
If you’re a developer, you can still use Persona. It’s open source. It works.
2. Persona is not central to the Open Badges Infrastructure
The Open Badges backpack is one place where users can store their badges. There are others, including the Open Badge Passport and Open Badge Academy. MacArthur, who seed-funded the Open Badges ecosystem, have a new platform launching through LRNG.
It is up to the organisations behind these various solutions as to how they allow users to authenticate. They may choose to allow social logins. They may force users to create logins based on their email address. They may decide to use an open source version of Persona. It’s entirely up to them.
3. A post-Persona badges system has its advantages
The Persona authentication system runs off email addresses. This means that transitioning from Persona to another system is relatively straightforward. It has, however, meant that for the past few years we’ve had a recurrent problem: what do you do with people being issued badges to multiple email addresses?
Tying badges to emails seemed like the easiest and fastest way to get to a critical mass in terms of Open Badge adoption. Now that’s worked, we need to think in a more nuanced way about allowing users to tie multiple identities to a single badge.
Persona was always a slightly awkward fit for Open Badges. Although, for a time, it made sense to use Persona for authentication to the Open Badges backpack, we’re now in a post-Persona landscape. This brings with it certain advantages.
As Nate Otto wrote in his post Open Badges in 2016: A Look Ahead, the project is growing up. It’s time to move beyond what was expedient at the dawn of Open Badges and look to the future. I’m sad to see the decline of Persona, but I’m excited what the future holds!