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.
I wonder if giving new hires more visibility would help somewhat. I.e. by having them post something on a Planet-aggregated feed (but not their own — ideally, prevent the lag stemming from the Planet team taking up to a few weeks before clearing their bug queue) to get them introduced to the community. I think there are single table rows for every new hire in the project meeting notes somewhere, but a more lively/personal introduction (in text form) would be much better.
Getting more transparency is the prime thing I keep coming back to in discussions about the role of community at Mozilla, I guess. There’s a lot of things about the skew towards MoCo that I don’t mind much, but I always hate it when I’m left to second-guess or ask specific questions because there’s some rumor swirling around inside MoCo. As I recently expressed it, as a community member I hate surprises. As much as reasonably possible, I want to be able to reason about things on a level playing field with employees.
I don’t mind so much about things that are specifically under NDA (although it should be possible to share most of those with Reps, for example), but much more general grapevine stuff. As one MoCo employee recently said to me, “you don’t want to see mommy and daddy fighting”, for PR purposes. As an OSS contributor, though, I like to see mommy and daddy fight it out on the mailing list and get a summary from LWN, so I can form my own opinion on things.
And that part is currently thoroughly lacking at Mozilla; the only way you can get some of it by spending a lot of time monitoring IRC channels, I guess.
So one thing that I hope works out is to get some mailing lists or discussion boards (IIRC there’s a Discourse experiment going on?) that should host all of the asynchronous Mozilla-internal discussions, with perhaps slightly diffferent ACLs for non-employees, but general access for vouched contributors. This should include things like the everyone@m.o list, so I can hear first-hand when people move on (instead of just when they also chose to post about it on their blogs) — which can have a significant impact if they were on a project I also contributed on (e.g. I have the experience of the mentor for a mentored bug leaving without me noticing).
To summarize, I think exercising of authority is currently less of a problem than providing the community with a way to find out where authority is being exercised, and in what way.
Maybe start by re-thinking that Org-Chart thing? I don’t think you can say people should have authority, but not have a public indication of how they relate.
What is the org chart useful/interesting for? The people-management hierarchy isn’t all that thrilling most of the time. If I’m communicating with a mozilla contributor, knowing who he reports to and who has to approve his expense reports doesn’t really help me much.
Is it useful for escalation paths, when either we reach an impasse over some decision, or the contributor does something obnoxious/illegal enough that I need to escalate? That seems plausible, so perhaps MoCo needs to expose a way to contact managers and/or HR for such things (“To Whom [Issues About Bob The Misogynistic Jerk] May Concern:”). It’d need to feel low-overhead enough for people to be comfortable using, though, which is a challenge. (I know! We can just make everyone’s permanent employee record be a public editable wiki page! Or not.)
Is it useful for figuring out who else is working in a particular area? “Bob works on this but is too busy; lemme check who else I can ask…” The org chart would seem to be of limited utility here, since knowing somebody is on the JS team doesn’t say much about whether that person knows anything about IonMonkey Inline Caches or whatever.
Is it useful for escalation paths for technical decisions?
Is it useful for figuring out who is making particular decisions? Like, you’re pissed off about some UI change, or you want to figure out why B2G is/isn’t doing X, and you want to get involved in the decision-making process? That seems plausible, though it feels like it ought to be more of a module governance thing than an org chart thing.
I’m not arguing that the org chart should or should not be hidden. I’m guessing there are good arguments on both sides, some of them involving lawyers. But I am honestly curious what people would use the org chart for, and whether there are better mechanisms for satisfying those needs. (I’ve been at Mozilla for about 3 years now. I think I’ve looked at the org chart 2 or 3 times total. Admittedly, that’s partly from laziness — I’ve sent a couple of emails beginning with “I don’t really know if you’re the right person for this, but…”)
Re: Discourse.
There is work going on but it’s first centered around building a proper infrastructure and security audit. The dev instance is at discourse.mozilla-community.org (but will die under load).
Thanks for your efforts in getting public discussion going around this area; haven’t really seen anybody else at MoFo/MoCo focus on it (that get syndicated to PMO), which is… in itself disconcerting.
I had a bunch of stuff written, and then on re-reading it I realized it all boils down to one thing — Mozilla is a one-org show. There’s been outside involvement (RedHat esp. with NSS and things, IBM with BiDi/XForms, various people building on top of Mozilla), but commercially it’s pretty much always been driven by Netscape/MoFo/MoCo. Contrast this with Linux (the kernel), where work is done by enough discrete companies that people don’t really have to worry about things like this.
Of course, I have no idea how we might get there from here. So far, there hasn’t been much noise about the phone hardware people contributing to things (I haven’t been keeping track of those repoistories; for all I know they could have written most of it – but there’s been no information on that, and I can’t recall any blog posts from people working for those companies). Time for me to look for a Chinese variant of PMO, perhaps…
One question to ask from this that I have is do we want to move away from a one-org show as you put it. Or rather… away from the One Mozilla ideals that we shared/expressed the last few years.
An issue I see for Mozilla in terms of goals/mission is that switching out to a more Linux like structure would mean a fragmentation of structure/efforts/community/etc… This I don’t believe to be healthy for Mozilla. Though it definitely works on some level for Linux.
New hire visibility: an interesting idea :-) A text version of what is said in the Weekly Meeting would be a good start. If someone were to volunteer to transcribe just that bit of the meeting and post the new hire info to a blog; it could also be open to self-introductions from volunteers who had experienced Mozilla long enough to say that they were quite likely to stick around.
I agree we need more transparency, but I continue to think that (as you point out) in order to get it, we need an appropriate non-public space. If we had that, you could see mummy and daddy fighting more, although you wouldn’t get summaries on LWN. I have hopes that Discourse will help us here.
I would love to be able to publish the MoCo org chart, but I fear that there will be HR and legal issues associated with that unless we can get opt-ins from everyone.
I don’t think that “One Mozilla” is the same thing as being a one-org show. “One Mozilla” was about not dwelling on the difference between the two entities MoCo and MoFo, and about properly representing our non-profit nature to the public.
I think that we could certainly have greater contributions from non-MoCo companies without running the risk of fragmentation.
But I also think that if the Mozilla community were to be as diverse in interest as the Linux community, we could not have build e.g. Firefox. Mozilla was able to build focussed consumer products because it moved away from the “we are a technology provider; others, like Netscape, make the products” attitude. That works for Linux (where the distros make the products), but it didn’t work so well for us.
Well, Mozilla should be a technology provider in its nature – (probably the option that will help Mozilla exist in 10 – 20 years from now on). It is the only way to have organizations and individuals collaborating around a set of values/shared goals. And it is the only way to grow an ecosystem (an ecosystem is usually a set of semi-autonomous, fragmented entities that despite fragmentation and different interests, find their way to co-habitate).
For example, I would love to see the Governance, in the (near) future having a diversity of participants – peers from various organizations maintaining modules and sub-modules.
MoCo is a commercial arm (good, as an example of building consumer focused products) that unfortunately has too much authority right now – especially in relationship with “the community”.
MoFo is an “open” philanthropy arm (also good, but not global) – focused more on programs than on mission.
But it is unlikely to have One Mozilla (a global movement) without some changes: see the board of directors for both MoCo, MoFo are entirely from the US – lacks of global perspective. The same regarding leadership positions and decision makers.
Second, I see there is a fixation with the employee – “the community” (usually volunteers, treated as cheap resource or buzz resources by some) relationship.
I think lots of people are really missing the point of what community is (rather than a bunch of volunteers requiring more and more authority).
To finish, I think that many of the Mozilla “leaders” (including founders) should start thinking more in terms of Mozilla as an ecosystem (with the risks it implies) rather than Mozilla as a community.
Agreed, it took me an excessively long time just to get access to a current list of employees (name + email only), and then I had to swear up and down that I would not spread it around.
Heh, but I thought Firefox was started *precisely* because there was an interest to start working on things that the leadership at the time wasn’t interested in doing. Yes, consumer focus; but that my point was that somebody needed to go off into a different direction to prove that the existing direction was incorrect.
Besides, claiming that Mozilla needs to have laser focus like that is just strange if you look at the things that’s currently underway. First, there’s Firefox OS; that’s clearly a different focus than the existing browser, but it’s nonetheless (to the best of our guess) a good idea. There’s also the various outreach programs MoFo is doing – WebMaker, Open Badges, the political advocacy around things like SOPA, etc. Those aren’t really all that directly related to the existing products, but they are all clearly attempts to forward the goals stated in the manifesto.
Furthermore, note that I only mentioned not being a one-org show, not that focus should switch away from Firefox. I think things would be a lot better even if it’s other people working on, say, FirefoxOS – something that MoCo is clearly putting resources into heavily *already*.
Can Mozilla keep running as a single entity? Probably, yes; IBM’s been around a while, after all. But I think that means frustrating discussions around the community vs corporate dichotomy will remain, since there’s a persistent imbalance between people who end up contributing as a day job versus those who don’t. (Of course, philor’s the counter example to that…) If there are very public examples of other people who get paid to work on Firefox/etc, it becomes a clear counter-example and erases some of the “advantage” MoCo has. After all, it’s that advantage that has people feeling disturbed.
We can work on Mozilla looking at being a platform after that; while I think that’s also an important thing, it’s not what we’re discussing right now. I can see why you think it might be, though, given my history ;)
“Laser focus” is your words, not mine :-) Another way of putting it might be “we have a lot on our plate already; we can’t guarantee to support an arbitrary number of additional initiatives”.
I hope the rise of Firefox OS will lead to a lot of people around the world being paid to work on our stuff. It might well be easier to do it there than it is for Firefox. We’ll have a different problem – making it possible for volunteers to contribute effectively.
Sorry about that – it was harsher than it should have been. I should stop typing things at midnight :-)
I think the difficulty in getting effective volunteer contributions wouldn’t change much; it matter little for time-strapped people whether they’re competing against MoCo employees or non-MoCo employees, given that they’re all full-time positions. That is, I don’t think having external commercial developers will make the volunteer contribution problems worse. But I wouldn’t trust what I think very much :p
Conclusion from the summit: non-MoCo people *are* working on things, we just never hear about them. At least, people are working on B2G; perhaps I haven’t paid enough attention to that. (I’ve been avoiding it since I don’t wish to wipe my phone to test builds.) I guess I haven’t really seen much B2G action on planet.m.o (other than non-technical advocacy things). Seems like planet.m.o + projects covers most things; both the .cn and .tw blogs look like official PR channels, and not an actual community.