Download Files:

• mitchell_baker_transcript.doc (79.9 kB)
• mitchell_baker_transcript.pdf (225 kB)
• MitchellBaker.wav (316 MB)
• MitchellBaker.mp3 (26.3 MB)

Description:

Interview with Mitchell Baker, Mozilla's Chief Lizard Wrangler.

Text:

Olivia Ryan: It’s June 26 and we’re here with Mitchell Baker. Mitchell, this is sort of a broad question, but when did you first sort of develop your interest in technology, and/or when did you begin working with computers?

Mitchell Baker: Probably in 1990 when I moved to the Valley. I actually moved down here because I was interested in Asia and China, in particular, and I was a relatively new law school graduate, and I wanted to find some place that was actually doing things in Asia. So I moved to a law firm down here, which was a technology law firm that happened to do a lot in Japan and Taiwan. So that was really the start of it.

Olivia Ryan: Okay. And how did you—what’s your role here at Mozilla and how did you come to work here?

Mitchell Baker: I have a couple of different roles. The one that I’ve had the longest and I really treasure the most is the Chief Lizard Wrangler of the Mozilla project, which really means general manager but in a setting where there’s not necessarily an employment relationship. It’s a much more consensual set of people who choose to follow or choose to have someone be the leader. So that’s the first role. And then I’m also the CEO of the Mozilla Corporation. So that involves running the set of employees in the Corporation, as you might think. And I’m also on the board of the Corporation and its parent, the Foundation, as well.

Olivia Ryan: Is it right you continued to serve as GM after, like on a volunteer basis in 2001?

Mitchell Baker: Oh, yes.

Olivia Ryan: And so how did you decide to stay as a volunteer, and did you work elsewhere during that time? What was that experience like?

Mitchell Baker: I’d been acting as the general manager, Chief Lizard Wrangler, since 1999 and already had a lot invested in the project in terms of thinking it’s an important piece of work to happen and recognizing that I had a role that I was good at, and there weren’t that many people who could step into it. So when I stopped working at AOL, I actually never had any doubt that I would continue to be involved. And that was clear both in my mind and in a set of other people who were equally eager for me to stay as the general manager of the project. So I guess there never was really too much doubt about it. And I did work as a volunteer for about a year, but not full-time. And I did notice, you know, there are some differences in being a volunteer. But I found that my voice or my authority was in no way diminished, and my ability to talk to people and get different perspectives and try to figure out the right path was certainly not less because no one was employing me to do that.

Then I went back to work three or four days a week, I think, with Mitch Kapor at the Open Source Applications Foundation, and Mitch subsidized maybe a day of that work as Mozilla work. So in that period I was part volunteer for Mozilla, paid a day to work for Mozilla and paid some to work on OSAF’s Project Chandler. So it was a mixture all the way around.

And I went back to work full time when we formed the Foundation, but at that time I was still splitting my time between the Mozilla project and OSAF. And then as the Foundation took off, and it was clear it needed more time and attention, Mitch and I agreed I would stay on the board at OSAF but stop being an employee and spend all of my time here because Mozilla certainly takes all of my time and more.

So, actually, to go on a little bit. So at that point we formed the Foundation in 2003, and I was not alone but certainly instrumental in that. And at that point I became the President of the Mozilla Foundation. And then later on when it became apparent that we should have this subsidiary, the Corporation, I gave up a day-to-day operational role with the Foundation and moved to the Corporation.

Olivia Ryan: Okay. To what extent does Mozilla rely on the work of volunteers? And has that reliance shifted over time?

Mitchell Baker: Mozilla has relied on the work of volunteers in a pretty fundamental way since maybe 2000. So when the project was launched in 1998, everyone was a Netscape employee, and the number of volunteers began growing slowly. So there were volunteers by, say, 1999 when I got there, and they grew over time.

But even as early as 2000 and 2001, our ability to actually produce and ship a product was dependent on volunteers. One of the things that’s sometimes hard to understand is the volunteers will provide—well, in our setting where we have so many employees—less time and less by quantity, but they’re still critical. And that’s critical today too, even as our employee base grows, we—I think everyone here understands in a deep sort of internal way, we alone could not create and distribute and be successful as we have with Firefox to date based on employees. It wouldn’t matter if we became 100 employees, 200 employees, 500 employees, it wouldn’t change the fact that Firefox has taken hold because there are thousands and tens of thousands of people around the world who are interested in it and have emotional investment in it and a mental energy and spend time thinking about it. That we cannot duplicate in an employee base.

So if you look at the amount of code that’s checked in or the amount of work that’s done, that would be skewed towards the employee base because we all have, you know, probably a minimum of 40 hours a week and upwards to spend on it. But that’s not to say that takes the place of the non-employees.

