2015 so far and looking ahead

2015 hasn’t exactly gone according to plan.


I began the year with a strong plan in place for personal development and skills building. That plan was derailed when the New England snowpocalypse happened. I became homebound for nearly two months, and depression set in. (It’s amazing how losing access to infrastructure impacts mental health. There’s something to be said for the interrelated nature of personal metabolism and community metabolism.)

Once the snow finally began to melt, I reemerged with a serious case of general anxiety the likes of which I haven’t experienced in years. I suffered from anxiety most of my life up until 2010 when I found help and subsequently beat it. This Winter brought it back, and combined with my executive dysfunction issues from my 2002 head injury, there was no way I was in any condition to find a productive groove nor work towards goals with any consistency. So my number one priority became to seek help!

Medical Agency

Since I moved to Boston, I hadn’t actually taken the time to establish relationships with new doctors, so I’ve spent the past few months doing just that. The act of engaging the healthcare system with all its quirks has been its own brand of therapy. So far I’ve seen a dentist (and it didn’t work out, so I’m looking for another), found a PCP I like as well as an ENT specialist, and finally found a psychologist I can work with! Hooray! Progress!

I’ll probably be writing more about my health in future posts. There’s a project brewing here that combines my personal health with my professional/activist interests around personal data ownership infrastructure, and I can’t wait to start sharing!

Focusing on my health hasn’t been the only thing I’ve been working on however.

Code for Boston

At the beginning of the year, I had a chat with Harlan Weber to say that I’d be stepping back a bit from my responsibilities as Community Lead to focus on my personal goals. At that point I was feeling a bit burnt out. At the end of April, we had a day long core team retreat to figure out the future of our brigade, streamline our collaborative processes, etc. By the conclusion of the retreat, I felt re-energized and ready to take on new responsabilites that we’d defined that weekend. In addition to many of the same community management activities I’d been doing, I also took on the role of ‘Scribe’, responsible for core team documentation. I immediately took over our collaborative Trello boards and have since discovered I have a knack for project management.

I’m really excited about what the rest of the year holds. After putting on two big events, and losing two of our core team members to life happening, we’ve decided we need to focus the rest of this year on the long-term sustainability of Code for Boston. We’re engaged in conversation with Code for America around the idea of ‘Institutionalization’ which is all about taking our brigade to the next level by figuring out how we can offload many of our logistical activities to paid staff. We’re not sure if this means we’re turning Code for Boston into its own non-profit, finding local partners, or starting a new organization that supports Code for Boston, but we’re heavily leaning towards the latter and looking to existing models in other cities for inspiration. In the mean time, we’re also going to begin working on leadership succession planning, diversity and inclusion efforts, and streamlining our documentation+processes so our members are better supported.

More on all this in future posts.


After six months off, I’ve become active again at Mozilla! I’d been hanging back since December to see how things would progress, and this thread started by Emma Irwin on the Participation Team’s collaborative process finally motivated me to dive back in. Since then, I’ve started working with Jonathan Wilde on a project called Gossamer, and next week I’m going to be in Mexico to work with the Mozilla Wiki Team at Wikimania.

Because many of my contributions to Mozilla have been invisible in the past (and because I have a terrible memory for most of it), I’ve started a blog specifically to track my daily/weekly activity. If you’d like to keep track of what I’m up to at Mozilla, check out http://mozillatracks.captaincalliope.net/

Working Open

One of the through-lines this year with all of the above has been documentation. I’ve spent a lot of time keeping and maintaining health records, making sure collaborative documentation is accurate and up to date, and documenting my own activities. While I haven’t been doing this all out in the open yet, I’ve been developing good record keeping habits, learning what works and what doesn’t in terms of practices and tooling, and as a side effect leveling up in my ability to work with others.

I haven’t yet revisited/renegotiated the goals I set at the beginning of the year, but I am working towards being more open in my goal setting processes. For the past two years I’ve run my life off of a private Trello board that I’ve recently refactored into a public one: https://trello.com/b/GrOdToFy/captaincalliope-overview

This is a big step for one of my major goals for the year: putting together a support network of peers and mentors. I consult this Trello board frequently as part of my overall GTD process. By making it open, I invite others to join me in my personal and professional development at a deep level with clarity around how it might intersect with theirs.

Expect to see me publishing more frequently in all areas of my work!

a new participation infrastructure project: Gossamer

