Wrangler Doodles, green.

Building a Better World through Technology

co-founder Mozilla

( from the LizardWrangling Archive )

Category: Mozilla

  • Firefox 1.0 Launch Day

    Launch day here was quite a day, and I thought I would describe my view of it.

    We knew it would be a long day, since the launch was schedule for 1 a.m. Monday night/Tuesday morning. On Monday most of us started rolling into the office about 10 a.m. or so. A number of us had been online from home before, especially those of us in contact with the localization teams in Europe and Asia. Meanwhile, these teams were trying to stay awake long enough to get last minute messages through to the release coordinators in California so that the localized builds could be certified for inclusion in the 1.0 release.

    The day in the office started with a flurry of activity around localized builds. The Firefox 1.0 release was the first time we’ve included localized builds in our main CVS tree and included them in our release process. Adding 50 or 60 builds (20 languages, 3 platforms each) to a release is a big deal and Chase spun many sets of localized builds. The last planned spin of all localized builds was at 10 a.m. Monday morning. As the builds arrived, the localization teams around the world began to check in to verify them again, and our Quality Assurance groups went into high gear.

    In the meantime, the engineers were always looking for last minute issues. We were confident of the release, but it’s in our nature to keep looking for things to improve until the last minute. Brendan isolated himself in the back of the office and went through crash data, trying to eke out one last problem until finally he gave up. Darin and bryner and dveditz continued their quest through bugs and mail to look for other improvements.

    Chris Beard and I huddled on a set of questions, ranging from press inquiries to official and unofficial builds to localization questions to distribution programs. I spent a lot of time working with organizations interested in the Fireflox launch and finishing the blog post about the Firefox end user license agreement. Chris Hoffman monitored all activity, constantly encouraging people. Dbaron tracked the set of things that needed to be done to make the launch happen. These included:

    • Determining the list of localized builds that were ready to be shipped with the English version
    • Getting all builds pushed to the ftp site at the right time
    • Verifying that the download infrastructure was ready (more on this later)
    • Verifying that the 1.0. launch page for the website was ready to go
    • Verifying that the infrastructure for the website was ready to go
    • Verifying that the infrastructure for the start page was ready to go
    • DNS redirect.

    Various people spent some time looking at the infrastructire for “update.mozilla.org.” This infrastructure was new and we knew that it would have trouble scaling, so we wanted to most out of the existing infrastructure. Others spent time keeping in touch with the Spreadfirefox.com community.

    We knew that Mozilla Europe and Mozilla Japan were ready to go. Each had done or coordinated massive amounts of work to have appropriate materials translated into localized websites in multiple languages as part of the launch. Bart Decrem had spent time in Europe with the Mozilla Europe folks and Chris Hofmann had gone to Japan to work with Mozilla Japan in coordinating the international launch. We made sure that Mozilla Europe and Mozilla Japan could be reached from the main page of www.mozilla.org, and tried to ensure that appropriate localized versions would be offered to people visiting those sites.

    During the day people would find interesting tidbits and tell them to the group. Ben and Asa found a few folks who had created countdown clocks. We read aloud various blog posts about waiting for Firefox to encourage people finishing up the last bits of work.

    All this formed the background activity. The main focus for much of the day was the QA and build team creating and checking out the localized builds. For each build, a whole set of things need to be worked out. This included:

    • Does the build open?
    • Does the installer work?
    • Are the UI items localized?
    • Are the right fonts used?
    • Are appropriate links localized, allowing users to get to content in their own language?
    • Are the search plugins localized, allowing users to get relevant search contents?
    • Is the start page translated?
    • Is the start page localized (including links, search capability, etc.)?

    Our amazing QA team here in the office — Marcia, Sarah, Tracy, Jay and Asa went to work and worked tirelessly. So did Chase, our build and release maven, who created the build infrastructure for the localizations before we’d even given him time to acclimatize to life at the Mozilla Foundation. We made a giant list of all the localizations that might be ready, a list of the localizations for which localized search engines are available, a list of the localization teams who had certified their builds, and a list of any problems the QA team had found.

    Periodically one of the QA folks would ask about some potential problem — was it a blocker or not? We have one big open space, so a bunch of us would look up and figure it out. This is particularly helpful in a few cases. For example, about 9 p.m. Asa groaned and announced that the Japanese version seemed to have a serious font problem and he didn’t think we could ship it. Immediate conversation ensued, since the Japanese team had just certified the build as ready. Chase started wondering about the fonts on Asa’s machine, jumped up and went to explore. Sure enough, Chase was right about fonts, the Japanese localization team was right about their build, and the Japanese version was cleared to ship out with the 1.0 release. One spike of tension receded.

    As the list of localizations was finalized, other bits began reaching the final stage as well. Ben became more focused about the website push. Dbaron became more focused about the various pieces fitting together. Ben and I finished our blog posts. We also started tracking the start page infrastructure to make sure it was online. Chase began the process of getting the final builds pushed to the ftp site. Pav decided that we need to have BitTorrent available for the launch, so he settled down in a corner and went to work to make this happen. He took some kidding from those who felt that this wouldn’t be needed. Pav wasn’t having any of this, put his head down and dug in. Anyone who knows Pav knows that there’s no point in trying to stop Pav when he gets into this mode, so we left Pav to get BitTorrent going. We noted that the load at www.mozilla.org was going up. We assumed this was caused by people polling to see if the release was available yet, since we had read blog posts about people doing exactly this. It gave us another clue that yes, people were excited about seeing Firefox 1.0 appear.

    About 11:00 pm Pacific Time Steve Garrity woke up to help with the final push. Steve is our lead contact with SilverOrange, the web design firm that has done the visual identity work for Firefox, Thunderbird and our website. Steve lives on the far East Coast of Canada, so our 1 a.m. launch time is 4am for Steve. Steve reports that he managed to wake up, but never got out of bed, and did the final push for the 1.0 launch website lying in bed with his computer in his lap. We were a bit nervous about waking Steve up but this turned out to be unnecessary — Steve came through on his own, as he always has. Even so, it was a mighty relief when messages from Steve began appearing! There were 4 or 5 things that needed to happen with the website for the 1.0 launch (changing the content at www.mozilla.org to our 1.0 release notice, pointing to localizations and some other info, and so on), and they went off without a hitch.

    About 11:40 p.m. Asa looked up and said in a concerned voice: “I timeout when trying to reach www.mozilla.org. Can anyone else get to it?” The answer was no. The mozilla.org website was down. The office grew suddenly tense. Asa hadn’t spoken loudly, but everyone knew anyway. This is often the case — in a network-centric environment with lots of people in one room, you can almost tell when the network is down. Often when I find I don’t have a network connection I simply look up. If I see other people looking around then I know — network issue. I usually ask to be sure, but it’s almost redundant. At that moment Vlad reappeared. He came in the door grinning, noticed the odd silence and said “I though you guys would be celebrating.” “Can’t get to www.mozilla.org.” Vlad’s grin disappeared, he sat down, pulled out his computer and buried his head in it.

    Dbaron and bryner went to work, as they always do when a problem like this arises. There’s nothing like this in their job descriptions, but that hasn’t mattered. In a minute or two there was a group clustered around dbaron debugging, and a steady stream of information was coming from dbaron. After a bit he says something about “two heaps” and “immense traffic.” Then he says “It looks like it’s coming from Myk!” Soon we’ve established contact with Myk. Yes, all the activity is coming from him. He’s bringing a second server on line to support the projected load at www.mozilla.org.

    Myk has been our toolsmith for many years. We got to know him as a result of his application Forumzilla, and we jumped at the chance to hire him years ago. Since the Mozilla Foundation was launched Myk has taken on the Herculean task of coordinating our systems administration and infrastructure. We’ve had great help from a group of tremendous volunteers, but Myk has been the central point. For someone who didn’t ask for the job, he’s done amazing things.

    “Right now?” we ask. “Doesn’t it seem a bit earlier would have been better?” Well yes, of course. But the machine took longer to arrive than expected, and now is when it was ready. Vlad looked up and said “Well, he’s got 8 minutes to get it done. That should be plenty.” And so it was. Being Myk, the job was done in 5 minutes, the work was perfect, there was no hitches, and within a few minutes www.mozilla.org was back and ready to go.

    Someone asked “are we ready?” Chase answered that the release bits were on the site, both in English and the many localizations. We went through the list of all things people were thinking about, orchestrated by dbaron for the network aspects and Ben for the Firefox specific elements. Chofmann’s nearly jumping up and down by now, “Yes, we’re ready, we’re ready, we’ve been ready. Push the bits!”

    We decide we’re ready. The last thing to do is to get the revised home page for www.mozilla.org actually “pushed” to the website, publish the blog and related posts, see the mozillazine news article posted and watch. Pushing new content to www.mozilla.org takes a few minutes. That’s because content is stored in our CVS repository and so at least part of the website source tree needs to be rebuilt to implement the new content. Normally this happens automatically every 30 or 40 minutes. We don’t want to wait that long, as we start a manual rebuild to get the content pushed sooner. We’re all used to this wait for new content to appear but this time it’s a very focused wait. No one is doing much of anything, we’re all sort of standing around.

    And then, voila. “It’s done.” We all race to our laptops and go check out www.mozilla.org. We’ve all seen the content before, we’ve been looking at it for days, checking for problems, tweaking it. But this is the first time we’ve seen the content live on our public website, and we all have to look to make sure it’s really there — Firefox 1.0 is available, the Mozilla community has delivered something exciting, and we’re proud of it.

    What did people do next? Did we all jump up and down, run around and have a giant party? No. We watched the network. Yup, that’s what we did. Chofmann managed to get a group to stop long enough to come back and at least acknowledge the glasses of champagne, and even to take one and wander around with it. But always back to watch the network. Is www.mozilla.org looking OK? Is the http download traffic looking OK? Is the ftp download traffic looking OK? Here we are:

    The next day we arrived at work a bit later. We were beginning to get an idea that Firefox 1.0 was getting the reception we had hoped for. (I don’t think we yet had any idea of the reception that Firefox 1.0 has actually achieved, which has been phenomenal.) In a sense it was a bit anticlimactic because I couldn’t touch or feel the response. Our download traffic is handled by a set of mirror sites coordinated by the marvelous folks at Oregon State University’s Open Source Lab (http://osuosl.org/). Other significant university and research participants in our mirror program are Georgia Institute of Technology, Indiana University, the University of Utah, the Friedrich-Alexander University Erlangen-Nuremberg in Germany, and the Spanish National Research Network) and the Internet Systems Consortium. There are also a few commercial entities that assist, and we are grateful to all of them. We get logs and such from the mirrors through OSU, but of course that’s a step removed from managing this ourselves and having immediate access to the data.

    After a while the anticlimactic feeling faded as we began to get information about the number of downloads and the general reception of Firefox. As best we can figure it, around 1,000,000 people came to download Firefox on the first day alone. That’s an astonishing number, far beyond what we had seen before. As Chris Hofmann put it, the building at the Mozilla Foundation might seem quiet, but the wires were burning up at Oregon State! And indeed the traffic did burn out some machines. By midday it was clear that our some of our mirrors were buckling under the load. For example, we had routed a good chunk of traffic to three jumbo sized load-balancers each fronting multiple machines in a big datacenter, and two of them burned out. (Note to alleviate speculation here: I am not talking about Google.)

    Myk and chofmann had given a good deal of thought to this possibility and had two backup plans. The first potential backup was a load-balancing tool that distributed load across a larger set of servers (more about this below), and the second plan was a commercial vendor specializing in high-availability hosting.

    Myk suggested we use a load balancing tool written by Mike Morgan of Oregon State. The idea was that in addition to distributing load to the small group of primary mirrors — the powerful ones that get our releases first, host everything we serve, and send us back logs so we can generate download numbers — we also distribute some load to the much larger group of secondary mirrors. The secondary mirrors may be less powerful, take more time to get our releases, not send us logs, and not host everything we serve (many of them host only the latest releases), but they still represent a significant amount of download capacity that could come in handy during periods of high demand.

    Myk had evaluated the tool and believed it would improve our delivery capability dramatically. So early afternoon on Tuesday the 9th we implemented it. Sure enough, Myk was right, the tool performed as hoped and our ability to deliver Firefox to interested people improved significantly. Another bout of tension was reduced. Many, many thanks to Mike Morgan for writing the tool, and to Scott Kveton and the mighty team at OSU who helped get much needed equipment up and running in short order.

    We didn’t reach perfection of course, the demand was too great. And as we had suspected, the infrastructure for update.mozilla.org was our weak point, and we had to curtail its operations during the peak activity.

    Meanwhile, Bart and Pav were preparing for the AIR MOZILLA web event, a 5 hour live webcast and text chat. The show had interviews and discussions with Mozilla staff, with questions and music. I was so engrossed in the day’s activities I didn’t quite understand why there were suddenly speakers next to my desk, but then the event began and it became clear. We wanted some way to connect with people involved with Firefox and we can’t do by all getting together, so Bart came up with the webcast idea and Pav played host. Bart has spent some time looking at technologies that help with community development, such as the drupal / civicspace technology he connected with the Spread Firefox project, and AIR MOZILLA was another example. Bart orchestrated, Pav interviewed a lot of long time mozilla.org participants for a webcast. We simultaneously hosted a 2-channel IRC session where people could pose questions. Hundreds of people joined the IRC sessions where Asa and Marcia played IRC hosts, gathering questions and passing them on to Bart and Pav and then to various participants. The event was a nice, low-key marker of the tremendous international interest and participation in the project.

    By the time the AIR MOZILLA event came to an end serious fatigue had set in, and many of us went home to get a good, long rest. Or at least the start of one. I suspect that many of us didn’t get enough of a good long rest until the holidays at the end of the year.

  • Unexpected New Year’s Resolutions

    I can’t remember the last time I made a New Year’s resolution. What does a new date really matter to changing patterns? Usually there needs to be a more effective driving factor to get me to change my ways. But to my surprise, this year I ended up coming back to work on January 3rd with two new goals. This may have had more to do with the effects of the much-needed holiday vacation than with the beginning of a new year. But whatever the cause, I ended up with two goals. First, and not related to the Mozilla project, to find time to get back to trampoline lessons. The trampoline is both great fun and good exercise. I gave it up when the Mozilla Foundation was formed and the demands on my time got out of control.

    Second, and definitely related to the Mozilla project, is the desire to describe publicly much more of what I am doing and thinking about. This must be a result of a vacation, because usually the idea of writing more is enough to make me want to hide. When I write things, it usually relates to people, or different perspectives. It rarely relates to something inanimate like code. The closest thing to code I’m involved in is the drafting and analysis of open source licenses. And that is definitely a topic where a careful approach and measured words are important. Usually I’m thinking about relationships, how different groups might work together, how to solve organizational problems, and now the set of things necessary to keep the Mozilla Foundation healthy. This ranges from employment issues to intellectual property to financial sustainability. All of these are topics where more communication would benefit the Mozilla project. But all are topics where other people, their goals, and often their constraints and limitations, are involved. I am cautious about dissecting people in public and so describing this work gracefully is hard.

    But I must feel rested, because I have the urge to try anyway. There’s a lot going on that won’t show up in code but that would benefit from a public discussion. So I’m going to try. Maybe once I’ve blogged even a fraction as much as Asa does I’ll be able to jot off quick but intelligible notes and things will get easier. In any case we’ll see how successful I am.

  • Update re Netscape DevEdge materials

    Now that the Firefox 1.0 launch has been completed, I’ve returned to working on getting access to these materials. I’m still optimistic. It seems to me that AOL wants to do the right thing and pulling the materials before the Mozilla Foundation had them posted was unintended. The recent delay in getting to this was from my end, as I was consumed with release-related activities.

    More solid info as I have it.

  • Firefox 1.0 Now Available

    Firefox represents something new for us — a release that is squarely aimed at the end-user. A great browser where power features don’t get in the way of the general user. It’s sleek, innovative, accessible to mere mortals and also packs enough punch for the most sophisticated power user. If you’ve been waiting to try Firefox or to recommend it to others until it has the official stamp of approval, now’s the time.

    This release also marks a new era in our international focus. I’m not sure one can imagine how much work is involved in the localization effort until one has tried it. In addition, our localization teams are all volunteers. That’s right, volunteers. People volunteer in order to have Firefox available in the language they care about. This involves not only the actual localization, but reviewing and verifying all aspects of the localizations, waiting for our build cycles to complete, working at odd times to hook up with everyone else and helping the Mozilla Foundation figure out how best to manage such a massive task. And of course, all this needs to be done on a very tight timeframe. I am regularly astonished by the outpouring of support for the Mozilla project, and the localization effort is a perfect example.

    In addition to improved localization, Firefox 1.0 also has integrated search capabilities, both in the Search Box and in the startpage. We know that search is a critically important feature of the web, and we’ve worked to make Firefox’s search functionality as useful as possible. Firefox ships with a set of search plug-ins, allowing the user to select the search engine which works best for his or her needs. In addition, one can choose to add a broad range of additional search engines quite simply.

    In keeping with our emphasis on the end-user, we have redesigned the Firefox startpage. We wanted a startpage that reflected the Mozilla project and provided a good access point to the web. Given the importance of search, we decided to add search functionality to the start page itself. Google has long been recognized as a leader in search experience and so we chose Google.

    We provide access to search services from a range of sources including Google, Yahoo, Amazon, eBay and others you can see in Firefox. We expect to see some funds come to the Foundation as a result of our integrated search. We’ll use any funds that result to help support the Mozilla Foundation’s non-profit operations. When finances are involved questions often arise about their influence on an organization and we’ll spend some time talking about this as we go forward.

    For now, I want to express my admiration for the vitality and commitment of the Mozilla community. The Firefox 1.0 release builds on the work of hundreds of programmers and QA contributors and thousands of participants. It also highlights the efforts of new groups of participants, including:

    • the Visual Identity team — a new group of volunteers that has brought great polish to Firefox, our new mail client Thunderbird, and our website;
    • Spread Firefox — the admins who spearhead community marketing campaigns, and the thousands using their creative energy to let others know about Firefox;
    • Mozilla Europe and Mozilla Japan — our international affiliates who assist with all manner of activities for users outside of the United States;
    • an increasing number of people employed to work on Mozilla technology, some within the Mozilla Foundation and many funded by other entities; and
    • the millions of people who have downloaded the Firefox preview releases.

    The breadth and depth and innovation of the Mozilla community continues to bring unprecedented results. Mozilla Firefox is a great browser, and a testament to the thousands of people who have contributed their energies to bring innovation, creativity and choice to the web.

    Rediscover the Web — Get Firefox

  • Firefox End User License Agreement

    The source code of Mozilla’s browsing and email clients is available under the Mozilla Public License (the “MPL”), an open source license certified by the Open Source Initiative. Until now we’ve used the MPL for our executable releases as well. It hasn’t been a perfect match, as the MPL is aimed at source code. And even if we change the MPL to clearly apply to executables it’s still an odd fit. One might have the right under the MPL to modify the code of the executable, but source code is the natural way to make most modifications.

    The MPL is not designed for the average consumer who isn’t interested in the complexity of a license aimed at development methodologies. (That’s assuming the average End User is really interested in any End User License Agreement. Even with all my background in this area I find it tedious to read through End User License Agreements, so I can only imagine that someone who’s not trained in this and only interested in getting something done may not pay much attention to the license.)

    Periodically people have suggested that our executables should ship with a EULA rather than the MPL. This is particularly true with Mozilla Firefox, which is aimed at end-users as well as our traditional developer community. So we’ve done this with the 1.0 release. I had hoped to get the EULA included much earlier, but my to-do list is longer than my capacity to execute.

    The Firefox EULA is pretty basic. That’s not to say it is as short as I would like — just including the standard clauses takes space. I thought about doing some things with the EULA that aren’t standard in the industry, like talking about distribution rights so that people wouldn’t need to look elsewhere. But it turns out that this adds complexity and I decided to leave this out, at least for now. I’ve written many EULAs in the past — almost every EULA that Netscape every used, in fact. But I haven’t focused on this in recent years, and now I rely on legal counsel to remain up to date and vet the content of the license. In this, as in so many other things, I want to thank Heather Meeker of Greenberg Traurig for her great help and unflagging positive nature in the face of time constraints and great demands.

    Many people, especially programmers, ask me why there is so much “shouting” in EULAs. The answer is that consumer protection statutes often require notices to be “conspicuous” so that consumers see them. One way to make things conspicuous is to have them in all capital letters. That leaves the license pretty disturbing to programmers who associate all caps with yelling, but it is hard to change given the legal parameters within which a EULA operates.

    We would also like to have translated versions of the Firefox EULA and we’re working on getting this done.

    I suspect that the Firefox EULA is not perfect. If I had more time I would have distributed it for review and comment. Firefox 1.0 is only the beginning of great new releases from the Mozilla project, and the license can improve along with other aspects. The Firefox EULA can be found at the Mozilla website.

  • Erroneous Press Article

    I see that Red Herring has an article based on an interview with Bart Decrem. I am astonished at the content of this article. Let me give a few specifics.

    The entity calling itself “MozSource.com” is not a for-profit spin-off of the Mozilla Foundation. I repeat, not. The Mozilla Foundation does not have a for-profit spin-off. The entity calling itself MozSource.com is not a spin-off of the Mozilla Foundation in any sense. It is an independent organization, not a part of the Mozilla Foundation. Whatever dreams the entity calling itself MozSource.com has for making money are not the dreams of the Mozilla Foundation. The entity calling itself MozSource.com cannot be an extension of the Mozilla Store.

    I am deeply distressed by this article. It does not accurately represent either the actions or the dreams of the Mozilla Foundation.

    Update: It looks like Red Herring has moved the article. And the website for “mozsource” describes the relationship between that entity and the Mozilla Foundation. So it looks like the chance of confusion has been alleviated.

  • People on the Move

    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 [email protected].

    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.

  • Netscape DevEdge Content

    It appears that Netscape DevEdge is gone. I am working to see if the Mozilla Foundation can get a license to important DevEdge content so that it remains available to the community. I suspect that the end of Netscape DevEdge before the Mozilla Foundation is authorized and set up to take over this function is a miscommunication somewhere along the line.

    We do not currently have copies of the DevEdge material, nor do we yet have the right to display and maintain them. I am hopeful this will happen, and that we can get something in place quickly.

    I’ll provide updates as soon as I can.

  • Mozilla.org homepage

    Bart’s recent blog post asked for comments about the mozilla.org homepage, and so here are mine.

    I disagree with the view that “the primary purposes of the mozilla.org homepage should be (1) to generate Firefox downloads and (2) to direct people to the information they are looking for on our site.” The mozilla.org homepage is the main view into the Mozilla project. The Mozilla project is bigger than the Mozilla Foundation and bigger than Firefox downloads. I believe that www.mozilla.org should reflect this.

    End user adoption is obviously a critical factor in the success in the Mozilla project and I totally agree that we need to need to make it easy and desirable for end-users to get Firefox. New end-users are coming to Firefox in record numbers; we should celebrate this success and maintain a strong focus on the end-user experience.

    But Firefox is an appealing product because it is an active project with a vibrant community. I am uncomfortable with a home page that doesn’t reflect this.

    It may be that the changes Bart has proposed are exactly what I would do with the page if I were designing it and that we agree on the specific look for www.mozilla.org that makes sense today. I’m not trying to design the page; I’m not the right person for that. But the mozilla.org homepage I would like to see will reflect a broader view of the Mozilla project than Firefox downloads.

  • More on Trademarks and Localization Teams

    I was told that my last post on Localization Teams and Trademarks needed context to make sense to people not intimately involved in the Mozilla project. So here’s a bit of background.

    The Mozilla project includes a phenomenal number of people who voluntarily localize Mozilla releases into their own languages. There are currently 30 localization teams registered for Mozilla Thunderbird, 48 teams registered for Mozilla Firefox and 104 teams registered for the Mozilla Internet Application Suite. Some groups do far more than translate strings, and may also translate website materials, localize the releases and evangelize use of these projects in their geographical areas.

    The Mozilla Localization Project is also a volunteer effort, providing help, structure and guidance for the localization teams. The localization, evangelism and related efforts are part of what drives me to participate in the project. When I look up and see what people around the world are contributing to the Mozilla project, it’s hard to imagine not doing what I can. Nevertheless, mozilla.org staff and more recently the Mozilla Foundation have not had a close working relationship with many of the localization teams and sometimes we appear as the distant central group acting bureaucratic or autocratic. We’re trying to interact on a more regular basis with the localization teams through the Mozilla Localization Project leaders, the Mozilla Europe folks and our own efforts. But of course we’re imperfect, short on resources and probably don’t have as good an understanding of what the localization teams need as we should.

    One area that’s been under discussion is how to respect the commitment, efforts and goals of the localization teams and still have a single Mozilla Firefox product and a single Mozilla Thunderbird product. We understand that some localization teams will want to make significant changes, perhaps including different, additional or locale-specific extensions, change themes and otherwise tune the releases to meet their view of local conditions. This is great; it allows a variety of options and experiments. At the same time, a product name should indicate what the product is. Having different releases with the same name would be very confusing. This is a basic strand of trademark law, and also fits with (at least my) general sense of what a product name means.

    This means we need to figure out the application of trademark requirements to our localization teams. Integrating these two is trickier than it might sound. Trademark law is intended to allow consumers to determine the source of origin and the quality of goods. Trademark law is easiest to apply in a highly centralized setting, where all decisions are made by one party and everyone else does as they are told. Of course, our localization teams are highly decentralized groups of volunteers who help build the Mozilla project based on their dedication and interest.

    I made the decision that the Mozilla Foundation will protect the Firefox and Thunderbird trademarks. This isn’t something I’m excited about doing, as trademarks require attention and limit flexibility. But I believe is critical to continued growth and vitality of the project — when someone downloads “Firefox” or “Thunderbird” we need to know what functionality they are getting. This decision meant that we needed a policy to do this while simultaneously recognizing the localization teams and hopefully helping them have both fun and pride in their work.

    A bunch of people went to work to craft a policy. This involved the Mozilla Localization Program, Mozilla Europe, the Mozilla Foundation, our legal counsel, mozilla.org staff, various module owners and other dedicated people. I want to thank everyone who has put time and effort into this, and especially Bart Decrem for driving the process through to completion. It’s taken months and several drafts, and today the 1.0 version of this policy went live. You can find it at www.mozilla.org/foundation/trademarks/l10n-policy.html.