Olivia Ryan: So you sort of described why you volunteered. Why do you think other people volunteer?

Mitchell Baker: I think there’s many reasons. Some people volunteer because they use a browser. They understand how bad things can be because they’ve had a typical experience. They’d like to have something different than what was available. Some people volunteer because they’re interested in good technology, and we have extremely powerful technology, not just for the browser but elsewhere. So some people volunteer because they want to use that and be involved. A lot of people are interested in working together with others. And so we find many people are drawn by the fact there’s smart people doing things they care about, and you can actually participate.

Some people, you know, a lot of people are not particularly fulfilled by their work, and they struggle with, “I don’t like my boss,” or “I don’t like my co-workers,” or “The people I work with are great, but the work is boring. I’m really interested,” or “I think I’m good at this set of things.” And there’s not an outlet for that. Whereas in our project and other open source projects, if you can find a spot that you’re good at and you like, you can pursue it.

And, you know, I think many people think programming is such a hard thing to approach. If you’re not a programmer, it just seems like how would you do that, and why would you do that if it wasn’t part of your job? But for the set of people who like it and are good at it and are comfortable at it, the chance to find a group of people that you like who will accept you, who don’t care if you’re 14 or 82 or, you know, where you are and actually work in a productive fashion and get recognition back and work together is actually more of a driver than people think. I mean, very often you’ll hear people say, “Work isn’t all about a paycheck.” And life isn’t all about a paycheck. You need one, but that’s not the most fulfilling thing in life. Sometimes it’s family, but often for people it’s productive work with others, and we offer that.

Olivia Ryan: How many non-coder managers or leaders, or however you would describe it, does Mozilla employ?

Mitchell Baker: I’d have to look. Actually, I don’t keep all those numbers in my head. A growing number. We’ve got three product managers, four if you count Chris, five—so I would call them managers right now because they’re not necessarily leaders. They have, as employees, a certain set of responsibilities, and we hire people who we think fit into our community and will become leaders. And their reputation will reach a point where others are interested in what they’re doing and will want to pursue that, but you can’t anoint someone just as an employee. So if you want actual numbers, I’d have to go actually get them.

Olivia Ryan: Well, I guess I was trying to get more like, how the decisions are decided among these different groups that sort of non-coded groups and coders who have sort of stepped up into a sort of management role and how that process works?

Mitchell Baker: We have a pretty clear set of decision-making guidelines for code, although in reality it turns out that the set of people who know the most about that generally agree. When we get into product decisions, we do a fair amount of back and forth, and there are a series of discussions between say product management and the engineers who will implement it, often done in public, so with other interested parties involved. We tend to go back and forth and get as close as we can, and then, ultimately, if there’s an unclear decision, someone’s got to make it.

Olivia Ryan: Have you noticed any tension between those who work at different levels, say, those who work on the front end, those who work at back end of development and, if so, how are those tensions sort of resolved? Or how much like communication between those two groups, as major decisions are made?

Mitchell Baker: Well, there’s communication among a project rather than sort of between those two groups. So if they’re interested in what’s happening in a product, everybody gets the same newsgroup or mailing list. So that communication level is self-selected. You could select out of that if you wanted to. I would be surprised that many people do. It’s probably a question of if you’re working on the, call it the platform or the back end rather than the application level, of how, actually, how much concentration you use when you read the mailing list. So the communication piece, I’m not sure gets separated out that way. There’s, you know, we live in this project, in a world of constant pressure, you know, relentless pressure to have new and better product and competitive pressure. So although we’re a big project, there’s never enough resources to get done what you want.

So sometimes there’s a focus on the application itself, and I don’t know the level of tension, but the more you need to focus on the application itself and the less the platform attention gets, then after a while people start to get jittery and think, you know, it’s really time to focus over here. Or, the application is lovely, let’s make sure our performance is good. So we do go back and forth on that spectrum.

Have we had tension? You know, every once in a while we’ll get someone who’s deeply involved in a project and will assert that, “I need to be able to do whatever I want to do because it’s important here, either in the application or over here, and everybody else just has to cope with it.” And that produces tension because nobody else wants to clean up forever. So we’ve had some of those settings. Sometimes they work themselves out, or sometimes somebody is just really jittery, and you can calm them down, and sometimes they go on for a while till roles change or something gives.

Olivia Ryan: What communication, means of communication do you think work the best? I know from other interviews, the newsgroups and there are decisions made at IRC, and there are kind of like different ways that people communicate. What do you think works the best? And would you ever want to sort of standardize what’s used to—

