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.