Product Thinking

Standard

I have a new job!  Still with Mozilla, still doing a lot of what I’ve done in the past, just hopefully more/better/faster.  The group I’m joining has a great culture of active blogging, so I’m hoping the peer pressure there will help me blog more often.

What’s the gig you ask? My new focus is to help the Mozilla Foundation make our products as adoptable as possible.

MoFo (as we affectionately call that part of the Mozilla organization) has a few main ways in which we’re hoping to change the world — some of those are programs, like Open News and the Science Lab, some are products. In a program, the change we’re hoping to effect happens by connecting brains together, either through fellowship programs, events, conferences, things like that. That work is the stuff of movement-building, and it’s fascinating to watch my very skilled colleagues at work — there is a distinctive talent required to attract autonomous humans to a project, get them excited about both what you’re doing and what they could do, and empowering them to help themselves and others.

Alongside these programmatic approaches, MoFo has for a while been building software whose use is itself impactful.  Just like getting people to use Firefox was critical to opening up the web, we believe that using products like the Webmaker tools or BadgeKit will have direct impact and help create the internet the world needs.

And that’s where I come in!  Over the last few years, various smart people have kept labeling me a “product person”, and I’ve only recently started to understand what they meant, and that indeed, they are right — “product” (although the word is loaded with problematic connotations) is central for me.

I’ll write a lot more about that over the coming months, but the short version is that I am particularly fascinated by the process that converts an idea or a pile of code into something that intelligent humans choose to use and love to use.  That translation to me is attractive because it requires a variety of types of thinking: business modeling, design, consumer psychology, and creative application of technology.  It is also compelling to me in three other aspects: it is subversive, it is humane, and it is required for impact.

It is subversive because I think if we do things right, we use the insights from billions of dollars worth of work by “greedy, evil, capitalist corporations” who have figured out how to get “eyeballs” to drive profit and repurpose those techniques for public benefit — to make it easy for people to learn what they want to learn, to allow people to connect with each other, to amplify the positive that emerges when people create.  It is humane because I have never seen a great product emerge from teams that treat people as hyper-specialized workers, without recognizing the power of complex brains who are allowed to work creatively together.  And it is required for impact because software in a repo or an idea in a notebook can be beautiful, but is inert.  To get code or an idea to change the world, we need multitudes to use it; and the best way I know to get people to use software is to apply product thinking, and make something people love.

I am thrilled to say that I have as much to learn as I have to teach, and I hope to do much of both in public.  I know I’ll learn a lot from my colleagues, but I’m hoping I’ll also get to learn on this blog.

I’m looking forward to this new phase, it fits my brain.

You are more than your job title

Standard

In grad school, I remember a conversation across the campus green with an visiting psychologist from Harvard.  I don’t remember much about the conversation except that he introduced me to Isaiah Berlin’s notion of the Hedgehog and the Fox, and correctly pegged me as a Fox.  I think I was a bit offended at the simplification, but time has proven him right.  I’m certainly no hedgehog.

I got into a silly argument on twitter last night, about whether my looking to hire someone who I labeled (as job descriptions make us do) a “Coding Designer” was not just foolish (I’d seen the Unicorn references in my tweetstream already) but apparently a bad idea, because, so the ultra-simplified argument goes, you somehow can’t be both.  And so I’ll use the energy to rant a bit about what seem to be prevailing attitudes around titleism and narrow definitions of “professionalism”.

We all need to define ourselves to others. It helps us be understood, and hopefully valued.  Labels can be useful for that. We also, even more, like to label others.  It helps us simplify our approach to them.  If I can find a label for you, then I can rely on a prioris about how people with that label tend to think and behave, and I don’t need to actually get to know you too much.  The more people we interact with, the more important these shortcuts are.  Some roles are particularly subject to that (Recruiters, VCs, politicians, etc. — people who routinely talk to dozens if not hundreds of people a day).  And the best at these roles are those who use a different labeling system than their peers.  Recruiters who see the latent ambition or genius in a shy candidate; VCs who see the determination behind a stutter, or, conversely, the lack of self-confidence behind the bravado, etc.