Mitchell Baker: Well, you know, communication is always imperfect. It doesn’t matter what you do. There’s always a set of problems. So it’s an ongoing improvement. So to answer your last question first, maybe we would standardize but not for very long because what’s needed changes, you know, depending on size. So I think there’s a pretty clear understanding that some kind of newsgroup mailing list piece is important. The question of exactly what goes in there and how much goes in there, I think, is a little unsolved.

The Apache folks are much more consistent and rigid than we are about the mailing list is a source of all information. I think the Wiki, you know, that’s associating a tool with a communications piece, but a place to actually find information other than a mailing list is a necessary complement. Although I guess if we had to pick one single tool in our project, we would choose the bug tracking system. Right? It’s not perfect communication but, over the years, the single place where you find the most answers is in the bug tracking system. We relied on that plus a mailing list for a long time. That’s clearly imperfect, so you’ve got to go beyond that. That would be the minimum.

You know, Wikis are still awkward. They’re getting better, but some collaborative works base where you can identify, this is the decision, and find it, would be the next piece. So I’d say bug tracking system, mailing lists and something like a Wiki. And it’s a paradox of open source projects that so often when you get people together information flows much more quickly. And that’s an unanswered question. Open source and distributed development has proved itself extremely powerful and in letting people work together who aren’t together, it’s one of the great, I think, victories, to see that people can interact online and be as productive as we are.

On the other hand, you know, we are human beings, and so when you get together all sorts of things happen, and that’s a constant strain. So we’re very lucky to be able to hire people, and it’s very helpful to have a set of people together here. On the other hand, if you’re not in these buildings, the increased information flow in the building is a problem.

Would you want to say, for example, that in an open source project, the ideal is you never have two people in the same room because you can never have face-to-face communication and then everybody is in the same boat? I don’t think so, but then I’m here. So, you know, maybe others would say yes, and I think that’s really the long-term strain, is if you’re trying to optimize communication it’s not so much is it the Wiki? Is it a mailing list? Is a newsgroup better than a mailing list? It’s do you optimize for ‘everyone’s distributed all the time’, and if you believe, as I do, that very often things happen when people are together that are quicker or faster or easier, you can’t optimize for that if you’re distributed, so what do you do?

And that’s the tension that we haven’t really solved ourselves. We all, you know, have these conference calls where people can call in. And I’m sure in the next few years video conferencing will get easier and cheaper, but I think that’s really the philosophical tension.

Olivia Ryan: And how else, apart from the communication part that you’ve been discussing, does managing and/or leading an open source project differ from any other business in a proprietary software project, for example? What are sort of the major ways that it differs?

Mitchell Baker: I think the most important thing is that the “community”—I’ll put that in quotes right now, you know, what community means—but the set of people that you rely on has to be healthy. In an employment, that’s always true in any sort of human organization, you hope that the organization functions well and people get along or they are not undercutting each other. But in an open source project where you don’t have employment and the tools that go with that, the importance of having a healthy community is even greater. Because in an employment setting, you’ve got, you’ve got employment, you’ve got letting people go, you’ve got bonuses, you’ve got managers, you know, you’ve got all sorts of tools that you can use to try and get to a healthier place or to get people to do something, even if it’s not in a healthy fashion. When you get into our world, that’s not the case. And so being on a path that people understand and can buy into is even more critical. That’s the first thing.

Secondly, there’s a lot, there’s much less ability to control the terms of the discussion. And so the ability to live in a world of criticism and to ferret out the grain of truth and to be, you know, open to be, “Yeah, I was wrong. I need to change that,” I think, is pretty high in our world. And then the key, of course, is how to be decisive in the face of all of that, and exactly how decisive can you be, which, I think, is an unanswered question kind of, in our case as well.

What else? I would say it’s a very high, a least tolerance and maybe appreciation, of what other people do even if it’s not exactly how you would do it, which turns out for someone who’s got a vision and really is a leader, often is very precise, and ‘I want things done this way’. That’s not the case for us. So you wake up some days and you say, “Oh, wow! Look what somebody over in Czechoslovakia did? That is astonishing. Who ever would have thought of that? That’s great.” And other days you wake up and you say, “Oh, look what these folks did. That’s kind of troublesome. How can we make it a little bit better? Or can we just live with it?” Maybe it’s troublesome, but it’s not really bad. Or maybe it’s troublesome to me, but in their environment, if I only knew more about it, it’s actually not. It’s very helpful. And learning to live with that—so I would say, leading has got to be about finding people and letting them move forward based on a shared view, but it’s the classic delegation, give somebody room to move and accept that where they go might be just as good or better than where you’re going to go.

