Posts Tagged with “staff”

One of the big changes Firefox initiated was our extension model. It’s turned out to be an important area for keeping the minimalist product goal, providing opportunities for customization and innovation, and creating an active area for developer involvement. There’s a lot to think about to make the extension world work well, and to help developers building on our products more generally.

Mike Shaver has agreed to turn his focus to these topics. Mike has been involved in many aspects of the Mozilla project starting way back in 1998, and has done a varied set of things since joining us full-time last summer. Mike is now going to turn his focus to the extension space in particular and the software ecosystem around Firefox and our technologies in general.

Mike’s initial focus will be on the extension space, where he’ll coordinate the development of a clear strategy for helping users and developers get the most out of Firefox extensions. I’ll leave it to Mike to specify in detail his current view on what this entails, and how he’ll go about learning more from interested people.

More generally, Mike will focus on development of the ecosystem around Firefox. The goal here is to work with technical leads, partners and our community to make developers happier and more productive with Firefox and the web.

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.

Traditionally, our Roadmap has been a short, very high level document that identifies the key issues of an era and sets direction in those areas. I’d like to see us try out a new approach to our roadmap going forward.

It would be very helpful for the Platform roadmap to become more of a working document, one that sets a global framework for what we’re doing, and is also tied structurally to other, more detailed planning documents. It should help engineering contributors relate their work to the overall plan, and should help everyone see what’s planned and how the pieces tie together. We should have an explicit plan for the Mozilla “platform” (often known as “Gecko”) and we should have an explicit plan for the products, starting with Firefox. Perhaps the two plans together are the Roadmap, or perhaps we have a product roadmap and a platform roadmap, I’m not sure. But in any case the two must be closely related.

I’ll outline here a plan for the platform piece, with the understanding that the product piece will follow closely. Mike Shaver, with Brendan’s encouragement, has started the effort to produce a platform roadmap along the lines I describe below.

More specifically, here’s a plan:

The Platform Roadmap remains a short, high-level document, but would provide a level more detail than our current and past roadmaps. For example, the next iteration should describe the technology capabilities of the Mozilla platform in the 1.9 release. It should have an outline of the major areas of technology that we know we’re working on for our 1.9 release, plus a summary of the rationale for these areas and a general statement of what we hope to accomplish in the 1.9 cycle. This document must have an owner who is responsible for the overall integrity of the plan, for including the correct areas of technology, and for figuring out how they relate together and for the ongoing vitality of the document. In my mind, this person is Mike Shaver, in close collaboration with Brendan Eich. By close collaboration I mean that Brendan is integral to the process and the document isn’t complete until Brendan signs off on it. By designating Mike Shaver as the owner I mean that it is Mike’s job to drive this process, to make sure the document gets written (either by writing it himself, or getting others to write pieces) and to sign off on the content as well. This means Mike is responsible for getting the deliverable done while needing key input from others. It’s a bit of a juggling act, and one for which Mike is uniquely suited.

The Platform Roadmap should provide pointers (links, references, etc.) to the more detailed planning and implementation work being done by the contributors. For example, there should be pointers to more detailed information on the state of our graphics initiatives such as cairo and SVG integration. The goal would be that someone can look at the Platform Roadmap, see that we’re working on a set of initiatives, follow pointers to those projects and get more detailed goals, schedules and status.

This detailed project-based information would be maintained by the contributors working in this area. This should help give the groups of contributors a way to describe what they are doing, and to have greater involvement and ownership in determining the deliverables, a reasonable schedule, etc. This second level of information will take some work to get pulled together. Perhaps not as much as might be expected, since many of the contributors working on major initiatives have documentation and status information available already and we can point to that information from the Platform Roadmap. In some cases we will have more planning to do. And in all cases the contributors will need to make sure that the description and status of their initiatives remains accurate. But of course, we need to do this in any case. I’d like to see the Roadmap become an organizing framework that allows us to get the most use out of that work.

This means that the Roadmap becomes something that the organization as a whole works on, works with, and relies on. That allows other organizations interested in Mozilla technology to rely on it as well, and to get better, more up to date information about what we’re doing than we currently provide.