Labels are useful and practical in the short term.  And I don’t know how one could run a large HR department without them.  But we should be careful to not take them too seriously, as in the long term, they can hurt. They hurt because people, especially interesting, worth-getting-to-know people, are much more subtle, complicated, confusing and hard to categorize creatures.  Whether you take the label too seriously when thinking about others (e.g., refuse to see the valid opinion about a design expressed by a non-Designer) or about yourself (and limit your impact on the world because “oh, that’s not something that a mere ____ like me could say/do”), you’re not getting the most out of anyone involved.

As I write this, I realize that I feel quite strongly about this topic.  Part of it is probably because I grew up in an educational system, which at least then believed way too much in labeling people and determining their fate based on that label.  Much waste ensued.  Part of it is probably because I can’t for the life of me figure out what my label should be, and if I can’t, then that must be bad. I’ve had a range of professional labels, from scientist to engineer, architect, team lead, vice president, CTO, CEO, blah blah blah.  I’ve been called a designer, strategist, entrepreneur, boss, blah blah blah. None of those words will, I hope, be in my epitaph.  And so I get cranky on twitter at night, because if there are people who strive to be both excellent at design and at coding, then by golly we should encourage them.

Titles are a poor approximation of a professional ideal, and a profession is a poor approximation of a human’s breadth, contributions, and talents.  Embrace your inner fox, and if you happen to have both design and coding skills, can see a problem, conjure up a solution, prototype it, welcome challenges to your idea from peers, data, and users, apply.

Personal computing in a decentralized world: a hopeful direction

Standard

I’ve been having a really stimulating few weeks, which is making me feel oddly optimistic, so I figured I’d spread the cheer.

It’s been somewhat quieter than usual in my little corner of Mozilla, as many of my colleagues were busy preparing for on our big announcements and demos at Mobile World Congress. This lull has allowed me to spend more time indulging in longer term thinking.

In that thinking period, I’ve had the privilege and distinct pleasure of spending a few hours of quality videochat with none other than Ward Cunningham, inventor extraordinaire.  We’ve been talking a lot about his new baby, which he calls Federated Wiki (the name is misleading I think, but as with many new ideas, awkward names are better than long descriptions. The shortest analogy I can come up with is a space for personal writing that borrows the forking attitude from github, within a smalltalk-like conceptual model. — Confused yet?).  Regardless of the name, it’s both refreshing and stimulating to talk to someone like Ward about topics we both see as important and interesting, with a shared commitment to improve the status quo.  If you’re intellectually curious, willing to do some mental backflips and deal with fairly raw and unconventional ideas, I encourage you to watch the videos and play around with federated wiki.  It’s a worthwhile exploration.

One of the surprising ways in which that exploration is changing my brain is that I’m finally starting to care about hardware.  Until recently, I’ve been quite uninterested in hardware talk, both of the standard computer geek variety, as well as the internet-of-things variety. The former has felt no different to me than talking about fashion, and the latter always struck me as an industrial problem, not a human one.  It’s made sense to me that companies like GE were keen on the Internet of Things — i just didn’t really care, and the odds of billions of networked computers being a net win for the world seemed pretty slim — I’ll admit to a bit of an head-in-the-sand reaction there.

What’s changed my thinking (and let me to acquire handfuls of raspberry pis and pcDuinos for the office) is a growing belief that the economics of hardware manufacturing, the maturation of the open source stack and standards, and the mainstream adoption of “the cloud” are, in concert, going to provide interesting opportunities for networked computation “by the people for the people”.

The default path

It’s fairly easy to see that the big players in computing (Apple, Google, et al) are deepening their stack and broadening their scope — from software or services to software and services to hardware to phones to tablets to TVs and other consumer devices, to cars, eyewear, physical networks, wireless carriers.  The path ahead for them is clear.  And I’d say that the consumer experiences that will follow promise to be stunning. But if nothing is done about it, it’s also clear that this will happen through market concentration.  That concentration of power, economic influence and wealth is particularly problematic because it also implies a concentration in modes of thought, in cultural outlooks, in possible futures.  As I’ve written before, I think the world would be poorer if that happened.

