Talk Scheduling At Conferences

I’m at FOSDEM this weekend; it’s a large conference. They seem to find one or two new rooms to use every year, and it now sprawls across most of the ULB campus in Brussels.

It has rather surprised me that several otherwise experienced and excellent devroom organizers (naming no names) have organized their rooms on the mistaken belief that switching between speakers, and having people exit and enter the room, happens instantaneously. It doesn’t.

If you schedule your talks in 25 or 55 minute slots (including Q&A) instead of 30 or 60 minute slots, you benefit yourselves, your audiences, and the whole conference in the following ways:

  • Attendees don’t feel they have to leave the talk in your room before the end in order to be sure of catching the beginning of the next talk somewhere else, thereby disrupting the talk, missing the last bits of content (perhaps the all-important summary) and missing the chance to thank the speaker.
  • Attendees can enter and leave the room without feeling they are being rushed or have to be totally silent. (“Please be quiet while entering and leaving/during the Q&A” really doesn’t work.)
  • Room organizers have time to encourage people to move to the middle, or other compression strategies, and pack their rooms for maximum benefit.
  • Whoever is helping you with audio-visual can switch over laptops and get microphones moved over without disrupting the end of the previous talk or making the next speaker start late.
  • Attendees released from your room do not turn up at a different room 5 minutes after the start, thereby disrupting their talks. Love your neighbour.

If you don’t do this, and schedule in 30 minute slots, what happens is that people actually still get 25 minutes or less to speak, as changeovers still have to happen, but the speaker ends up starting late, rushed and grumpy and no-one really knows when they need to finish. 30 minute slots are an illusion. 10 minute/5 minute/2 minute/Time’s Up! cards are a very useful addition to this system, so the speaker knows exactly where they are. If they don’t finish in time and have to be cut off, then they need to be gently encouraged to prepare better next time.

It may be that 5 minutes is not long enough for people to get from one side of the conference campus to the other, and so the issues are not totally suppressed. But there’s only so much you can do, and giving people 5 minutes is much better than giving them 0 minutes.

Making Good Decisions

Mitchell has been focussed for a while on how Mozilla can make good decisions which are made quickly rather than getting bogged down, but which do not bypass the important step of getting the opinions of a diverse cross-section of interested and knowledgeable members of our community.

In relation to that, I’d like to re-draw everyone’s attention to Productive Discussion, a document which came out of a session at the Summit in Brussels in 2013, and which explains how best to hold a community consultation in a way which invites positive, useful input and avoids the paralysis of assuming that consensus is required before one can move forward.

If there’s a decision you are responsible for making and want to make it using best practice within our community, it’s a recommended read.

What I’m Up To

It seems like I’m only managing one blog post a month at the moment. I’m doing loads of things, but don’t seem to have time to blog about them! Currently, the major components of my work are:

  • Helping Thunderbird get to a good and sustainable place (status update)
  • Running MOSS (applications always open!)
  • Copyright work for the public policy team

On that last point, we just submitted a filing to a US Copyright Office consultation on the famous section 1201 of the DMCA, which is the one which regulates the every three years exemption process for bypassing DRM. See our blog post here, which links to our filing. While this process is not really fixable in its current form, I hope we can help to make it a little better.

The Zeroth Human Freedom

We who lived in concentration camps can remember those who walked through the huts comforting others, giving away their last piece of bread. They may have been few in number, but they offer sufficient proof that everything can be taken from a person but the last of the human freedoms – to choose one’s attitude to any set of circumstances – to choose our own way.

This quote is from From Death-Camp to Existentialism (a.k.a. Man’s Search for Meaning) by Victor Frankl. Frankl was an Austrian Jew who spent four years in concentration camps, and afterwards wrote a book about his experiences which has sold over 10 million copies. This quote was part of a sermon yesterday (on contentment) but I share it here because it’s very powerful, and I think it’s also very relevant to how communities live together – with Mozilla being a case in point.

Choosing one’s attitude to a set of circumstances – of which “someone has written something I disagree with and I have become aware of it” is but a small example – is an ability we all have. If someone even in the unimaginable horror of a concentration camp can still retain it, we should all be able to exercise it too. We can choose to react with equanimity… or not. We can choose to be offended and outraged and angry… or not. To say that we cannot do this is to say that we have lost the most basic of human freedoms. No. We are all more than the sum of our circumstances.

Unanimity Is Not a Requirement

People sometimes wonder how to best involve all of the affected/important/relevant parts of the Mozilla community in a decision. The prospect of doing this can lead to a certain amount of fear – of criticism, bike-shedding, etc.

At the last All Hands in October 2013, at a session in Brussels, we produced a Best Practices document called “Productive Discussion” to help with exactly this problem. Given Mitchell’s keynote at the recent All Hands, I thought it was worth reflagging its existence.

How We Should Be

Four weeks ago, I posted about Who We Are and How We Should Be. I wrote:

