Posts Tagged with “staff”

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.