All conventional indicators (especially those concerned with things like “eyeballs”) are in that direction, of course — large amounts of money make it possible to make shiny attractive things, as well as to identify attention-grabbing things in a sea of uneven quality.  Popular culture naturally gravitates towards superstars, be they pop stars, or youtube clips. We seem to be wired as people, societies, and markets to head that way.

Another architecture, and the economics that can power it

And yet I mentioned above that I was optimistic. That’s because while there are natural economic incentives for markets to create large companies, and for those large companies to concentrate attention on a few things which are safe, non-threatening, and profitable, the centralization forces are not the only ones at play, and not everything behaves in market-expected ways.   Clay Shirky has written and talked about this eloquently — sometimes we don’t need to do what economists tells us we should want to do.

You can now buy $35 full-featured computers which, within seconds of being plugged in, are fully capable internet nodes.  Within years at most the price will keep dropping and the capabilities will keep expanding. In addition, the open source software stack which powers them is the same which millions of web developers already know, and hopefully soon millions of amateurs as well.  In other words, the means of production  are being commoditized and democratized, and the network is ready to serve as a coordination layer for these devices.  I am not predicting a utopian world of DIY hardware running bespoke software written by each user.  Instead, I want to point out that the entire value chain for using the internet to do new things (from hardware to services) is now ripe for new, good ideas, even coming from single brains. The substrate for deeply personal web experiences is here.  I should also acknowledge Allen Wirfs-Brock’s recent writings on the need for a bigger picture plan here as helping me to process the need to actively shape the architecture of the connected things around us.

Much has been written about the impact of Big Data for business, but internet-available Personal Data could be just as transformative for individuals and small groups. I’d wager that a Raspberry Pi and a cheap drive can store all of the words I will write and read in a lifetime, do meaningful computation on that corpus, and be available to all of my internet-connected devices. That feels significant. When people routinely have that kind of agency over their stuff, and if their digital agents are well coordinated through a well-decentralized network, it’s easy to imagine just as futuristic and impactful but less commercially driven outcomes.

When compelling experiences that work thanks to a decentralized architecture emerge, I’m confident that many kinds of business models will follow, including consumer devices, services, and others. Some of those devices will run FirefoxOS.  All will have the web stack built-in. As important, these things (or virtual things) will be cheap enough that cost and profitability won’t be the primary consideration. Instead, you’ll think about what you, your family, your neighborhood, your community need.  I could easily subsidize a fairly powerful computing service for all the children in my kids’ school.  Larger foundations could subsidize the same on the scale of countries.  Combining Shirky’s cognitive surplus and insanely cheap delivery systems means we can be freer from the stranglehold of short term economic thinking.  Bring in network-enabled funding models like Kickstarter, and we can keep baffling economists and conventional investors for a long while.

The Product Challenge

The conundrum, then, is to find those compelling experiences which thrive on a decentralized architecture, and not just try to force decentralization on experiences which work well in a centralized model.  As a “product person”, I’ll admit that it’s not easy to  wean oneself from the dominant world view, which favors neatly bounded and hard, polished exteriors (metaphorical and otherwise), where control is critical to quality, and where complexity is managed through barriers.  That’s why I’m so impressed with Ward’s thinking — he’s been starting with a decentralized architecture, and seeking to identify and facilitate outcomes that are easier, more natural in that world.  We need more such thinking.

When I start thinking that way, my mind wanders towards deeply personal systems and deeply meaningful relationships.  Private diaries.  Family-centric stuff (family recipes, private calendars, snapshots, secrets).  It is worth noting that Ward has seen his ideas resonate in tightly knit communities who need deep connections over ideas and data, but who aren’t seeking mass audiences.  More generally, I suspect that this kind of architecture will naturally complement  offerings from giant players by gravitating towards parts of our psychology which the giants aren’t built to serve.  Our need for quiet; play space; safe space.  Our need for a small number of deeply meaningful relationships. As the giants define what the “mall” style of interaction with the net is, I’m (finally) optimistic that we’ll see structures emerge that mirror many other social structures, from the self to the couple, family, school, workplace, church, interest club, support group, etc.