I have a confession to make.

I’ve been a volunteer contributor at Mozilla for a number of years now.. and during this time, I haven’t even begun to do the work that motivated me to join to Mozilla in the first place. I’ve made all sorts of excuses like needing to cultivate new skills, or thinking that Mozilla’s organizational culture needs to change somehow.. and then I can finally do the real work I’m here to do.

Well, I’ve been working to level up my skills and in the past year Mozilla has shown strong signs of becoming the organization I’ve been dreaming it could be! All the excuses I give myself are disappearing, and yet I still don’t feel ready to participate where I think I can make the biggest difference.

Maybe I’ve been looking a this all wrong. Maybe what’s missing isn’t something intrinsic to Mozilla as a whole, nor something within myself. Maybe what’s missing is a process, a clear contribution pathway for me to participate in the work I’d like to do within Mozilla.

The work I’ve long felt driven to participate in is facilitating the design of new architectures for personal data ownership and sovereignty. I want to help find answers to questions around what the web looks and feels like when your user agent is no longer a browser running on top of an operating system, but a networked ecosystem of devices, data services, physical objects, and contextual identities all tied together securely by open infrastructure you can choose to delegate to companies like Google and Microsoft, or completely host under your bed without loss of functionality or experience.

Like so many of the technical challenges facing Mozilla right now, working towards such a vision requires figuring out whether the chicken or the egg comes first. In Firefox, this often translates to Platform or UX. I see a path towards the web I want that begins with UX, but Mozilla doesn’t really have a viable contribution pathway for volunteers (especially non-coding volunteers) to participate in proposing ambitious new browser features.. especially features tied to a longer-term vision. Rapid prototyping is difficult because not only would I have to recruit a developer, but technical overhead is also a barrier (the dev environment, learning how to create browser extensions which often means learning some XUL, etc) for whomever I recruit. And don’t forget the step of sharing an experiment with Mozilla UX to vet the idea and make the case for getting it into Mozilla’s bloodstream.

Provided a volunteer-driven project could get to that point, would the UX team even have the bandwidth to engage volunteers let alone vet and possibly champion their ideas? For my own efforts, I’m confident I could make this happen. I could totally recruit a team, build some prototypes together, and essentially create my own process for pipelining new experimental features into Firefox. But something about this pathway just doesn’t sit right with me. Other people should be able to participate through such a pipeline, but the process I could surgically create for myself definitely wouldn’t scale. Is there a more Mozilla way to do this that paves a viable path for others to follow?

There are many parts of Mozilla that face challenges like this where by increasing volunteer participation, staff would be stuck with the crippling administrative burden of processes meant to drive innovation. What’s needed is trailblazing participation infrastructure that empowers volunteers to largely self-administer their participation while at the same time transforming how Mozilla staff gets work done day to day. An integration of new processes and tooling that unlocks creative possibilities for volunteers and staff alike.