As I see it, the principle behind the [Community Participation Guidelines] was, in regard to non-mission things: leave it outside. We agreed to agree on the mission, and agreed to disagree on everything else. And, the hope was, that created a safe space for everyone to collaborate on what we agreed on, and put our combined efforts into keeping the Internet open and free.

Is that CPG principle still the right one? Are the CPGs the best expression of it?

Following on from Who We Are, here is my answer to How We Should Be.

I think the principle is still the right one, but the CPGs could express it better.

The CPGs have many good things about them, and I think that they did a good job of defusing the difficulties in our community at the time they were written in 2012. But they still very much bear the marks of the worldview of the person who wrote them. (This is not surprising or in itself worthy of criticism; it’s very difficult to write in a way which does not show one’s own worldview.)

The world the CPGs conjure up is one where there are two groups of people. There are those who are wholeheartedly for “inclusion and diversity” in every way – let’s call them group A. And those who “identify with activities or organizations that do not support the same inclusion and diversity standards as Mozilla” – let’s call them group B.

The CPGs seem to have the following assumptions:

  1. Attacks on Mozilla’s inclusivity and diversity will only come from group B;
  2. Anyone who supports exclusionary practices in some other sphere (i.e. those in group B) is likely to want to see them in Mozilla;
  3. The key thing is to keep support for exclusion out of “Mozilla spaces”, so they remain safe for people who would otherwise feel or be excluded.

Therefore people in group B need constraining, such that “support for exclusionary practices in non-Mozilla activities [is] not … expressed in Mozilla spaces”. And so that is what the CPGs say.

However, in the recent series of unfortunate events, the attacks on Mozilla’s inclusivity and diversity came from people who would self-identify with group A (not matching assumption 1) and were directed at someone who, by long example, clearly did not match assumption 2. Support for exclusion (or, at least, for restriction) was expressed by some Mozillians in a very public way, but it was not in a specifically Mozilla space – yet it clearly resulted in exclusion, and in damage to the project and its mission. So assumption 3 didn’t really hold either.

It is true that the CPGs also restrict people in group A, in that they are conditionally asked to “treat [support for exclusionary practices outside Mozilla] as a private matter, not a Mozilla issue”, and that was not done in this case. That is a matter of deep regret. But I don’t think the consequential and conditional statement here gives full and clear force to the strong need for both sides to understand that disagreements of this kind within Mozilla are deeply damaging to our unity and capability as a project.

So, I think we would do well to redefine our alliance as a community. This would involve rewriting the CPGs in a way which expresses the principle of “agree to disagree on non-mission things” more evenhandedly and broadly, and making it clear that it applies to everyone, in all the Mozilla-related communications they make, wherever they are made. I think we must abandon the distinction between Mozilla and non-Mozilla spaces. It clearly wasn’t useful in staving off the damage in this case, and as a definition it always had boundary problems anyway. On today’s internet, it doesn’t matter where you express something – it can be around the world in an instant. And if we move to that model, in order to avoid unfairly restricting people’s speech wherever they may be talking, we would also need to change our attitude to the content of what people say. Instead of “don’t talk about that here”, we should instead affirm the principle of “I disapprove of what you say, but I will defend to the death your right to say it”.

That is not to argue for carte blanche for people to fill up Mozilla communications channels with political advocacy of one sort or another. Most of our channels have a concept of “off-topic”, and that would not change. But only a project dominated by a small group of people from a single consistent political ideology could ever hope to have and maintain a policy of “do not ever even expose me to ideas with which I disagree”. And, as an international project with big growth ambitions, Mozilla is and should not be such.

Respectfully expressing opinions – in any space – should be fine; calling for exclusion from or demotion in Mozilla due to those opinions – in any space – should not be.

Who We Are

Two weeks ago, I posted about Who We Are and How We Should Be. I wrote:

But before we figure out how to be, we need to figure out who we are. What is the mission around which we are uniting? What’s included, and what’s excluded? Does Mozilla have a strict or expansive interpretation of the Mozilla Manifesto?

Here is my answer.

I think Mozilla needs to have a strict/close/tight/limited (whichever word you prefer) interpretation of the Mozilla Manifesto. To quote that document: we need to focus on “the health of the Internet”. We need to work on “making the Internet experience better”. We need to make sure “the Internet … continue[s] to benefit the public good”. As well as the 10 principles, the Manifesto also has a Mozilla Foundation Pledge:

The Mozilla Foundation pledges to support the Mozilla Manifesto in its activities. Specifically, we will:

  • build and enable open-source technologies and communities that support the Manifesto’s principles;
  • build and deliver great consumer products that support the Manifesto’s principles;
  • use the Mozilla assets (intellectual property such as copyrights and trademarks, infrastructure, funds, and reputation) to keep the Internet an open platform;
  • promote models for creating economic value for the public benefit; and
  • promote the Mozilla Manifesto principles in public discourse and within the Internet industry.

