Just back from MozFest, where we announced BadgeKit, an Open Badges tool stack that will support the key pieces of the badging experience. This includes defining/designing, assessing, issuing, collecting/managing, sharing and using. BadgeKit will consist of open, lightweight tools that can snap together or be used alongside or within other sites or systems. Sunny and Jess both respectively wrote about it in more detail, but I wanted to dig into the “why”.
Why BadgeKit, why now?
We’ve been pretty good about explaining the WHAT of our work, but I think we can be better about explaining the WHY. Often the WHY is because of feedback we’ve gotten from you, or because of a risk to ecosystem, etc. The WHY is always tied to our values. But I don’t think we talk about it enough. So, I wanted to take a second and jot some of my thinking on the WHY for BadgeKit down for folks to start that conversation:
[] Despite the progress we’ve made with interest and buy-in with badges, the gap between I get it and I have it is way too big. Platforms have emerged that are big, closed and expensive, and there is a huge risk of segmenting or closing large chunks of the ecosystem. Despite us promoting the ‘open’ part of Open Badges, its increasingly EASIER to build a closed system because of the limited availability of tools. We need to fix that. The ecosystem needs simple, easy, open options to move quickly and do so in a way that benefits the entire ecosystem.
[] And building from that, we need to bake our values into the core so that it is easy to build badges and systems that are open, interoperable, transparent, learner-centric, etc. By offering a set of tools to scaffold badging, we have a chance to support our values even further. For example, we care a lot about the open standard (and in fact think that’s the most important piece of all of this), so we should make it REALLY easy to build badges that are aligned with that standard. Easier than building badges that DON’T align with the standard.
[] But that’s not all. This isn’t a new idea out of nowhere, this is actually WHAT WE BUILT FOR CSOL, but more standalone, more complete, and more valuable to the broader ecosystem. We actually ALREADY HAVE BADGEKIT - we have all of the foundations. We are now really working to build out these tools in a way that makes them easy and accessible.
[] Oh yeah and there are TONS of other organizations, cities and groups that want to do what Chicago did or something similar. Networked or ‘connected’ badges are the future - that’s the secret sauce that badges provide but we need the systems to support it. There are so many variables with these badge systems, that it seems to make sense to try to have some shared pieces to help minimize the burden and maximize the speed and efficiency of these roll outs. Plus, a shared technology infrastructure makes for easy sharing and leveraging across these networks. And if that technology is open and extensible, we all win.
[] Finally, we don’t have a bottom line. Building tools in a way that works well with other tools, and invites - even welcomes - competition, is not what any VC would recommend or support. Our priorities are ease of use, but also extensibility, interoperability and playing nice with others. We want to spend the time defining common interfaces so that you can use our issue tool with an assessment tool from somewhere else. Or pick up our build tool and make it better. We want more and better tools in the ecosystem, but the key is that they all work within the same open ecosystem. I don’t say all of this to be snobby, I think its a luxury that we can work this way. But also an obligation. That’s what makes Mozilla Mozilla, and I think we need to step up and build these foundational pieces to increase access and help everyone, including other open tool providers, thrive.
On the why now piece, the demand really speaks for itself. But above and beyond that, I’ve been reflecting back on this entire wild ride. In late 2010 (2010!), when badges was merely a few months old, there was a lot of pressure internally and externally to build an issuing platform. Brian and I, the only Open Badges employees at the time, resisted this at the time because we were afraid that if we did that, we’d too greatly influence the development of the badge ecosystem. We didn’t have a really solid idea of what a good badge looked like or how badge systems could work at that point. And whatever decisions we made and built into the platform would have heavily weighted the ecosystem out of the gate. We showed this diagram (below) all the time and repeated over and over that the stuff in the boxes (with the big blue lines around them) was independent of us, by design. We wanted to build the necessary pieces to support and not confine innovation at the edges, where the learning was taking place.
And yet here we are building issuing tools. But I really think things are different now. We’ve seen a ton of badges and badge systems. We’ve built a ton ourselves. We’ve seen a market emerge around the tools, some done the right way, and some done the wrong way. We also know how to build more neutral systems, and our role in protecting and promoting the open standard. I still think that was the right decision initially, but also think that we’re really primed to do this now.
When BadgeKit?
BadgeKit is already available for select partners - we’ve used it to support Chicago Summer of Learning, Connected Educator Month and Open Badges badges to date. We’ll continue to build out instances to support specific partners and campaigns that engage with us, but are aiming to release a free, open public beta of the standalone offerings in early March 2014.
We really do need feedback from folks on this direction, as well as the specifics of BadgeKit. We keep saying “simple” and “easy” but need some help defining exactly what that means to people, what they need. We will need help prioritizing all of the potential features as well. And more. So look for more from us, and in the meantime, reach out and tell us what you think.
-E