You know, there’s a few geniuses in the industry who don’t work that way at all, and you can see that it really works. But our strength comes from these thousands or tens of thousands of people who have their own conviction about how to move forward and what’s good and how to help people understand how to make life on the Internet better and doing it. So you have to be able to let people do things.

Olivia Ryan: You’ve blogged a little bit recently about the RSS icon and there’s like this discussion about whether or not to sort of standardize that or if that would be a good idea. I was just sort of wondering if you could talk a little bit about your thoughts about that and how you think maybe other people are receiving those ideas?

Mitchell Baker: I think the RSS discussion is an example of another unsolved piece, and that is standardization—there’s no standardization body for marks or trademarks, and I think that trademarks are a fundamentally difficult concept for open source projects because open source and free software are based on licenses that are ‘use’, what you can do with it, or what can be done with the code. So you as the recipient have this enormous freedom to do what you want.

But the icon, so if you look at an icon, there’s two things. There’s, “Oh, gee, I’ve got the code. What can I actually do with it?” But there’s a separate question of “What does it mean to a set of consumers who see it?” And those are very, very different. And so this question, for something to mean something to consumers, it’s got to have some degree of consistency. Unclear just exactly how much, but it’s got to be consistent. Well, consistent is not the same as, “Everybody does whatever they want with it.”

So the underlying nature of open source and free software, go do whatever you want, to me, doesn’t line up very well with wanting the results of that to mean something to a mass market set of consumers. So I think that discussion is going to be very painful. There have been a set of brand and trademark discussions in the open source world and some very good thinking about it but, in general, I think there’s a view, “Oh, we can standardize just by goodwill, and it will all work out.” And that might be the case, but my experience is that the general citizen understands far less about the Internet than most technically savvy people realize.

So I think the ability for the consumer to actually understand what these icons are is just bordering right on its infancy right now. And the more variation and changes and technically sophisticated things go into these things the less understanding we’re going to see for a while. And I don’t know what the answer is.

I think we need some other kind of community or trademark piece because trademark law is very far on one extreme and given that I think recognition and standardization of icons is quite different than what built the open source movement, I think we need to try and have some ‘trademark-like’ activity. Just like the MIT and BSD licenses and the GPLs have changed the way of thinking about copyright. The GPL in particular, to say, “Well, it’s copyright, based on copyright.” But it doesn’t do what copyright law does. It voluntarily chooses to do something different, you know. As do the licences, you know, they followed.

I do think we need something like that for trademark. Trademark-like, but not what currently—at least US trademark, which I understand requires--. But we don’t have it yet, and I think that discussion will be sort of positive. But the acceptance that if you want people to recognize something, you can’t change it the way open source expects you to be able to, is going to be painful.

Olivia Ryan: And how do you think—I mean, the open source community is probably somewhat different today than it was back when the GPL license was written, and how do you think the way that the community has changed might change the process for having something similar for trademark? Do you think it’ll be more difficult? There would be more voices now and it might be harder to get the community to accept—

Mitchell Baker: You know, I don’t think so, because I know that Richard Stallman has given some thought and talked a bit about trademark and how it’s different and how the GPL doesn’t purport or makes sense to cover trademark. So I think, you know, sort of in that era a trademark might have been different, and I think people understand that at some level now and open source and free software community is broader now. It’s got business types. It’s got businesses. It’s got projects like us, and it’s got all these enterprise software companies. So you’ve got all that spectrum that certainly understands it. So I’m not sure that the timing is different. I think we just haven’t really had the discussion yet, and I think it’s coming very shortly.

When we first launched Firefox—before Firefox, we had a product before that, the Mozilla Application Suite that had a browser and mail. It was integrated. And when we launched Firefox, we actually had the Foundation then and had both the ability and the need to pay more attention to trademark—the icons. That was very painful because there were elements of the Mozilla community who had been used to doing whatever they wanted to, and we knew once we had a product that again was moving out of the technically savvy early adopter world into the consumer mainstream, we needed to pay more attention to that. And that was very, very painful, especially among the overseas, the non-US parts of the Mozilla community.

We spent a lot of time on trademark policy for Firefox, and I think eventually most people came to understand what we were doing, although they didn’t particularly like it ‘cause everybody likes to have, you know, have freedom to do what they want. So we went through a round of that, which—we probably lost some contributors. And open source projects, I think, are going to go through more rounds of that.

Olivia Ryan: During that early development of Firefox as CVS access was sort of restricted to a small team of developers; can you sort of discuss why that decision was made and if the restriction was sort of changed over time and--?

Mitchell Baker: Oh, boy, you know, I’m not exactly the right person to ask for that. You should probably find someone else on that one because I’ll just be repeating what I’ve heard.

Olivia Ryan: Okay. Let’s see.

