The fundamental requirement of each staff member is that he or she care about the Mozilla project as a whole, separate from an interest in a particular Mozilla-based product. Staff members work for different companies and represent different interests, but we share the common task of making the organization and project infrastructure work well so that everyone (ourselves included) can focus on making the code work better. Many but not all of us are paid by our respective employers to work on mozilla.org activities.
Staff members deal with a broad range of issues, primarily those that affect the entire project. For issues whose scope is less broad, staff tries to delegate authority to community members who have expertise with a particular area, as we have done with drivers and module owners. Issues that affect the entire project include such things as the roadmap and milestone planning, code review processes, handling of security-related bugs, reorganization of the Mozilla website (where we are way behind), etc.
Not every staff member participates equally in every issue. We don't have a formal committee system within staff, but staff members with expertise and interest in an area will take the lead in those areas. Nevertheless, all staff members pay particular attention to the management of the source tree and our instance of Bugzilla. These are our primary assets, and we all participate in its management when issues arise.
Since mozilla.org is a virtual organization, there is no formal employment or authority relationship among the staff. Nevertheless, we operate with a certain sense of order, shared responsibility, consensus building, and trust. We seek a general consensus among staff, and we expect a sense of give and take. We expect staff members to state their view forcefully, but to recognize that even passionately held views will not always be adopted by the group. When consensus is difficult or an individual decision-maker is needed, we look to Brendan Eich for technical matters, and Mitchell Baker for policy and organizational matters. It would be hard to imagine staff taking technical actions to which Brendan is adamantly opposed, or policy actions to which Mitchell is adamantly opposed. It's possible of course, and critical that the possibility remain. We lead because people trust us, are supportive of our mission, and are willing to follow, not because we have some unalienable right to the position.
Staff members need to be clear when they are expressing their views as a contributor to the Mozilla project, and when they are speaking for mozilla.org. And we expect staff members to speak for mozilla.org only after a decision has been reached.
Here is a list of current staff members. We have not determined whether there is an ideal size for staff. Too big and the group is unwieldy and becomes a bottleneck; too small and we can't do what is needed and again become a bottleneck. We expect that future staff members will have participated in the project in a variety of capacities and will have the ability to separate their desires from that of the project, and make decisions accordingly. We anticipate that future staff members will have been Staff Associate members and probably a Module Owner or Activity Owner as well before being asked to joing mozilla.org staff.
mozilla.org Staff Members
If you have a project management issue, you can email the entire staff via firstname.lastname@example.org.
- Mitchell Baker, Chief Lizard Wrangler (email@example.com)
Mitchell is the general troubleshooter, spokesperson and policy arbitrator for mozilla.org. She works extensively with companies and projects using Mozilla. This involves explaining mozilla.org processes, listening to the needs of contributors, and seeking to integrate open source development techniques with the world of commercial software development.
Mitchell also spends a lot of time driving consensus as to how mozilla.org ought to manage the project, which suggests she may have a masochistic streak. She dreams of making the Mozilla project easier to understand.
Before joining mozilla.org staff, Mitchell was the attorney at Netscape responsible for all legal issues related to product development and intellectual property protection. During that time she wrote the Netscape and Mozilla Public Licenses.
- Chris Blizzard (firstname.lastname@example.org)
Chris hacks on various parts of Mozilla. The straight Xlib port of Mozilla is mostly his fault. He also hacks on the gtk port when it really needs help and people ask really nicely. He dreams of things like adding WebDAV support and other fun network features. He also dreams about the directions the mozilla project could take and what it can accomplish.
Chris has been using Linux and open software since the 0.99 days. Starting as a user he self taught himself programming and now hacks on various projects when he has time. He's been working with Mozilla code since the source was released. In the past he's played roles as a sysadmin, web jockey, database programmer and project manager.
- Asa Dotzler (email@example.com)
Asa is our community quality advocate extraordinaire. He joined mozilla.org to turbo-charge our quality programs and to further develop our volunteer QA and testing community. When he's not helping new contributors test Mozilla and report bugs he's working with firstname.lastname@example.org to define requirements for and ship Mozilla milestones.
- Brendan Eich (email@example.com)
Brendan is responsible for architecture and the technical direction of Mozilla. He is charged with authorizing module owners, owning architectural issues of the source base and writing the roadmap that outlines the direction of the Mozilla project.
- Gervase Markham (firstname.lastname@example.org)
Gerv works part-time for the Mozilla Foundation, and is the only staff member based outside the continental USA. He is responsible for the relicensing project and trademarks, has a strong interest in security and usability, and does most of his hacking (when he has time) on Bugzilla. His blog is Hacking for Christ.
- Myk Melez (email@example.com)
Myk is a toolsmith and sometimes document writer. Besides hacking on Bugzilla and occasionally coaxing it back to life when the world gets to be too much for it, he stands ready to write new tools (like Doctor) as the need arises. He tries his best to balance daily work with grand visions for the future.
Before mozilla.org, Myk wrote ForumZilla, before which he worked at UC Santa Cruz as a Web applications developer, before which he spent copious amounts of time, money, and energy getting a degree in the practical field of Sociology, before which he taught himself programming (apparently a common theme around these parts) on his sporty 0.3Mhz Apple IIe in order to hack keyboard support into video games.
Mozilla.org Staff Associates
Staff Associate is an experimental position we created in the fall of 2001. The role is for a person who
- Has demonstrated experience and/or aptitude for addressing the types of issues that come to staff attention. These issues tend to be balancing of perspectives, communication and problem resolution, and fitting together differing needs. These are quite different from being a primo hacker, and require a different set of interests. Often the two do not overlap.
- Has been involved in Mozilla in a range of activities (i.e., code contributions are precious, but alone would be unlikely to make an Associate position make sense)
- Has demonstrated to staff an ability to work in our consensus based organizational style.
- Fills a hole in the expertise/resources of staff members.
- Is interested in the direction of Mozilla technology and in the Mozilla project in general, separate from an interest in any particular product
- can make decisions for the benefit of the entire community, both by temperament and because his or her employer (if any) permits this
An Associate supports mozilla.org staff by providing input into staff discussions and decision-making process. An Associate may also investigate issues and provide background materials to staff. An Associate does not speak for mozilla.org, and does not have an "@mozilla.org" email address.
The Associate role might be a step in joining mozilla.org staff, or it might show that the Associate and staff members don't work that well together. We may also use this role for staff members who no longer have enough time available to remain staff members but whose input we seek whenever we can get it.
mozilla.org Staff Associate Members
- Peter Bojanic (firstname.lastname@example.org)
Peter is an engineering type with that elusive combination of development experience and business acumen. He promotes Mozilla technology and translates tech talk to execs then reads their minds and explains the business speak to engineers. Peter works for OEone Corporation which is developing the Penzilla operating environment based on Linux and Mozilla. He's their VP Software Development and resident Jedi.
- Scott Collins (email@example.com)
Scott is a core engineer, technical evangelist and liaison for the Mozilla project. You may already be familiar with Scott's work on XPCOM, nsCOMPtr, Mozilla's Strings, or from his technical lectures (e.g., on C++ portability [slides, video] Mozilla Strings [slides, video], XPCOM [video], or at campuses, conferences, and users' group meetings across the US). If you want to hack on Mozilla and don't know where to start or how to get involved, or if you're looking for someone to speak to your group about Mozilla engineering or technical details, Scott is here to help.
- Frank Hecker (firstname.lastname@example.org)
Frank Hecker is mozilla.org's self-appointed policy wonk and amateur document editor; among other things, he helped create the Mozilla Relicensing FAQ document, the mozilla.org License Policy, the policy for handling Mozilla security bugs, and the Mozilla Crypto FAQ document. Frank was one of the people who successfully sold Netscape management on the advantages of releasing source code, and in the spirit of "service after the sale" he has been volunteering with mozilla.org ever since.
- Marcia Knous (email@example.com)
Marcia can't be easily categorized in any technical sense since she doesn't have much of a technical background and often flies low on the radar.
Her mozilla.org work involves dealing with a lot of administrative minutia, including handling all CVS accounts and troubleshooting when things go awry. In her pre-Mozilla days, Marcia worked in entertainment and law and still dabbles in freelance writing. These days she mostly dreams about treating the anxieties of the present with the wisdom of the ages.
- Dan Mosedale (firstname.lastname@example.org)
Dan has been working on pieces of Mozilla (LDAP support, LDAP typedown autocomplete, getting UNIX Quantify to play nice) as well as mozilla.org tools (Bugzilla, Despot, license and statistics scriptage) for a while.
Before joining mozilla.org, Dan was the systems administrator at Mosaic Communications Corp. From there, he moved on to IS Architecture work at Netscape, co-wrote the DNS server used by Netcenter to distribute its Website worldwide, and enhanced and maintained Netscape's mail-to-news gateway code.
- Mike Shaver (email@example.com)
As a founding member of mozilla.org, Mike has enjoyed a rare opportunity to inflict a wide variety of trials and errors on the Mozilla code and project. He is stronger for it, and hopes that Mozilla is as well.
Scheming diabolically from his fortress of solitude in Toronto, shaver meddles in matters ranging from platform architecture and implementation to licensing and organizational development. If you are short on opinions, he often has some to spare.
- Seth Spitzer (firstname.lastname@example.org)
Mozilla.org Emeritus Staff
- Dawn Endico (email@example.com)
Dawn is a toolsmith and Webmaster. In addition to getting LXR working on the mozilla source code, Dawn worked to keep the documentation on this site organized and up-to-date.
In previous lives, Dawn has worked as a Production Artist, exhibited digital artwork, designed commercial Web sites, and worked as a system administrator.
- Daniel (Leaf) Nunes (firstname.lastname@example.org)
Leaf was mozilla.org's release engineer and build-issue spear catcher for many years. He spent a lot of time worrying about piddly little details, like whether or not the Mozilla source can be compiled into something runnable. This means he worked on details like the build systems and getting the source and test executables to developers.
Leaf is a veteran of UC Santa Cruz and Fabrik, and his sense of humour and compassion is greatly appreciated by everyone who received a 3AM "so you broke the tree" wake-up call.
- David Hyatt (email@example.com)
- Terry Weissman (firstname.lastname@example.org)