Wrangler Doodles, green.

Building a Better World through Technology

co-founder Mozilla

( from the LizardWrangling Archive )

Category: Mozilla

  • Mozilla Foundation Activities (Part 2)

    In my last post I identified three major areas of importance to the Mozilla Foundation. These were: project governance, promoting open source and Mozilla software, and development of the Internet as an open, accessible platform. Here I take a stab at translating these broad areas into specific activities that the Foundation should consider. I would say “should undertake” but all things require prioritization and I haven’t tried to rank activities here.

    A. The Mozilla Foundation should cause useful open source internet software to be delivered to human beings. The Mozilla Foundation has delegated a piece of this work related to technical and product development to the Mozilla Corporation. So the Foundation should exercise oversight.

  • Mozilla Foundation Activities (Part 1)

    What kinds of activities should the Mozilla Foundation undertake? When I think of this I look at three major areas that provide input. The Mozilla Foundation could take on additional tasks as well, but there are three that seem fundamental to me. I’ll describe each area in some detail below, but the summary is:

    • Project governance and community dynamics — keeping the project healthy
    • Promoting open source software and Mozilla software; and
    • Promoting development of the Internet as an innovative, accessible universal platform

    A. First, the Mozilla Foundation is the home of the Mozilla project. The Mozilla project existed long before the Foundation. The project was founded in 1998, and developed a community, a governance and implementation model, a set of projects and a great deal of software, expertise and best practices. This was done through informal arrangements based on community norms and participation, without the assistance of a legal home for the project. Those active in project governance had long wanted a legal organization for the project and that goal was achieved in July of 2003 with the creation of the Mozilla Foundation. The Mozilla Foundation enjoyed a high degree of continuity with the organizational structure. Key leaders remained in essentially the same roles. Key processes remained in place, particularly the ways in which developers interact with each other and create software. The Mozilla Foundation became the natural and long-awaited official home of the Mozilla project. Some things fall out pretty clearly from this role as home of the project.

    One critical piece of the identity of the Mozilla project is tied to how we build software — an open source, distributed model with delegated authority. So a critical aspect of what the Foundation needs to do is to maintain healthy project dynamics relating to how we build software. Historically this was done by mozilla.org staff; it’s time to integrate the Mozilla Foundation and community-based leadership.

    B. Second, because it is a public benefit corporation the Mozilla Foundation has a specific legal reason for existing which is set out in its Articles of Incorporation “The specific purpose of the Corporation [here meaning the Foundation] is to promote the development of, public access to and adoption of the open source Mozilla web browsing and Internet application software.

    C. Third, the Mozilla Foundation’s tax-exampt status is governed by the exempt purpose approved by the IRS and the State of California. This purpose in the IRS application is: “The exempt purpose of the Foundation is to serve the general public by undertaking activities to (1) keep the Internet a universal platform that is accessible by anyone from anywhere, using any computer, and (2) promote the continuation of the innovation on the Internet (which as already affected the lives of more than 500 million Internet users). Specifically, the Foundation’s exempt purpose is to develop (a) open source, standards-compliant, free Internet applications that will be usable by (and made available free-of-charge to) tens of millions of users, and (b) foundational technologies that will be used by content developers and software developers to develop standards-compliant online content and open source Internet software.”

    In my next post I’ll translate this into a set of more specific activities.

  • RSS Icon and trademark application

    There have been some questions about the RSS icon and trademark protection. The Mozilla Foundation filed a trademark application a while back during the process of evaluating what course of action to take. Same with creating a trademark license to see what it would look like.

    After looking at this, we all believe that a community driven approach is best and that trademark licensing don’t make sense for a number of reasons. So several things could happen with the existing trademark application. The Mozilla Foundation could abandon the trademark application. The Mozilla Foundation could commit to managing the trademark only as determined by the community process.

    The one thing that I don’t know how to do effectively is to give the mark to some other organization for it to manage. That’s because I don’t know of any generally known and accepted organization for dealing with trademarks. Creative Common is copyright only; the standards bodies aren’t trademark organizations. I’m pretty sure there are organizations that enforce particular marks, but I don’t know of anything analogous to a standards body for enforcing community-governed icons and marks. In the long run having such an organization could be very valuable and I think we’re going to see an increasing need for this. In the meantime, I think the options are as noted above: either the Mozilla Foundation has a trademark and manages it based on community process or we rely entirely on community norms.

    My belief is that trying to have the Mozilla Foundation officially responsible for an icon that is already in use is going to cause angst as well as make it harder to have calm discussions about the RSS icon and the proper role for trademark in community-driven activities. This is counterproductive. If abandoning the trademark application (a) makes people feel safer using the mark and/or (b) allows us to have the community-driven trademark discussion in a calmer setting and without suspicion, then withdrawing the trademark application makes sense.

    Look for more on the RSS topic from Frank Hecker shortly.

  • Leadership vs. Coordination

    Last week I wrote a bit about leadership and there was a brief discussion of the degree to which a leader helps the community decide and how much a leader actually make decisions.

    The coordination function in the Mozilla project is huge. We are a large group of people with many different perspectives. Just developing good communication channels is a challenge. Coordinating the responses, repercussions and interactions of our activities is an even bigger task. This involves constant communication, gathering input, making sure relevant ideas are heard and understood, and juggling some set of activities to get to an answer. At heart, coordination is a process. It’s a critical process, particularly in an open source world where so many people can easily go elsewhere if they don’t like the results.

    But coordination is not leadership; leadership is much more. Leadership involves taking all that one knows and setting direction. Open source projects are different from many other organizations in how one achieves a leadership role and how the scope of that role is determined. But the fundamental need for some person or group to make decisions, articulate a direction and lead forward motion remains.

    One classic form of leadership in the Mozilla project is the module owner system. A good module owner listens to peers and contributors and in most cases makes decisions that set the direction for the code under his or her stewardship. And yet a module owner’s authority is ultimately determined by the expertise and contributions of the people s/he leads and the degree of confidence of other project leaders. Another classic form of leadership in our world is the person who decides it’s necessary to do something and does it. New projects, new ideas; new technology. Often people lead by doing, and seeing what happens.

    Coordination is critical. Good listening is critical. Good leadership is more.

  • What do icons mean? (Part 2)

    My last post ended with the question: What is the best method of encouraging the use of the RSS icon in Firefox today by many players and still have the icon mean something clear and accurate? There are a few possibilities.

    Option 1: The Mozilla Foundation allows the icon to be modified as people want, and to be used on whatever products, services or applications people want to use it on. No one has any particular ability to cause consistency. In other words, we treat the icon like code — use an open source license and turn the icon loose.

    This allows maximum flexibility for software vendors and website operators — each can take a recognized image and use it for whatever one want. The flip side is that consumers won’t be able to look at the icon and know what it means. Many consumers are intimidated by the Internet as it is, and struggle to understand the difference between software, search, “the Internet” and data provided by websites. So to my mind, making things clear to the consumer is a high value. The purpose of the icon is to indicate something specific to consumers.

    And we know that successful open development efforts have leadership to guide development, not just intellectual property assets floating in the wild. So even this route requires some attention and structure from someone as to how the icon is used, how it develops and how people might want to use the icon.

    So to my mind attaching an open source copyright license to the icon and turning it loose seems like a bad plan; one likely to lead to maximum confusion for consumers, and minimum assistance for the groups wanting to create a useful marker for consumers.

    Option 2: The other extreme is a classic trademark licensing program. In this setting the Mozilla Foundation licenses the icon as a trademark to everyone on the same terms and has a formal process for managing the evolution and use of the mark. That process might be community focused, and the Mozilla Foundation would be the ultimate decision-maker as the owner of the mark.

    The advantage to this system include:

    • A level of clarity over the degree to which the icon can be assured to mean something to consumers;
    • Having a known “home” for the icon, a known place to bring issues and work out discussions
    • Not all organizations show much respect for community norms. Living within a known legal framework provides another tool for responding to bad actors.

    Disadvantages include:

    • Use of trademark law in open and community processes is new and sometimes not well liked.
    • I believe the Free and Open Source Software world is due for a long discussion of trademarks, how we use them, what their value is and so on. Ultimately I’d like to see some Creative Commons type options available for trademark-type purposes. (Creative Commons licenses are all copyright licenses, and do not purport to address the trademark-like issues of providing clarity to consumers about what consumers are getting.) We haven’t had this discussion yet.
    • A formal trademark process can be a significant amount of work. The Mozilla Foundation will take that work on for key marks, like its product marks. The Mozilla Foundation should also be willing to take on leadership, organization and work for other marks that are important to the industry, including the RSS icon. However, taking on these activities before we’ve had the trademark discussion could be counter-productive. If we use the RSS icon to start talking about what industry wide icons can and should mean we should come to some shared understanding (or at least shared vocabulary, if not understanding) of the value of an icon and how best to make this visual clues mean something real for consumers.

    Option 3: Another option is to try a less formal process with more authority resided in community norms and seeing how that works. To do this the Mozilla Foundation would:

    • develop a clear set of community norms and usage guidelines;
    • lead a community process for the evolution of the mark and the guidelines; and
    • identify a mechanism where companies using the icon (particularly in software products) publicly pledge to the implementation of the guidelines and complying with the results of the community process.

    I believe Option 3 is the best approach for the RSS icon at this point in time. People are interested in the icon, people are already using the icon, we can learn how precise a meaning we believe it should have and how community norms function in this setting.

    I’m recommending that the Mozilla Foundation adopt Option 3, publish a set of usage guidelines and proposed community norms (potential examples include: public discussion and evaluation before using the icons for new versions of file formats, proposed modifications of the icon, statement of intent that the icon continue to mean something precise to consumers, etc.) and provide a forum for discussion as soon as possible.

  • What do icons mean? (Part 1)

    Here’s a question with both philosophical underpinnings and a concrete set of product implications. The philosophical side of this question includes questions such as:

    • how does a consumer know what web services he or she is requesting?
    • How important is consumer clarity?
    • How do we encourage clarity across a networked base of products?
    • If consumer clarity is important, how do we get this?
    • Is it possible to provide consumers this level of clarity without some organized control mechanism?
    • Can these issues be managed through a community-based process? Or is a more formal legal structure useful?
    • Is community leadership enough, or is an ultimate decision-maker necessary?

    The concrete example here is the RSS icon that’s been in Firefox for some time now. Mozilla Firefox includes an icon that represents the availability of an XML based RSS feed. When you click on the icon in the location bar of Firefox you are able to add an RSS feed just as one adds a bookmark. When you click on a bookmark identified with the RSS icon (a “live bookmark” in our parlance) you see the recent entries from that RSS feed. A number of web sites use the same icon to help consumers recognize the presence of an RSS feed that can be added to Firefox or an alternative piece of software that understands RSS feeds (such as a “feed reader”).

    A while back Microsoft approached us about using the Mozilla RSS icon in the upcoming version of its browser. We thought that having multiple software products use the same icon to represent the presence of an RSS feed would be helpful to consumers. It would provide a standard visual clue for consumers and provide clarity. Of course, this only works if the icon actually represents something reasonably crisply and accurately. If a single icon comes to be used for many different things then there’s not much benefit to consumers, and might even be some disadvantages. (For example, it would not help consumers to click on the so-called RSS icon and end up downloading some wildly different format.)

    So what is the best method of promoting the use of this icon by many players and still have the icon mean something clear and accurate to consumers? In an effort to keep my posts to a digestible length I’ll describe the methods we’ve thought though in the next post.

  • The “community” and decision-making

    Periodically I hear people say things like “the community will decide.” Or “let the community handle it.” This has always sounded amorphous to me and I’ve finally realized why. This way of looking at things assumes there is little clear leadership and no actual decision-maker. This is a misunderstanding of many open source projects, which have real leadership and ultimate decision makers. For example, Linus Torvalds makes decisions for the kernel, Apache has a committee system, Brendan is responsible for technical decisions in the Mozilla project. In the Mozilla project we try to delegate authority so that:

    • many decision-makers are involved in their areas of expertise;
    • an ultimate decision-maker exists but is involved only when necessary; and
    • decision-makers are chosen and evaluated by their ability to provide leadership that draws in other contributors.

    This last point is extremely important. Decision-makers who don’t provide leadership make it hard to build a good project. Decision-makers who people don’t want to follow will struggle. Open source software always gives people a choice. Participants are always free to try something different using the same underlying code. So the decision-maker’s role has many facets. Basically it boils down to making enough decisions correctly enough that people continue to choose to participate. In other words, leadership.

    Other projects may invoke the authority of the ultimate decision maker more or less often. The important point is that many open source projects incorporate clear decision-making into their processes.

  • Coming 10 July 06: More on the grants and donations program

    In late March I wrote a bit about a grants and donations program I’d like to get started. Since then I’ve received some great comments about some of the issues this raises, some suggestions and seen some press comments. Even more important, we’ve come across someone we think is the right person to help us make progress. He’s someone with a proven commitment to the thoughtful use of funds to improve community and community leaders as well as background in business matters, which is important and designing and implementing programs related to money. He’s just graduating from business school, is taking a month off and will start working on this program on July 10. So this is a note to say that we haven’t forgotten about this, we’re making progress and expect more in a month.

    Until then I want to emphasize that the goal of any program we test is not to turn our community into employees. The goal of such a program is to learn if and how we can use some of the Firefox revenue to support and strengthen the activities of the Mozilla community beyond those people employed by the Foundation and Mozilla Corporation.

    A number of the comments I received refer to the dangers of doing anything with money. They express the concern that any programs involving money run the risk of contaminating our community, or of turning it into a mercenary group interested only in money. I understand the risks. I also believe there are risks in ignoring money. Firefox generates revenue now, that’s a fact. So we need to deal with money. (And we have the privilege of being able to employ people to work full time on Mozilla, which I believe is necessary for a project of our size and scope. Not all open source projects believe this however, and some are wary of employees or almost any activity that requires the distribution of funds.)

    We use all other resources to strengthen our community. Key contributors devote time to paying attention to others, to helping others, to getting help from others. We redesign our planning, development and marketing processes to make them easier for others to particulate and to build on what we do. We evaluate our technology to make it increasingly useful for others to build things. We distribute authority and leadership. We value reviewing patches written by others, sometimes above having experts code themselves.

    The idea of using money to help strengthen our community is new. Having revenues is new for most open source projects and so there isn’t a lot of experience in how to use it wisely to build community. It’s possible the doubters are correct, and the best thing to do is use it all for employees, expenses, bandwidth, infrastructure and a savings account. I hope this is not the case and we can strengthen the commitment and effectiveness of the Mozilla contributors and the reach of the Mozilla project through small applications of funds to the right places.

    It feels to me that we should try. Our DNA is to distribute all sorts of things that conventional wisdom says (or said) can’t be done: distributing code without charge, distributing the development of that code, distributing authority over that code, distributing outreach programs (think Spread Firefox and the localization communities), distributing motivations, expertise and leadership. I’d like to see if we can develop some programs to distribute funds where appropriate.

    We’ll turn to this in detail in mid-July.

  • New Roles in Open Source — Part II

    In a recent post I wrote about the role of non-engineers in our project. A couple of people responded along the lines of “why can’t we just use our standard techniques, where people come up through bug triage, or our online communities, etc?” I’m glad people asked this because this is a critical point, and at the heart of the topic I want to address.

    I whole-heartedly agree with the spirit of this response — people are effective when they are known and respected. This is the basis of shared values, community cohesiveness and continuity. It’s one of the tenants of open source software development that I believe must permeate everything we do. Our challenge is to use this approach in places where engineering “chops” aren’t a sufficient and may not be a particularly necessary criteria.

    When we apply this approach of legitimacy-through-reputation to the Mozilla project, it’s clear how engineers “come up through the ranks” and move into broader roles. The combination of “coming up through the ranks” and an organization that is historically mostly engineers means that one “comes up” through an engineering process — bug triage, patches, etc. And we have gotten some great product and project management through our phenomenal collection of lead engineers.

    But if one’s skillset is something other than code, then proving oneself through understanding the intricacies of our code is at best inefficient and probably a blocker for many people. So the challenges are to find mechanisms for people in non-code roles to demonstrate they share the values of the Mozilla project and can make contributions that people want to support.

    Right now, we’re in the early phases of both building communities focused on product management or marketing and of building those functions into our product development. We’re further along with marketing, since the spread firefox has been active since Fx 1.0 and volunteer marketing began even before that. But even so, a few years isn’t a long time. Open source has been around for decades, and there is a significant group of engineers who participate as volunteers, and a significant group whose work involves open source projects. We know what the set of activities are that lead to acceptance and leadership. That’s no so clearly the case for the set of other activities.

    The heritage of open source is primarily about code; only recently about product. And even more recently still about consumer products — I often hear Firefox described as the first genuine open source product for the “mass market.” So it’s not surprising that the Mozilla project is looking at a lot of activities that are new (or new-ish) to the open source world.

    We certainly don’t want to exclude people from influencing the project because they aren’t writing or testing code — this would limit the project drastically. At the same time, we maintain our technical excellence through openness, peer review, and the open source process. We need to find ways to continue to build these strengths into all of our activities.

  • Mozilla Foundation and Project Leadership

    The Mozilla project is an enormous worldwide community of people who choose to work together to produce and share technology, products and a passion for the web. The Mozilla Foundation is the official home of the Mozilla project. It has certain special abilities and responsibilities with regard to leadership of the Mozilla project and stewardship of the project’s assets.

    In some ways the Mozilla Foundation is like the proverbial “tip of the iceberg.” It’s the easiest part to see, it has a size and structure that is easy to understand. But the heart of the Mozilla project is the enormous, highly motivated, loosely structured set of communities that make the project vibrant. Like the tip of an iceberg the Mozilla Foundation is a good marker for the larger reality and a good place to start an understanding of the project. And like an iceberg, one needs to go far beyond the surface of the Mozilla Foundation to understand the breadth and depth of the Mozilla project.

    In other words, the Mozilla project is larger than the Mozilla Foundation and its employees. This fact should be reflected in the way the Mozilla Foundation organizes itself. Employment with the Mozilla Foundation is not and must not become the source of all authority within the Mozilla project. Contributors must have a voice within the Mozilla project unrelated to employment.

    In the days before the Mozilla Foundation existed a group of people known as “mozilla.org staff” provided this voice. Mozilla.org staff was a virtual organization which governed the Mozilla project in general, and did so increasingly unrelated to any employment relationship. Some of the functions that mozilla.org staff used to fulfill now live in the Foundation — stewardship of the assets, release of products using the Mozilla name, as examples. So the old model of mozilla.org staff cannot continue unchanged in the world of the Foundation.

    Nevertheless, we need a mechanism to recognize, organize and legitimate the leadership of key contributors and community members unrelated to employment status. This mechanism should both (a) organize and amplify this contributor voice and (b) give this voice input and participation into the Mozilla Foundation’s activities.

    We have proven policies for ensuring authority unrelated to employment in the development of code itself. We need a way to maintain and update these policies that doesn’t put all leadership in the hands of Mozilla Foundation employees. We also need to ensure contributors can provide leadership in Mozilla project activities other than writing code.

    Some may ask “why?” “Why doesn’t the Mozilla Foundation simply take on the leadership and governance role through its employees?” there are many answers to this. First, the Mozilla project is an open source project. We build software through distributed authority based on reputation, peer review, proven results and ability to lead others through results rather than title. This system produces great results, allows new contributors to appear from unexpected places and join us, drives technical excellence and prevents group-think from making us complacent. The operating style of the Mozilla Foundation must reflect this DNA.

    Secondly, the Mozilla Foundation does not and will not employ all the great contributors to the Mozilla project. There are far too many contributors for this to be the case. And it is an explicit goal to have volunteers and people employed by different organizations contributing to get broader perspectives into the heart of the project. Expertise and dedication will exist outside of the Mozilla Foundation’s employee base. It is critical that these contributors have an understood, identified, accepted way to participate in the Mozilla Foundation’s activities.

    Those people who have been involved in the project for along time have a short hand phrase for this — we say that “mozilla.org staff needs to be revitalized to provide this role.” Framed more generally the question is: We need a way for participants to exercise leadership and moral authority in the governance and activities of the Mozilla project that is unrelated to one’s employment status. We need to articulate the scope of that leadership and authority and create a mechanism by which that voice is involved in Mozilla Foundation activities.