Mitchell Baker: I’m going to stop in a few minutes here. We can go like another five minutes and then we’ll stop.

Olivia Ryan: Okay. Can you then briefly describe the relationship between the Mozilla Corporation and the Mozilla Foundation? I don’t know this is something you can do in the next five minutes or not—

Mitchell Baker: Sure. Oh, sure, it’s not that hard, so I think I can. The Mozilla Foundation is a non-profit organization. In US terms, it’s a 501-C3, so reviewed by the IRS and vetted for having a purpose that serves the public benefit. And that purpose is to keep the Internet an open, accessible platform. The Mozilla Foundation has a subsidiary, the Mozilla Corporation. It’s wholly owned. That means the Mozilla Foundation owns all of the corporation, selects all of its board of directors, and there’s no private interest in the corporation at all. So there’s no investors in the corporation. There’s no stock options like you find in technology companies. It’s completely owned by the Foundation, and it exists to help meet the goal of the Foundation. That is, build an Internet in the public interest.

Olivia Ryan: Do you have any questions Ken?

Ken Albers: Well, I guess, the only thing I could say to that is, you know, because you’ve been blogging about that a little bit and that seems to be sort of a hot topic. We’re sort of wondering, you know, a lot of people seem to like, I think, maybe just because of the word corporation, they’ve become concerned about that. And if you felt, sort of like if you’re starting to feel pressured to sort of explain this to people, or you know, because I’ve noticed you’ve been writing about it more and things like that, like, you know—

Mitchell Baker: I’m writing about it more because I always should have and never did before, but—but, well, two things join. One is we now have this corporation, and the corporation itself is not tax exempt. So people translate that as to “for-profit” is how they think of it. But that also aligns with a whole set of activities and needs that have changed unrelated to legal structure or tax structure. So, and so I think those two get mixed up, and one of the reasons I’m taking the time now to talk about organizational stuff is to see if we can make some steps forward to make people comfortable enough to talk about what I think are the real issues that drive many of these concerns.

So we have now a significant user base, 40, 50, 55 million people, whatever exactly the number is. That changes a whole range of activities for us. So whether we’re a non-profit, whether we’re taxable or not taxable doesn’t actually matter. You’ve got 50 million people around the world, if they want to get to the Internet, they’re relying on us. And so that means that we need to operate with a level of professionalism that was not necessary earlier.

Like before Firefox we had three million people. They were technically savvy, and they were important, but it’s not like 40 or 50 million people who you have to update and think about security when they don’t understand security. Also, when you become like a part of the industry—so one of the things we want to do is build the Internet in the public interest. Not just ourselves, but be a catalyst so that others use Firefox and build Firefox. That means you have to, you have to act like a software vendor so these other organizations, commercial or not, can rely on you.

And so that means you need an infrastructure, and it means you need process, which people think of as bureaucracy, and it means you need to pay attention to other organizations and things that we’ve always been a little, maybe more ad hoc about. We need to be much more orderly. And so you have to pay attention to your, not just your volunteers, like we always have, but those people who built extensions, and you have to have a set of activities that feel very software vendor-like as opposed to open source project-like.

And so all of those things are happening right now, and that changes how it feels, what we do, where we pay our attention, and I think that gets merged in with the organizational piece.

So certainly among the employees, there’s a very strong concern that the corporation stay true to the values of the Foundation. And—I mean, that’s among the people who are here and equally so, or more maybe, I don’t know, I’m not sure if it could be more, you know, from outside. So that is an important, I mean, that’s critical to who we are. At the same time, I think we need to address these issues. Well, if you really want to have a significant and noticeable enough portion of people using your product to drive change, then you need to behave in this fashion. And what does that feel like? Even if we were all still employed directly by the Foundation, and we never formed a subsidiary, many of the day-to-day activities are going to feel just the same. And so, is that something we want? And if you’re uncomfortable, would you give up those users and go back to a much smaller sort of market share and reduce the leverage to driving change in order to live in a more sort-of open source “projecty-like” piece.

Olivia Ryan: In an interview in May 2002 with C-Net you said that one of the lessons that Mozilla learned during its first four years of existence was to set reasonable expectations. And you said that Mozilla was quote, “launched with the expectation that thousands of programmers would suddenly appear to make—to—able to work on this complex key technology. That technology alone was going to make a massive dent in the Microsoft juggernaut. In what ways did Mozilla revise its expectations, and how did practice shift to meet those expectations?

Mitchell Baker : I think the first thing is that when you have complex and powerful technologies, thousands of people don’t just suddenly erupt who are able to—able and interested to work on that. So over the years we probably approached that number, but it certainly takes time. And you know, hundreds of people on a piece of technology is a fine number. So that was one expectation. And in fact, if you had thousands of people every day doing something it would be quite a management challenge.