At the recent Mozilla Whistler Work Week, Mark Surman surreally illustrated the need for new tools by first coming on stage with an axe, and then later bringing a chainsaw on the stage. (Or at least, that’s what I think happened.. I was following #mozwww on Twitter and it basically looked like pure insanity. Never change, Mozilla.) To use Surman’s metaphor, the surgical process I described above is an axe I could build to personally accomplish my mission at Mozilla. (And no one should ever do surgery with an axe.)

For the past few weeks, I’ve been collaborating with Jonathan Wilde to build an experimental chainsaw!

Since the #Mozlandia work week last December, Jonathan and I have been talking about how the browser.html project could be used for more than just platform level research, but to bootstrap participation infrastructure that enables research and development in browser UX. A little over a month ago we began work on just that, and refer to it using the codename ‘Gossamer’. You can read more about the technical inspirations and details behind Gossamer on Jonathan’s blog.

We’re not quite ready to share a demo just yet, but we have enough momentum that we want to begin working in the open. We’re also trying to work via Heartbeat-style sprints pioneered by MoFo and recently adopted by the Participation Team.

We’d love your feedback as we work towards our first few rounds of demos! Join us on the irc.mozilla.org channel #gossamer, file some github issues located in the gossamer repo, and tweet at us via @CaptainCalliope and @hellojwilde!

Mozilla-wide Open Badge Systems and the Learning Organization

With an increasingly ambitious tech roadmap in motion, Mozilla has spent the past two years or so scaling up its organization with hundreds of new employees. As an organization that has traditionally been volunteer driven, this growth doesn’t come without growing pains. I’m not going to pick apart the theoretical nor specific challenges that come with this growth, but I will point out that for an organization as important as Mozilla, staying at the cutting edge of innovation requires perpetual change.

It is therefore imperative that Mozilla grow into an even greater ‘learning organization‘ than it has ever been.

In The Fifth Discipline, author Peter Senge identifies five characteristics of learning organizations that he describes as disciplines: personal mastery, mental models, shared vision, team learning, and system’s thinking.

If you’re unfamiliar with these concepts, the two Wikipedia links above provide pretty good overviews of the whole framework. I recommend reviewing them before continuing. (Protip: The second link is shorter!)

In a few mere days, the Mozilla Summit 2013 will be upon us. Many discussions will be had about Mozilla’s future, and I would like to share my thoughts on the central role Open Badges could play in it.

While the majority of the work thus far around badge system design has been geared toward personal learning, I believe the truly transformative potential of Open Badges will be unlocked when tools and best practices are established for organizational badge system design. In the future I’d like to discuss how this might play out in academia and civic society, but today I will focus specifically on Mozilla as ground zero (patient zero?) for the 21st century learning organization.

Here’s a breakdown of how I see Open Badge system design relating to each of Peter Senge’s five disciplines within the context of Mozilla. All quotes come from the Wikipedia article on the ‘learning organization’ linked above.

Personal mastery

“The commitment by an individual to the process of learning”

Right off the bat, Open Badges comes in strong as a system built around individual learners!

“Research shows that most learning in the workplace is incidental, rather than the product of formal training, therefore it is important to develop a culture where personal mastery is practiced in daily life. A learning organization has been described as the sum of individual learning, but there must be mechanisms for individual learning to be transferred into organizational learning.”

There are far too many organizations that don’t invest in the personal growth of their people. Organizations can use badges as a building block in building an internal culture of personal mastery by offering meaningful badges with pathways toward increasing personal agency. I think Mozilla is off to a great start here with fantastic teams prepared to deliver on this very promise!

Mental models

“The assumptions held by individuals and organizations are called mental models. To become a learning organization, these models must be challenged.”

This is where things start to get meta. I believe the process of creating badge systems within the context of an organization can help reveal hidden assumptions. Doing so might also help to entrench them, which would make the application of badges a double edged sword that amplifies both good and bad organizational habits. To mitigate such effects, internal badge systems should always be under review. New analytics tools can be built to facilitate these processes.. but even more important is keeping the community discussion going.

At this point, you might begin to suspect that organizational badge system design is not just a facilitated process, but a process of facilitation. Powerful stuff.

Shared vision

As a mission driven organization, this is where Mozilla shines. As an organization driving change within a rapid industry that actively drives some of the most unprecedentedly rapid change in the history of our civilization.. it’s easy to see how our shared vision might become misaligned from time to time. That’s ok! This provides opportunity for Mozilla to lead by example!

Shared vision (or lack thereof) informs mental models, and should therefore inform badge system design. Whereas there has (and continues to be) tons of awesome conversation around new processes for aligning badge systems to new or existing learning standards, alignment of badge systems to shared vision is a whole ‘nother level!

If there is one question for Open Badging Mozillians to take away from this post, it’s this: What are the processes we need to put in place to ensure our internal badge systems align with our shared vision?

That is of course assuming we do have shared vision. If we do not, this project could get a bit messy. And that’s a good thing! If our organization is misaligned, badges may serve as an indicator. A validation test of sorts for non-software processes within the organization.

Keep in mind that many of our internal badges can (and should!) also align with external learning standards. As badge ecosystems pick up in number and sophistication, we want to adopt badges internally that our community can meaningfully use in contexts outside of Mozilla.

I propose a rule of thumb: When possible, individual badges should always align as closely as possible with external learning standards, while badge pathways should be optimized for alignment with shared vision.

Team learning

“The accumulation of individual learning constitutes Team learning. The benefit of team or shared learning is that staff grow more quickly and the problem solving capacity of the organization is improved through better access to knowledge and expertise. Learning organizations have structures that facilitate team learning with features such as boundary crossing and openness. Team learning requires individuals to engage in dialogue and discussion; therefore team members must develop open communication, shared meaning, and shared understanding. Learning organizations typically have excellent knowledge management structures, allowing creation, acquisition, dissemination, and implementation of this knowledge in the organization.”

Another of Mozilla’s historical strengths! Now that staff is growing by near an order of magnitude, Mozilla’s larger community of volunteer contributors should theoretically be able scale up in kind. Open Badges have a clear role to play here in onboarding new contributors as well as new leadership development.

I propose that badge system work shouldn’t be the responsibility of a single group, but of the whole organization. While Open Badges inherently facilitates mentor relationships, it can also facilitate documentation processes as a form of documentation itself. Over time, badge pathways accumulate data that represents institutional memory. In the same way it should be everyone’s responsibility to maintain the organization’s documentation (and therefore history), it should be everyone’s responsibility to maintain badge pathways relevant to their ever-changing roles so others can either follow in their paths or deliberately tread new paths of achievement. Learning at every level of the organization thus becomes a tapestry of interwoven stories of birth and renewal that can be tangibly referenced.

Most importantly, defining badge pathways within the context of a learning organization is a governance activity. As the discussion around Mozilla’s governance processes evolves, I predict badge pathways will become central. This reason, more than any other, is why everyone involved with Mozilla (and especially staff!) should be perpetually involved in the evolution of organizational badge systems.

System’s thinking

“This is a conceptual framework that allows people to study businesses as bounded objects. Learning organizations use this method of thinking when assessing their company and have information systems that measure the performance of the organization as a whole and of its various components.”

System thinking is Peter Senge’s proverbial ‘fifth discipline’. As a mission driven organization, Mozilla’s success is often defined by non-quantitative measures. By applying badge systems and building tools to manage and analyze badge pathways, Mozilla will gain an unprecedented toolkit for transparent understanding of the organization as a whole.


General takeaways to consider!

  • The act of designing badge systems can help bring humanity to organizations!
  • Internal badge system design is not just a facilitated process, but a potentially core process of facilitation.
  • Badge system design is an act of organizational alignment around interlinked activities. Everyone should be involved.
  • Alignment of badge systems should happen along two dimensions: alignment with learning standards that benefit the individual, and alignment with shared vision that benefits the whole.
  • Badges and badge pathways can be a form of process documentation that accumulates data which forms a transparent landscape from which institutional memory can be engaged.
  • Badge systems stewardship is an act of organizational governance. Everyone should be involved.

I think Open Badges can play a major role in building 21st century learning organizations and Mozilla is well situated to break ground making this possible.

More importantly, Mozilla is in a critical transitional period with many challenges that I believe Open Badges, as a tool applied within larger facilitation processes, can help navigate. The concept of badge pathways may provide a framework for systemic alignment of personal, organizational, and technical roadmaps.

on Webmaking Science

Since the end of October, Mozilla has had an open Directorship position for something called the ‘Webmaking Science Lab’. Other than this posted opening, I can’t seem to find anything written on this project. My assumption is that this is an idea that hasn’t been developed much beyond the recognition that ‘open science’ is an important area lacking critical open web infrastructure.

I’ve been eyeing this open position since the holidays, and I’ve decided to throw my hat into the ring the only way I know how: by starting to hack at it! And if someone else gets the position, hopefully I’ll have helped get them started with their awesome new job!

Apologies to peeps at the Mozilla Foundation if this turns into a case of awkward overstepping.. but it’s all about the love! <3

Where does Knowledge come from?

Mozilla’s Webmaker program is concerned with setting a high standard for web literacy and connected learning. I think Webmaker is an integral program for figuring out solutions to the problems identified in the recent Connected Learning Report because the way in which knowledge is modeled in the human brain mirrors how the web works: like a directed graph. Moving toward an educational paradigm that ‘works like the web’ also has the benefit of ‘working like the brain’. This is both personally humanizing and validating of the global brain theory.

But if open web conventions become the default means by which we encode our civilization’s understandings of how the universe works, how do we integrate the beginnings of understanding into the (social and technical) architecture of the web? How does the scientific process fit into the picture?

This is the question that underscores the idea of a ‘Webmaking Science Lab’ and I’m glad Mozilla’s asking! This is a really important question!

Oh, and it’s made of pure awesome!

Stand back, I'm going to try Science!

Webmaking Science Lab

And so it makes sense for the Mozilla Foundation to create a new ‘Open Lab’ in the tradition of HiveNYC, OpenNews, and OpenArt to investigate this question. And it makes sense to associate this Lab with Webmaker because at its core, science is about the creation of interconnected bodies of literature that encode knowledge and lead to learning. Scientific papers have been linking to each other before the web even existed.

But as our education system is breaking down, so are the research institutions associated with it. And it’s not just the economic models supporting scientific research that are in need innovation, but the way in which science is conducted itself. In fact, I just spent half an hour looking for some links to support these two assertions, and decided doing so would completely derail where I want to go with this blog post! Holy crap, there’s so much! I may come back to break these down further in a future. For now, let’s just say the opportunity space is VAST!

Finding starting points

I have a hypothesis: Figuring out the models that will make open science thrive is a prerequisite for solving the challenges that currently face journalism.

Given that science journalism generally sucks, I think the work OpenNews has done in their Source project would be a great way to build connectivity between the budding world of Open Science and innovative storytellers with global distribution.

Peter Aldhous of New Scientist has a profile in Source and an article published there, ‘How We Made “Your Warming World”,’ which explains the creation of an awesome interactive work of science data journalism!

Great start! Peter: I’m not even sure if I have any authority to make a statement like this, or if it even exists as a real thing yet.. but welcome to the Webmaking Science Lab!

Another hypothesis:  Scientific fields studying the web will be amongst the best collaborators in figuring out how to make open science webby.

The historical trend in science toward specialization is rapidly breaking down as cutting edge science is increasingly happening through interdisciplinary collaboration. At the very center of the cutting edge of interdisciplinary collaborations lies Network Science. From Wikipedia:

Network science is an interdisciplinary academic field which studies complex networks such as telecommunication networks, computer networks, biological networks, cognitive and semantic networks, and social networks. The field draws on theories and methods including graph theory from mathematics, statistical mechanics from physics, data mining and information visualization from computer science, inferential modeling from statistics, and social structure from sociology. The National Research Council defines network science as “the study of network representations of physical, biological, and social phenomena leading to predictive models of these phenomena.””

There is soooooooooo much I could say about how awesome network science is.. but instead, I’ll post two videos featuring field luminary Albert-László Barabási.

Here is a mindblowing  TED Medical video where he talks about the applications of network science for medicine. (This is the sexy video!)

And here’s an hour long lecture entitled “Web Science Meets Network Science.” (I found this one sexy too, but your mileage may vary..)

If my hypothesis is right, this leads dangerously to the meta-ist of meta-projects ever undertaken in the history of humankind. Webmaking science tools built in collaboration with scientists weaving in and out of the growing body of network science could become some of the most powerful tools Mozilla will ever have to, for starters, create analytics for informing future radical developments in the core architecture of the open web. This is an incredibly amazing side benefit that would make the cost of entry completely worth it. But I digress..

When it comes to engaging the scientific community for the Webmaking Science Lab, the two clusters of people I would initially focus on would be those involved in Open Science activism and Network Science.

Third hypothesis: Webby tools for scientific modeling will be just as helpful for conducting original science (plus replication of results) as it will be for making new knowledge accessible to the masses.

This is what makes the connection to Webmaker so amazingly prescient, and relates to why I started out with my hypothesis regarding journalism: interactive simulations of systems are the future of storytelling and the propagation of knowledge. Right now, the application of simulations within science are primarily for the creation of knowledge.. but not so much the transmission of it. Instead, we get pdf documents, textbooks, and poorly written fourth-hand news stories. What if the tools for conducting science were also the same tools for publishing, sharing, and remixing the science?

My third hypothesis will be difficult to find supporting material for because this is the major technical work that has to be done: researching what’s out there and coming up with product ideas for prototyping. But here are a few projects I’ve run across that get my tickle my imagination.

Last week I ran across a Javascript library for chemical informatics and graphical presentation. It’s called ChemDoodle Web Components and is based on the latest HTML5 technologies.

Here’s a demo of this technology rendering 3d molecules within a very old version of Firefox for Android:

This is very cool, and I could definitely see how this could be the starting point for creating webby chemistry content. An academic chemistry paper could be fully interactive using this technology, and these same simulations could be made to be embeddable for journalists who want to strip away all the academic jargon in order to tell a a more compelling story. Then some kid in Webmaker elementary school could remix this same simulation for a class project in such a way that leads the original chemist to find a cure to cancer!

Hey, stranger things have happened on the web! Let’s see.. what else is out there?

There’s an open source toolkit for applied Graph Theory called TinkerPop produced by a company called Aurelius. Graph Theory is one of the major tools used in Network Science, and this group of products includes a tool for interacting with graph data via RESTful web services.

There’s also a javascript statistics library based on R called jStat. A project like this might go well with something like the ROpenSci project to create webby tools for statistical analysis.

Oh! And I can’t forget the Hypothes.is project which seeks to create a distributed platform for web annotation! This project is directly relevant to making the culture around science (via Peer Review) operate more like the web. This is an ambitious project seeking to create a system that could eventually become a core technology built into the browser. Based on what I’ve read, I’m imagining something like Google Docs commenting feature tied to Mozilla Persona. Frankly, this almost feels like a Mozilla project already!

What’s next?

One of my major motivations for writing this was to get people talking! So far, the only indication that the ‘Webmaking Science Lab’ is a real thing is the description accompanying the Directorship position. Call me overeager.. but I’ve been wanting to know more and how I can contribute! I bet there are others as well.

Seeing as the position hasn’t been filled yet, I figured I’d start working on a framework for identifying key problems and opportunities this Lab might seek to explore. I really REALLY like where this is headed.. so I’ll be polishing my resume this week. ;)