Some Foundation activities—currently the creation, delivery and promotion of consumer products—are conducted primarily through the Mozilla Foundation’s wholly owned subsidiary, the Mozilla Corporation.

I think that’s an awesome summary of what we should be doing, and I think we should view activities outside that scope with healthy suspicion.

It seems to me that this logical fallacy is common:

  1. Mozilla supports awesome things X and Y.
  2. I, and many Mozillians, also support awesome thing Z, and we use the same type of language to talk about X, Y and Z.
  3. Therefore, Mozilla does/should support awesome thing Z.

It can also appear as:

  1. Mozilla is an activist organization.
  2. I am an activist, and I’m in Mozilla.
  3. Mozilla does/should support me in all my activism.

Given the diversity of Mozillians, these cannot be good logic if applied equally and fairly. Mozilla would end up supporting many mutually-contradictory positions.

Some people believe so strongly in their non-open-web cause that they want to use the power of Mozilla to attain victory in that other cause. I can see the temptation – Mozilla is a powerful weapon. But doing that damages Mozilla – both by blurring our focus and message, and by distancing and discouraging Mozillians and potential Mozillians who take a different view. Those who care about Mozilla’s cause and about other causes deeply may find it hard to resist advocating that we give in to the temptation, but I assert that we as an organization should actively avoid promoting, or letting anyone use the Mozilla name to promote, non-open-web causes, because it will be at the expense of Mozilla’s inclusiveness and focus.

We are Mozillians. We need to agree on the Mozilla Manifesto, and agree to disagree on everything else.

Your Ire Is Misdirected

Hi. My name is Gervase Markham. I’m a supporter of traditional marriage, and I work for Mozilla. In fact, as far as being on the record goes, I believe I’m now the only one.

Many people who agree with me on this issue are very upset about what happened to Brendan Eich, our co-founder and, for two weeks, CEO of the Mozilla Corporation. Brendan was appointed and then, after 10 days under the Internet’s lens of anger based on his donation in opposition to the redefinition of marriage, stepped down and stepped away from Mozilla – to our great loss.

I am assured by sources I trust that Brendan decided to leave of his own accord – he was not forced out. My understanding is that the senior management of Mozilla (many of whom disagree with him on this issue) worked very hard to support him, even if I would not agree with all the actions they took in doing so. However, he eventually felt that it was impossible for him to focus on leading if he was spending all of his time dealing with the continued, relentless news and social media storm surrounding the donation he made. In other words, he wasn’t forced out from the inside – he was dragged out from the outside.

So, here’s my plea: please don’t be angry with Mozilla. Mozilla and what it does and stands for is too important to the future of the free web to allow this to do it damage. It was us who brough innovation back to the web browser market and started the process which led to the awesome web you use today. And now, we’re trying to do the same with the closed smartphone market. I believe that connecting billions of people in the developing world to the web at minimal cost and with full fidelity will lead to the next great advance in human flourishing, as people can use the information they discover to make their own lives better. That’s our goal.

If you can’t find it in your heart to forgive them (the course I would recommend), then your anger is best directed at those outside Mozilla who made his position untenable. The press that twist and sensationalize without investigation, social media which magnifies and over-simplifies without consideration, and those who rush to judgement without understanding. I’m not going to name names or organizations. But as far as Mozilla itself goes, please, please continue to support us.

I am determined to work to make all Mozillians of whatever beliefs – and whatever actions they take outside of Mozilla in support of those beliefs – confident that, if they can work with other Mozillians as Brendan did so well for 15 years, Mozilla is a place for them. How successful we’ll be at that depends on how our community deals with what just happened – but it also depends on you. If you jump to paint Mozilla in the colours of ‘the opposition’, that will become a self-fulfilling prophecy. And the world will be poorer for it.

Mozilla is caught in the middle of a worldview war. Let’s not make the free web a casualty.

Mozilla and Proprietary Software

Mozilla is both a principled organization and a pragmatic one.

Mozilla products run on proprietary operating systems, and on proprietary hardware. We are in the mobile OS business, and no-one, not even the mighty Google, has yet been able to make a 100% open source phone available in commercial quantities. So proprietary software is part of Mozilla’s life. But I think most people in our community would be rightly upset if Mozilla decided, for example, to take advantage of the provision in the MPL which would allow us to ship proprietary builds of Firefox on the desktop.

So, the question arises: where’s the line? Where in the big picture is it OK for proprietary software to be, and where is it not OK?

“You don’t have to make a case for open. You have to make a case for not open.” — Johnathan Nightingale

Over time, this question has been arising in a number of different contexts. And I think the answers we might give at the Mozilla project would be different to those you might hear from the FSF, or the Apache project, or the Android project, to name but three points on a wide spectrum of opinion. So I think it would be a productive conversation to try and work out some principles in this area – or, at least, to gauge the range of opinion. As johnath says, if we are using or distributing closed software, we need to make an active case for why we are doing it.