So, I think one is to realize that the contributors that one wants are like the layers of an onion. You have the key, in our case, probably C++ programmers at the very deep, deep, deep levels of the product. And then there’s a set of people with the application technologies, Java Script in our case, XUL and so on, which is much more broadly dispersed and more people can do that. The QA community turned out to be massively important to us in a way that was not anticipated when the project developed.

So our expectations changed in understanding and identifying different kinds of contributors who mattered. And certainly the programmers at the core have been critical and many of the employees of the corporation found their way in. We came to know them because as volunteers they found their way in. But the QA folks and the localizers who make Mozilla products available in local languages and local regions, of which there are hundreds to thousands of those, plus the people who do a whole range of other things, turn out to be critical as well.

So, one change in expectation is just raw numbers, expecting thousands of C++ programmers right away was off. Secondly, was the kinds of contributors who are important. Third is realizing there’s actually more to technology. More to being adopted than technology. So, there’s plenty of people who have done evangelism adoption work. And fourth, this expectation that an open source project somehow magically would change a monopoly position that the industry itself has been unable to change. It’s pretty aggressive, or pretty optimistic in its hopes.

Now as it turns out, Firefox actually has been able to improve Internet life for all sorts of people, not just Firefox users, but eventually, you know, IE users. And so, I think sometime later we were meeting that challenge but I don’t think it’s one anybody would really set out to take as—you know, take a monopoly position with 90, 95, 98% market share, and somehow change that.

So, it’s a phenomenal triumph that we’ve done that. But the expectation that it would happen immediately or that you could script the timeframe or even set out in advance what the steps would be to make that happen was aggressive.

Olivia Ryan: What do you think the success Firefox will do for, or has done already perhaps, for open source as a whole?

Mitchell Baker: Many things. One is demonstrate that open source can produce an end user product. A question mark beforehand. Two, demonstrate that if the need is great enough and the product is good enough, people will come find it—not known before—consumers. Three, we’re a long-term successful open source project that has managed to create a product, really ‘productize’ something, that’s a new thing. So, many open source projects are infrastructure level, and making a product out of something involves making sure that very technically savvy people can adopt it and use it. But the term productization, which I never really understood until the last few years, is something quite different, because it involves internalizing the perspective of people who aren’t technically savvy and trying to build a product that’s elegant and works for them.

So, I don’t think open source has done that in a mass consumer space before, or with the adoption level that we have. So, you take all of those together and people believe that open source can do more than it could have four or five years ago.

There’s also the case that open source projects—I think in the long run, what other people will look at and say, is that brand is really important. And I know that the folks at Red Hat have said this for quite a long time, but that Firefox is an identifiable project on the consumer scene, even though the code that underlies it is open source and could be duplicated by others.

So, the question of, could you build a business, or what do people care about, has different terms now than it did a few years ago. And we’re not the only thing driving that but I think we’re an important data point.

Olivia Ryan: How does Firefox generate revenue?

Mitchell Baker: We generate revenue through the connection with web services. You know, we’ve talked about the browser as being the mechanism for showing web services to consumers for many years, but in that language people don’t understand it, but when you say ‘search’ I mean, that’s the predominant web service today, and we integrate search into the browser, and so there’s revenue related to that. And it’s not just Google. I hear people talk about you know, the Google search bar, but it’s a Firefox search bar and there’s providers in there other than Google, and if you happen to be in Asia, Google is not the default, and the start page isn’t Google, that’s Yahoo. So, it’s the search. As I think many, many websites fund themselves today as well.

Olivia Ryan: And has the number of paid employees increased since this process—

Mitchell Baker: The search piece?

Olivia Ryan: Yeah.

Mitchell Baker: Oh, absolutely. You know, we did a lot of thinking before we entered into any business relationships. We’d had just Google search in our product before Firefox for quite some time, and in the pre-release versions of Firefox. So that the service to people had been there, in fact for years, I think, but it was a very focused discussion about, maybe there’s revenue there. Should we leave it there? If there is revenue, should we have a business relationship that generates some of that for us? As opposed to leaving it all with the search engines. And decided that it made sense for us to try it. First of all, we know people like search because we’d been in the products and they’d been telling us for a long time. So we weren’t adding a feature that people didn’t want.

Secondly, we needed to support ourselves, and fundraising by non-profits is no fun. And it’s certainly not guaranteed and it takes a lot of time and energy. And you have to figure out what it is that people will give in exchange. So there’s a choice between raising enough money to support yourself in a non-profit way or seeing if you can do it through your product.