This type of “roadmap” is something different from the past. It combines the high-level direction setting of past roadmaps with a new operational role. Mike Shaver is ready to take this on, Brendan is working closely with him and pushing to make this successful, and they plan to have a draft Platform Roadmap posted in the next couple of days. It will be a draft, it will undoubtedly need revision and have plenty of room for improvements. But I’m optimistic we’ve got a plan that lets us make progress. And that’s good news.

We have added some new people and management capabilities to the Mozilla Foundation engineering organization recently and I’d like to let people know how they fit together.

First, Mike Schroepfer has joined the Mozilla Foundation as director of engineering. We’ve talked many times about the need to integrate overall product goals, specific engineering goals, technology goals, resource planning, engineering coordination and management much more fully in our development process, and to have someone chartered to guide the overall engineering effort. We’ve talked about this among employees, and I’ve received mail from a set of other community members noting the need for more organization, communication and planning as we grow. Mike is the person the Mozilla Foundation has asked to do this. We’ve consistently identified organization and knowing what other people are doing as areas needing improvement. So we’ve asked Mike to focus initially on product planning and delivery. We have planning efforts underway for specific areas, such as graphics, layout, content, toolkit, XULrunner, Firefox, Thunderbird, Firefox 1.1, Gecko 1.9, etc. We have asked Mike to lead the effort to bring these into a coordinated whole and to drive our efforts into cohesive product releases.

Mike will also take on the classic people management functions for those people who are employees of the Mozilla Foundation.

Chris Hofmann has picked up a number of special projects in the last 18 months that need more attention. Having Mike Schroepfer on board means Chris Hofmann will now focus on these projects. The two most active projects today are working with organizations interested in understanding how to integrate with our technical development team; and the security work.

There are a number of organizations that want to understand how to work with us. These include the companies who have engineering groups working on Mozilla, companies wanting to use Mozilla technology, companies thinking about support for Mozilla projects, to name a few. These needs have gone up dramatically in the last 6 months and we need more focus in this area. On the security side, Chris has been working with Secunia, our security group and interested parties. He’s been tracking security issues, proposed fixes, what those might mean for the web and so on. He’s been helping those who find bugs understand our process and figuring out good ways to work together. Security is a topic that will require even more attention in the future. Chris also has an enormous amount of information about our engineering and release processes; he’ll be spending a chunk of time initially making sure that information is dispersed throughout the organization.

Mike Shaver is now officially working with the Mozilla Foundation. We’ve asked him to help identify and investigate technical domains which we should understand, and to help figure out and drive implementation of what we should do in these technology domains — should we build our own offering, partner with an offering from another source? Examples of the kinds of technologies that Mike might investigate include “identity,” “presence”, VOIC, XMPP / instant messaging. Mike will work very closely with Brendan in these areas.

We’ve also asked Mike to help us bring out “platform” strategy and our product focus into crisper alignment, and to help us think of our platform technologies in more product-like terms, requiring not only technical excellence, but also an understood scope and good delivery mechanisms.

Brendan Eich will continue in his role as the guiding voice of our technical development. No changes here, I include Brendan so no one wonders why I’ve left him out.

These changes also allow Chris Beard to focus more on products, helping bringing a product focus to our engineering efforts. We’ve done some work in this area, but a great deal needs to be done and it’s a big step forward to be able to give Chris Beard time to do this. Chris has done a remarkable job at filling many roles, I’m very excited to be able to offload some of the operational and other tasks to have allow him to think in a much more focused way about our products, and to make sure that this thinking is closely tied with our technology and engineering plans.

Needless to say, everyone will be working closely with each other and with the engineering mechanisms the project has developed — drivers, module owners, reviewers, etc. And there is always a fair amount of “doing what needs to be done” so flexibility remains key.

A couple of weeks ago I wrote something about my belief that mozilla.org staff membership is different than employment with the Mozilla Foundation. Here’s a concrete example of questions that come up: email addresses. It almost sounds trivial when I write it. But email addresses are often a statement of identity or relationship and so they turn out not to be trivial I believe that membership in mozilla.org staff is not a decision that should be made by the Mozilla Foundation. And a hiring decision by the Mozilla Foundation should not automatically convey mozilla.org staff membership.