This post is therefore a discussion starter, and outlines where I currently think the line is – i.e. where a reasonable case can be made for closed, and where it cannot. It could be in the future, a case can be made for additions to, removals from or modifications of this list. But having a defined list at least helps to make it more clear what is a new situation where a case needs to be made, what is another example of something we’ve done before.

Note that this post represents my opinion only, and is not official Mozilla policy. Although it speaks of things that currently are, as well as things that currently are not, for ease of reading, I will write directly rather than using conditional language (i.e. “will” rather than “should”).


  1. The basic rule is that software written by Mozilla will be open source. Mozilla is a public benefit organization; we do not use money given to us to write proprietary software.

    Rationale: Manifesto Principle 7.

  2. Mozilla may distribute proprietary software written by others with its own software under the following circumstances:
    1. If it’s a missing important piece of functionality provided by an OS vendor for a proprietary operating system on which our software runs;
    2. If the software is required to make use of the hardware on which the product runs, and there is no open source alternative driver of sufficient quality.

    Example of A): the Direct3D DLL, included under the Binary Components policy. Example of B): hardware drivers for Firefox OS.

    These situations are seen as sub-optimal and we look for opportunities to eliminate them, as opportunity and market power permit. They are not seen as precedent-setting. This is a negotiating point in discussions with hardware manufacturers, particularly for reference devices.

    In the past, we shipped the “Talkback” crash-reporting software, which did not fall under either of these exceptions. We now use the open source Breakpad. This replacement took seven long years to arrive. Now that Talkback is gone, we should not go back there.

    Rationale: without such exceptions, we can’t ship competitive products (or, in the case of B, any products at all). But we need to define them tightly.

  3. Mozilla’s products will execute proprietary code in web content.

    Example: most JavaScript on the web today.

    Rationale: without this, our products would effectively not browse the web at all.

  4. Partners

  5. Mozilla may permit its partners to distribute proprietary software in a product using a Mozilla brand under the circumstances above. Mozilla’s partners may also ship proprietary apps in their versions of Firefox OS. Such apps must be uninstallable. Additions to the platform not falling under one of the exceptions above must be open source.

    Rationale: same as above, plus requiring that all default partner apps be free software means many popular apps could not be bundled, making our offering much less compelling. If we allow users to install proprietary apps, there is not significant additional harm in bundling (uninstallable) ones. Requiring arbitrary platform additions to be open source is necessary to allow users to build updated versions of the software for their phones. (Binary driver blobs use a known API and, while it’s sub-optimal, can be copied from official builds into user ones.)

  6. Mozilla will only allow Mozilla brands to be used for software on phones which are bootloader-unlockable.

    Rationale: Mozilla stands up for user freedom, including the freedom to hack one’s phone, and update the OS even when the vendor has ceased support.

  7. Software Added Later

  8. Mozilla’s products may sometimes automatically download and install deterministically-built binary builds of other open source software where we would prefer not to distribute it ourselves, e.g. for patent license reasons. However, there may be additional requirements we would want to be met before we solved a problem using this solution.

    Example: Cisco’s H.264 binary builds made from OpenH264. (Note: the exact user experience in this case has not yet been determined. I am just saying that I think it would be OK if Firefox downloaded and installed this software automatically.)

    Rationale: Software patents suck. Because Cisco have made H.264 free-as-in-price at the point of use for everyone, we managed to get a draw in this particular round of the codec wars. (The other options were much worse.) But fighting patents is done at the standards and industry level, not at the “make every user click a button” level. If the source is open and the binaries are deterministically built, then users are using binaries of free software which is bit-for-bit identical to that we could build for them ourselves, and so requiring a user confirmation here gains us nothing.

  9. Mozilla will allow proprietary software in the app stores and addons stores that it runs. Mozilla will make sure the license terms for software are clearly marked, and are searchable as a metadata field.

    Example: Firefox OS Marketplace, (Unfortunately, license metadata is not currently collected or available for searching.)

    Rationale: some people, including members of our community and vocal Mozilla supporters, wish to avoid using proprietary software; we should help them make choices in line with their ethics.

  10. Mozilla’s products may give the user the UI option of downloading, installing and running binary builds of proprietary software (e.g. an addon or plugin) but will not get to the point of executing such software without getting explicit or implicit user consent somewhere along the way. “Implicit consent” means that the user has taken some action (e.g. installing the Flash plugin themselves) which was not mediated by Firefox but which we know must have happened.

    Example: Mozilla allows users to download proprietary Firefox add-ons through the Add-On Manager UI. The Plugin Finder Service will point users at downloads of proprietary plugins such as Flash. But all require at least one explicit confirming click to install.

    Rationale: some people, including members of our community and vocal Mozilla supporters, wish to avoid executing proprietary software; we should not sneakily run it on their systems. However, even offering it is enough for Firefox to not be in the FSF’s directory of free software. :-|

  11. Network Services

  12. Mozilla prefers to use open source software for end-user network services it builds into its products. However, we are willing to partner with companies who use proprietary software and/or data. Such proprietary services must be able to be disabled by the user, and the API endpoint must be configurable by the user or 3rd party software such as an extension (e.g. an about:config setting in Desktop Firefox).

    Examples: Safe Browsing, geolocation.

    Rationale: Mozilla is starting efforts in geolocation, speech recognition and translation to either replace or avoid depending on proprietary services in these areas. But building e.g. a replacement for Google Safe Browsing, which protects many, many Firefox users from malware and phishing every day, would be a mammoth undertaking. And removing it would put our users at significant risk. Endpoint URL configurability allows people to reverse-engineer service APIs and implement alternatives which Firefox can then easily use.

  13. Development

  14. Mozilla’s products will run on proprietary operating systems, and therefore may require proprietary software, such as a compiler or SDK, as part of the build process for such systems. Mozilla’s products will not require proprietary tools to build on free operating systems.

    Example: Release builds of Firefox on Windows are built using Microsoft Visual Studio, and most developers on Windows use it for their builds too.

    Rationale: if one is using a proprietary OS, there seems no additional harm in using proprietary build tools.

  15. Mozilla strongly prefers to use open source software for network services it stands up for use by the Mozilla developer community, but may use proprietary software if no open source software of equivalent functionality is available. In such cases, Mozilla provides some resources (money or people) to help rectify that situation.

    Example: Mozilla uses Vidyo, and so Mozillians who want to use it have to use the proprietary Vidyo client, or Flash. But we are developing WebRTC in the browser, and hope that thereby solutions will emerge where people can participate in multi-party video using only open source software. We are also trying to get the SIP gateway working (that bug is restricted to the ‘infra’ group so you may not be able to see it) so people can video-call in using free software.

    Rationale: we should not compromise our effectiveness by using significantly sub-standard tools; but as a member of the wider open source community and as a public benefit organization, we have a responsibility to grow the commons in areas where we have an interest.

  16. Mozilla community members are free to use proprietary desktop software if they wish. Mozilla may therefore pay for licenses for particular bits of proprietary software for the use of Mozilla employees, contractors or interns. Mozilla will not implement systems which require non-employees to use proprietary desktop software to be part of the community.

    Example: Windows, Office, internal payroll or HR systems. (Vidyo doesn’t quite break that last rule, as someone can still dial in to any meeting by phone.)

    Rationale: there are no effective substitutes for some of this software. However, we should not lock free software advocates out of full participation in our community.