Since we had this opportunity that we knew people liked the service, it just didn’t make sense to me in particular, well, to the few of us who were thinking about it, to say, we know that that functionality is generating revenue, but we won’t take any of it and instead we’ll go off and try to ask people to give us money as a non-profit. So after a long discussion we decided that we’d try it and take what had previously been a service for which we didn’t get any revenue and see if we could work out an arrangement where we got some of that.

And so, that’s been more consistent, you know, than the fundraising efforts before and it’s tied to the product which I like, that’s controversial. Some people think, oh, you shouldn’t have anything tied to the product. But I like it tied to the product because that’s what we build, and it shows that the revenue is based on people using the service and liking it and you know, all sorts of things. So that has allowed us to expand.

You know, we’re still pretty lightweight in terms of people for the scope of what we’re trying to accomplish and we’re a giant open source project—in overall contributors and in employees. But we’re still pretty slim in terms of the space that we occupy, because the browser is still so central to the Internet experience. And it’s so complex and it changes so quickly. So, we’re still growing and it is the ability to generate enough revenue to pay people and bandwidth and infrastructure that lets us do that.

Olivia Ryan: And can you explain the relationship among people who work—are employed by Mozilla and people who are employed elsewhere to work on Mozilla products, like Google or Red Hat, or wherever.

Mitchell Baker: Sure. We’ve done this forever in the code. So, we have divided the code into different chunks called modules and those people who have expertise in a certain module will become the owner of that module. And then those people are responsible on a daily basis for what goes into the code. And in many cases they review each patch before it goes in, or they’re able to authorize other people to review and decide what should happen. And that so-called module ownership is unrelated to employment, completely. So, we’ve known how to do that for many years and we’ve had employees of different companies working on the Mozilla code base with volunteers for many years. That’s why I say we’ve been a successful open source project since, maybe 2000, maybe 2001. Somewhere in there.

What else? Then there’s a level of product decision, which isn’t as clear because we haven’t been doing that for as long. There’s some set of decisions that we know—related to the Mozilla brand, and that’s controlled by the Mozilla Foundation—someone at the Mozilla Foundation, probably delegated to the Corporation, must be content that the thing that ships as Mozilla Thunderbird or Mozilla Firefox is acceptable to the Foundation. So, there’s some level of product decision that the Foundation, and through it, the Corporation, have particular responsibility for.

But they key of course is not to exercise that very often in our world, and so on product stuff we do a lot of discussion and consensus back and forth with both engineers and the information from product managers and that discussion is again, unrelated. So, you can go to our website and you know, find out how to participate along with everybody else. Turns out you have to be pretty dedicated to want to do that because it’s a lot of detail, but that’s not limited to employees.

The only thing that is particularly limited to employees is a set of business relationships and information that relates to them, because we’ve found over the years that companies are learning, or have learned how to participate in a free software open source development process. How you get code in, how you talk about code. But when you get to the business reasons for why they want that code, or what they think they’re going to do with it, or how it relates with their products or their business, then they’re not open. In fact, they’re very careful not to broadcast what their product and marketing plans or timing is to their competitors.

So, we’ve learned to live with that. But it does mean that many of the terms of business relationships, in this case the search stuff in particular, is confidential. And we’ve had some discussion back and forth about, well, maybe that’s a reason not to have any business relationships. Because there are some set of information that you can’t talk about publicly. And I’m sympathetic to that but not planning on going in that direction for a couple of reasons.

I’m not sure that’s going to change, right. I think taking on the business practices of how companies talk about what they do and the marketing and all of that, is a long, long battle. Maybe it’s a good battle, but it’s not our battle right now. I would rather take on the user experience on the Internet, i.e. through the browser, as the battle of choice right now. And so if you’re not willing to take that on and require that all of your agreements and every detail be public, you either have to decide we’re not going to do this, and we’re going to go back to the non-profit fundraising, or we’re going to live in this middle ground, which is decidedly imperfect, and try to make the best of it. And that’s where we are.

Ken Albers: Some people recently have been talking about how are we going to protect our technological advances, you know, I’ve read that in a couple of—you know, how do you see that working in an open source sort of—

Mitchell Baker: You mean in the browser space?

Ken Albers: Yes. Like, how do we protect the advances we’re making, you know, that seems sort of antithetical to kind of how open source software works, you know, and I was just wondering you know, if you would—

Mitchell Baker: Well, I think consumers are in for—for an active period in browsers right now, because clearly IE will return, something will happen there. They’ve got some good ideas, they’re smart. We’re pretty active and you know, there’s other browser vendors out there. And you know, features are not hard to copy. So, I don’t think one can protect that. And I’m not sure that it’s so true of open source. Because you can see features in closed source browsers as well and say, hey, that’s a nice idea, we ought to think about something like that.