This future feels more humane. That’s worth working on.

What computing will she need, and who will build it?

Thanks to Havi Hoffman for her editorial help.

Simple analogies as taglines are dangerous: do better

Standard

“It’s like YouTube for ___”

For a non-investor, I end up hearing a lot of pitches.  I even make pitches of my own (not for companies, but for product ideas — same basic idea).  Around Mozilla, we tend to say that things are “like the web” or “very Mozilla”.  Those are equally fuzzy analogies, which assume a shared conceptual map — a dangerous assumption. What if your audience thinks of the web as a scary, confusing, complicated place? or have a Mozilla concept that is anchored by a dinosaur?

In the startup world, a quick glance at Angel List shows how prevalent that phrase is among budding entrepreneurs.  It’s clearly both trendy and attractive to rely on other successes to explain your concept.  I’m here to warn you about what may be an attractive nuisance, but suggest a simple way to do it better.

Whenever you say something like “It’s like YouTube for _____”, or “like Pinterest but for ____,” you hope you’re concisely communicating a key part of your business or product idea but you could easily miss the mark, and not know it.  Analogies work to the extent that the analog is a concise description of a key concept, which you’re applying to a different market. The problem is that products, and especially successful products, are not that simple.  If I say “like YouTube”, my interlocutor will have a very different set of words pop into their minds depending on whether they’re an Italian judge, my kid, a devops, or a music industry executive.  The people you pitch to likely think differently than you do (after all, that’s likely why you want their attention, time, money, patches, whatever).  It’s therefore much too easy to confuse rather than elucidate.

My advice is to refrain from saying “like ____ for ___”, even though it feels nice to glow in the reflected glory from these successful precursors.

You can do better, and you should: there’s usually something in that appealing analogy which is the concept you’re trying to convey, so focus on that aspect of the inspiring product.  “It’s got the same instant gratification of Instagram, but with ___”.  “It’s as disruptive to an enterprise market as MySQL was, but targeting the  ___ market”.  By making the analogy precise, you bring your audience along where you want them, and you show that you understand one of the many reasons why these products were successful.

Ruminations on front end-centric webapps

Standard

I’ve been poking around firebase & meteor, and sparkleshare+github and dropbox+site44. I’m a bit disturbed (in a good way) by what feels to me like a sea change that’s happening there, and it seems to me that almost anyone thinking about web developers writ large needs to think hard about what this means for their roadmap.

In particular, a few brief thoughts:

I’ve been, for a while now, using sparkleshare + github pages with CNAME support as a way of making trivial static sites that are real. Sparkleshare is an open source git-syncing-to-filesystem client (with nice ergonomics and design, OMG!). With github-pages and CNAME support, this means that I save in my favorite text editor, and within _seconds_ the thing is live on the web. That’s a disruptive flow.

I’ve been coaching the harp.io team through WebFWD, and they have a service which does similar things on top of Dropbox, including coffeescript/haml processing, CDN, load balancing, push-button deploy, screenshotting for multiple user agents, rollback, etc. In other words, you author your webapp locally on a dropbox folder, and they take care of high-quality, high performance hosting. There is no app-specific server-side logic (which means you need to either have static sites or integrate with hosted services for said features).

I recently ran into site44.com, which does a ‘cheap & cheerful’ version of what harp.io does, with no push-button deploy/rollback, and much more like sparkleshare — instant deploy, with little management capabilities (but instant gratification).

Both harp.io and site44 use Dropbox for syncing, which is a Big Idea in my opinion because setting up Dropbox is so much easier than setting up git credentials (what with SSH keys, etc.). Both assume that the user has write access to local files (which may be a problem in some retrograde environments like enterprises and schools, but which could be solved with web-based editors).

I finally bit the bullet and dig in again into Firebase. Firebase is effectively a key-value store, with Pubsub messaging of data changes. They’ve made some interesting progress in their security and auth models (they include persona support, which is cool). Firebase feels like it makes it trivial to add state and real-time behaviors to previously static sites. The API surface area is quite small, so it should be fairly easy to adopt.