How To Run a Productive Community Discussion

I ran a session at the Mozilla Summit with the (wordy) title of “Building a Framework to Enable Mozilla to Effectively Communicate Across Our Community”.

The outcome of the Brussels session, cleaned up, was this document which explains how to run a useful and productive community consultation and discussion. So if you propose something to a colleague, they say “you should ask the community about that”, and a cold sweat breaks out on your forehead, this is the document for you.

Many thanks for Zach Beauvais for doing the initial wrangling of the session notes. Feedback on the current document is very welcome.

What Does ‘Mozillian’ Mean?

Six Summit sessions (2 in each location) tried to determine “What does ‘Mozillian’ mean?”. (For the tl;dr, skip to the bottom.) This blog post explains what the groups in Brussels came up with[0].

The proposed session plan tried to get the group to come up with statements about what does, or does not, make someone a Mozillian. The planned output was one, two or three bullet points under each of four headings – Task/Role, Opinions, Character and Actions. Here is the output from the two Brussels sessions, which I facilitated; I have tried to align similar ideas across the two columns.

Category Brussels 1 Brussels 2
Task/Role Must promote Mozilla values regularly  
  Job title does not have to include “Mozilla“ Must be unrelated to employment
    Must be unrelated to technical skills
Opinions Must share Mozilla values Must believe in open web.
  Must believe that users should be in control of their online presence  
Character Must be open-minded Must be respectful to people of different opinions.
  Must be a team-worker Should be conscious of and interact with community.
  Must not want all the credit  
Actions Try not to exclude groups out of Mozilla
  Must have contributed to a Mozilla project in any way Should proactively benefit the mission.
    Should share and/or use open source.

(Table by Tableizer)

It seems to me (and this is borne out by reading the more freeform Etherpads from Toronto) is that participants felt that a Mozillian has three major characteristics. Firstly, they have to believe in the Mozilla mission. Secondly, they have to actually do something to further that mission. People were willing to be generous about what that might be – it didn’t have to be technical and a potential Mozillian certainly didn’t have to be employed – but they had to do something. Further follow-up work might investigate what counts as something; important cases on the edge here are people who simply make a donation, and people who simply use the software – and the answer may be different for Release, Beta, Aurora or Nightly. But thirdly, the answers of both groups assumed (“must be a team worker”, “should interact with community”) that the person is actually part of a Mozillian community. Which would mean that donators, and people who simply ran the software (without e.g. filing any bug reports) would not be Mozillians.