When we set up the Foundation a set of key contributors became employees. Some of these people were mozilla.org staff members (Asa, Myk, Leaf, Brendan, me) of long tenure. Others were key contributors who had previously been employed to contribute their work product to the Mozilla project but weren’t officially chartered to speak for the Mozilla project or guide its general policies — jst, dbaron, Ben Goodger, Scott Macgregor, Chris Hofmann. (If this sounds obtuse or too “inside” to be understandable, please take a look at the Mozilla Roles and Responsibilities doc which lays out the role of mozilla.org staff in our past incarnation.)

It’s pretty hard to argue that this latter group of folks haven’t been “speaking for the Mozilla project” or guiding policy or determining releases or doing the myriad of things that mozilla.org staff has historically been chartered to do. Even so, we didn’t have a policy for what mozilla.org staff meant vis-à-vis Mozilla Foundation staff. So we didn’t officially make these new people staff. That is, they are (still) not listed on the staff page. However, we did give them “@mozilla.org” email addresses. These addresses have historically been limited to mozilla.org staff members. And in the real world, an email address that is in use everyday is probably a much clearer indicia than a listing on a web page most people never see and may think is outdated anyway.

As management goes, I’m not proud of this. It left key contributors in a state of limbo that would have best been avoided. However, I felt it was important for the health of the project to keep the idea that mozilla,org staff membership means something separate from employment status. Fortunately the people living in this limbo are dedicated primarily to the success of the project and were able to live with this. As I said, tolerance for ambiguity is a key value.

Then we began hiring a few more people. By this time I had realized that not having a process for determining staff membership meant that we really shouldn’t give out “@mozilla.org” email addresses. Not just realized it, which wasn’t hard. But realized it enough to force implementation of it. So over the last year we’ve hired a set of people and asked them to continue to use their own email addresses. More precisely, I have declined to authorize more “@mozilla.org” email addresses. (I would say refused, but we haven’t had a real fight about it. Maybe others would say refused.)

Again, I’m not proud of this. It’s definitely been awkward for the people involved. So we’re going to create email addresses for Mozilla Foundation employees. I’m not sure what they’ll be — @mozillafoundation.org perhaps. That’s awfully long so perhaps we’ll choose something shorter. Those of us with mozilla.org addresses will probably continue using them, just as current staff members employed elsewhere use their mozilla.org addresses.

I expect that these new addresses will remain in use after we figure out the relationship between mozilla.org and Mozilla Foundation staff. Maybe it will turn out I’m wrong, and we’ll end up realizing that there is no need for mozilla.org staff or no need to distinguish it from Mozilla Foundation employees. But we spent years learning how to build an organization and manage the project separate from an employment chain, and I don’t want to let that experience fade away by accident.

When we figure out exactly what the email addresses representing employment with the Mozilla Foundation will be we’ll say something about that, and hopefully get them implemented soon. And of course we’ll keep working on the question of what mozilla.org staff membership means — or could mean, or should mean — in the current era.

I remember when I joined the Mozilla project I was astonished at how much energy went into technical topics that didn’t seem so important to me. I’m embarrassed to admit this included such things as directory names. Now of course I understand their importance better. And judging from the attention I have paid to the topic of email addresses and organizational identity, I have come to fit right in!

For months I’ve said I’ve been optimistic that the Mozilla Foundation would be able to reach an agreement allowing us to host and improve the materials from the former Netscape DevEdge site. I’m very pleased to report that my optimism was well founded.

We’ve reached an agreement with AOL that allows us to post, modify, and create new documents based on the former Netscape DevEdge materials. The agreement is done. I want to thank AOL for making this happen. Netscape DevEdge was a great resource. We’re very pleased those materials haven’t been lost and that the Mozilla Foundation can host their continued development and use. I also want to thank the many people who wrote to offer encouragement and help regarding the DevEdge materials — your encouragement was very helpful.

What happens now? Well, we probably won’t be able to simply recreate the site — we don’t have the build scripts for one thing. Naturally, we’re eager to get the data sorted out and the most important documents posted asap.

