Wrangler Doodles, green.

Building a Better World through Technology

co-founder Mozilla

( from the LizardWrangling Archive )

Category: Mozilla

  • Firefox 3 — Tip of the Iceberg

    Today Mozilla releases Firefox 3 — fast, smart, safe, fun. Full of new things. Firefox 3 once again demonstrates how a great product makes Internet life better.

    Firefox 3 is also the tip of a much bigger iceberg. For one thing, Firefox is the tip of the web itself. Firefox is exciting because the Web is exciting, and because Firefox does such a nice job of making the richness of the Web available to people in elegant, useful ways.

    Firefox is the visible tip of an enormous amount of powerful, open-source technology. That technology makes Firefox possible, and it
    also makes a range of other products possible. Some of these other products are released by Mozilla, some by other organizations.

    Firefox is the tip of an enormous, wildly active community of people who are building a better Internet.

    Firefox is the tip of an innovative development process that uses open source techniques in a range of activities extending far beyond code.

    Firefox is all of these things. And it’s one unbelievably good browser.

    Congratulations and thank-you to everyone who is participating in building Firefox and the Mozilla community.

  • Launch Day in Seoul

    Tomorrow I’ll be mixing OECD events with the Firefox 3 launch day and Mozilla community events. I’ll get up very early to participate in an Air Mozilla event coinciding (almost) with the official Firefox release. Then I’ll go to a local TV station to talk about Mozilla. The only downside is I’ll have to miss some of the interesting roundtables at the OECD Ministerial. That’s disappointing, but reflects how much is going on that is relevant to Mozilla. I’ll go back to the OECD for the lunch and afternoon events. Then in the evening I’ll have the chance to meet up with a significant group of Mozilla contributors. I’m really looking forward to this. The community in Korea has long been wildly creative, active and part of what makes Mozilla Mozilla.  It will be great fun to see Firefox release day from this vantage point.

    Thursday I’ll participate in a forum on web standards and the importance of interoperability for a healthy Internet environment. “The Global Web Technology Workshop will be held for the adoption of global web technologies and web standards within the Korean web industry . . . ” This is organized by long-time Mozilla contributor Channy Yun. It should be a great opportunity to meet the broader web community within which Mozilla lives.

    It’s a rare treat to combine three great events in one all-too-brief trip. The OECD, the Mozilla community on a Firefox release day, and a community interested in the open web. No doubt I’ll come home buzzing with excitement and stumbling with exhaustion!

  • Mozilla and the OECD in Seoul

    As Gen mentioned, I’m in Seoul for a couple of events. One is the Ministerial level Meeting of the Organization for Economic Cooperation and Development on the Future of the Internet Economy. I’m speaking at one of the five roundtables, this one on Creativity. There is an opportunity for online participation organized as well. If I learn anything more about this during the day I’ll update this.

    The OECD traces its roots back to 1947 as part of the post-war reconstruction in Western Europe:

    The OECD brings together the governments of countries committed to democracy and the market economy from around the world to:

    • Support sustainable economic growth
    • Boost employment
    • Raise living standards
    • Maintain financial stability
    • Assist other countries’ economic development
    • Contribute to growth in world trade

    The OECD also shares expertise and exchanges views with more than 100 other countries and economies, from Brazil, China, and Russia to the least developed countries in Africa . . . its mission has been to help its member countries to achieve sustainable economic growth and employment and to raise the standard of living in member countries while maintaining financial stability – all this in order to contribute to the development of the world economy.

    Part of our dream for Mozilla has been to be a voice for the health of the Internet itself. To use our technology, our products and our community process to demonstrate what is possible, and to help others see that openness, participation and distributed decision-making can lead to many positive developments. Mozilla’s participation in events such as this OECD meeting demonstrates that we are doing this. We represent a new style of development for Internet product and the Internet experience.

    On one hand I’m extremely honored to be asked to speak at such an event. On the other hand I believe that Mozilla should be here.

  • Firefox 3 — Coming Very Soon

    Firefox 3: June 17. Our target release date is less than one week away.

    The web experience gets dramatically better for millions and millions and millions and millions of people with Firefox 3. If you know anyone who’s not using Firefox already, now is the time. Help them head over to Download Day, set a world record, and enjoy what the web can be.

  • Incubator Repositories Proposal

    Stuart recently described the need to allow improved collaboration with groups of people in specific circumstances: changes to Mozilla code that are larger (and possibly more experimental) than individual patches and where the new contributors don’t yet have commit access to the source tree and where existing Mozilla contributors want that collaboration to occur within a Mozilla-hosted source repository.

    At the same time, our policies for determining who has commit access are critical to maintaining the quality of our work; we certainly don’t want to change that.

    We (Brendan, Stuart and I) have come up with a proposal that we think gives us some flexibility without changing the rules for obtaining commit access to mozilla-central. It includes a mechanism for allowing such collaboration plus a description of the logistics such as how to file a bug for individual access and get it closed. Comments are welcome here or in the mozilla.org Governance newsgroup. (You can also participate through the mozilla.governance Google Group. )

    Incubator Repositories

    Incubator Repositories are a tool available to module owners in the following circumstances:

    1. the module owners are engaged in significant cooperative development with contributors who are not yet experienced enough with Mozilla to have commit access to the Mozilla source tree; and
    2. it is impractical to break contributions into bug-sized patches and follow the standard review and check-in process, either because the scope of work makes this difficult, or the work is experimental and a precursor to patches that will eventually end up in Mozilla-central or another reason the module owners can describe persuasively.

    In other words, an Incubator Repository is a temporary repository hosted by Mozilla where we allow people to check code in before they have official source code write access for our production code base. An Incubator Repository is not needed for repositories where all contributors have full source code commit access.

    An Incubator Repository should meet the following conditions:

    • An incubator repository requires 2 module owners to be committed as sponsors.
    • The work is important to Mozilla’s stated development roadmap; Incubator Repositories are not a hosting site for potentially-related work.
    • The work is not duplicative of work in mozilla-central. There is some possibility that duplicative incubator repositories are possible, we can look at that if the setting arises.
    • Incubator branches are temporary. In general, an incubator branch probably shouldn’t last longer than six months. By that time it should be clear whether the work has potential. And if it is an effective branch, there should be enough activity from the contributors to determine which if any of them are ready for commit access. However, setting a one-size-fits-all date for all which must be tracked for its own sake requires a bureaucracy to track and manage that. Instead, we’ll say that six months is the general timeframe. For a branch to last longer, the sponsors should have a good rationale why this is the case, they should ideally make that rationale to the Incubator Repositories module owner, and they must make that case effectively if the Incubator Repositories module owner or peers ask.
    • Incubator Repositories are publicly available repositories just like mozilla-central.
    • Incubator Repositories incubate both code and people. They are not training branches where the code doesn’t matter. They are not intended to provide examples of coding to evaluate someone’s readiness for commit access; we have policies for that. They are intended to help the sponsors make progress that otherwise wouldn’t be possible while new contributors learn about Mozilla and become known to Mozilla.
    • Participants in an Incubator Repository may also develop patches that relate to the work in mozilla-central, for example a patch relating to start-up performance. When this happens, the patch or patches in question should be submitted through the standard process. This not only improves our code, but it provides a chance for the author’s work to become known, which is necessary for commit-access outside the Incubator Repository. The sponsors are responsible for encouraging this process.
    • There is no right of potential contributors to have an incubator repository because it is easier for them. There is the ability of existing module owners to sponsor one.
    • The sponsors are responsible for the operation of the Incubator Repository.

    Logistics and Operational Parameters

    • The creation of an Incubator Repository must be approved by the owner (or a designated peer) of the Incubator Repository module. (This is a new module which we will create as part of the implementation of this policy assuming it is approved.)
    • The proposal should describe why the Incubator Repository meets the required conditions, who the sponsors are, hoped-for results of the Incubator Repository, the approximate number of people likely to be given check-in access through this process, and any possible effects on other parts of Mozilla.
    • The proposal should also be filed as a bug and also posted in the relevant newsgroup.
    • The sponsors are responsible for figuring out a reasonable system for getting code from the Incubator Repository into mozilla-central. “Reasonable” generally does not mean dropping six months of work on reviewers and asking for code review. Sponsors may meet this responsibility by using Mozilla code-review techniques in the Incubator Repository or by other means, but they are responsible for getting code review in reasonable increments.
    • Anyone checking into an Incubator Repository must have signed a CVS Contributor Form on file with the Mozilla Foundation.
    • Once approval for an Incubator Repository has been granted and recorded in the appropriate bug, the sponsor or Incubator participants should file a bug asking for commit access for that person for the Incubator Repository. Details on filing the bug and getting it closed are below.

    Incubator Commit Access

    Here’s a list of the steps that need to happen to get Incubator Commit Access.

    1. Make sure the creation of the Incubator Repository to which you wish access has been approved.
    2. File a bug. Product: mozilla.org; Component: CVS AccountRequest. Don’t change the Default Assignee or the Default QA Contact. Your summary should say something about creating an Incubator Account (“Incubator Account Request – John Doe <[email protected]> “). You should also include in the bug a pointer to the earlier bug in which the creation of the Incubator Repository in question was approved.
    3. Each of the two sponsors should comment in the bug saying s/he’s sponsoring the Incubator Repository and your participation in it.
    4. Make sure to include your CVS SSH public key as an attachment to the bug. (Please mark it as text/plain when attaching it!) Note that you will need to attach an SSH key for all types of access.
    5. Complete the Contribution Form and fax it to the location specified on the Form.
    6. Update the bug to note that you’ve faxed in the Form.
    7. An appropriate Mozilla representative will update the bug to say whether s/he has received the faxed Form.
    8. Update the bug when all the needed info is in the bug. This way, Bugzilla can send off mail to the Mozilla representative tending to accounts.
    9. The Mozilla representative will double-check that the needed info is recorded and, if so, create an account.
    10. The Mozilla representative will then reassign the bug to IT to have your SSH public key added.
    11. A Mozilla IT representative will update the bug with account creation information and close the bug.

  • Ellen Siminoff Joins MoCo Board

    I’m very pleased to announce that Ellen Siminoff is joining the Mozilla Corporation board of directors. She joins John Lilly, Reid Hoffman and me on this board. Ellen brings a deep understanding of the consumer Internet, experience at growing and operating organizations of around our size, an entrepreneurial spirit, experience with Board-level responsibilities and a commitment to using these talents in the service of Mozilla’s mission.

    I’ve been impressed with Ellen’s ability to figure out what a traditional profit-oriented start-up would be likely to do in a given situation, and then to recognize when those actions might be modified to reflect Mozilla DNA and to move forward in a Mozilla-like way. Those of us who live with Mozilla are used to doing this. It’s not so easy to find people with deep experience in the Internet industry who take to this so quickly. I’m looking forward to having Ellen’s perceptiveness and experience on the MoCo board.

    Ellen’s CV is below. We’ll schedule an Air Mozilla broadcast with Ellen before too long so you can talk to her directly.

    Ellen Siminoff is President and CEO of Shmoop University, an educational website. She is also Chairman of Efficient Frontier, a pioneer of dynamic search engine marketing management services. She worked with the founders to evolve Efficient Frontier from a groundbreaking idea into the leading Search Engine Marketing agency in the world with business in the U.S., Asia, Europe, and Latin America.Prior to Efficient Frontier, Mrs. Siminoff had six adventurous years s a founding executive at Yahoo!. During her tenure, she led business development (VP, Business Development and Planning), corporate development (SVP, Corporate Development) and eventually ran the small business and entertainment business units, representing approximately 25% of Yahoo’s revenue (SVP, Entertainment and Small Business). Before Yahoo!, Mrs. Siminoff worked for the Los Angeles Times as electronic classifieds manager, where she developed strategy and implemented the newspaper’s own on-line businesses as well as a joint venture of Career Path with 5 newspaper companies.With her husband, David, Mrs. Siminoff founded EastNet, a global syndicate barter company distributing television programming to 14 emerging market countries in exchange for advertising time. She graduated Stanford’s Graduate School of Business with an MBA in 1993 after having completed a summer in corporate finance at Salomon Brothers. Mrs. Siminoff worked as a human resources management consultant in New York after graduating from Princeton University with a bachelor’s degree in Economics.Currently, she serves on the board of directors for US Auto Parts, an Internet retailer with more than 550,000 top-rated discount car parts; Journal Communications, a diversified media and communications company operating businesses in newspaper publishing, radio and television broadcasting, telecommunications, and printing services; and glu mobile, a leading global publisher of mobile games. In 2005 she was one of eight industry professionals named “Masters of Information” by Forbes magazine. In addition, she is on the boards of directors and advisors of a number of private companies including 4info.net, the leader in mobile SMS marketing. She is a frequent speaker at industry conferences, including Ad-Tech, Search Engine Strategies, and Supernova.

  • Mozilla Corporation Board of Directors

    The Mozilla Corporation is welcoming a new board member. I’ll introduce her in a moment. First I’ll describe the role of a board member, and what we looked for.

    Role

    The board of directors is generally responsible for the conduct and the management of affairs of a company. More specifically, they have fiduciary and ethical responsibility and accountability for what a company does. There are many opinions about specifically what these means as a couple of Wikipedia entries make clear. The main point for this discussion is that a Board is really not like the operational groups. To use more traditional terms, the Board is not like the “management team.” The Board asserts authority in the areas of governance and accountability; it provides assistance, guidance and support in strategic decisions and tactical activities. There’s no one better equipped to understand our world than the people building it every day. We look to the Board to support and improve those efforts, rather than try to micro-manage those efforts.

    As in all roles related to Mozilla, we’re looking for individuals who are fundamentally excited about the Mozilla mission and what makes us different, and are highly attuned to MoCo’s role as part of a much larger community. For a board member we’re also looking for someone who can execute the fiduciary and accountability responsibilities required of a board, and is likely to work well with the existing members of the board and the people with whom the board works most closely. We’re also looking for people who understand the consumer and developer Internet world where MoCo lives, and can help MoCo perform better against our mission within this world. Operational experience in running an organization the size or scope of MoCo is very helpful. Experience in working with other organizations and companies in the consumer Internet is also a plus.

    All Mozilla directors — those of MoCo, those of the Mozilla Foundation, and those of Mozilla Messaging — are volunteers. There is no compensation for being a board member. This is true of many non-profits but a difference from board membership in many private and public companies.

    History

    When the Mozilla Corporation was created we had three board members. Chris Blizzard left the Mozilla Foundation board and joined the Mozilla Corporation. At the time Chris worked at Red Hat. I remained on the Foundation board and also joined the MoCo board. I was (and still am) the only person to be part of both boards. Reid Hoffman joined the MoCo board to bring his insight into the consumer Internet space to moving the Mozilla mission forward. That gave us a board of three, two of whom were “outside” directors. “Outside” here means not part of the management team and employed by MoCo. When John Lilly became COO (“Chief Operating Officer”) in late 2006 he joined the Board as well, and we had a board of four.

    Last fall Chris Blizzard changed jobs, moved to the Mozilla Corporation as an employee and resigned from the Board. (We’ve been extremely lucky to have Chris’ contributions in many roles over the years.) We began a search for at least one and perhaps two additional outside directors. We talked to people who have solid experience with what a board does and how good boards interact with the people making things happen on a day to day basis. This is normally called the “management team” or the “executive team.” At Mozilla we don’t use those terms as much, but the concept is the same: a good Board is not trying to manage the operations of the organization, it is providing support and guidance and governance to the group that is. In our case, that’s the Steering Committee.

    Legally, Mozilla Corporation board members are responsible to the Mozilla Foundation as the sole shareholder. The Mozilla Foundation Board of Directors is the group responsible for electing board members. We talked to a bunch of people; always looking for people with a good sense for the Internet and a fundamental understanding that MoCo is a mission-driven organization dedicated to building the Mozilla vision. This is key — MoCo must provide consumer offerings that excel — that’s the way we move our mission forward. And yet we do it for a public benefit mission; not for the reasons companies usually create software.

    Eventually a few people appeared whom had great expertise and we thought might fit well. John and I asked them to talk with a bunch of Mozilla folks. From there the person with the best fit spent time with the Mozilla Foundation directors. We did some due diligence, talking with people who’ve worked with her before. When everything lined up, the Mozilla Foundation board of directors formally took action to elect a new board member to the MoCo board of directors.

  • Governance and Module Ownership

    At the end of March I made a proposal about updating the way we manage the health of our module ownership system. I’m happy so say that the proposal has now been implemented. Specifically this means:

    1. We now have official modules — currently known as Activities Modules — for non-coding activities.
    2. We now have a Governance module (owner: Mitchell Baker).
    3. We now have a sub-module of Governance for Module Ownership (owner: Brendan Eich).
    4. We now have an official Planet Mozilla module (owner: Asa Dotzler).
    5. The long-standing web page listing module owners for code modules has been undated to also point people to the Activities modules.
    6. The Activities modules are described and listed on wiki.mozilla.org.
    7. The policy governing module ownership has been updated to reflect the creation of the Module Ownership module.

    Thanks to everyone involved, and special thanks to Mike Connor for jumping up and down until I got this underway.

  • The Approach of Summer

    Summer is staring here at Mozilla. What that means is not primarily summer vacation. It means summer interns. A 3 to 4 month influx of students working full time on Mozilla. That means the number of full time folks grows by 20 or 25% almost overnight. These folks bring new perspectives, new skills, new expertise, new ideas, new questions, as well as a bunch of new people to get to know. It’s a great time.

    Our intern program is a bit unusual. We don’t have special intern projects. We don’t identify special niches where people can dip their toe in the water for a summer.

    We identify critical areas of our technology, our product, our outreach, our marketing, our websites, our content, our testing, our localization, etc where a smart, engaged person can make a difference. We expect to get every intern immersed in such an area. We want the work our interns do to affect the lives of 200,000,000 people, just as the work of other participants does.

    This isn’t a dream, and it isn’t naive. We did this last summer, when our interns made giant contributions to the product we’re shipping today. We can do this because of how we work and the abilities of our interns. Our interns don’t get a free pass — they live within the processes, policies and discipline we apply to all contributors. They don’t need a free pass — the openness of our development system means that good work is seen and can be incorporated quickly.

    Also, it’s a great excuse to drag bunches of people up to the circus gym for some Flying Trapeze lessons 🙂

  • Firefox 3 — The “End Game”

    We’re getting very, very close to the release of Firefox 3. It’s an odd time around the Firefox part of the Mozilla project. Most of the Firefox and platform engineers are mostly done. The long, long push to get hundreds of issues triaged and resolved is over. Our first Release Candidate is out. Maybe we’ll do another release candidate, that depends on what we learn over the next short period. And if we do there will be a burst of activity. But the vast bulk of the engineering work is done. These engineers are already defining and working on the next projects, from Firefox to mobile. But there’s also a sense of waiting. Firefox 3 isn’t done until we’ve completed a massive test cycle, and there’s a constant and growing throbbing in the air as we work through the final stages.

    Meanwhile, other groups of people are in high gear. The QA team is one. It’s a quiet storm of QA activity right now as we throw every test we’ve got at Firefox 3, looking for any cracks or stress points. It’s a quiet storm only because QA is a well-organized, experienced and highly effective team. Otherwise it would be a wild frenzy. Quite a contrast with the Firefox 1.0 release, where we hand-tested the localized versions up through the day of the launch itself, using an easel size pad of paper covered with a hand-written list of localizations and status updates.

    Other engineering teams are hard at work as well. The web development team, for example, making sure sites like addons.mozilla.org are ready to go. The website content teams and localization teams are making sure that the many pages of content are available in the massive number of languages that are part of the Firefox 3 release. This includes both the websites themselves and the “product” pages which are part of Firefox. Build and release is the final stage of the release, so they are also in the thick of things right now.

    The marketing team is extraordinarily busy, from community activities to press briefings to creating and distributing all the materials needed to explain Firefox: both new features and the overall pleasure of using Firefox to people who haven’t yet experienced what’s possible with Firefox. It’s a massive undertaking to launch a product with a userbase the size of Firefox. We couldn’t do it without the deep integration of the marketing team with the massive Mozilla community and we’re seeing that at work.

    So we’re experiencing extreme levels of activity and performance in giant parts of the Firefox community. That’s combined with an intense sense of pressure building. It’s a little like seeing the first rays of sunshine appear on the horizon, and knowing that blazing ball of summer will appear soon.