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.
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.