One of the categories was “Character”. An interesting question which only crystallized itself during the session is this: “if someone does not exhibit a particular desirable character trait, does that make them not a Mozillian, or just a flawed human being (as we all are)?” This issue was discussed in groups when talking about points like “must not want all the credit”. Another interesting follow-up might be to explore whether there are any character flaws so severe, or actions so heinous, that they disqualify someone entirely from consideration.

Another key follow-up question, which we also didn’t have time to explore, is: “If someone in the Mozilla community is not a Mozillian by our new definition (e.g. someone who is paid to work on Mozilla, but does not believe in the mission), how do we treat them? Is it any different?”

But, to try and summarise, I think the Brussels groups felt that a Mozillian was someone who:

  1. believed in the Mozilla mission
  2. took action in support of that mission
  3. was an interacting part of the Mozilla community

So how do we produce a million Mozillians like that? :-)

[0] The Santa Clara sessions have not (yet) provided any session notes, and the Toronto sessions did not use the same session plan as the Brussels sessions and so did not have comparable outputs. The six session note Etherpads can be found linked from the master session Etherpad.

Authority and Accountability

When considering the governance and running of organization such as Mozilla (which we should be doing in the run up to, and during, the Summit), it’s good to think about the relationship between authority and accountability.

Having authority usually requires being accountable. And you can’t make people accountable for something unless they have the authority to affect it. The two go hand in hand.

So: how does Mozilla at the moment (and how should Mozilla in the future) bestow authority on people and hold them accountable? The answer to this question should be the heart of Mozilla’s governance structure.

Mozilla currently de jure (as a matter of law/rules) bestows project authority on people by making them module owners (or by the module owners making them peers). But we also de facto (in practice) bestow project authority on people by hiring them into MoCo (or MoFo), signing a contract, telling them to do a job that advances the project, and holding them accountable. They are accountable because if they stopped doing the job, we would stop paying them and hire someone else. Because of the link between accountability and authority, the fact that they are being held accountable means that they acquire a form of authority. This is sometimes represented by the ability to direct the actions of others within MoCo, but in any case, one can always direct one’s own actions. And other employees, at least, will recognise their role and will support them in carrying out that responsibility.

Historically, Mozilla has said that being hired should make no difference to your position or level of trust within the project. I have been a strong proponent of this view, and we sometimes puts employees to reasonable levels of inconvenience in order to maintain it as a principle. For example, we made a newly-hired release manager wait to join the security-group mailing list, so it did not appear as if he were being given that access as a direct result of being hired, without any community track record.

If Mozilla consisted solely of a community, and people hired out of that community (in order that they could spend additional time working on Mozilla), that system would be entirely suitable. But I now think it starts to break down as soon as you hire people who are not already community members. If those people are hired to direct your engineering, the breakdown is pretty serious. And we have many people hired into roles like that.

Consider: if Mozilla is investing a significant amount of money in an employee (in salary and benefits) then it would make no sense for them not to rapidly become responsible for stuff – to be in some sort of authority, and in turn be held accountable. If this were not true, what would we be paying them for?

At the moment, someone hired by Mozilla from outside the community has authority and accountability within MoCo from day one, but outside MoCo, among volunteers, they have neither. This means that there is tension. How we best resolve that tension is part of the answer to the question initially posed.

At the moment, the tension is too often resolved by that person not seeking to obtain relevant positions of project authority (which may not even exist, because the module ownership system only covers part of Mozilla’s activities), but simply getting on with their assigned task. This results in the marginalization of the Mozilla governance structure as not relevant to many people’s day-to-day activities, and it means the actual working authority structure of the project is undocumented (at least, outside MoCo – the org chart is, unfortunately, confidential) and opaque.

Would it be better to instead accept the logic that we only pay someone when we want them to do something useful, and that therefore sometimes it would be reasonable for someone to acquire some project authority as a direct consequence of being hired by MoCo – which is, after all, the organization we’ve created to hire people to work on the project? Would this, perhaps, actually reduce the divide between volunteers and employees because they would, much more often, both be working within the same, clear, public governance structure?

There are, of course, risks to this approach. Someone might feel that their role has been usurped by a newly-hired person. But I’m not sure these risks are significantly greater than the risk of upset if you hire out of an existing community, and person A gets chosen to become full time over person B, and then ends up, in that additional time, doing some of what person B did.

A possible corollary of the above is the further acceptance that there are some roles which are sufficiently important and time-intensive that Mozilla the organization is not comfortable entrusting them to someone who is not able to give their full time to them. (And that basically, today, means being hired by MoCo or MoFo.) The roles of which this is true will change over time; after all, for the first part of MoFo’s life, there was no MoCo and we had a Chief Lizard Wrangler who had a day job! But I think that, given how big Mozilla is, we have many such roles today. In other words, does it make sense to accept and work with the fact that that some roles within the project will end up being employee-only – not because of a cabal or a glass ceiling, but because of the nature and expectations surrounding the role?