I’m also looking again at Meteor. Since they first launched w/ both fanfare and a bit of ridicule due to overhype, they’ve cleaned up their act significantly: the license is now MIT, they’ve announced $11M in financing from tier-1 VCs, announced an enterprise business plan to complement their open source offering, and build a bunch of APIs. Meteor feels like a steeper learning curve, and another “at-bat” for reactive programming (a topic I’ve been interested in for a decade).

Meteor feels like a solid foundation for a potential full-stack offering, and I like the open source option; Firebase feels like a really compelling basis for demoware and hacks. Regardless, syncing from filesystem to websites without thinking too hard about deployment is a huge benefit of front-end-driven sites.

Single-page apps feels to me like the conceptual next hurdle. Figuring out how to manage history and state management so that the app feels as dynamic as the best webapps, but has good URL support, etc., is an engineering challenge (see e.g. history.js). And it certainly challenges the old mental model of one URL -> one file which pulls down other resources. The newer model (especially on mobile, low-latency devices) needs to be one app -> many URLs, with one core application logic which pulls data-as-JSON and builds most state clientside (with serverside rendering as an optimization for high traffic or slow-CPU environments, as per airbnb’s post).

I’m not sure what this means for advanced webmaker skills. At the very least explaining some of the above to a broader audience is something we could do.

Mentoring isn’t worthless after all!

Standard

I enjoy talking to young companies (or proto-companies) about their projects. I do that with a few incubators and the like, and I consistently find it rewarding. I find myself always trying to tweak people’s product vision a bit, looking for a way to turn a “business idea” into something that will have deeper, human value — not just because I think it’s the moral thing to do, but because if you’re “just working for the man” (even if you are the man), then when things get tough, it’s going to be hard to get up in the morning. When you’re doing something that deeply resonates with people, and which either relies on positive human qualities or strengthens them, then I’m confident that your odds as an entrepreneur are better. Also because there are plenty of mentors who will do a better job of getting your social viral marketing plan in shape.

Sometimes I wonder whether I’m the only one getting value out of our conversations, but this blog post reassured me that at least sometimes I have an interesting impact: Do you really need a server? Build your minimum viable product entirely client-side.

I’m particularly interested by the fact that I wasn’t really trying to force them to think about the privacy advantages of client-centric development (I realize it’s hard for budding entrepreneurs to make that a priority), simply going for the pragmatics of it all. I’m so glad it’s working out for them.

Volunteer-powered product development?

Standard

Over the last few weeks, I’ve had the pleasure of working with the small-but-growing team that’s building the software offerings that are part of the Webmaker effort.  If you don’t know about Webmaker, you should — go check out the website, and Mark Surman’s blog for more details and an inside view about why Mozilla’s doing it.  The really short version is that one of the major initiatives Mozilla is engaging on in 2012, apart from some of the already incredibly ambitious projects that you may know about (Firefox, Firefox for Android, Firefox Mobile OS, Identity, Apps, etc.!), is to teach the world that the web is not just something to consume, but something that everyone can help create.  In Mitchell Baker’s words:

“Mozillians are people who make things. Moving people from consumption to creation is Mozilla’s goal.”

Now, Mitchell’s words often inspire me (she’s probably the biggest reason I joined Mozilla full time), but this phrase in particular has been bouncing around in my head for weeks.  It’s also one that resonates deeply with many people I talk to, regardless of their degree of familiarity with the web, technology, Mozilla, open source, etc.

Now, the premise of the Webmaking software offering is both incredibly exciting and so ambitious as to be scary.  We want to reach large but diverse populations and find ways to make creating on the web both compelling for them, and fun/productive.  That means that we need both specialized tools, specialized content, and deep connections with whole new populations of Mozillians who can join Mozilla to build these offerings, bringing their passion, skills, knowledge, connections, etc.  We’ve already got great start in a few beacheads: kids/tweens, filmmakers, newsrooms to name a few.  There are many more on the roadmap.

Each of these slices of webmakers will require specific content, and likely tooling, which we think of as a “product.”  As an example, Thimble is a combination of a code editor (a tool) and learning projects (content) developed in partnership with a bunch of great organizations, aimed at giving people who don’t know anything about the web the first bit of a clue, and the first bit of a sense of agency over the web. It’s an early effort, that we built really quickly, but it’s showing a lot of promise.

