Archive for February, 2005

Sounds Fishy

February 25th, 2005

Two different people have contacted me asking if I am involved in a United Nations project related to equipping developing countries with open software. Each of these people had been contacted by someone claiming that I am involved in such a project and using my name to encourage some action. In one case the action was buying ads in a publication theoretically related to this UN project.

Such a project sounds like a good idea. Nevertheless I am not involved in any UN project. Anyone claiming I am is incorrect — perhaps honestly confused, perhaps intentionally making misstatements.

Email Addresses, and the Mozilla Foundation

February 24th, 2005

A couple of weeks ago I wrote something about my belief that 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 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 staff membership.

When we set up the Foundation a set of key contributors became employees. Some of these people were 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 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 staff has historically been chartered to do. Even so, we didn’t have a policy for what 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 “” email addresses. These addresses have historically been limited to 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 “” 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 “” 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 — perhaps. That’s awfully long so perhaps we’ll choose something shorter. Those of us with addresses will probably continue using them, just as current staff members employed elsewhere use their addresses.

I expect that these new addresses will remain in use after we figure out the relationship between and Mozilla Foundation staff. Maybe it will turn out I’m wrong, and we’ll end up realizing that there is no need for 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 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!

DevMo and DevEdge updates

February 23rd, 2005

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 that is hard to navigate, not well designed, and filled with material that is or may be outdated. staff and Mozilla Foundation Employees

February 7th, 2005

In the beginning of the Mozilla project there was the “ staff.” 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 staff were all Netscape employees. As time went on more and more staff members were volunteers or employed by someone other than Netscape / AOL.

Over time 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. 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 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 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 staff and Mozilla Foundation employees (ie, Mozilla Foundation staff) has been on my mind, but not front and center. We’ve trimmed the staff list to reflect those people who have moved on and are now longer active. But we haven’t had a policy for what “ 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 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 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 “ staff” is important for the project, and (2) this role will build upon and modify the previous role of staff.

It probably doesn’t make sense to continue the previous role of “ staff” unchanged. Before the Mozilla Foundation, 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 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.

Skip past the sidebar