On a side note, I’ve chatted a bit with a few people from the Open Science Federation over the past month, and they also seem really excited about the prospect of Mozilla becoming a voice in the Open Science movement. (They also really helped me out when I was looking for subject matter experts for CrisisCamp! They’re awesome!)

Partnership and community building opportunities abound, and I think there’s a large community ready to jump into whatever Mozilla ends up doing within this space.

Why Mozilla? Manifesto and Milestones

This post is going to be the first in a series I’ll revisit from time to time answering the question: “Why Mozilla?”

A little known fact: Mozilla is an organization with a Manifesto.

It’s an inspiring document that outlines the principles upon which Mozilla operates toward fulfilling its mission of preserving a free and open web.

There is an ongoing dialogue at the Mozilla Foundation about whether the Manifesto needs revisiting. When I read the Manifesto today, I feel like it is just as relevant now as when it was first published.. but perhaps some of the language could be touched up to add emphasis on how the principles manifest in Mozilla’s efforts to tackle contemporary challenges that didn’t exist just a few short years ago.

I have no specific suggestions along these lines right now, but what I would like to do is discuss the expression of these principles in terms of major historical milestones and begin to explain why, frankly, I’ve become so obsessed with this organization.

Right now, Mozilla has three significant tent-pole projects: Firefox, FirefoxOS, and Webmaker. Each project delivers a milestone that builds upon and supports each other toward accomplishing Mozilla’s mission.