Starting next Monday we’ll have a new person working full time at the Mozilla Foundation to help with just this activity. On Monday Deb Richardson joins the Mozilla Foundation as a Technical Editor and Project Manager for DevMo. DevMo is our community based project focused on developer documentation and resources. We have a group of people interested in working on this, and are thrilled Deb can join us to provide the overall coordination, support and project management for this effort, working very closely with our volunteer community. Deb comes to us with extensive documentation and open source experience, having founded both Linuxchix and the Open Source Writers Group. She has also worked professionally as a technical writer, freelance editor, web designer and developer.

One of the first things we’ll ask Deb to do is to work with those familiar with the DevEdge material and sort out the most important documents, get those posted asap, and then develop a plan for handling the rest of the material. We want to make critical resources available asap and also build a coherent site. We already have a website at the developer part of mozilla.org that is hard to navigate, not well designed, and filled with material that is or may be outdated.

In the beginning of the Mozilla project there was the “mozilla.org staff.” Mozilla.org staff is the virtual organization that guided the Mozilla project, spoke for the project, developed and implemented policy for the project. At its inception, the individual members of mozilla.org staff were all Netscape employees. As time went on more and more mozilla.org staff members were volunteers or employed by someone other than Netscape / AOL.

Over time mozilla.org staff took over more and more of the activities previously managed by the Netscape management team — milestone releases, managing the CVS tree and so on. Mozilla.org staff members guided both the policy decisions and the daily operational decisions that kept the project going. Some years ago I described the role of mozilla.org staff in some detail in the Mozilla Roles and Responsibilities document.

The Mozilla Foundation was born in July of 2003. For the first time we had an official legal organization that could hold the critical assets and hire people to work on the project. Launching the Mozilla Foundation was a hectic and pressure-filled time. The pressure grew continuously through the release of our 1.0 products. I’m sure anyone who’s been through a make-or-break product release cycle will understand this!

With the creation of the Mozilla Foundation it was clear that some thought needed to be given to the relationship between mozilla.org staff and Mozilla Foundation employees. But we also needed to get the Foundation off the ground, establish key relationships, focus on maintaining our development community, think out how to raise enough money to sustain ourselves (a big topic, more on that later), develop our new applications and make progress on the underlying platform technologies as well. So the question of rationalizing the roles of mozilla.org staff and Mozilla Foundation employees (ie, Mozilla Foundation staff) has been on my mind, but not front and center. We’ve trimmed the mozilla.org staff list to reflect those people who have moved on and are now longer active. But we haven’t had a policy for what “mozilla.org staff” means in our new incarnation and so we haven’t added anyone to it. Even key players like our lead developers aren’t officially listed as mozilla.org staff members. (Tolerance for ambiguity is probably a characteristic of those comfortable in our world.)

The Mozilla project still has a great deal to accomplish, and we’ve all got more to do than we can imagine finishing. But we have successfully completed a series of milestones with the release and adoption of Mozilla Firefox and Mozilla Thunderbird. So I’d like to start the discussion of mozilla.org staff and Mozilla Foundation employees.

I have a few basic premises that drive my thinking. I should be clear here — these are my personal views. At some point I’ll write an official policy for review and (hopefully) adoption, but this isn’t it. My current working framework is:

• The Mozilla project is bigger than the Mozilla Foundation
• The Mozilla Foundation does not and probably never will employ all leading contributors to the project or all those whose voices represent the project
• An employment relationship with the Mozilla Foundation should not take the place of peer review and leadership through respect
• A single management chain, even that of the Mozilla Foundation itself, does not reflect the diversity of the Mozilla project
• An employment relationship with the Mozilla Foundation should not be necessary in order for key contributors to have a respected voice in the direction of the project
• Checks and balances create a messy governance structure but are nevertheless worthwhile

In concrete terms this boils down to my belief that (1) a role for “mozilla.org staff” is important for the project, and (2) this role will build upon and modify the previous role of mozilla.org staff.

