Archive for March, 2006

The Mozilla project has always been a pioneer in bringing new functions and roles into an open source project. In the early days, this was integrating open source DNA with commercial organizations. A number of people are doing this day, and we’re still learning new things ourselves. Another topic in our world today is the additional of people in non-engineering roles. We’ve generally had a small amount of non-engineering personnel — though for many years this meant me. When the Foundation was formed Bart Decrem joined as our second non-technical person. About the time Bart left Chris Beard joined and picked up a range of non-technical topics. Today we have more such people. This includes roles such as:

• product-wide coordination (this role is often known as “product management” but I’m wary of this label because anything with the word “management” in it generates all sorts of reactions),
• communications and outreach (some of which is generally known as “marketing”, some of which is quite new like the Spread Firefox work),
• working with other organizations in the industry who want to build on our work (classic “Business Development” and “Partner Relations”).

This raises many interesting questions. One is that the open source community is not nearly as rich in home grown expertise in non-engineering areas as it is in developers. So filling these roles often means bringing in people who haven’t “come up through the project.” These folks who are new to the Mozilla project need to be accepted by the development community in order to be effective. Status as a Mozilla Corporation employee isn’t enough.

Another issue is that we don’t have an established path to meritocracy for non-technical roles. For potential developers, we know about several paths for getting involved and developing legitimacy — we know about the Quality Assurance path, we know about fixing bugs, we know something about hacking on the code, we know about writing a great extension and so on. We also have clear ways of identifying a person’s known expertise — they may be a peer for code, a “module owner” for code, etc. All of these are reasonably well understood roles within the project that convey a person’s expertise.

We don’t have analogous paths for non-engineering roles. We don’t yet have ways for the non-engineering staff to indicate the scope of expertise of their colleagues. And we are just building a core group of product coordination, community and partner relations (aka product management, product marketing, marketing, business development) contributors whose judgment and commitment to the project are understood by the technical teams to equal their own.

Itegrating non-engineering contributors takes a lot of trust and feeling our way gently. Those people joining us in non-engineering roles must trust that the technical contributors will give them a fair chance to participate, add value, become respected and gain influence and leadership. The engineering community must trust that these people who may be new to the Mozilla community and don’t have deep technical expertise are worth listening to and giving a fair shake.

Periodically I say or write something like “Please give this person the benefit of the doubt. If they seem off on a path that feels really wrong to you, please say so gently. Assume they are unaware of some relevant fact. Assume they are trying to do the right thing. Don’t assume they are evil, or out to change the project or claim control.” It’s generally worked so far, but it reflects the newness of these sorts of positions to our project (and I think, open source projects in general).

Relying on trust is a funny thing. One absolutely needs it. A well-known system for gaining respect and influence doesn’t mean much if participants don’t trust each other. And, who wants to work in a world that’s full of mistrust? But relying on trust alone without any guidelines is difficult in the long run, is intensely personal and leads to people needing to “reinvent the wheel.”

I’m interested to hear what other projects do, and if there is any general learning on this subject. In any case, we’re working through these issues now. No doubt both our successes and our missteps will be apparent 🙂

I mentioned in a previous post the intention to start grant-making and donations programs to transfer some of the Firefox related revenue coming to the Mozilla Corporation to the Mozilla community and perhaps related efforts. Here is my current thinking on the guiding principles I would like to see used in developing and implementing such a program. There’s plenty of room for improvement and you may have alternative suggestions that would be better. Please let me know.

1. The Mozilla Corporation has revenue from Firefox. We use that revenue to support the Mozilla project infrastructure, activities and a critical mass of employees at the Mozilla Corporation. But the Mozilla project involves many organizations and people besides the Mozilla Foundation, Mozilla Corporation and their employees. The quality and adoption of Firefox are based on the activities of this much larger set of people. Using some of the Firefox revenue to support and strengthen the activities of this larger Mozilla community can benefit the Mozilla project in many ways. It reflects the stewardship role that permeates the Mozilla Corporation and Foundation. It might allow volunteers to devote more time to the project, and help them feel better when they do.