As part of designing a system for running the Mozilla we have in 2013, we need to have a conversation about how we think about employment, and how it relates to authority and accountability, and what consequences that has. This is a start; please contribute.

Identifying The Problem

Tobbi and Ricardo’s blog post, entitled “New Mozilla” or “Community 2.0″? has been generating conversation, and deserves a thoughtful response. This response has no tl;dr – please take the time to consider it in its entirety.

Often when people are upset, it’s hard to step back and work out what the problem actually is. And if the problem is mis-defined or poorly defined, it can be far from obvious, because if you ask them “what’s the problem?”, then they’ll have plenty to say! :-) But sometimes what seems to be the problem is not actually the problem.

It can also be that something one person considers a bug, another person considers a feature. There may be a bit of that going on too. But even realising that is happening is a step forward.

(It can also be that when someone raises a problem, others try and make the discussion about their pet problem. I hope I’m not doing that; let me know if you think I am.)

So, I want to try and figure out what the problem is.

Not The Problem

To begin with, without at all wanting to be dismissive, let me suggest some things which (I submit) are not actually the problem. (I agree not all of these were explicitly or implicitly flagged as problems in Tobbi and Ricardo’s post specifically.) The things in this list might be done badly (which can be a problem), but are not bad in themselves.

  • Having leadership (and it being meritocratic). An organization such as Mozilla needs (and, in fact, can’t exist without having) leadership. Mozilla has long been a meritocracy, and I think that continues to be a good thing to aim for. And having a leadership in a large organization inevitably means that some people make decisions, and a larger set of people provide input, but they can’t take input from everyone.
  • Having a strong UX team. The original post referenced a distant and un-influenceable ‘Apple-esque creative vision’. I hope we don’t behave like Apple, and I don’t want our UX team to be un-influenceable, but there’s no denying that Apple make products which people love, and we should aim to do the same. Many years of hard experience in the project has led us to conclude that this requires an overarching and consistent user experience vision, and that sometimes ‘imposing’ is the price we have to pay to get it. (This is an observation which is specific to UX.)
  • Having products. Mozilla is different from advocacy organizations – we make an impact by doing much more than by talking. Making products that are loved by millions of people not like us is the primary way we further the mission. It allows us to affect events and standards, gives us credibility, and makes people listen to us. Having products and being a community are not incompatible ideas.
  • Having a focus. In order for any organization to do things well, it must only do a limited set of things. We can’t “focus our resources across the board” (relevant historical blog post). That means choosing to push some things, and explicitly choosing not to put resources into others.
  • Encouraging the whole community to work on particular things. If we are an organization united by a vision, and we have a focus, then it seems entirely reasonable to me to enthuse people with that vision, persuade them that the set of activities we are undertaking are the best ones for furthering that vision, and encourage people to work on those things.
  • Changing our focus over time. It’s also OK for our focus to change as circumstances change. The best thing to advance the Manifesto today might not be the best thing tomorrow, either because we find it doesn’t work as well as we thought, or we had a better idea, or it doesn’t gain market acceptance, or the situation has changed.
  • Deprecating products and reallocating resources. That means that it must be OK to deprecate products and reallocate resources away from them to something else that we think will have more impact. Thunderbird is not deprecated in the EOL sense, but there has been a reallocation of resources because, after several tries, we found that it just wasn’t the right vehicle to move the needle in the messaging space.
  • People leaving the project who aren’t interested in that particular execution of the vision. I don’t think it’s a problem in itself if some people who decide that what we have agreed to do isn’t their cup of tea leave and go and do something else. If we see a wholesale exodus, we need to be very confident we haven’t made a serious mistake. But people coming and going will be a natural part of an organization such as Mozilla.
  • Projects which don’t help further the vision spinning off or getting more loosely associated. And, as people come and go, projects do too. Just because a project isn’t furthering the Mozilla vision doesn’t mean it’s useless to everyone, or that it must be abandoned. The great thing about open source is that as long as someone cares about a codebase, it can live on.

Then, there are some things which would be a problem if they were happening, but I don’t think they are:

  • People being forced to work on certain things they don’t want to work on. I don’t know of any non-employee Mozillian who is being forced to work on anything. Heck, I don’t know of any employed ones who are forced, although they may sometimes end up doing dull or tedious things they might not have otherwise chosen. People round here respect a “no, thankyou”.
  • Lack of space or opportunity to incubate ideas for new projects or products. It’s easier than it’s ever been to start a new thing – GitHub makes collaborating on new codebases trivial; you don’t even need to ask Mozilla for some SCM space. And at the more formal end, we have quite recently started Hatchery – which is very much open to non-employees.

The Problem(s)