Firefox: The First Avenger Milestone

The initial release of Firefox set the web aflame. It ended the days of vendor lock-in to a stagnant web under Microsoft’s tutelage. In very measurable ways, it was Firefox’s impact on the market that led to the rebirth of the web in the form of ‘Web 2.0′ and social media. As a highly visible project, Firefox was a major source of mass contributing to the momentum of the Open Source movement. It proved that a purpose driven organization like Mozilla could have impact, and its creation made Mozilla a pioneer in the forms of open collaboration that 21st century organizations must adopt in order to achieve excellence.

I’d argue that only one other product has done as much as Firefox to advance the state of the web in recent years: Apple’s iPhone. It was Apple’s work on Webkit for the iPhone that launched the mobile web and mobile web apps before the iPhone even had an App store. Webkit also became the foundation of Google Chrome: an excellent browser worthy of Mozilla’s vision for a platform-agnostic Open Web.

Despite the original positive and high impact the iPhone had on the web, it quickly became a threat. Native Apps backed by cloud-based data silos circumvent and break the web. Google’s Android, despite being a more open platform, is not an Open Web platform and exacerbates this very problem. Although there has been talk of Android and ChromeOS eventually merging, Google’s ultimate incentive is not to preserve the Open Web but to organize the world’s information in the most direct way possible: by swallowing all the data.

