Open Vs. Closed Badging Systems

Not all digital badges are alike, and that is okay. There is plenty of room for different badge designs and uses. Some worry that people using digital badges as 21st century stickers and gold stars will ruin the enterprise for those of us interested in using them as micro-credentials for substantive (even rigorous) learning contexts. I have no concern about one use diminishing the value of another, at least not when it comes to open badges built around the open badge infrastructure (OBI). OBI helps us address such matters.

There is discussion about whether people understand the difference between open badges and closed badging system. I’ve run into more than a few questions about that difference. The former is interoperable. The term has come to mean badge designs that are built around the open badge infrastructure, leading to:

  • important meta-data being attached to badges,
  • allowing badge earners to own and control their credentials,
  • making it easy for a badge earner to collect and display badges from different issuers in a single location (like an electronic portfolio, online resume or social media profile),
  • democratizing credentials by making it difficult for a single group or a few organizations to monopolize the badge ecosystem,
  • and giving freedom to any person or organization to “use, create, issue and verify” badges.

OBI gives us a common standard that allows for countless integrations between different systems that issue, display, store, curate and verify badges (hence the phrase “badge ecosystem”). And the meta-data allows people to easily understand who issued badge and what one had to do to earn the badge, helping to clarify issues about the authenticity, value, and distinguishing between playful “sticker” badges and those that represent loftier achievements. This allows us to know the difference between the equivalent of a certificate of participation and a Pulitzer prize. The ability to distinguishing between such qualitatively different credentials is built into the open badge infrastructure.

What about closed badge systems? Those are systems that have an option to issue badges, but the badges go nowhere, can’t communicate with other systems, and are usually entirely owned and controlled by the system used to issue the badges or the badge issuer. There is not necessarily anything wrong with a closed badge system, but it doesn’t promise any of the advantages listed above. They work fine if you are interested in using them as digital gold stars, but they are extremely limited if you want to issue and earn credentials that can be shared and displayed more broadly, if you want to capitalize upon the rapidly growing interconnected network of software/systems that allow one to earn, issue, display, and store credentials for many purposes. If you are fine with creating a language that will only be spoken and used by a small group of people, and you are confident that you don’t need or want to speak to anyone beyond that small group, then a closed badge system is fine. If you want to speak about the credentials to the world, then open badges are the way to go. For a growing list of options for issuing open badges, see my recent article on that subject or this great list from the Badge Alliance Wiki.

One compelling illustration between open badges and closed badging systems was introduced by Mark Surman at the 2014 Reconnect Learning Summit. It was a comparison with the development of email. In early stages, email was a closed system, only allowing messages to be sent and received within the mainframe or computers that use the same standard. If people wanted to send messages between mainframes, that required a common mail standard, which eventually became Simple Mail Transfer Protocol (SMTP). It was when we had a largely universal standard that we saw a rapid increase in the adoption rate of email. This example works well for thinking about open badges compared to closed badging systems. If you only want to do the badge equivalent of sending mail between people in a single class or organization, then a closed badge system might work fine. However, if you want the capabilities given by the badge equivalent of SMTP, then you definitely want to find a system that is OBI compliant.

There is another perspective that I tend to take on this matter as well. If you follow my blog, I’m clearly an advocate for digital badges, and if I want to help nurture more widespread adoption of badges as a more widely accepted credentialing currency, then I need to advocate for open badges. They might be able to do for badges what SMTP did for email. I do not tend to speak negatively about software that has a closed badge feature, but when I am asked for advice on what products to use, be assured that my advice almost always focuses on the systems that allow for open badges.