I've always been a fan of the Mozilla Foundation, and not just because of the Firefox web browser. As catalyst for some of the great communities in the open source world, Mozilla is something of a recipe factory for what to do right when it comes to building community. As it turns out, Mozilla's Director of Developer Relations, Chris Blizzard, is a long time friend of mine.
In fact, this is not the first time I've interviewed him-- my first Blizzard interview experience was back in 2002 when Mozilla 1.0 came out and he and I both worked for Red Hat.
I spent some time with Chris to discuss his experiences and learn more about community-building the Mozilla way.
1. When I first met you ten years ago, you were a Red Hat employee with a day job keeping the redhat.com website up and running, and, even then, you were hacking on Mozilla for fun in your spare time. Now you run developer relations for Mozilla, and you've had some other amazing experiences, including working on the One Laptop Per Child project, along the way.
It strikes me that you are a great case study of someone who has achieved success in the meritocracy of open source by doing good work. Knowing what you know now, if you were starting from ground zero as a community contributor, how would you get started?
That's kind of a tough question because I don't have that perspective anymore. I know too much about how these communities operate to be able to answer that with the fresh face of someone new to a project. But, honestly, I think that that if I were to guess I would say find something that you're passionate about and just start working on it. My own case is instructive.
Well-run projects easily accept people who show up and work on things that they didn't even know they needed in the first place. I often think that's the best place to make your mark—at the edges, working your way in, and tends to be the path that I've taken through the projects I've worked on.
When I started with Mozilla I started by hosting a server to download the source code. The server was actually the workstation under my desk, but had a "real" IP address on the Internet and had excellent connectivity since I worked in the main office of an ISP— 10Mb/sec, I believe, which was nothing to sneeze at in 1998. From there, I started helping out with porting code to Linux, spent a lot of time writing up the project's weekly reports, helped to run some releases around Mozilla 1.0 and also was part of the early Mozilla.org staff.
My decision to work on Mozilla was intentional, but I started with something simple at the edges—hosting a download server. From there I found places I could help and made a difference in the lives of others.
If you're interested in helping a project, this is the best thing you can do. Play the part of the generalist, listen a lot, drive change where it's important, and make the biggest difference you can. And always remember: these projects are made up of people, not code, and how you treat others is the most important thing.
2. Firefox is arguably the most successful open source project from a mainstream consumer standpoint. Meaning, it not only has an active community of developers, but it also attracts a broad community of users from all walks of life. Why has Firefox succeeded at reaching a mainstream audience when other open source projects (like the Linux desktop) have struggled?
There are a lot of factors at work there, especially when compared to the Linux Desktop as it stands today. I could also compare it to browsers in the market at large, or the other platforms we compete with, but that's not what I'll do. When compared to the Linux desktop, I can break it down to a few specific things:
1) A specific intent to build something for people.
We're not building a platform or a set of libraries. We're not creating something for a set of developers that some other organization is going to bundle up and ship out to some market segment. Instead we do the whole product and can create a great experience for people. Everything from code, to user experience choices to privacy features. In this sense, we're probably the most vertically integrated open source project on our little planet.
More often than not, I tend to think of us an "open source product" instead of an "open source project" because we do things that a lot of projects don't. We're worried about the whole product experience and how we can drive changes throughout the project. From how we make choices at a code level to what features we're going to include to how that interacts with marketing campaigns we run—all of this is highly evolved and integrated.
I would also point out that we're heavily technology focused but we also make sure that we have the best people in the world in other areas—marketing, legal, business development, QA, build, etc. A whole product is not just a piece of software, it's a full experience that touches on all aspects of how someone interacts with it. These things matter.
2) A platform that lets us target people but still build things for software developers.
It's important to remember that the model that Firefox has been built on (Gecko) is more than just a web rendering engine. It's more of a web browser platform that is highly modular and allows for amazing extensibility. This might seem like a technical detail but it's actually been a huge advantage for us to be able to move quickly and become not just a great browser for a huge number of people, but also become the platform for web browser innovation across the industry.
The fact that you can hack the interface of the browser in the same way that you can hack the web means that anyone can change the interface of the browser. No one else has this architecture—not Safari, not Google Chrome, and certainly not Internet Explorer (Chrome has an "extension system" but it's not even slightly related to the power and flexibility you find in Firefox).
What this means is that people at the edges are able to experiment and change things and then share those changes with others. This also means that we get to see all the cool stuff that people are doing and take the great changes that people have made and bring them to our 350 million-strong user base when something rises up as truly excellent. This is a pattern that has repeated itself over and over again in our project.
It also means that we can avoid one of the classic traps of software development—that it's basically impossible to get rid of a feature. Our software can actually get simpler and smaller with time because we can move stuff that doesn't make sense into extensions and send those users to those extensions. It also means that we can service a much larger user base than anyone else, since most people want at least one thing that almost no one else wants. They can do that with the power of our platform.
Most programmers wouldn't choose our architecture because it doesn't look good on paper. But it turns out to be a huge part of our engine for innovation. View source is power, distributed directly to the edges.
3) Fantastic leadership model and a model for sustainability.
I talked about this briefly but we have fantastic leadership. And this isn't just leadership in the CEO-is-awesome sense (although we like ours!) but our distributed module system means that people at the edges are empowered to own and make decisions on their own. We communicate fast (telephones and videoconferencing, not just mailing lists!) so we manage to achieve consensus on a lot of issues even with that distributed decision making in place.
The other side of this is that, along with direct contact with our user base and the ability to make decisions on their behalf, we've built a business model around our product that lets us pay people to work full time. This means that we're able to go fast, operate as a team, and not worry too much about if someone is going to get redirected to some other project at work. There's nothing casual about how we work. We are intentional and competitive.
Sustainability lets us do that and I think most projects shy away from money because of the concern that it taints the process around building free software. There's a line from The West Wing that goes something like "Money is motive with a universal adapter." This is how I look at it—it lets us get the stuff we need to get done faster than without it. And given how we approach our product, as I explain below, we're pretty confident that we're still achieving a positive outcome for more than just ourselves.
4) Knowing the change we want to create and driving that through the organization and the product.
We're very intentional about what we do. We don't just talk about open source software. For us, the open source code we deliver is just a tactic. It's a symptom of a larger organization that operates transparently and accepts and encourages the work of others to achieve a goal larger than what it could achieve on its own.
For us, that's about keeping the Internet alive and vibrant. And making sure that the people who interact with this thing we call the Web are still treated like people. People who might be searching for something private and personal, people who might want to talk to friends online, people reaching out to long lost friends... This is what matters, not the technology.
Our role in the market is to act on their behalf and make their lives better, both through strong positive product improvements, but also sometimes by standing up and saying that something is wrong. Our market share (30% of all traffic to Wikipedia comes through Firefox!) gives us a lot of leverage in that space to make choices in the market or drive other browser vendors to make the web better as well. It's a virtuous cycle.
5. We care about Windows, Mac, Linux and mobile.
The last big thing that makes us different is that we have a set of first tier platforms we care about, especially Windows. Most open source projects tend to ignore Windows largely because it's dirty or something. But it turns out that's still where the people are. As I said, we go where the people go, so we support Windows aggressively. Over 90% of our user base is on Windows, 7% are on the Mac, and 2% are on Linux.
If you want to go mainstream with your software and drive change you have to be on Windows, end of story.
We're also getting into mobile now in order to bring our mission to those platforms. We did an early browser (that got rave reviews) on the N900, a relatively niche phone. But we're coming up on Android quickly, which a lot more people have in the market. Expect us to do in the mobile market what we did on desktops—revolutionize the experience. The current set of mobile browsers are anaemic and are ripe for the kind of innovation we've been experts at driving into the desktop browser market.
3. Mozilla has a noble mission, beautifully articulated here, of "encouraging choice, innovation and opportunity online." What role to do you feel this mission plays in attracting developers to work on Mozilla projects? Are most developers oblivious to it and just want to work on cool technology? Or is the mission meaningful to them?
I think that it depends on the person. Some people are into cool technology, that's true. We have thousands of individual code contributors for our core source code and we also have thousands of developers doing add-ons and extensions. Some of those people are here for the mission, but some of them are just here for the exciting hack.
But I also think that stating what we are and what we care about does more than just lay out what kinds of developers we want—it lays out the kind of change that we want to create in the world and what tactics we're willing to use to get there. That layer of ground rules is important since it sets how the community is going to interact and what will be acceptable. Setting expectations is important because it lays out the kind of community you want to build.
Here's an example: Are you out to "build something amazing that normal people can use" or are you there to "kill Microsoft?" The two statements turn out to end up building very different communities. Ours is certainly along the former, not the latter.
4. What's the dumbest thing a company can do when trying to build an active, engaged community of contributors?
Fail to be transparent about motives and tactics. Especially if you're a commercial company (we're not in the classic sense), it's important to be up front about how you want to engage and what that means for someone who contributes. To borrow a phrase from a friend, I'm not dumb enough to lie. I don't think anyone else is either, so don't try.
5. And what's the smartest thing?
The opposite, of course! Be transparent, apologize when you make a mistake, talk about your decision making, and make sure that you're laying out a solid roadmap to what a successful relationship looks like. I'll borrow a John Lilly phrase here, and I repeat it often: surprise is the opposite of engagement. I use that in my own thinking and actions when I'm dealing with people. It's an important way to think about community building since communities are built on communication, shared activities, and shared goals.
Thanks so much for your time, Chris!
--
Chris Blizzard has his own Wikipedia entry and other than his title, it looks mostly accurate, so I've copied it below:
Christopher Blizzard is an Open Source Evangelist working for the Mozilla Corporation and a long-time contributor to Open Source projects, notably with Mozilla, Red Hat, and One Laptop Per Child.
Prior to his position as Open Source Evangelist he was the Software Team Lead for the One Laptop Per Child project at Red Hat and sat on the Mozilla Corporation Board of Directors. Before joining the One Laptop Per Child project he was a Systems Engineer and Open Source software developer working at Red Hat.
It doesn't say (and I will add) that Chris is an extremely thoughtful, thought-provoking, and downright interesting human being. With good music taste.
2 Comments