More Context on Brendan Eich’s Appointment as CEO

It goes without saying that Mozilla is an open organization, they promote the open web, promote open source software, and advocate for open learning, open journalism, and even have a pretty badass manifesto. Given the enormous number of companies involved in the badging ecosphere, (see above) who do you want to develop the plumbing that keeps all this together? A company that sees every eyeball as a dollar sign? Or a foundation built on the principals of open source?

I wrote the above soon after joining Mozilla. I still agree with it. Mozilla is the best community I’ve ever been a part of. I care deeply for it. On Thursday, March 27th, almost exactly two years after I wrote the above – and a short time after participating in a Mozilla Foundation discussion about the appointment of Brendan Eich as CEO of Mozilla, I tweeted:

The wording of the tweet was provocative. “I am an employee of @mozilla” makes it clear that my voice in this situation has more power and more responsibility than a non-employee. I chose that wording. I wanted to be clear and unequivocal. Other wording was just as intentional. I didn’t ask Brendan to resign, I asked him to step down as CEO. I didn’t demand, I asked.

When Brendan was announced as CEO, my hope was that he would explain himself, maybe apologize or recant his actions of 2008. Six years is a long time; maybe now he understood the larger context of Proposition 8 and its terrible effect on thousands of Californians. Instead, he was wholly unprepared to speak about the issue. We waited, being told he would write a blog post that would clear things up. The post came, but was underwhelming, and he neither apologized nor offered an explanation for the donation.

In the meantime, Christie Koelher wrote an amazing post explaining that though she disagreed with Eich on the subject of same-sex marriage, she trusted him, and the organization, to not let his personal views cause harm to Mozilla employees. Fundamentally, I agree with Christie – it would be impossible for Brendan to discriminate within Mozilla; he wouldn’t be allowed to exercise his personal views of same-sex marriage in a way that discriminates against employees. There are plenty of checks, both within Mozilla and legally that would protect employees from Brendan’s personal views.

I didn’t ask for Brendan to step down because I was worried he’d discriminate against those in his reporting chain. If that was the case, I would have asked in 2012 when this story originally broke (just a few short weeks after I joined the organization).

So why tweet at all? This morning, Mark Surman, one of the key people who make me proud to be a Mozillian, wrote “I worry that Mozilla is in a tough spot now. I worry that we do a bad job of explaining ourselves, that people are angry and don’t know who we are or where we stand. And, I worry that in the time it takes to work this through and explain ourselves the things I love about Mozilla will be deeply damaged. And I suspect others do to.” I agree with him, we as Mozilla are in a tough spot now. So again – why did I tweet? Why risk damaging a community I love so much? I want to be absolutely clear: I never meant to hurt this community, everything I’ve done has come from a place of love, love for this organization, love for the community it built, and most importantly, love for the people who make it possible.

This very public debate about Brendan’s appointment points to a divide in Mozilla’s identity, which I’d characterize as Mozilla as tech company versus Mozilla as activist organization, which is the fundamental reason why I believe the Brendan Eich that contributed to Prop 8 isn’t the CEO that Mozilla needs. Our power as an organization comes from our ability to assert technology as activism. Webmaker, Open Badges, Web Literacy, a smart phone that puts the web in every hand, the protection of privacy and identity in the face of attacks from every corner.

Mozilla is a leading organization in the fight for an open web. That’s well established. Less known is Mozilla’s role in open education, open journalism open research / science and web literacy. An open web is a tool to empower individuals. To paraphrase Woody Guthrie’s guitar, “This [internet] machine kills fascists.” That’s the open web we’re fighting for, a machine that ends human suffering, a machine that won’t let a government stop our sons and daughters from loving who they choose. An open web not tied to a mission like essential human freedom and empowerment is an empty web.

Our manifesto is vague on this point, “The Mozilla project is a global community of people who believe that openness, innovation, and opportunity are key to the continued health of the Internet.” We promote the health of the internet, but never make the bigger connection to the health of humanity. We interact with organizations who accept that goal, but take it one step further, their goals aren’t just the health of the Internet, their goals are the health of humankind, of the planet, of our place in history.

Mark once quoted Mitchell as describing projects as rockets. A rocket is a thing, but in every rocket, there’s a payload. The payload can be anything, a belief that the web should be open, that open source is a fundamentally different paradigm of work. Paraphrasing, “a rocket without a payload isn’t worth anything.” The payload of Mozilla is human freedom through technological empowerment. Those are my words, my interpretation of the Manifesto, but I can’t imagine anyone in the organization, even Brendan, disagreeing with them.

In a blog post yesterday, we go beyond the Manifesto and state, “Mozilla’s mission is to make the Web more open so that humanity is stronger, more inclusive and more just. This is why Mozilla supports equality for all, including marriage equality for LGBT couples. No matter who you are or who you love, everyone deserves the same rights and to be treated equally.” Maybe Brendan can lead us on that path by showing how a person can change, as an example of how a community can change.

The Brendan that contributed money to Prop 8 (and also invented Javascript) is the right CEO for a tech company that makes a web browser. We’re more than that. We have a payload. It’s an open web, yes – but it needs to expand to include a fundamental belief in the right of all humankind to live their lives to the fullest extent of their potential. We don’t just make tools, we change lives. The Internet is the ultimate potential amplification machine, let’s make sure that Mozilla is at the forefront of innovation, both technological and social, for the century to come.

BadgeKit Future!

This is the second post in a two part series on BadgeKit, in the first part, I wrote about BadgeKit Now, looking at how you can set up a version of BadgeKit on your own servers now.

BadgeKit is coming! Like I wrote last time, it’s already here. You can pull a handful of Mozilla Open Badges projects together, host them on your servers and build a complete badge platform for your project. All that’s easy to say, but not easy to do. BadgeKit will streamline launching an open badge system so that just about anybody can issue open badges with an open platform that grows with them.

Sunny and Jess wrote an overview of where we want to get to by March, a MVP Beta release for the Digital Media & Learning conference. The release will give users two ways to work with BadgeKit,

  1. SaaS – define your badge system on the fully hosted site (or your self-hosted site), integrate the system with your existing web applications through our API’s.
  2. Self hosted – the full experience outlined above, but hosted on your own servers.

In both cases, the issuers build a website that interacts with our API’s to offer the badges to their communities.