Just as in the days before Firefox, vendor lock-in is the name of the game.

FirefoxOS: Scaling Kilimanjaro

As mobile OSs and native app platforms have taken over,  the ‘Web Platform’ has not stayed still. Between HTML5, CSS3, and advances in Javascript rendering engines, the web itself is rapidly becoming a viably cross-platform option for first-class app development.

Few in the technology industry truly understand what FirefoxOS represents. It is not just another competitor entering the already crowded mobile OS market.. it is the beginning of a new era in computing. The success of FirefoxOS isn’t dependent upon adoption of devices, but development toward a future in which Web Browsers and Operating Systems begin to blur.

Developing in parallel to FirefoxOS is Firefox itself. Both projects will benefit from the convergence of projects that began in Mozilla Labs including Persona, WebAPI, and Firefox Marketplace.

There was a thread early last year on the Mozilla Dev Planning mailing list by Damon Sicore titled “The Web as the Platform and The Kilimanjaro Event” which proposed a major milestone for Mozilla to work toward:

“The Kilimanjaro Event is the point in time (not a release) when we realize a tightly integrated set of products that enables users to use the ID of their choice to find and install Web apps from HTML5 App marketplaces–including one created by Mozilla–and have those apps and appropriate data synchronized amongst devices.  It is important to point out that the Kilimanjaro Event is not a single release.  It is an incremental effort where we deliver a series of releases and features to each of our products that result in and enable an end-to-end user experience across these efforts.”