It probably doesn’t make sense to continue the previous role of “mozilla.org staff” unchanged. Before the Mozilla Foundation, mozilla.org staff was the group involved day-to-day, making the operational decisions. Doing this requires pretty intense, constant involvement and Foundation employees do much of this. A staff member who isn’t involved on a serious if not full time basis will have trouble keeping current with enough info to make these decisions. This isn’t to say that I believe that dailyoperational decisions should be made only by Foundation employees. It’s possible this is the case, but I can also envision scenarios where this is not the right path at all. But I do believe that maintaining a group separate from Foundation employees to make daily operation decisions is a mistake.

There should be a mechanism for clear, valued input into project direction and Foundation activities by those who are not employees. Our open-source DNA gives us mechanisms for this when code is involved — module ownership, peer review, leadership through reputation, etc. I think it’s important to develop mechanisms for significant issues that don’t end up in source code. This could be extending the Module Owner system to non-code areas. It could involve a role for mozilla.org staff. Perhaps both; perhaps something entirely new. The Mozilla Foundation will grow and change over the coming years. I want to do so in a way that delivers great products, moves the web forward and reflects the community that has built the Mozilla project.

There’s much more to say but I think I’ll stop here since it’s getting late and there’s no need to get everything into one comment.

I recently came across a post I started many, many months back (like a year ago) but never finished. So I updated it. Here are a few short vignettes of coming to work at the Mozilla Foundation.

Some months ago (this would be late 2003) there was a rattle at the door of the Mozilla Foundation. Our office is one big space, and it was about 5:30 pm, smack in the middle of prime working time, so everyone looked up. Someone actually got up, opened the door and let the new person in.

The visitor looked right at home. He had a cardboard box under one arm, and knew exactly where he was heading. No one said a word; he went straight for a desk, dropped his box down beside it, sat down, plugged in his laptop and settled in. As he connected to the Mozilla network he lifted one arm in a giant “score” sign, a small cheer went up and he went to work. He was no visitor, he was our then-newest employee. He had finished his exit interview at his previous job, driven straight over to the Mozilla Foundation, plunked himself down at 5:30 and started work. I’ve never seen someone looks so happy at starting a second workday.

This morning (August or September 2004) there was another rattle at the door. Someone got up to open it and asked — does anyone know this person? Marcia replied “Maybe it’s Chase, he’s supposed to be here to start working as a Mozilla Foundation employee today.” Chase is our new build engineer, stepping in since Leaf has moved on to other things. We knew Chase by name and skills, but none of us knew what he looked like. All of our interviews had been done by phone, since Chase wasn’t living in the San Francisco area. Someone opens the door, there’s an awkward silence as the visitor looks around and we all look at him. Feeling responsible but a little awkward I get up and mumble something like “Hello, er, ah, are you Chase?” Sure enough, this is no visitor, it’s our newest Foundation employee. Wahoo!

Update 1:

7 days ago (Fall 2004) Chris Beard arrived for his first day. This time we all knew him, as he’s local and pretty much everyone in the Foundation met Chris before he joined us. So we greeted Chris by finding a half-empty desk periodically used by visitors and inviting him to make himself at home. This went on for a few days until Chris unleashed a frenzy of spatial reorganizing. Looking up one day he noted “We probably should actually figure out where I might have a desk because the person who uses this one is going to be back one of these days.” I suspect it may be because his temporary desk left he and I starting at each other across the table, and some distance is definitely a good thing. Soon machines were moving, racks were moving, our swag pile was moving, people were moving and desks were rearranged. Asa profited the most, coming away with a nice space near the windows and the sunlight he so craves. My own craving for a window and a nice space has totally evaporated — I can’t tell if this is good or a sign of trouble. In any case it’s convenient.

Update 2:

Doug Turner has arrived. There wasn’t much available room after our last re-shuffle, so Doug got the space facing the door. Doug addressed that problem by turning his back to the door, making a space with two desks and hunkering in. He still graciously answering the door when we have visitors, but I’ll bet he’s waiting for our next spasm of reorganization.

Update 3:

Today I came in and found that the giant chess board (about 18′ by 18′ — literally) has been folded up and moved out of the center of the floow. We’ll pull it out for special occasions. There is also a new cluster of desks set up under the soda-can bridge (a 19 foot long replica of the Golden Gate bridge made of soda cans, brought from Netscape and lovingly but partially reassembled by chofmann). So far, no one has claimed the new desks — maybe looking up at soda cans is inhibiting people. Or maybe people are waiting for the “real” office furniture we’ve been talking about getting, since we need some ergonomic upgrades.