Now, having got those out of the way, here are some things which I think might actually be a problem:

  • It is easier for an employee to influence Mozilla’s direction than a non-employee of the same experience and impact. In other words, leadership is not as meritocratic as it should be. Advantages of geographical proximity, available time and internal communications channels mean that the playing field here isn’t level.
  • Non-open decision-making; lack of transparency about the reason for decisions. Too often, decisions are not only made in private, but also badly communicated, or the decision is communicated without any rationale. This makes those in leadership positions seem inscrutable and works against community collaboration and cohesion. It’s OK to decide to close Live Chat, but it’s not OK unless everyone involved understands exactly why it was done (even if they don’t agree). [Note: this sentence is a conditional because I don’t know anything about the Live Chat situation. The lack of specific examples is also intentional.]
  • Employees are too focussed on their quarterly goals. There is little room for non-employees to work on their goals, or them to work on non-employees’ goals. Non-employee interaction and community building does not feature sufficiently in people’s goal frameworks and reward structures. And if you aren’t being measured against a particular thing, it’s much easier to let it go when time gets tight. Which it often does.
  • (Some) new employees don’t understand the way Mozilla should work, and see community as a resource to be leveraged when necessary rather than co-workers to be involved. This is a cultural problem. I submit that Mozilla has not done well recently at inculcating our culture into new people, and the culture itself is suffering as a result – a self-reinforcing problem.
  • Mozilla is moving so fast that community members can’t keep up. We did B2G 1.0 very fast, and community-building wasn’t a focus. I hope that’s changing now, but the pace is still high. Long gone are the days where you could pick a small, self-contained feature and spend a few months implementing it – if it is necessary, someone else will have to do it (faster than you can manage), and if it’s not, you’ll need to keep rebasing and you’ll still have trouble finding reviews.
  • Contractual restrictions make non-employees second class. Despite trying, we haven’t managed to obtain the right to talk about certain things with non-employees, or distribute some builds of B2G to them, and other things like that. Working in the mobile space means we have partners who are by default very secretive. And some code owners think open source simply means “a patent lawsuit from my competitors”.
  • We still don’t have a non-public non-employee-only discussion space. In order for us to talk about a wide range of not-on-Slashdot’s-front-page-please subjects, we need such a venue, and the lack of it means that this discussion happens in employee-only spaces. There is talk that the Mozillians Yammer, currently officially aimed only at discussion of the Firefox OS launch, will become this, but we aren’t there yet.

All of the above problems perpetuate a Corporation/volunteer divide, and lead to volunteers feel unappreciated and disenfranchised. And that’s the sense I got from Tobbi and Ricardo’s post. And that, in itself, is a problem. A big one. Let no-one say I am minimising it.

There are a couple more things which I think are or might be a problem, which come from ‘the other side’, as it were.

  • The idea that Mozilla should put organizational resources behind every project a Mozillian wants to do. A consequence of having a focus means that it’s not reasonable for Mozilla’s leadership to command that organizational resources be deployed in support of every idea anyone has. We have to evaluate how well it promotes the mission, and look at the opportunity cost – what do we have to stop doing in order to do this?
  • People not wanting to support an idea unless they were involved in coming up with it. Mozilla is now way past the size where everyone can be consulted on every decision. That’s not to say our decision-making process is anything like perfect, but “I was not consulted” cannot be, by itself, a reason to object to something.

Of course, pointing out that these are also problems does not make the other longer list of problems disappear! And no-one is suggesting it does.

So what do we do? If we are to make progress on addressing these issues, we need to have and execute a plan – they won’t fix themselves. I have some thoughts about that, but perhaps figuring out what the problem is, is the first step, and proposals for solutions can come a little later. So please comment, whether you agree or disagree with my analysis.

Reflections On Trusting…

I’ve just been watching Laura Thomson’s excellent talk “Minimum Viable Bureaucracy” on She talks about “chaordic” management. “Chaords” are a combination of chaos and order, and a chaordic, bottom-up management style is enabled (in part, and to summarize) by trusting people who work for you, and letting them get on with it.

Trust needs to be earned, but Laura said that we need to assume that people have earned trust by passing through the hiring process, and therefore once they are a colleague of yours, you should simply trust them.

I can see the wisdom in that advice in the context of an ordinary company, but it made me think: what sort of trust have they earned in this scenario? It seems rather like they could earn “MoCo trust” that way, but not “whole community trust”. MoCo employees have more visibility into, and are more likely to trust the MoCo hiring process than non-employees. Unless the MoCo hiring process were very open and participatory, which it is not. (Doubtless for good legal reasons.) And if new employees are treated as if they’ve already earned the trust of the peers who surround them in the office, would they be less inclined to see a need to earn “whole community trust” as well? Does it subtly reinforce the employee/non-employee divide, and make it harder to be a core contributor as a non-employee, because inter-employee relationships are assumed-trust, and other relationships are not?