The project divides easily into two big buckets – first building out the API’s we created in Open Badger, Aestimia and the Backpack, second building a solid administrative toolkit to define badges and assemble them into larger badge systems. Issuers use the toolkit (which will live at to design and launch their badge systems, then they’ll integrate the community facing portions of the system into their own site (which preserves their custom look and feel) with our API’s. Here’s a quick sketch of what it all will look like,

BadgeKit Layout

Lot’s of API’s

More Flexibility

Last week we talked about a few services in the BadgeKit Now post, OpenBadger, Aestimia, Badge Studio, a ‘badging site’ and the backpack. None of those pieces are going away, but they are all going to get a makeover – each is stripped down to the roots and rebuilt with an emphasis on their web API interfaces. We’re going to standardize on MySQL as a datastore, explore Node.js’ streaming API’s for database access and output and rebuild the account authentication model to allow the services to support more than a single ‘badge system’.

Data Model

The current data model uses a three-tier ownership chain to define a single badge – a badge belongs to a program, a program belongs to a issuer, a issuer is part of a badge system by being defined in the instance of Open Badger. There’s a one to one mapping of a ‘badge system’ like Chicago Summer of Learning to an instance of Open Badger. Adding an extra layer, so that a badge belongs to a program, a program belongs to an issuer, an issuer is part of a badge system, which sits beside other badge systems in the single instance of Open Badger will open us up to hosting several large systems per ‘cluster’ of Open Badger servers. We’re breaking the one to many relationship of a badge to a program and a program to an issuer and allow for badges to belong to multiple programs, or programs to multiple issuers, issuers to multiple systems, providing more of a graph-like collection of objects.

Authentication and Authorization

This collection of applications authenticates the identity of each piece in the chain by signing API calls with JSON Web Tokens. The key used in each app is configured as an environment variable, as long as each app knows the key, they can read and write to other applications with the same key. When we build badge systems that are co-hosted, but span multiple applications (Open Badger talking to the badge site, the badge site passing messages to Aestimia) we’ll have to change the way the distribution of keys between the applications. The client site API keys will allow them access to the hosted API’s.

What’s Next?

You can follow the development of all these pieces on Github and read more about the system as it develops on Planet Badges.

BadgeKit Now!

This is the first in a two part series on Badgekit, the new badge issuing platform from the Mozilla Open Badges team. This post talks about the current suite of issuing tools we’ve built, the next post will talk about where we’re headed.

Badgekit is in active development. We’ve written about it a bunch, Erin, Sunny and Jess have all written introductions to it from different angles. There is a release in the future called Badgekit, that will do all the things that the Badgekite site talks about, but there’s also Badgekit-right-now, a collection of tools that the Open Badges team has used to launch the Chicago Summer of Learning, Connected Educators Month Badges, Open Badges Badges, Mozilla Summit Badges and MozFest 2013 Badges.

This post will explain how you can cobble together your own version of what will become Badgekit now. A follow-up post will explain the improvements we have planned, which will make Badgekit different from the collection of tools we have today.


There’s a few things in common in the apps that I’m going to write about here, in no particular order -

  • Node.js – everything we build is in Javascript with Node.js on the server.
  • 12 factor – We’re bought into Heroku’s 12 factor application architecture. We follow it pretty closely. That means that most of these apps use environment variables for configuration and don’t write to the filesystem for anything.
  • Heroku – for most of our production applications, we run in custom AWS EC2 instances, but given the above 12 factor point, it’s entirely possible to run a complete Badgekit-now system in Heroku.
  • Datastores – there isn’t much consistency in datastores, we use MySQL in some places, MongoDB in others, Memecache here and there, Redis. There’s very little consistency (which will change as we move towards real-Badgekit).
  • Lot’s of API’s and Webhooks – the apps all have big healthy API’s and do lot’s of inter-app communication by Webhook callback.
  • One instance per ‘client’ – every client of Badgekit runs their own instance of all the tools. That made it easy for us to punt on serious user authorization. If you can log in, chances are you can do just about everything.
  • Design – we have awesome designed front ends (thanks Jess & co.!) but slightly clunky developer designed admin panels.

Open Badger

Open Badger is the biggest application in the current Badgekit implementation. It handles the core functionality of a badging system, defining badges, issuing them, tracking whether someone has accepted an issued badge, creating claim codes for in-real-life badging, it’s a big collection of tools that accumulated over time. Almost everything is available via the API. A single instance of Open Badger will manage a full badge system with multiple issuers. The model fit the Chicago Summer of Learning, which had issuers, who had programs, which had badges.

You can build a badge inside of Open Badger, define criteria to earn the badge using a bulleted list of yes / no questions the assessment tool uses to evaluate the application, and upload a badge image. You can’t design the visual image for the badge, which we realized was a limitation on CSOL. So we built Badge-Studio (try it out here) to visually design the badge. (Badge Studio is another tool that will be greatly improved for the release of Badgekit).

The best thing to come out of Open Badger is the API. It’s full featured, makes it easy to list badges, easy to issue, and served us well in several installations. It proved to us that a solid API is worth the effort (I mean, we were already pretty bought in, but it reinforced the idea). You can see an example API call here – a list of badges available for MozFest 2013.


First of all – it’s Latin for “assessment.” I named it, for better or for worse, in a fit of Latin nostalgia (does that exist?). Aestimia is the thinnest possible assessment platform. When a user applies for a badge, the client site sends a package to Aestimia that includes the learners submitted evidence and a criteria listing it grabs from Open Badger. Aestimia returns an application id, then calls a webhook url the client site defines with any updates to the application. When an evaluator evaluates the application, Aestimia tells the client site about the changed state. The client site then chooses what to do with that information, either issuing a badge and emailing the learner about their new badge, or emailing the learner that the badge wasn’t awarded.

Because Aestimia only cares about criteria and evidence, it doesn’t necessarily need to end in the awarding of a badge, it could be used for assessment for any sort of situation. It’s entirely possible to build a system on top of Aestimia and Open Badger where a user does several assessed activities before a badge is awarded. Open Badger doesn’t understand an activity outside of a badge, so you’d have to hack it a bit to store criteria, and you’d need to build in some logic (maybe with tags?) to define a ‘path’ but – you could do it. Hacking aside, all those things will be key features of Badgekit, we have lots of plans!


One interesting sidenote from CSOL – because the Open Badges infrastructure doesn’t yet support federated backpacks, and because the current Mozilla Backpack can’t host badges for under 13 year olds, we ‘faked’ backpack functionality by creating an Open Badger API authenticated endpoint that provided a list of badges issued to a particular email id. In installations where users under 13 aren’t an audience, we push the badges to the Mozilla Backpack as a way of ‘accepting’ the badge.

All badge issuers need a place to store badges, I’ll write more about our plans here in the next Badgekit post, but for now – federation will fundamentally change how we think about backpacks.

Client sites

The CSOL client site was heavy compared to Connected Educators Month and Open Badges Badges. Largely because it had to handle user accounts and parent / guardian approval workflow for learners under 13. Subsequent sites were stateless with limited server code, feeding off the Open Badger and Aestimia API’s. That architecture works well for us, we expect continuing with it as much as possible as Badgekit develops.

How it all flows together

Phew, that was a lot of words. Let’s make some (low tech ASCII) pictures explain how all these pieces fit together.

Here’s all the players,

                                                   |              |
                                                   |              |
                                                   |  E-mail      |
                                                   |  Service     |
                                                   |              |
         +--------------------------------------+  +--------------+
         |   A badging site                     |
         |                                      |
         +--------------------------------------+  +--------------+
                                                   |              |
                                                   |              |
                                                   | Backpack     |
         +---------------+      +---------------+  |              |
         |               |      |               |  |              |
         |               |      |               |  +--------------+
         |  Open Badger  |      | Aestimia      |
         |               |      |               |
         |               |      |               |
         +---------------+      +---------------+

Everyone’s there, the overarching site, Open Badger, Aestimia, the Backpack and a e-mail service of your choice.

First of all, a learner visits a badge listing site, the badging site requests a list from Open Badger and shows them to the user,

                                                   |              |
                                                   |              |
                                                   |  E-mail      |
                                                   |  Service     |
                                                   |              |
         +--------------------------------------+  +--------------+
         |   A badging site                     |
         |                                      |
         +--------------------------------------+  +--------------+
                 ^                                 |              |
                 |                                 |              |
                 +                                 | Backpack     |
         +---------------+      +---------------+  |              |
         |               |      |               |  |              |
         |               |      |               |  +--------------+
         |  Open Badger  |      | Aestimia      |
         |               |      |               |
         |               |      |               |
         +---------------+      +---------------+

The user picks a badge, and submits evidence that they’ve completed the badge. The evidence, plus the evaluation criteria for the badge (from Open Badger) are sent to Aestimia. After the evaluator evaluates the evidence, Aestimia calls back to the badging site to let them know they finished the evaluation. (see all the new arrows?)

                                                   |              |
                                                   |              |
                                                   |  E-mail      |
                                                   |  Service     |
                                                   |              |
         +--------------------------------------+  +--------------+
         |   A badging site                     |
         |                                      |
         +--------------------------------------+  +--------------+
                 ^                     +  ^        |              |
                 |                     |  |        |              |
                 +                     v  +        | Backpack     |
         +---------------+      +---------------+  |              |
         |               |      |               |  |              |
         |               |      |               |  +--------------+
         |  Open Badger  |      | Aestimia      |
         |               |      |               |
         |               |      |               |
         +---------------+      +---------------+

Let’s say the learner got the badge! Hurray for learning! The client site then calls to Open Badger to issue the badge, most likely by asking Open Badger for a claim code embedded url that the site can email to the user. Once the site has that link, it sends it to the user via the email service.

                                                   |              |
                                                   |              |
                                            +----> |  E-mail      |
                                            |      |  Service     |
                                            +      |              |
         +--------------------------------------+  +--------------+
         |   A badging site                     |
         |                                      |
         +--------------------------------------+  +--------------+
              +  ^                                 |              |
              |  |                                 |              |
              v  +                                 | Backpack     |
         +---------------+      +---------------+  |              |
         |               |      |               |  |              |
         |               |      |               |  +--------------+
         |  Open Badger  |      | Aestimia      |
         |               |      |               |
         |               |      |               |
         +---------------+      +---------------+

The learner gets the email, clicks on the link, which takes them back to the site to accept the badge and push it to their backpack.

                  |                 |              +--------------+
                  | An email        |              |              |
                  |                 |              |              |
                  +-----------------+              |  E-mail      |
                          +                        |  Service     |
                          v                        |              |
         +--------------------------------------+  +--------------+
         |   A badging site                     |
         |                                      |
         +--------------------------------------+  +--------------+
                                +                  |              |
                                +----------------->|              |
                                                   | Backpack     |
         +---------------+      +---------------+  |              |
         |               |      |               |  |              |
         |               |      |               |  +--------------+
         |  Open Badger  |      | Aestimia      |
         |               |      |               |
         |               |      |               |
         +---------------+      +---------------+

And that’s it! Easy, right? Not really. It’s actually pretty complicated. There are multiple variations to the above flow, and it’s not even clear that we want to make the learner jump through the claim code acceptance flow – most learners just want their badge! Plus, each of those boxes is a separate piece of hosted software. This isn’t a setup for the feint of heart.

Which is really the point of Badgekit – all those services make sense. They’re the right thing, so what can we do to make it easy to use them? Plus – we’re not the only tool provider, maybe there’s a better assessment tool out there, maybe an issuer uses another issuing platform, but wants to use Aestimia. Badgekit will make hosting all these things seamless, without having to know the difference between Open Badger, Aestimia and whatever else, and give an issuer choice in how the pieces of their program work together. To paraphrase some advertising campaign somewhere – issuers should worry about teaching and making cool badges, not about how their badge system moves bits of data around.

[editing help from Sunny and Brian, thanks!]

Open Badges Tech Panel – Backpack Federation

The Open Badges team had its first tech panel way back on September 26th. The tech team met with active Open Badges community members to talk through the heavy tech-bits of Backpack Federation (which I wrote a bit about in “Let’s Make More Backpacks.” The raw notes from the meeting are here and video is here. It’s been a while since the meeting, but I wanted to summarize what we talked about there, and add some thoughts on where we’re headed next with Backpack Federation.

Federation is the Pipes

Backpack Federation in its minimum viable form is about moving badges around between the users backpack of choice. That was our target for the tech-panel demo, and our target for the first release of the feature. The result looks a bit like this,

Federation System Flow diagram by Jess Klein and Brian Brennan

Federation System Flow diagram by Jess Klein and Brian Brennan

It’s a simple goal, we’re confident we can roll it out in a couple of weeks, given it’s prioritization against other projects. However – that’s the Open Badges core team’s goal – the community wants more, and weren’t shy about saying it.

Federation should be about mobility

One of the themes from the discussion was that backpack federation is about more than just moving the badges around, it’s about creating more value in the badge – adding evidence directly to the baked badge, making the badges portable without relying on an issuer’s site, making the badges less about pushing them places, and more about pulling them.

Where do we go from here?

To start with, we’re absolutely going to have more tech-panels. It was a useful conversation and influenced our thinking, which I think you can see in some of the projects that came out of the Mozfest hack-sessions – the full assertion baked in the badge, and the start of the directory service. The former starts to address the issue of true portability of open badges and the latter starts to move us toward a pull-model of badge discovery.

We’re still committed to basic “push your badge to the backpack you want to” functionality as the MVP for Federated Backpacks. It’s a key part of the Badgekit project we launched at Mozfest and opens up the world of customized backpacks in a way that we’re convinced will change learners use of open badges.

Thanks to all that attended the first Open Badges tech-panel! The next one is tentatively scheduled for early November (fill out this Doodle Poll if you’d like to influence the timing). We’ll be talking about the 1.0 changes to the assertion specification and all the possibilities it enables.

Open Badges Hackery at Mozfest

Erin and Jess announcing Badgekit at Mozfest 2013

Erin and Jess announcing Badgekit at Mozfest 2013

Following up on a post on the Mozfest blog, I wanted to give a big shout of thanks to the folks that came out to support Open Badges in our hack-track. We had around 8 hours of time built into the schedule for building new things on top of the Open Badges infrastructure and the Badgekit stack. I’m thrilled with what we accomplished, some highlights…

Open Badges Crawler / Indexer

Andrew from DIY built a service on top of the backpack that indexes all the badge classes loaded and marked public. It uses our database to bootstrap a crawling process that finds and indexes badges. It’s a first big step towards building a service that makes it easier for learners to find badges they want to earn. We’ll get it deployed live soon, in the meantime the code is up on github/thisandagain/badgecrawler.

Bake Everything!

In the current baking spec, we only specify that the link to the hosted assertion file be ‘baked’ into the badge png. It’s a good thing, because it pushes validation back to the issuer, but it makes very lightweight issuing difficult. Any issued badge requires a server to host the assertion, or a public key to validate a signed assertion. For a huge swath of badges, we’re less concerned about validation, and more concerned about attaching metadata that describes an accomplishment. Mozilla’s own Potch submitted a pull request to the bakery service that bakes the entire assertion into the badge, a huge leap forward for anyone that’s ever wanted to just quickly bake and email someone a badge without worrying about hosting.

Badge Everywhere!

The fine DigitalMe folks posted a map where people could put physical push pins that represented a commitment to launching a badge program in the place under the pin. The ever-resourceful and recent OpenBadges full-timer, Erik Christensen, built it as a real web site – Badge the World!

Badgekit and Appmaker, PB&J

We announced Badgekit (more on that from Erin, Sunny and Jess) at the festival, launched Open Badges Badges and MozFest badges on the platform and then started playing around with it. A few people came to the hack sessions wanting to mobile-ize issuing. Jess led several sessions on tools for disaster relief that included badges (which she writes more about on her blog), Telefonica and Unicef joined Mozilla to work on a mobile donation platform that included badges and bunch of us wanted an app to issue badges in a game of werewolf (excuse me, WereFOX).

When we realized we were in a room full of people that wanted to make mobile badging apps, we decided it would make more sense to build a series of Appmaker components. All in all, David, Laila and I built three key components, an issuer (which interacts with OpenBadger via claim codes and the API), a badge lister (fed by the OpenBadger feed) and a Twilio SMS’er. Given those ingredients, it’s possible to build a whole bunch of interesting things. The Appmaker team is working hard on getting external component libraries includable from the main Appmaker site – as soon as that happens we’ll be able to unleash a hoard of custom mobile badging apps!

Appmaker is really pretty cool to work with, and matches the goals we have for Badgekit – make hard things easy, build a community around a product. We’ve known the Appmaker squad for a while, and we’re super thrilled how easy it was to smoosh Badgekit tools into Appmaker containers. Really excited to keep that going.

Doug caught a great picture of the Erin / Jess plenary demo of the Appmaker / Badgekit super-combo,

@willowbloo just posted (Nov 3) a video summary of the disaster relief badge project she and others worked on, more on Youtube.

Learning Pathways

Chloe and Mike built this amazing demo of where we could head with Learning Pathways. The process of linking badges together into a pathway that other learners can duplicate and follow.

More Yack

After a series of discussions during the hack sessions, Brian launched the Github discussion repo mozilla/openbadges-discussion. There’s already a great conversation going about extensions to the spec for indexing going on. We all like hack, but without a good yack now and then, we’re all just bumping into walls. ORGANIZE THE HACKS!

Who needs digital?

Finally! Cross-stitch badges, courtesy of Cordelia,

Huge thanks to everyone that helped during the hack sessions, supports Open Badges and were super fun to hang out with…BADGES IS A BIG DEAL FRIENDS, LET’S KEEP MAKING THEM.

If I missed something badge-ish you worked on at the festival, drop me a note in comments and I’ll get it added!

[Oct 31 edit - added Learning Pathways]

[Nov 4 edit - adding disaster relief badges video]

[Nov 5 edit - adding link to Jess' summary of the Community Aid Badging sessions.]

Let’s Make More Backpacks

School is starting, which makes me think about school supplies. We use some school supplies as metaphors in the Open Badges world, the Mozilla Backpack is the place you can store your Open Badges. The current backpack stores open badges, organizes them and displays them. It’s really more of a portfolio than a backpack, a collection of achievements instead of something you need while you’re learning day-to-day.

The core functionality of what makes an open badges backpack valid supports the broken metaphor. A backpack (in the open badges sense) is a place to store badges. It validates the badges. It displays them. Maybe it organizes them, but that’s not a requirement. It’s just a filesystem with stuff in it.

So, should we change the name? Should we ditch the backpack metaphor and start calling it a ‘badge storage system’ (gag) or something? No, we shouldn’t, we should let the metaphor guide the development of what an open badges backpack is.

Backpack as Personal Expression

Ask my six year old about his school backpack. He’ll tell you all about it. It’s big, but not too big. It has Marvel super heroes on it. It has a special flap that let’s you choose between two different sets of super heroes, so he can change it up day-to-day. It has a single pocket, nothing fancy to get in the way of the essential nature of what a six year old needs, a place to put his lunch and a small amount of homework.

Ask me about my backpack, it’s biggish, but has these straps that make it small. It’s full of pockets that are easy to get to, some of which have a soft lining for electronic devices. It has a stiff back so that protects my laptop. It’s flat black and emphasizes utility and comfort. My last bag was a courier style bag with snazzy materials. It had a big single pocket that was easy to get to, and the design would impress people who were impressed by that sort of thing. I like both of these bags, but they’re very different and I use them for different reasons.

See what I’m getting at here? Real backpacks serve different purposes. They’re indicative of who we are and express ourselves in different ways. My bag won’t work for my son, his bag won’t work for me. Sometimes I use my utilitarian bag, sometimes I use my fancy bag.

Real backpacks as open badges backpacks lesson one – one size doesn’t fit all, open badges backpacks should be as various as real backpacks. Sometimes you need more than one backpack for different situations.

Backpacks with Constraints

Some schools have requirements about what their kids can use as a backpack. The most common is that they are clear, so teachers and staff can see inside them at any time. It’s not the greatest thing for student privacy or personalization, but as a constraint – it exists.

Lesson 2 – institutions will put constraints on the open badges backpack that won’t apply to all users. We need to accommodate them.

You’re lost without your backpack

Did you ever forget your backpack at home? Or your laptop bag? Your stomach  flip-flops, it’s borderline terrifying. In a learning situation, you’re lost without your backpack.

That isn’t the case with the current Mozilla Open Badges Backpack. The backpack is an after thought in a learning experience. It’s the place you push the results of your learning, not the place you’re actively planning your learning. It’s the equivalent of forgetting your report card at home. Who cares?

Which leads to lesson 3 – let’s make our open badges backpacks more useful, part of your day, essential to the way you learn. The badge backpack isn’t a trophy case, it shouldn’t just be a portfolio, it absolutely isn’t a report card. The backpack is where you go to track your progress, reflect on what you’ve learned, discover new paths you can take to get where you want to go. It’s your learning GPS, something essential to your learning.

What’s Mozilla Doing About It?

Yeah, so – backpacks can be cooler. What’s Mozilla doing about it? Three things:

Many Backpacks

There’s only one real open badges backpack today. If you press the button “push this badge to your open badges backpack” on any issuer’s site, it really means “push this to your Mozilla Open Badges Backpack located at” That’s what the world of badging needed to get started. It needed a single backpack, to prove the concept and bootstrap issuing.

Now that we have a healthy issuer ecosystem, it’s time to bootstrap a healthy backpack ecosystem. We’re working on extensions to the Open Badges Infrastructure that will allow a user to choose their backpack and push their badges there. There isn’t any burden on the issuer, they’ll still integrate a single button served by Mozilla, but the button will be 17% more magical. Once a user can push their badges wherever they want, they’ll want choices.

This feature has been on our roadmap for a while under the unintentionally obfuscated title “Federation.” It makes sense to us, but it’s hard to explain to the community. We’re working on better language (and could use your opinion, get involved in the mailing list) regardless of the name, the result of the feature is clear, learners get to choose their backpacks.

Mozilla Backpack 2.0

After a fair amount of soul-searching, we’ve decided to refactor the existing Mozilla Open Badges Backpack. We’ll do the work alongside support of the current 1.0 backpack. We’re not planning any significant features in the 2.0 backpack, it’s mostly a feature for feature replacement of the existing backpack. We’ll rework the UX, make branding changes to get the backpack in line with the current branding of Open Badges, but will mostly mirror the existing 1.0 backpack.

Why do it? There’s a significant amount of boiler plate functionality that makes up an open badges compliant backpack (which in itself is a moving target, we haven’t actually declared the requirements of a backpack yet, we will, so keep your ears peeled). If we want to encourage a diversity of backpacks, we’d like to offer a solid starting point. A collection of code that allows for easy extension of the backpack concept. If you have an itch to scratch backpack-wise, you can do it in a few days, or hours, you won’t have to recreate yet another storage system for assertions, or validation against the spec. Fork our code and focus on what you should, providing an awesome experience for your users.


Finally, Jess, Andrew and Emily are leading the charge towards a new vision of an open badges backpack. They’re working on backpack 3.0, or backpack 3000, or Badgeopolis. A backpack prototype that’s as important to you as that backpack with the flippy cover so you can show whatever super hero you want to. It will be a concept car like experience that will help guide future backpack crafters and seed the world of post it-just-stores-badges backpack thinking.

Exciting, yeah?

We hope so. Open Badges is taking off. We’ve proven to issuers that they can use open badges to guide their learning communities. Let’s get the same level of innovation applied to tools for the learners. Let’s make open badges backpacks as diverse and personalized as real world backpacks. Why settle for badge storage? You’re way cooler than that.

Badgecamp ’13!

The Open Badges team is going to spend a few days in retreat mode, stepping away from day-to-day work to think through what we’ve been up to for the past year, where we want to go and the best way to get there. It’s a welcome change, we’ve run full speed since January. First to the 1.0 launch of the OBi, and then to release Chicago Summer of Learning. We need a chance to slow down, raise the periscope and figure out where we’re at.

Back in early June, Erin presented a vision of where Open Badges could go to the Mozilla Foundation board (slides). The work that the team agreed they wanted to explore pre-badgecamp all fits in with the concepts outlined in the board slides. We split the (growing) Open Badges team into smaller focused groups, and divided up the work. The goal is to have something to demo or present at badgecamp. By the end of camp, we’ll have a solid roadmap for the next couple of months. The rest of this post is me explaining my thinking on the pre-badgecamp projects, as preparation for the big get together.

Chicago Summer of Learning Learnings

From the launch of OpenBadges 1.0 in March until June, the badges team worked with the City of Chicago (and others) to launch the Chicago Summer of Learning. The largest citywide open badge system ever. The project and outcomes are worth a post of their own, so for now I’ll say that it was a difficult project. Tremendously rewarding, super important for the city and for the open badges ecosystem, but taxing for sure. There are lots of details to discuss coming out of the project, and we’re planning on spending at least the first day of camp talking them through.

We learned a few important things. First, what it means to build a product for a community that doesn’t know you and hasn’t already bought into the concept of open badges. We’re fortunate to have worked with a very supportive open-minded community up until this point. Our backpack has UX issues, the community accepts it and works with us to fix it, someone finds a bug, same thing. With CSOL, we put our work out in front of a large group of people who weren’t interested in us, they support the product. It’s an obvious lesson, one that we’ve all experienced individually, but as a team – it was a first. A very valuable lesson.

Second, design driven development is what we’re best at, and it’s not worth trying to deny or reinvent the system. I tried to shorten the development time by running broad design in parallel with the site development. It was a worthwhile experiment, but ultimately proved that we should take time up front to make fundamental design decisions. It doesn’t mean we’re running a waterfall project, but it does mean we need to have a solid handle on what we want to build before we just start building stuff. Think of it as agile with a slightly more cautious first week or two of up front work. At camp, >Jess will get to say, “I told you so” for no more than 3 minutes.

Like I said, there’s lots of learning from the project, I don’t want to spend this entire post figuring it out, so I’ll leave it for now with a third (and final) CSOL takeaway – building a team that invents things is different from building a team that executes based on a pre-existing template. The fact is, the badges team is a team of deep thinkers who are amazing at proving or disproving the validity of an abstract idea. CSOL was a problem solved largely by elbow grease, phone conferences and grinding out code. I’m excited that the core open badges team is moving back towards designing the future of badges. We’ll find more sustainable ways to execute the next CSOL level project that don’t cut into the kind of work we’re good at.

The Backpack

The Mozilla Open Badges Backpack has been online for a year and a half now. It’s allowed users to collect over 100,000 badges so far. It’s an important piece of software, what’s next for it? It’s a big topic, so we divided into two teams – a “what do we do with the backpack now?” team, and a “what will the backpack be in the future?” team. It’s possible, actually pretty likely, that those two teams are actually working on two separate products, that the second team will conceptualize something that’s way different from the current backpack. I hope they do. Innovation in the open education world is starting to level off. Everyone is developing things that are versions of something that already existed. I want to see this team propose something wholly different and wonderful, Willy Wonka level innovation. Wallpaper that tastes like fruit. That sort of thing.

On the other hand, the current backpack has 100,000 badges! That’s a pretty big responsibility. Here’s the thing though – if you’ve been on a community call in the past year or so, you’ve probably heard us refer to the backpack as “a reference implementation.” The implication is that the Mozilla backpack is just something to prove a concept. That’s not the case anymore. People are using it, they’re collecting important information about themselves there, we have to treat that with respect and make sure they have the best possible experience. The first step is to clean up the implementation. Fix long-standing bugs, monitor production in a way that makes it easier for us to find bugs before our users. A lot of the thinking around the operationalization of the backpack comes from the launch of CSOL. We learned a lot about quick launches and monitoring in the run up to CSOL, we’re applying that thinking to the backpack now. There’s plenty more in the works as well, including another pass at UX / UI enhancements. We saw a huge improvement with the 1.0 launch, we’re due for another overhaul, both to streamline badge earners workflow and to match the branding we established back in March. We want our backpack to be a place that encourages users, not challenges them.

Open Badges Infrastructure

For 1.0, Brian nailed signed assertions, a revised assertion spec that allowed alignment to standards and a slew of other extensibility features and opened the door to alternative authentication systems. Atul prototyped Backpack Connect, a backpack specification that gives users the ability to directly connect trusted issuers to their backpack, allowing the trusted issuer to put badges directly in the users backpack.

Next on the list is Federation, best described as “the user has a backpack someplace, their badges should go there.” Federation implies two things (maybe more), 1) a backpack has a standard interface that it implements at a minimum. Things like “accepts badges”, “authenticates a user”, “authenticates a badge” are all things that a backpack should do. Without a common standard of backpack behavior, we can’t treat any backpack like any other. 2) If there’s a bunch of backpacks out there and a bunch of issuers, and a user earns a badge on some issuer, how does the issuer know where to send the badge? At its simplest, the user would tell the issuer where their backpack is. We’re discussing (animatedly – it’s kind of a hot topic now, which means its fun to talk about) some sort of magical directory service, that’s both distributed and centralized enough that it’s easily discoverable but not a dumb fat server sitting out there in the world. When you combine the two pieces, you get an infrastructure that supports the holy grail of badge issuing, “I have earned a badge from issuer x, it goes into my backpack (that I host on my desktop) magically, but safely and verifiably.” That’s the story I’m interested in building. When it’s done, and you peek behind the curtain, it’s probably going to be strange and unmagical, but on the surface, I want the user to know as little about their backpack as possible, as little about the issuer as possible and everything just comes together. We’ve been compiling research here, and plan on presenting a version of what we want to build to the openbadges-dev list soon.

The flipside of the Federation coin is Discoverability. What interfaces can an issuer give that makes their badge offerings discoverable by indexing systems? A tangent, but related idea – what opened standards are already out there in the world that we should use in the OBi? I started a small list here but am sure it’s only a start. I’d like us make sure we understand the geography of the various groups out there pursuing similar goals. My guess is, things like discoverability will be easier to execute if we borrow from other similar standards, which will also make the OBi more interoperable with existing products and services.

There’s More

We’re getting serious about product marketing, communications, partnerships – all the things that can make or break a large project. We’re going to start issuing our own badges (I know, right? We sort of missed that one. Heh.). We’re going to figure out who we can play with and how. There’s a lot of things we’re going to talk about at camp, I focused mostly on the tech things here. It will be an epic week, we’re all very excited to come back to the real world and share what we figured out together.

A Webmaker User Story in the Wild

As Mark explains, it’s Webmaker Planning Season, which includes writing user stories for where we want to take Thimble, Popcorn Maker and what we build to tie it all together. A really fantastic real world user story appeared over the weekend, courtesy of Notch and his army of followers.

It started with Notch tweeting about something he was experimenting with,

Then he finds a similar experiment from Mr.doob,

If you liked that, @ made a Minecraft type renderer using WebGL:
Markus Persson

And a conversation starts around the code, licensing and aesthetics.

Soon, a fan posted a Youtube video that explores Notch’s original code in detail. Notch moves his example to another community site similar to JSFiddle, but with social bits baked in.

Spent most of today learning new stuff. Ported Minecraft4k. Code is awful due to the nature of the project, but here:
Markus Persson

Why’s this like Webmaker?

Notch posts something he’s proud of, gets feedback from his peers (ignoring the fact that Notch is without peer for the purposes of this example), the community dives into his code and explains it to each other (the Youtube video), others remix or build off the original code (Mr.doob, I’m altering history here and pretending that the doob code came after Notch’s original post, artistic historical license).

The whole goal of Webmaker is to bring people together, show off what they’ve learned, help each other learn and get excited about making the web.

That’s cool, so how does Webmaker improve on it?

Right, that’s the big question. Everything you saw above happened today without the involvement of Webmaker, so what are we bringing that will improve it? A few things – in convenient bullet form,

  • Make it explicit – Notch learned something, he shared the learning and others built on top of it. Notch’s experiment, regardless of whether it’s on Thimble or JSFiddle, belongs in a gallery where it’s easy for others to find, share and remix.
  • Make it live beyond today – Twitter tied it all together. Twitter emphasizes real-time, it would be difficult to recreate this chain of events a year from now. It would be even more difficult to recreate the chain if a personality as large as Notch hadn’t initiated it. We need to see this chain of events as a unit without detective work.
  • Build and acknowledge reputation – the video commentator is a bit anonymous in the chain. He did significant work, and will help scores of learners make sense of Notch’s code. He deserves recognition for that work in a way that pushes his career, or gets him reputation in a community. (In short, give that guy a badge)

What should we build?

In this context, what is Webmaker.

  • A series of tools, Thimble and Popcorn Maker lead the way.
  • A gallery, currently in the planning stages, but we’re looking to build much more than a listing of projects. The gallery needs to fit a variety of roles, it should show what you made, what your friends made, and what everyone aspires to make.
  • Social‘y stuff. Take the conversation around a made item to the social network you choose, find better ways to let the work flow back and forth between tools and networks.


How are the Firefox people going to tie all this together? I love Firefox, it’s my browser, but Mozilla isn’t just Firefox. Mozilla has a manifesto. We, Mozilla, are more than the sum of the people who get a Mozilla paycheck. We’re a world spanning community of contributors and zealots that believe working in the open has meaning beyond the products we produce. Mark Surman and Mitchell Baker say that very product has a semi-secret payload – Firefox’s payload was belief in the open web and open source and open standards.

The payload for Webmaker is still being worked out, but my take on it is that we build  together. We learn from each other, we make each other better than what we could be alone. Given that, everything on the web deserves a button that let’s someone else remix and comment on it in whatever way they see fit. The act of creation should encourage more creation, not just consumption and +1′ing.

It’s entirely possible to take all of this and make a product that fulfills basic requirements, and doesn’t worry so much about secret payloads and manifestos – but that would be boring, and unsuccessful. Mozilla doesn’t work in boring, we work on big stuff. The success of Webmaker is a world where the internet is writable, everywhere – and by extension, the world is writable, everywhere.

For more on the make the world writable idea, watch the Mozfest 2012 keynotes.

Building the Platform to Teach the Next Generation of Webmakers

New software products start with a vision, solidify as a product plan, and are fully realized through design and engineering. A few days ago, Mark wrote about the clarified vision of Webmaker, then Erin followed up with what that meant to Webmaker as a product. This post is about that third corner of the triangle, the implementation. I’ll mostly focus on how Webmaker has affected the architecture of Mozilla Foundation projects, which means Jess is on the hook for a post about Webmaker design Jess writes about the design over on her blog.

The rest of this post steps through the key changes we’ve made in how we work, what we work on, and how it all fits together. If you’re interested in contributing to Webmaker as a developer, this is a good overview, you’ll need to jump into the mailing list if you want to start contributing code right way.

I didn’t read any of the prerequisites

If you didn’t read the links above, here’s the story so far — The Mozilla Foundation wants to teach people how to make the web. Mozilla Webmaker: a quick way to make, remix or tweak a webpage or 
video while learning how the web works.. This means that the bulk of projects the Foundation has been working on now fall under the Webmaker mission, Thimble, Popcorn Maker, are all Webmaker tools. As someone progresses in their mastery of the tools and concepts, they earn Badges which they push to their Backpack, which will one day help them figure out the next thing they should learn. There’s really more to it than that explanation, you should read Erin’s post.

Team Quilting

If you looked at MoFo projects in the beginning of the summer, you’d see teams dedicated to a single project, each with their own platforms, project management tools, testing practices…islands of development that all got along, but mostly worked independent of each other. The teams got a little closer in the June / July push to Thimble, but we had to really squish the islands together to start working on Webmaker.

Lots of organizations would just give up and die at this point. Not MoFo, the developers here are the most easy going, open minded people I’ve ever worked with. This wasn’t an exercise in protecting turf, from the beginning it was about figuring out how to make the large vision that pulled all our products together work. There was negotiation, but every negotiation ended with compromises that each team was happy with. It was way smoother than anyone could have anticipated. These are some great people.

Scary MoFo’s

The biggest decisions we had to make,

  • Server side platforms aren’t uniform, should we push towards a common platform?
  • We track bug’s and features all over the place, do we unify the bug trackers?
  • We manage the projects in the individual bug trackers, how do we express cross team dependencies?

The answers to the above are kind of obvious, not super complicated, but still took a couple of weeks to work out. Picture a montage of lot’s of discussions about tools, failed attempts to organize with the wrong tools, wrong approaches to the right tools, all ending in a giant group high five freeze frame.

Here’s where we ended up,

  • Asana tracks the projects, specifically new features and daily tasks. Asana is where the engineers go to figure out what to work on next, and where the product teams go to figure out what should be built after that. It’s a great tool, really well thought out, and easy to use. We still need to work out the details of what it means to work in the open, and build a community around the development of the products with Asana, but we’re confident we’ll figure it out.
  • The whole development team meets with the whole product team once a week. By the end of the meeting, engineers know what they’re working on until next week’s meeting. Sounds ideal, right? It’s a total lie. It’s not this easy. It’s a bunch of work. Every completed task is a victory worthy of a million high fives.
  • Server side decisions are still up to the individual product teams, but a series of services will decouple the architectures enough that there’s no advantage to unifying the platforms. Which means we’re still proudly a Djangoplaydohpythonnodejsexpressmysqlmongodb shop.

The Webmaker Roadmap in Asana

Services We Need to Build

Once we had the logistics of how we were going to work as a team worked out, we started talking about what exactly we were going to build. This is going to be an on-going conversation over the next couple of months, but we made a few decisions immediately that we’re moving on now.

Single Sign On – If you sign into your account on, you should be signed into automatically, and you should be able to manage your profile (including seeing what badges you’ve earned) on Persona manages authentication, but we need a service that authorizes an authenticated user to an application, and keeps the user logged in across apps.

Open Badger – I’ve written about it before, but to issue badges across the applications, we don’t want to duplicate the work of creating and maintaining badge systems.

Unified Publishing – All of our projects publish something, each of them use different storage systems and different security models. If we offer publishing as a service to our tools, we can consolidate backups, consolidate security and make developers feel are warm and special.

Project Database – Before you start working with a tool, you pick a learning project. The projects are described in a couple of different ways. If you want to make a list of available projects across tools, it’s not easy. It should be easy. The same goes for making a list of everything everyone has ever published with the tools, or anything a single user has published with the tools. We need services that make these queries simple.

Make it all look good – Not really a service, but everything needs to look like it’s all one. Jess, Chris and Kate are way on that. They already have a three stage information architecture in mind, and the start of a style guide. We’re still developing new stuff as they figure out the design, so engineering is working really closely with these folks to keep things fast and loose.

Make it work for everyone – Webmakers cross languages, cultures and devices. We need a common way of internationalizing, localizing and making the apps and sites accessible to a variety of devices.

Build it Right

We’re going to bring a lot of new work to Mozfest, some will be in production, some will be there purely to get feedback. It’s going to be an amazing couple of days. MoFo engineers are going to spend the time working with people working with their tools, figuring out how to make them better. MozFest is our next big milestone, it’s also our next big proving ground. We refuse to release bad products, so all of our timelines are based around the question, “how much time is it going to take to put something out that we can all be proud of?” The best way to figure that out is to start working and see how things shape up, if you want to be part of the discussion, join the Webmaker mailing list, or join our weekly community call.

Badger Glue

A few days ago, Mark Surman wrote a blog post, Making tools for webmakers. I love the opening line, “We want everyone to tap into the full creative power of the web.” That’s a great mission. The rest of the post is a review of what we’ve done towards that mission so far, and some direction for the next few months. We’ve been talking about the ideas in the post inside of MoFo for some time now, trying to figure out what’s missing from the tools, what it means to learn on the web, and how to support the teaching goals of the Foundation with the software the Foundation is producing.

I’ve been focused on the idea that we need a central framework to hang all the learning pieces MoFo is producing off of, so that there remains a large amount of flexibility in the ways someone can interact with our tools, but without having to recreate a significant amount of architecture with each new tool feature.

Some constraints (fun-ppurtunities!) I had in mind,

  1. We want lots of data around the effectiveness of the learning.
  2. We want to give people a learning path, but also let them mess around on their own.
  3. Features should speed time to release, not throw up more roadblocks or add to the workload.

A Webmaker Project

The Summer Code Party is using Popcorn Maker and Thimble for most of the online webmaker activities. Both tools have a similar project pattern,

Pick a Project

Both Thimble and Popcorn start picking a project.

Pick a Thimble Project

Pick a Popcorn Maker Project

The metadata carried with the project is different, the assets are different, but the essential thing you’re doing is the same – picking something from a list of options, with information about what you’ll be doing in the project.

Work on the Project

The learner works on the projects inside of the tools.

Inside Thimble

Inside Popcorn Maker

Publish the Results

After the learner finishes the work, they publish. The publish step is similar in both tools, with Popcorn requiring a user account, but no user account for Thimble. The Popcorn team has had a gallery in the works for a while, which will change the way we publish projects, creating a gallery of published projects. Thimble has similar gallery in mind, but only publishes the finished project.

Thimble Publish Dialog

Popcorn Publish Dialog

Modularize all the things!

Given the similarity between the two tools, it makes sense to break out the common parts into modular tools you can mix and match to build future webmaking tools. The two obvious pieces are the project builder, and the gallery tool. In both cases, they’re responsible for either creating or displaying blobs of html & static assets. Both contain tool specific metadata, but they’re not so wildly different that we couldn’t make a base tool to create as much as possible, then extend it to include the tool specific bits. The gallery is the essentially the same thing – display a bunch of output html, plus some static assets.

All that said, it’s not a slam dunk, the details are…the details. There’s a fair amount of work contained in these humble paragraphs, so buyer beware. Let’s focus on the positives – if we’re working off a common codebase, we save time and energy. If we deploy these things as services, then we only need to work through security audit once. The bulk of our time should be focused on making the learning tools awesome, not recreating a gallery or a login system or a whatever. We’ll have all the lego pieces, if we build the sockets right, every day will be an exciting lego land adventure, rather than constant weeding and tending and digging.

OpenBadger, gluing it all together

So – lots of moving parts, everyone wants modular pieces, how do we glue it all together?

Badger Glue Fixes It All

The three parts to any webmaker project – pick, make, publish, match the three pieces of a badge pretty closely – criteria, evidence, assertion. The criteria are the list of things someone needs to do to earn the badge, the evidence is the result of them doing what the criteria asks, and the assertion ties it all together in badge form. The intent of the three pieces is to create a badge, but it’s not strictly necessary. We could use the three pieces as the scratchpads that each stage in the webmaker process looks to understand the context around the step it’s being asked to complete. Each of the three major pieces could be built on top of OpenBadger, like this convenient ASCII drawing illustrates,

 +-------------------+    +--------------------------+ +-------------+
 |                   |    |                          | |             |
 |Create a Project +-|----|-> Do the Project +------>| |Publish      |+--------------->  MASTERY!
 |/ Pick Project     |  + |                      +   | |             |        +
 |                   |  | |                      |   | |             |        |
 +-------------------+  | +--------------------------+ +-------------+        |
                        |                        |                            |
              |         |                        |                            |       |      
              |         v                        v                            v       |
              |                                                                       |
              | Create Criteria URL           Ping Complete              Confirm      |
              |                               Evidence URL Created       Issue Badge  |
              |                                                                       |
              |                                                                       |

Arrows pointing to OpenBadger are either webhook API calls, or posting next-step metadata.

By splitting the direct connections between the pieces, and passing them off to OpenBadger, we can leverage OpenBadger for all sorts of clever analytics – regardless of whether we’re offering a badge for a particular project. That’s an important note – OpenBadger doesn’t need to limit itself to issuing badges, it’s a platform for any sort of learning activity, if we use it in a way that makes sense. OpenBadger isn’t about issuing the sticker at the end of a process, it’s about keeping track of the steps involved with an online learning project.

The most Meta of Metadata

We’re not the only people in wide world web looking to make exchanging education data easy, LRMI is a Creative Commons project to bring common metadata to learning resources. If we use LRMI as a basis for our criteria url’s, and then extend it with tool & display specific information, we’ll be able to take advantage of other LRMI parsing infrastructure (like the Learning Registry).

Next Steps

Over the next week or two, we’ll be discussing the plans for Webmaker tools, and start working on making everything fit together in early August, with a launch of all kinds of new stuff for Mozfest London in November. Between the Thimble, Badges, and Popcorn teams, we have some super smart developers. I’m hoping they tear this blog post apart, rebuild it in a way that makes sense to them, so we can start pounding keyboards in dramatic software development montage sequences that end in high fives, hugs, and exploding fireworks over Big Ben (because we’ll be in London…get it?)