Initial approach

We built Thimble v1 “the easy way” — a dedicated designer, a dedicated product manager, and a dedicated engineering team, working full-time over a few weeks, coordinating with professionals who themselves had well-defined roles and responsibilities.  It wasn’t really easy, but it was familiar territory for most of us.  We knew what to expect of each other, we could rely on the traditions of both open source projects for the “code”, and product development for the integration of the code into an overall “consumer experience” (although the word consumer is particularly ironic in this context). 

I don’t think we can expect to keep this approach and scale the way the Webmaking project deserves to. (Michelle Levesque thinks so too!).

Now, one might think that that’s what Open Source projects do, but I think in fact very few open source projects are run as products.  In particular, in my experience, a good product team has learned that code is only part of the equation — design, project management, writing, engagement, etc. are equally important, for which there is no equivalent to the code open source culture.  As an example, good designers, as a result of decades of abuse by clients, typically refuse volunteer work. There is no global culture around any of the non-coding skills (with a few notable exceptions, such as QA and localization, and most interestingly, the legal profession, who has incorporated pro bono work into its professional culture).  Now, Mozilla as a whole has been tackling all of these issues for years to support the main products (Firefox in particular), but even then we have not yet figured out how to gather volunteer contributions in many parts of the workflow.

I’m hoping that within the Webmaking effort, which I think is so compelling to so many non-engineers, we have another opportunity to refine our approach.  I used the title “volunteer-powered” rather than “open source” in the title because I think that while open source has a lot of lessons to bring in, it also has a bunch of antipatterns.  Forcing non-developers to think or act like developers isn’t the answer.

Question!

Here’s my question for the day: are there collaborative models of work in non-engineering disciplines where people have developed ways of working that I should be reading about or talking to people about? 

To make it more precise and hopefully a bit controversial: I fear that a lot of the tradition of “collective action” has its roots in cultural norms around equality, fairness, and making people feel good about their contributions ahead of all other values.  And as a result, in my experience at least, a lot of volunteer groups for example end up very pleasant and “nice” but lacking the urgency, the drive, the decisiveness, the ambition to kick ass in the market that turns ideas into shipping code that users love.

How can we combine the rapid pace, deliberate action, role assignments of a product team, and the openness to volunteer and part-time contributions of open source?

Story telling as a webmaking task

Standard

In a new-thing-for-me, I’m working with a group of four students from the Center for Digital Media as part of their Masters program, on a design-led project that ties to Mozilla.  Specifically, these folks are working on a project they call The Cucumber, which is (in my words), trying to make a tool that lets any traveler easily create a compelling micro-documentary about a place they like, using the tools of the open web.

At this point, they’ve done a bunch of thinking, blackboard sketches, paper prototypes, and more, and they’re making good progress, but they need your help!  In particular, they’ve got a hypothesis that by preparing a few templates and story-telling concepts, they can define a design framework that everyone could use to make something compelling.

If you’re interested, it’d be great if you could check out their questionnaire and do a “pretend story-telling” — think of a place you want to document, and fill in the form — it will only take a few minutes, and be very helpful to the team!

What’s the lesson?

Standard

I’m not supposed to be in front of a computer right now. I’m supposed to be attending the Vancouver premiere of Tiffany Shlain’s Connected, in a fundraiser to benefit A Human Right.  This looked like a fun event, for a good cause.  So I bought two tickets, one for myself and one for my 14 year old son, who seemed really interested in the trailer, and who I was pretty sure would both enjoy and get a lot from the movie & discussion.  I was happy for Mozilla to sponsor the event, promoting it.

But, this is Vancouver, British Columbia, in North America, a continent where lawyers and fear have way too much sway on policy and clearly no firm grasp of reality.  In this particular case, the problem is that the venue — the swank Vancouver International Film Festival’s VanCity Theater has the audacity to serve wine and the like to its patrons.  As a wine and movie enthusiast, that seems like a delightful plan.  But apparently, this very civilized offering is seen by regulators as implying that the location is evidently such a den of iniquity that my kid would obviously be irretrievably harmed by the sight of some adults having a glass of wine. Of all the things that I worry about as a parent, this doesn’t make the top 1000.