So, I think there will be a fair amount of feature development which hopefully will be good for users. You know, sometimes it could get confusing. So, we’ll have to watch that. But I think what we stand for and what we protect at the Mozilla world is the focus on individual human beings as being important, not a business plan, or revenue, and the trust in the brand. And the trust that—what we care about is your security, your privacy, your data, and you! I mean, people ask what I think is important about the Internet and my answer is ‘me’. I’m important. Unrelated to whether you make money off of me or not, I’m important and you’re important, and I think that’s the piece that a typical commercial enterprise can never match the way we do. And that’s the ultimate thing we need to protect.

Ken Albers: Yeah, and it’s great for the user then, with the benefit and a lot of hard work on a lot of different fronts but you guys are way more conscious of us I think than any of, you know, a lot of others, certain other browsers.

Mitchell Baker: Right. Well, the thing is, as you know it’s a—it’s a phrase—it’s a virtuous cycle. Of those, say, let’s pick a round number, 50 million Firefox users. No one of those 50 million people has bought a machine and got Firefox on it, right. Every single one of those people has gotten Firefox through a personal choice, some way or other. You, your mother, your father, your brother, whoever it is, somebody, for some reason, has told you that you’ve got this option and you’ve adopted it.

So, we live in a cycle where, not only do we feel that way but our reach is utterly dependent on others agreeing with what we’re doing, so. But I think this question—and it will be a hard one to get known, because it’s easy to compare features and the press loves to compare features, but what’s really different about Firefox is why it exists, and what we’re trying to do with it, right. Not one of us here is going to get rich on it. Not one of us has got any private interest in this, or has, you know, a business plan that’s generating money back into us beyond salaries and so on. So, building for the public interest. So that’s really the piece that I think we haven’t been so crisp about to date because it’s been very product focused, but we need to explain more clearly.

Ken Albers: Do you mind keep on going with that, like just, I mean, why do you think Firefox has been able to attract so many people, you know, what do you really think is there—is it because of that—because they recognize, you know, the philosophy of Firefox, or is it, I mean, you know—

Mitchell Baker: Not directly. Some people do. So, I think it’s many factors. One, the browser is the key to being on the Internet right now. There’s other tools but you do a big chunk of your Internet access through the Internet. A single option for citizens is bad. Bad, bad, bad. We’ve seen that. So, we have this key product. We’ve got a terrible experience for people and finally a choice appears. So all those things lined up. Plus, the indirect piece—let me go back. All those things line up, you know, browser is really important, really terrible experience to date, an option that’s really much better. Many people using Firefox don’t know that it’s open source, or what that even is, or why it matters or why it’s important to them, directly. But indirectly they know it because of the thousands, tens of thousands actually, of people worldwide who know about Firefox, care about Firefox, have participated in Firefox and have gone out to tell people that it’s out there.

So although we get mail from people and they’ll say things like, “My computer was out of control. Firefox is so great. Thank you, thank you, thank you.” Doesn’t mention open source. The reason those products exist and the way it got to them is through this open source process of having people really invested in what you do. So, indirectly it plays a part.

Olivia Ryan: And how is, or has open source sort of principles, influenced marketing?

Mitchell Baker: Ah, well, you should again, talk to folks who are actually doing it. So, a couple of things. One is, our “marketing”, let me put that in quotes for a moment because you might think of it as outreach, has to line up with what the set of people who have built Firefox feel is the right message. So, we’ll often hear, and many companies will do this, they’ll say the marketing needs to line up with their values. Or the marketing needs to line up with their product goals. And that’s true. In our case it’s not just sort of a statement or goal, it’s an absolute requirement. So, the ability of marketing to move beyond that scope is pretty limited.

Secondly, we try to be a lot more transparent about marketing and to involve people who aren’t employees. So, it’s not transparent like the code. At least not currently. We haven’t figured out how to run a marketing program completely in the open yet. But we do have sets of people who have shown that they’re interested, who aren’t employees, with whom we vet ideas, make sure that, yes, what you’re thinking about really does feel like Mozilla. That if I saw, like, that kind of program I wouldn’t be offended. I’d think, “Yes, I participate in the Mozilla project and I’m proud to see this out there.”

And other than that, I think you should talk to the marketing folks and get it directly from them.

Categories:

• featured: These objects are marked as featured, and therefore have higher prominence in the Mozilla Digital Memory Bank.
• interview:

Citation:

Mozilla Digital Memory Bank, Object #7279, 23 July 2007, <http://mozillamemory.org/detailview.php?id=7279> (accesed 9 April 2021)