2. Ideally, a grant and donation program will reflect Mozilla project dynamics. We build software in a distributed, collaborative fashion where many people make decisions in their area of expertise and contribute their input to the greater whole. This brings a richness and vitality to the project that no one person or small group of people could generate. I’d like to try to capture that model our grant-making and donations programs.

So my initial thinking is not to create a single, centralized grant-making body that evaluates all proposals. I’m thinking that it might be possible (and very exciting) to create a program that moves decision-making about where grants and donations should go deep into our community. Over the years we’ve had a number of organizations that have played an important role in the Mozilla project — mozillazine, mozdev, Mozilla Japan, Mozilla Europe, xulplanet, the localization groups, the Spread Firefox community come to mind immediately, and I’m sure this list off the top of my head has grievous omissions. These organizations know more about their part of the Mozilla project and their participants than a central organization ever will. One could see these type of organizations as potential recipients of grants or donations. I also see them as potential decision-makers about getting grants or donations deeper into our community — to individual people and activities. Perhaps different parts of the Mozilla community will be best served by different uses of funds. For example, perhaps a set of contributors from one geographic area would propose machines for themselves for their work. But perhaps they would find greater satisfaction and motivation by donating materials to a local library or school to benefit a larger set of people. To my mind, either could be a good use of funds. If anything we try ends up being disruptive we’ll adjust.

3. Large grants may be appropriate in some cases. I’m personally inclined to aim for many smaller grants and donations. The goals in doing this are:

• recognize and involve many people
• try many things to see what works — is buying books for contributors who need them for school a good use of funds? Is helping people get to conferences and events a good use? Are scholarships a good use? Is paying rent or tuition for a contributor a good use?
• reduce the loss when some grant or donation doesn’t work out — nothing is perfect.

4. I don’t know if there is a good pre-existing model for this. It would be nice to find one, since there is no sense reinventing the wheel. I do know there are innovative approaches to identifying needs and donors. For example, I recently donated specific math materials to a needy classroom through the “Donors Choose” program. This program allows classroom teachers to specify materials their students need, and allows potential donors to select exactly the project they want to fund. In my case I choose something I feel strongly about (mathematical literacy) in the public school district I attended (which was bad then and worse now). It means much more to me a general program for “improving math skills” would. I’m not suggesting the Donors Choose program as our model. I mention it because the feel of actually touching someone’s life with something concrete is very real. I would love to see us get something of this feel in what we do.

5. It will take some work to make this happen. But the Mozilla community is the key to what we are and what we do. It is a fundamental element of our accomplishments to date and of our possibilities for the future. Using resources to support that community feels like the right thing to do and a good investment in the expanded health and vitality of the Mozilla project. That makes it worth the effort.

Suggestions, improvements, alternative approaches welcome.

This weekend I had a bad fall to the trapeze net during my flying trapeze class. I was lucky and didn’t get hurt, only scraped a bit. (A half inch cut starting at my eyebrow and a friction burn on my forehead). But it was the kind of fall where one could get hurt, and no good instructor would let a student continue to make the mistake that lead to that fall.