This was mildly embarrassing for all concerned, and led to my son and I going home early and having a conversation about the puritanical roots of the Canadian legal system rather than the much more interesting discussion that I expect would have ensued after the movie.

Such a waste.

Somebody let me know how the show went?

You knew the old Mozilla, meet the new Mozilla

Standard

One of the notable things about working at Mozilla over the last few years right now is that our aims have gotten much more ambitious, but perception moves slower than reality, even among people who spend every working hour working on the project. I’ve been privileged enough to have a lot of conversations with a lot of people, and to see an evolution in the thinking that motivates our priorities. I’ve also been unfortunate enough to see and participate in high-emotion conflicts, which emerge from the disconnect between various individuals’ perceived priorities. I’m hoping that this post can explain the high level reasons for our current initiatives & why they matter, and maybe help get people past short-term conflicts.

History

For many years, the area that Mozilla needed to focus on was clear: to save the promise of the web, we needed to make a fast and useful browser that didn’t get in the users’ way, and get lots and lots of people to adopt it. This was (and is) a product play, which implies is that success would be determined by what real people would choose to use based on the real choices in front of them. And the people demanded high quality code, zarro boogs, security, etc., but they mostly demanded compelling experiences that solved their problems. In the case of the browser wars, the outcome has been pretty good for society, if slower than we’d have liked: standards have evolved, browsers got better and faster, and websites got more interesting (I’ll note in passing that cross-browser dev work is still way too painful).

Rethink

While that fight is far from over, we’re now at a distinct point in the evolution of the web, and Mozilla has appropriately looked around, and broadened its reach. In particular, the browser isn’t the only strategic front in the struggle to promote and maintain people’s sovereignty over their online lives. There are now at least three other fronts where Mozilla is making significant investments of time, energy, passion, sweat & tears. They’re still in their infancy, but they’re important to understand if you want to understand Mozilla:

The first such effort is, in some ways, “lower in the stack” than the browser. We started an ambitious exploration called Boot to Gecko (B2G), which I don’t yet understand well enough in detail, but which is clearly trying to ensure that there are realistic options for mobile devices which bake in the right values as low as possible in the stack. As I discussed in my last post, the verticalization of the internet means that we’re heading towards a world where who you get your phone from will determine way too much about how you can experience the internet. B2G is a bold exploration tackling the operating system layer of that world.

The two other such efforts are higher-level in the stack, specifically in areas which I’ve been following closely: user identity, and apps. Both of these are spaces where the shape of the real world ergonomics & economics of the internet have managed to completely sneak around the “traditional” world view of browsers & websites.

User-centric Identity on the web

For identity in particular, it’s now possible to create highly engaging experiences thanks to personalization, but that personalization is by far easiest to achieve by adopting technologies like Facebook Connect, which, while appropriate in some contexts, is inappropriate in many, and highlights how much “we in the internet” have failed to address the very real needs of website developers and their users. It’s taken Mozilla a fair bit of time & experimentation to get to something that feels truly great, but I’m very bullish on our first big push in this space, which we’re calling BrowserID for now. The goals of BrowserID are simple:

  • users and websites want to make sign in easy
  • users should be able to choose who their identity provider is
  • websites don’t want to be beholden to a single identity provider
  • sign in should work everywhere

With BrowserID Mozilla took a bold step, which is still poorly understood even within Mozilla:

  • we built a system that works in all modern browsers
  • we’re standing up a service to bootstrap the system until identity providers opt in, with the strictest transparency and privacy guarantees we can come up with
  • identity providers can federate it when they want
  • we build on identity concepts which users and developers understand and trust today.
  • we’re hoping that all browsers provide enhanced user experiences on top of the protocol, but we don’t need and won’t wait for their cooperation. This fight will be won by offering something compelling to website developers (and their users!) first.