While this may sound like Mozilla playing the vendor lock-in game, the difference is that everything is being built upon open technologies. If other vendors don’t eventually adopt and/or adapt these technologies toward a seamless end-to-end user experience that crosses browsers and operating systems, then Mozilla will have failed to replicate the original success of Firefox in preserving the openness of the web.

The key to scaling this monumental goal is an unprecedented alignment in Mozilla’s organizational capacities.. and Mozilla is well up to the task. The work that we see being done now toward launching FirefoxOS can be viewed as establishing Basecamp at the summit of Mount Kilimanjaro. This is only the beginning, and there is so much more to come.

However, FirefoxOS does not solve the ultimate problem of apps being a threat to the web. Apps still, more often than not, lead to silo-ed data.

Webmaker: Shooting for the Moon

If FirefoxOS represents the movement toward a high summit, Webmaker is the launch pad for Mozilla’s Moon Shot.

Through Webmaker, Mozilla is tackling the problems of online learning and web literacy. Webmaker is part software, part movement.. just like Firefox.

This may sound like it’s a new area of focus for Mozilla, but it’s actually a natural extension of the work Mozilla has been doing all along. Webmaker is about making the full creative read/write promise of the web accessible to the masses. This is about far more than just ‘teaching people computers': this is about things like personal security, socioeconomic opportunity, civic engagement, access to food and healthcare, and global security. Web literacy is that important.

As the Web Platform continues to advance, it’s important that we don’t get swept up into the world of apps thereby losing what makes the web so powerful. It may sound like I’m demonizing apps, but they have a saving technological grace: RESTful APIs! Combined with new technologies coming to HTML5 (Web Components, Web Intents/Activities, Web Sockets, etc), I’m convinced that Webmaker will become the platform that closes the loop between Apps, APIs, and the Open Web. I’ve written about this previously here and here, as has Atul Varma here, by Kin Lane here, and this thinking is already impacting Webmaker prototyping and roadmapping efforts.

In the same way Mozilla has been a leading voice in Open Source during the last decade, it will be a leading voice in Open Data during the next one. This will become apparent as many of the tools developed and delivered into the Webmaker product eventually find their way into the core of Firefox.

Where the success of FirefoxOS is predicated upon unprecedented collaborative alignment within Mozilla, the success of Webmaker will be based upon unprecedented collaborative alignment between Mozilla and the world at large.

It begins with personal data remixed to create personal stories, but it will soon expand to the organizational stories told in aggregate via the Apps that help us weave our webs of social (and cultural, political, medical, etc) interaction.

And that’s just the launch pad! At this point, there’s no telling what Mozilla’s actual Moon shot will be.

The end of the Web Browser

While writing this post, I ran across another blog post with the same title, ‘Why Mozilla?’ written almost two years ago by Allen Wirfs-Brock.

In some sense, this post is almost an uncanny mirror image of that one. In fact, he begins his post with the same conclusion I want to end on: we’re about to witness the end of the Web Browser.

The work being done around FirefoxOS and Webmaker together form something of a knockout one-two punch to followup Mozilla’s first act with Firefox.