The root cause was a mistake many people make quite often with this motion, which is called a “layout.” Basically one does a backward head over heels rotation with a straight rather than a tucked position. During the first half one holds on to the trapeze bar. Then one lets go, rises above the trapeze bar, completes the rest of the rotation and is caught. The common mistake is to rush at the last minute, particularly when the catcher is there. One learns a flying trick first to the net before the catcher is there. In these cases, there is no possibility of a catch, the flyer knows she is going to the net. The layout is one of the hardest tricks to make the transition to having the catcher in the air. For me that’s because the layout it feels like the flyer is going to kick the catcher in the head. For others it’s a fear of actually knocking heads with the catcher. And for many of us it’s the feeling that the catcher is *right there* (!!!###) and so we need to complete the rotation quickly.

Like many others, I do nice layouts to the net and poor layouts to the catcher. I’ve probably caught 50 of these, and catch them regularly. But they are never good catches. They’re OK, or poor, or maybe better, but they are never good. I’ve heard the mistake described in many different ways and understand it intellectually, but have never been able to translate that into action. Over the weekend I rushed a lot. I also made an earlier timing mistake and the catcher was over-eager and tried to make the catch even though he should have let it go so I could land in the net safely. So I landed badly, banged my face up, and was lucky I didn’t break my nose or foot or pull a hamstring, etc.

This caused some suddenly clear thinking. I had to sit out a few turns to recover my balance and wait for the cuts to stop bleeding. During this time I had a revelation. My husband, in a comment breathtakingly like something my Dad would have said, noted that the fall had “knocked some sense into me.” Suddenly I put it all together.

I could feel the position of my body at the moment I made the mistake. I could see in my mind’s eye the visual cue at the moment I make the mistake. I could hear the instructor’s verbal command at the moment I make the mistake, and, most amazingly of all, I could suddenly feel *both* what I do next when the catcher is there AND what I do correctly when the catcher is not there. Suddenly I am holding in my mind both alternatives. The moment is frozen — the kinesiology, the visual, the audio — and I feel the two alternatives. One is panicky, rushed for time, racing for the catch. The verbal command to let go of the trapeze bar is translated into a rush to get to the end of the rotation, not enough height, too much spin, and ultimately the dangerous trip to the net of a few minutes before. The other alternative is free, open, floaty. The verbal command to let go of the trapeze bar is now the signal to *begin* the floaty second half of the trick.

Now I’ll have to wait for my next class to see if all this intellectual activity actually results in a change of behavior!

Last December we had a gathering of people who were critical to shipping Firefox 1.5. It was called the Firefox Summit and it was about 100 people. I think 10 or so came from Europe, and Roger Sidje came all the way from Australia. We had volunteers, Mozilla Foundation and Corporation employees, and employees of other organizations who are deeply involved in shipping Firefox. (It was an astonishing event for me. I spent most of the dinners looking around in amazement. )

We had a general session on Mozilla Project Dynamics and a discussion about keeping the identity and culture of the Mozilla project as we grow. We’re growing in user base, user needs, contributors, program needs, scale of infrastructure, industry stature, employees (both employees of Mozilla Foundation and Corporation, and employees of other organizations), and management. How do we keep the core identify of the project in the midst of this change?

Ben Goodger made a comment that stuck with me and has been connecting with some other thoughts lately. Ben noted that our identity is deeply tied up in how we build software. A continuing focus on openness, peer review, merit, leadership through reputation, influence through action in building software is fundamental to our continued health. In one sense this seems obvious, but I have found it very helpful. There’s a lot going on with Mozilla and Firefox these days; it is very helpful to focus on the fundamental thing we have done well for years and years, even before the world knew of it — we build software in an open, distributed manner where people choose to participate because the project is worthwhile and works at least well enough. I think of this often as I think about how to manage all the new things that are on our plate today. I also think about it in relation to a set of questions about management and an open management style — more on that later.

I’ve been following the news reports that Symantec has decided to change the way it counts security threats for browsers. Symantec is moving from a system which counted only vendor-acknolwedged problems to two categories. One is vendor-acknowledged and one is both acknowledged and not-acknowledged.

I want to applaud Symantec for making this change and for noting that this is a better methodology. The new method is better because it reports serious problems whether or not the vendor has acknowledged them. The information citizens get should not be so dependent on what the software vendor chooses to tell them, so this is a good step.

The new method is also better because it removes an insidious (and I’m sure absolutely unintended) side effect of rewarding software vendors for not acknowledging problems. Acknowledging problems is hard enough in any setting — for companies, for people, for most organizations. Symantec’s new system removes this unintentional public relations reward for not acknowledging problems.

The Mozilla project creates its own internal incentives for acknowledging security issues in a timely way to protect consumers. We do this through our community and our open source development process. We open our code to people who are not employees. By doing so we make sure that we have independent experts involved in improving Mozilla products and acting as consumer advocatees. These experts monitor our performance constantly and provide an expert voice in getting security information from the Mozilla project to our user base.

Security in the Internet era is a complex, constant process. No one is perfect today, and no one will be perfect tomorrow. Internet security will be a hard problem requiring vigilance for a long time. Protecting consumers over the long run requires a software vendor to have appropriate motivations, effective policies and develpment methods, and of course, good results. In this setting a strong, open process with built-in consumer protections is critical.

We’ve pioneered such a process and we see its results in our products.

I’ve been thinking about how to describe the goals of the Mozilla project, and how the Mozilla Foundation and Mozilla Corporation fit into that. By “Mozilla project” I mean all the people who are involved, unrelated to any employment relationship. The Mozilla Foundation, including its subsidiary the Mozilla Corporation, together make up only a small portion of the people involved. It’s important that the Mozilla Foundation remain in sync with the larger project it seeks to lead, and that we have healthy discussions about that goal.

We’ve been using the goal of “choice and innovation on the Internet” for some time now. Recently someone asked me for a history of this phrase. I did a bit of research, here’s what I found.

I. Pre-Foundation website.

As far as I can tell, I think we started using the specific phrase “choice and innovation” when we created the new web pages for the Mozilla Foundation. Before the Foundation existed, our web site and communication was mostly internal, aimed at developers and participants in the project. It was less aimed at end-users or at the general public. So the mozilla.org site did not have a focus on explaining the importance of the project in general terms.

II. Pre-Foundation Public Statements

In the pre-Foundation era I did explain the importance of the Mozilla project to the press, particularly around the release of Mozilla 1.0 in June, 2002. I’ve found and copied a few of these interviews that were done by email below. The comments show their age a bit (2002 was a long time ago in Internet time) but overall still seem relevant today.

Question: “What is your view on the market share currently held by the Mozilla browser? Is it important to take on Internet Explorer? (if it is, how to do that?)”

Answer: “The Internet is becoming an increasingly important part of our lives. ‘Browser’ software is the means through which consumers and citizens access and manipulate data via the Internet. It is an unhealthy situation to have only one means of accessing Internet information. It is unhealthy to have our means of accessing the Internet determined by the business plan of a software vendor. The goal of the Mozilla project is to provide alternative, open source software through which people can access the Internet. This is a critical piece in allowing the needs of citizens and consumers to determine the development of Internet technologies.”

“The Mozilla project provides a viable, vibrant technical alternative to Internet Explorer. This alone is not the entire story, distribution is also important. But distribution is impossible until a viable technical alternative exists, and Mozilla provides such an alternative.”

Question: “Going further than the published roadmap, where do you see the Mozilla browser five or ten years from now? Which kind of features may be incorporated in the future?

Answer: “The Internet is a diverse environment. Human beings can access their data and conduct transactions on the Net based on their goals. Different people choose different means of doing so, some focus on convenience, some on protecting their privacy. Innovation has returned to “browser” software, providing new convenience to users. Many of us use devices other than desktop computers to access the Internet, and Mozilla based software helps power the change.”

Answer: Our goal is a World-Wide-Web where consumers have choice, and where no single entity dictates what the consumer can do or see. In other words, to maintain effective consumer choice in how our personal information is transmitted and used. We’re dangerously close to losing that choice now, as more and more websites provide their data and services in formats only IE can understand.

III. The appearance of “Choice and Innovation”

I believe the “choice and innovation” phrase first appeared in Nov. of 2003, when we set about finding a good way of describing our purpose that could be easily absorbed and understood. “Bonsai” (our web-based tool for showing what has changed in our source repository) suggests it appeared in version 1.2 of the “about” page. The phrase also appeared on the front page of the mozilla.org website when it was revised in mid to late Nov. 2003. In this case the reference was:

What is Mozilla?
The Mozilla project maintains choice and innovation on the Internet by developing the acclaimed, open source, Mozilla 1.5 web and email suite and related products and technology.

IV. What I take from this

“Choice and innovation on the web” has been an excellent way to describe our goals or mission so far. The phrase has developed staying power because it expresses a basic nature of what we’re doing. My believe is that “choice and innovation” is a great starting point, has served us well and is part of our heritage that we should look to. I also suspect it is not enough to guide our daily activities. Is any innovation equally desirable for us to pursue? And do we care if choice lead to a better overall better experience? If so, for whom? “Choice and innovation on the web” is a great foundation, and I’m proud of it. We have the opportunity and the responsibility to build upon this foundation and define what we think the Mozilla project can and should do to make the net a better place.

As part of talking about organization, goals, etc. it might be helpful for me to lay out where I think things stand today. To the extent other people agree we’ve got something written down. To the extent others have corrections, changes and disagreements we can identify those and start discussions. I’ll start with the Corporation.

1. Mozilla Corporation Employees. The Mozilla Corporation has about 40 people working for it now. That’s about 40 “FTEs” or” full-time equivalents.” Some people work part time. Most of those employees are in the United States or Canada. That’s partly because of the history of people working on the project from before the Foundation/Corporation were formed. It’s also in part because it is difficult to hire people without having a legal organization in the country in which they live. It’s hard for the Mozilla Corporation to hire people in Europe of Asia without having either a series of branch offices or forming subsidiaries. We are able to engage people as contractors in some cases, and try to do this when the work involved fits with the legal definition of “contractor” applicable to us and the potential contractor. One of the things on our list of things to do is to try to figure out how to improve this. I’m distressed at the idea of forming more legal organizations. But the difficulties in not able to hire people outside the US and Canada is a bigger problem. More legal organizations is annoying but living with the limits on hiring is something that has to change.

The largest number of Mozilla Corporation employees in a single place are in Mountain View, California. The next largest concentration is in and around Toronto. Others are spread out, often one person to a locale.

2. Mozilla Corporation Revenues. The Mozilla Corporation pays its employees from the revenues we receive from our product. We are very fortunate in that the search feature in Firefox is both appreciated by our users and generates revenue in the tens of millions of dollars. People sometimes ask if there are other features from which we could make money. The short answer is: We don’t know. Perhaps search is the only feature that will both benefit users and generate this kind of revenue. We’ve seen browsers that appear to have sold off all sorts of features and links to website with an eye to revenue rather than helping people make sense of the web. We won’t do that. The people working on the product couldn’t stand it and our users would abandon such a product.

I sometimes hear people refer to Firefox’s “Google bar.” I understand this but it’s not quite accurate. The Search Box has Google as default in many languages, but always has options for the consumer to choose. I think it’s a *big deal* that both Google and Yahoo are next to each other in the same product so that consumers can choose. (The UI for this is tough, I agree about that.) And Yahoo is the default search for Japanese, Chinese and Korean. So if you are using Firefox in those languages the “Google bar” wouldn’t make sense.

We’ve been using the money generated from the search providers exclusively to build the capabilities of the Mozilla project. We’ve hired people. We’ve built a much more robust infrastructure. (This may not sound like a big deal, but the server load of what we’re doing with update and extensions is significant.) We’ve got a “reserve fund” now which I view as extremely important. Having savings means that people are much more likely to believe us when we say we will turn down revenue if it doesn’t benefit the user. We’ve always said this, and we’ve meant it. Or to be more personal, I’ve always said it and meant it. One sounds naïve when one says this, particularly to large commercial enterprises. It helps people comprehend my statements when we have a reserve fund that allows us to operate whether or not we’re interested in them.

In the near future the Corporation will be looking at how to disperse some of the funds generated outside of our corporate structure (and here I mean outside both the Mozilla Foundation and the Mozilla Corporation). I’ve been told by some people that this is risky and that the thought of money distorts the community. I’m sure all that is possible. But we do have money in the project now and some of it should get spent on a project-wide basis unrelated to employment. I’m hoping we can do this in a way that reflects our community organization and distributed authority. I’m not sure what the mechanism is yet but I know it needs to happen.

3. More Topics. Now that I’ve started, there’s a lot more to say. Topics that are on “the tip of my tongue” include: the health of the community, the relationship between the Mozilla Foundation and Mozilla Corporation; long-term goals of the Mozilla project; developing a more open communications style in non-code topics; how do coordination and “management” fit in; what roles has the Mozilla Corporation been hiring for and why. But in the spirit of writing more informal, *digestible* posts I’ll stop here now and put those thoughts in separate posts.

I learned another lesson about fear in my flying trapeze class last night. I’ve been doing flying trapeze for about 5 years now, and a lot of it is overcoming fear. Last night’s lesson was small, but struck me.

To do anything on the flying trapeze, you first climb up to the platform (about 22 feet off the ground in the gym I go to), grab hold of the trapeze bar with one hand, jump off the platform and put your other hand on the trapeze bar. Then you kick backward as hard as you can, so the body is in a giant arch. (Here’s a video of a nice warm-up swing). I kick back late. I’ve been told repeatedly, but something kept me from fixing the timing. That something was a fear of bashing my feet into the platform. Not the biggest thing I’ve been afraid of with the flying trapeze, but it’s been enough fear to stop me from fixing this problem. I’ve worked on plenty of other things to make the swing stronger and higher but conveniently ignored this.

Last night the timing got so bad it started messing up all the things that come afterward. So I had to address it. Sometimes the best approach is to be absolutely determined and force one’s body to react despite the fear as an act of willpower. Sometimes the alternative approach of relaxing and trying to “let go” of the fear is best. Often nothing works for a while 🙂

Last night the results of not fixing the problem were too clear to ignore, and after a false start or two I finally managed to push aside the hesitation and put all the energy into the kickback when I was told to. The result was instantaneous — power. More power in the swing, more height, more time. And unexpectedly, the moment of full extension brought not only power but also an moment of lightness, of complete freedom. And with it, an instant of exhilaration. I’ve known for a while that when my actual position lines up with what the physics of a good swing call for, a moment of “float-i-ness” or seeming lack of gravity appears. At these times it feels like one has all the time in the world.

Last night I learned again how a small amount of fear, seemingly too small to matter much, has far greater impact than one might imagine. That’s what I love about trapeze — these lessons are combined with a level of fun that seems too good to be true.

My experience with the Mozilla project in 2005 was about a few things:

1. Growing our organization into the stature the rapid adoption of Firefox brought us. We started the year with about 15 people, and an unexpectedly large set of users. Organizationally we needed to get more people involved full time to take care of things, to build our physical infrastructure (with special thanks to the Oregon State University Open Source Lab), to take care of our user base, and to start to add more coordination among our contributors. Coordination means management of resources so we added a few managers to the employee base. Management in an open source project like ours is not as well understood or developed as code development in an open source project, and I hope to describe our thinking more clearly here and to generate discussion before long.

2. We adjusted our organization a bit, forming the Mozilla Corporation as an adjunct to the Mozilla Foundation. Personally, this was a lot of work. It needs more work, in particular to work explain, refine and further develop the roles of the Foundation and Corporation to help guide the Mozilla project.

3. We shipped Firefox and Thunderbird 1.5. This was important to get updated technology to our users and to provide a way to help protect users through automatic update, particularly for improvements related to security and privacy. It was also important to show that Firefox 1.0 wasn’t a one-shot wonder; that we understand how to ship software on a regular basis. We also broadened our search relationships, with Yahoo becoming the default in the Japanese, Chinese and Korean languages.

We did a lot of other things, but these are the chunks that occupied me for long periods of time.

In 2006 I see a continued focus on products. This has always been the core of what we do and we will continue to ship great products. For me personally, another large focus is in articulating the overall nature and goals of our organization and the means by which we will seek to achieve them. What is the mission of the Mozilla project? How do we best achieve these? What should the Mozilla Foundation do to help people enjoy free, useful participation in what the Internet offers? How best can the Corporation develop products and technologies to promote this goal? How do we combine management with open source DNA? How can I help bring the open, collaborative and distributed decision-making principles of code development into management and leadership of the Mozilla Corporation?

I don’t think there’s a how-to guide about how to do this 🙂

I’m going to try writing more shorter, informal thoughts than I have been. Please bear with me if they are awkward or only partially formed.