For Mozilla devs, this is a bit shocking, as we’re not starting by putting a feature in Firefox first (although we sure hope that Firefox will implement BrowserID before the others!). While I love Firefox, this makes me happy, because in my mind, Mozilla is about making the internet work better for everyone, not just Firefox users, and in this case being browser-neutral is the right strategic play.

Note that Mozilla has always been about making the internet better for everyone, and that’s what’s driving e.g. our policy work. Pragmatically, Mozilla is now big enough that I believe we’ll be more effective if we fight on several fronts at once — coordination costs are very real, and progress on BrowserID in no way diminishes Firefox’s value proposition, although they can (and will!) be better together.

Apps that are of the web

The other critical challenge to the web is the rise of Apps, as a mechanism that developers are turning to because it’s easier to get your apps found & bought, and that users love because it’s an easier way to experience functionality on mobile devices in particular. And here too, Mozilla has a strong play, which is just starting, but which I believe has legs. We launched a developer preview of our Apps initiative, which has the following bold (but doable!) aims:

  • make web technologies the best way to create apps that users can find and install on all devices
  • propose a standard for app purchase and installation that allows many appstores to compete for developers and users, so that developers don’t have to go through an arbitrary process to reach their audience, and users can choose where they want to get their apps.

There are many more things to say about our Apps effort, but I like to summarize it as teaching the web about the good bits of apps, and teaching apps about the good bits of the web. Right now we’re watching the sausage being made (something you don’t see in the Apple and Google kitchens), and it’s a bit chaotic.  But over time, and by the time it gets into consumer hands, it’s going to be splendid.

Here too, the goal is complementary to the success of the Firefox browser. And here too, we need so much help, from app developers to help us prioritize features, from web runtime developers to negotiate and implement the APIs that app developers need, and from early adopters to help us iron out the experience (and be forgiving especially in these early days).

“Finally!”

I’ve been speaking to app & website developers about BrowserID and Apps for a few weeks, and the feedback has been great — webdevs & entrepreneurs are very aware of the dangers of relying on Facebook, Google, or Apple as the bridges to distribution or users. They desperately want an upgrade to the internet that solves these issues in an infrastructural way, and they are quite aware that Mozilla has a unique position beyond being the makers of Firefox.  Webdevs understand the public benefit charter of Mozilla, and many are keen for us to take on more responsibilities there, and happy to help.

Culture shock

I expect it’s not obvious from a distance, but this kind of strategic broadening is hard on a culture. It means that we don’t have a single way of going after things. It means that others in the project seem to work in directions which don’t appear to line up with your own. It means that now engineers don’t just argue with product folks (a tradition in every software organization), but with other engineers with different priorities. It means that it’s impossible (and frustrating!) to keep track of what everyone is doing. All that is painful, especially as the odds are long in each of these battles, so it’s natural to want everyone else to drop what they’re doing and come help you out.

The best advice I have if you find yourself in this kind of culture shock is to first recognize it for what it is: you’re looking up from something you’ve been heads-down in, and your world (and your Mozilla!) looks like it’s changed in surprising ways — that’s scary, for limbic-brain kinds of reasons. We all tend to feel this way when we learn about new developments around us that we weren’t deeply involved with, from SOPA to “what the kids are up to these days”. We have to moderate that gut reaction with a bit of brainpower, and realize that just because it makes us uncomfortable, it’s not necessarily bad. That’s when the work begins: finding out who is working on whatever it is that’s making you uncomfortable, and reaching out to them to get looped in. In particular, doing so tends to work better face-to-face, or at least one-on-one. Finding the right people to talk to will take effort and time. It’s on you to do that work, though, and get informed.  Take the time to understand the history of the change before expressing your unhappiness — the people involved are likely just as smart as you, and if they’re Mozillians, they’re motivated by the same mission.

Looking forward

So while there’s tension aplenty, when I think about this new Mozilla, which not only is committed to producing the best possible browser on desktops and phones, but is willing to invest in shaping what mobile devices should and could be like in 5 years, and reaching out of its comfort zone by standing up to internet bullies in critical areas like identity and apps, I’m pretty proud to be involved.  I’m confident that 2012 is going to see the emergence of new facets of Mozilla, just as the net needs its particular blend of values, ambition, and pragmatism more than ever.