We didn’t really throw much away in all any of these rearrangements — we have a hefty supply of things left over from the Netscape era or accumulated on our own. Now there’s the real challenge!

Ben Goodger has just noted that his employer has switched from the Mozilla Foundation to Google. We expect Ben’s role within the Mozilla project to be just about the same as the role he’s played for the last 18 months — pushing Firefox and the Mozilla platform ahead, and focusing on improving people’s experience with the Web. Ben has been the lead engineer for Mozilla Firefox because of his talents and drive, not because of his employment status with the Mozilla Foundation. We expect this to remain true.

This is not unusual in the world of the Mozilla project. A number of people have moved from one employer to another within the Mozilla project. IBM, Novell, Sun, Red Hat, Oracle and now Google have employees contributing to the Mozilla project — some dedicated, some part time, and some as individual contributors. Having multiple companies offer jobs to key Mozilla figures has long been a part of our view of a successful project and we’ve traditionally worked closely with companies whose employees contribute to the Mozilla project. We’re looking forward to more great progress with Firefox and the Mozilla platform, and we don’t foresee changes in Ben’s role.

Some people have asked if this means that Google has a corporate voice in Mozilla Firefox. The answer is “no.” Ben is the Module Owner for Firefox, and as Module Owner he has responsibilities to the Mozilla community. These responsibilities are documented in our policy on Module Owners and Ownership. The key responsibility is that the Module Owner’s job is to act in the best interests of the community and the project at large, not in the interests of his or her employer. Ben has lived with these responsibilities as a volunteer, a Netscape employee, a Mozilla Foundation employee and now as a Google employee. We’re confident that Ben will continue to help us drive great innovations in the browsing world.

We have some additions and changes to the Mozilla Foundation employees, and I’d like to make some belated introductions.

First, we’d like to thank Leaf Nunes for his years of full time work and ongoing volunteer efforts as build engineer for the Mozilla project. Leaf filled this role full time for many years with panache, good humor and great skill. Leaf remains involved with the Mozilla project but is moving to a different challenge for his full time employment. Jonathan Granrose has been helping us temporarily on build issues and a giant thanks to Jon as well.

We’re thrilled to welcome Chase Phillips as our new build engineer. Chase comes to us from Champaign, Illinois, where he worked at the National Center for Supercomputing Applications — the birthplace of Mosaic! — and continues to volunteer for the Champaign-Urbana Community Wireless Network. Chase has been with us for about a month now, learning his way around our massive build system, picking Jon’s brain and generally trying not to sink under the weight of things we keep throwing his way. For those of you you have noticed the recent expansion of our build systems to include localized builds (30 localizations so far) you’ll know why we think Chase is up to the challenge. You can reach Chase at chase@mozilla.org.

Second, Christopher Beard joined the Foundation about 3 weeks ago. Linux folks may remember Chris from his days as co-founder and CEO of The Puffin Group, where he launched the project to port Linux to HP’s PA-RISC architecture, helped organize the Ottawa Linux Symposium, and ultimately became Linuxcare’s General Manager for its Emerging Services business after Linuxcare acquired The Puffin Group. Chris later joined HP’s Linux Systems Division in a strategic, product management and general organizational role — a broad mixture that makes his experience invaluable for the Mozilla Foundation. Most recently, Chris has been honing his international and business expertise through a stint at business school in the UK and Spain.

Finally, Bart Decrem is moving to a new role. Bart has made enormous contributions to the Mozilla project, launching our marketing and PR efforts, generally bringing a consumer focus to the Foundation, driving the Spread Firefox effort and also working with business and enterprises interested in the project. This has been a big help in getting the Foundation off to the great start that we’ve had. After driving these efforts since the Foundation’s launch, Bart is now joining the company that operates the Mozilla Store to help develop their Mozilla and other opportunities. Bart plans to remain in the Mozilla world as one of the Spread Firefox leaders, a friend to the Foundation, and generally bringing the spark of his energy and creativity to the project.