Mozilla Persona brings identity into the browser and blurs the lines between user agent and user. The FirefoxOS ecosystem, in blurring the lines between OS and browser, will bring identity into the device.. mobile, and otherwise.

And so, the Web Browser as a technology gives way to the Web Browser as a person: a consumer of information via the first global unifying computing paradigm. This is a pretty bleak future.

And this is why the term ‘Web Browser’ must eventually be deprecated: it is an absolutely unacceptable state for humanity to be stuck in. We must aspire to be a world of Webmakers.

Why Mozilla? Because the mountain will be scaled, but preparations are already underway for us (all of us, globally) to reach for the Moon! Who’d want to miss that?

Markup APIs and the Read/Write Web

In my previous post on how Web Components should inform the Mozilla Webmaker roadmap I make mention of ‘widgets, buttons, and badges.’ The context behind this grouping of things is Kin Lane‘s exploration of ‘Embeddable API Strategy‘ contributing to his work on defining API Building Blocks.

When Twitter first came out with their suite of embeddable widgets, it occurred to me that this was a way in which  web services could be democratized for hacking by the masses. I haven’t seen very many web startups build comprehensive widget offerings on top of their APIs, but the ones I have seen often tweak my personal vision for what the web can be.

I also haven’t seen very much written on the best practices of building an embeddable API strategy, and I think this is because we’re still in the early days of the practice. I also think Web Components finally landing could be the catalyst that changes this. Every consumer facing company with an API will want to make their users data available for mixing into the web. And if they don’t, their users may very well do it for them. Either way, Apps with APIs will be growing veins into the rest of the web more and more.

Last week Mozilla’s Atul Varma wrote up some thoughts in a post titled ‘Building Bridges Between GUIs and Code With Markup APIs‘ which not only upgrades our use of ‘widgets, buttons, and badges’ with the fantastic term ‘Markup API,’ but adds some serious clarity to how Markup APIs can preserve the accessibility of a read/write web as the web continues to Appify. This is some seriously important stuff!

A few weeks ago, I sent an email to Kin Lane and some people at Singly to talk about some of these ideas and how Webmaker could be an opportunity to define an embeddable API strategy for the entire web. I targeted Singly specifically because of how their dedication to personal data ownership is leading the development of their ‘API Fabric’ platform which generalizes an increasing number of APIs into a single sane API for developers to work with. A Singly Markup API would lower the learning threshold for anyone interested in remixing all of their personal information together in new ways.

Check out all the web services accessible via Singly’s API explorer: https://singly.com/explore

Now imagine if personal data from all of these services were available within Webmaker via Markup APIs.

I think Singly would make an excellent partner on Webmaker for this and many other reasons. Kin Lane and I are going to keep developing these ideas to see if this is a real opportunity.

In my previous post on this topic, I suggested that the x-tags registry could be thought of as a prototype for a Thimble Widget Directory. I stand by this idea.. but seeing as things keep evolving, I’m now going to call it a Webmaker Markup API Gallery prototype. We’ll see how long this moniker sticks around.

Speaking of ideas continuing to evolve, the Webmaker team got together this past week for some intensive hacking and yielded some exciting new prototypes which you can check out on Brett Gaylor’s blog! They are all extremely exciting, but the thing that stuck in my head was the ‘Save for Later’ experiment which provides a potential vector for integrating Webmaker with Firefox through the collection of web content intended for remix. Markup APIs should definitely be a collectible content type!

Furthermore, it would be super cool if there was a way for a Markup API to declare an interface for being hacked on within Webmaker. Imagine for instance if the Popcorn Maker timeline UI element was a hidden part of every Popcorn video or webpage with Popcorn content. Webmaker wouldn’t necessarily need to have Popcorn Maker code within the core application because the UI module for editing temporal based web content would come with content.

In this way, the content itself, once collected, extends the UI of Webmaker within the editing interface for ease of editing. Webmaker’s UX could be infinitely extensible this way, and it defines an avenue for getting everyone with an API in on the Webmaker vision for an accessible read/write web!

Aside from integration with ‘Save for Later’ prototypes, there’s another area where Markup APIs can help integrate Webmaker with Firefox: through Apps.

If a user installs an App with an API into their web browser, that user should have automatic access to their personal data through that API. And if an installed App has a Markup API, those widgets should automatically be a part of that users Webmaker experience.

The implication is that with every single App you install in your browser/OS, your ability to learn and make the web should grow.