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.

41 thoughts on “Identifying The Problem

  1. I would also give some consideration to 2 additional points, which may hurt mozilla community in the longer run:

    – while still a small portion of things, while there’s no shareholders, commercial partners are often calling the shots and even deciding on the company direction, specially due to firefox os.

    – not being able to talk to everyone is different from secret projects. mozilla now has quite a few secret projects (ie there is no way you’ll know about it without a leak or the release day) due to the previous point. the community has zero chance to give input, unless they’re commercial partners. That’ a large disconnect from the “development in the open” and I think it has absolutely nothing to do with the organization size.

    • Do you have examples of where you think the commercial partners have been “calling the shots and deciding on the company direction”?

      Clearly, for Mozilla to be successful in the mobile market, we have to provide something that our partners want. The difficulties arise when they want things which we would prefer not to give them. How well we can do in that situation depends on our market power and leverage, which will start small but (we hope) grow over time.

      I certainly agree that projects should not be secret without a good reason (e.g. some confidentiality requirement from either a partner or because revealing what we are doing would make it harder to get the outcome we want in a negotiation).

  2. Are there today people in leadership position in Mozilla that are not employees or full time equivalents? I can only think of localizers that have some leadership on decision making for the products for their locale, are there others?

    • Good question. The ones I can find from the Module Owners list are the leaders of NSS (employed by Google and Red Hat), plus the leaders of SeaMonkey, Calendar, and Rhino. Peterv co-owns DOM and owns some other things. Jungshik co-owns i18n. Some people from Telefonica have started to own or co-own modules in Gaia.

      Of course, the coverage of the Module Owners List is not comprehensive – that’s one of the problems.

      It’s not nearly as much as one would hope.

      • peterv is a long-time Mozilla employee and Jungshik hasn’t been involved in Mozilla for many years, his G+ page says that he was a past Mozilla contributor and now works for Google. Even in this very short list of still active contributors, people are usually paid to work on Mozilla by other companies for business reasons or they work on projects Mozilla is not interested in (seamonkey, rhino, calendar). That raises the question of *volunteers* getting significant responsabilities in projects that really matter for Mozilla or being limited to subordinate roles and minor tasks on such projects.

        • Please don’t understand me as saying that I think the current situation is as it should be! You asked if there were any, and I listed those I know of.

  3. I was an active Mozilla contributor for a few years and then eventually stopped due to two of the problems you identify, Gerv: “Non-open decision-making” and “Employees are too focused on their quarterly goals.”

    These two problems interact badly. As a non-employee contributor you’d hear “OK! Our focus is x! Let’s make changes to accomplish x!” and you’d think “OK, I can work on x. Cool.” Then you’d starting working on x and suddenly “The goal is y! Let’s make changes to accomplish y!” And you’d think “OK, I guess I can work on y instead. What about x though? Are we leaving that unfinished?” Then it would be time for z…

    FWIW, I thought the Live Chat system that the original group lovingly refers to was terrible at actually helping people with support issues but was good at keeping the contributors entertained.

  4. Gerv, I tend to disagree with a few of the things you said:

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

    Yes Mozilla is an organization united by a vision, however, as you pointed out in your next statement, focus changes over time:

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

    As I wrote in my blog post, we need to distinguish between the Manifesto and the way Mozilla is enforcing that manifesto. The way Mozilla is enforcing the manifesto is *one way of possibly very many*.
    Even though Mozilla created that manifesto doesn’t mean that they have the right to say “People, this is the (best|only) way to go about it” (treading the thin line between organizational focus and individual people’s minds/interests etc.).
    There’s no way to tell that the current path of the Organization is the right way. Not at the moment, not in the future. The problem in itself is that Mozilla has done it this way. Therefore not only jeopardizing the manifesto itself (“We welcome a broad range of activities, and anticipate the same creativity that Mozilla participants have shown in other areas of the project.”) but also jeopardizing the contributors of this project and their own vision (that perfectly enforces the goals of the manifesto) and the creativity that may come with it.

    • As I wrote in my blog post, we need to distinguish between the Manifesto and the way Mozilla is enforcing that manifesto. The way Mozilla is enforcing the manifesto is *one way of possibly very many*.

      I agree pretty much with that (I’d say “further” or “promote” rather than “enforce”, but that may just be a 2nd language thing), although I’d say we are doing several ways of many, rather than just one. Firefox is one way, Firefox OS another, Persona yet another. But yes, there are loads of things that could be done which we aren’t doing.

      Even though Mozilla created that manifesto doesn’t mean that they have the right to say “People, this is the (best|only) way to go about it” (treading the thin line between organizational focus and individual people’s minds/interests etc.).

      I agree with that too… but I do think the Mozilla leadership has the right to say “we are going to focus Mozilla-the-organization’s efforts on this limited number of ways”. That doesn’t stop people doing manifesto-supporting things on their own, with other organizations or in other contexts. In fact, the Manifesto page specifically invites people to do that, while recognising that Mozilla will only do a limited set of things to advance the Manifesto.

      I think what you are actually arguing with is my point at the bottom, i.e. when I say that “the idea that Mozilla should put organizational resources behind every project a Mozillian wants to do” is wrong. I think you think that if a Mozillian wants to do something which furthers the manifesto, then Mozilla should support them. I think that doing that would inevitably lead to a loss of focus and effectiveness.

      I don’t see Mozilla-the-organization as having spare resources and capacity – in fact, we are really overstretched. So adding new things will mean doing the current things less well, or with fewer resources.

      • “I think what you are actually arguing with is my point at the bottom, i.e. when I say that “the idea that Mozilla should put organizational resources behind every project a Mozillian wants to do” is wrong. I think you think that if a Mozillian wants to do something which furthers the manifesto, then Mozilla should support them. I think that doing that would inevitably lead to a loss of focus and effectiveness.”

        “I don’t see Mozilla-the-organization as having spare resources and capacity – in fact, we are really overstretched. So adding new things will mean doing the current things less well, or with fewer resources.”

        I wouldn’t go as far and say Mozilla should “support” side projects. I believe, people who really have a creative vision beyond what Mozilla is currently promoting have that vision as their support. Also, it’s their responsibility to make it easily integrable into the whole picture (it’s their project after all).

        However, engaging people to do a certain thing actually counteracts that initiative to let people be creative. Creative people (and I’d count myself as someone who likes to be creative) cannot stand being “encouraged” to do things and “leadership” is something which goes against their creative vision.

        So, what we need to find out is: “How much encouraging can this community stand?”. It’s really as easy as “not doing something too much” in my opinion. Mozilla managed to engage the whole community, now it’s time to only engage those who are actually willing to be engaged. No big deal!

        • I think you are mistaken to oppose leadership and creativity. The opposity of leadership is anarchy – everyone just does what he or she wants to do.

          I don’t see how Mozilla having leadership stifles anyone’s creativity, unless by “creativity” they mean “I want Mozilla to back my ideas”. If they don’t need Mozilla resources backing them, and it’s no problem if Mozilla doesn’t provide them, then how can Mozilla possibly prevent them doing whatever creative thing they want to do?

          • It’s not leadership in itself that stifles creativity. It’s a rather narrow set of projects that are being advanced (which they are).

            Creative people like me can only act creatively when they feel like they do not have boundaries. However, due to pushing a small set of projects, Mozilla is creating virtual boundaries that, although they shouldn’t exist, do exist because of the nature of preferring some projects over others.

            As I said, having a preference is fine with me. Carrying that preference into community is the wrong choice.

            • You say “Creative people like me can only act creatively when they feel like they do not have boundaries.”

              What boundaries do you feel you’re running into?

                • I think I’m looking for more specific examples. Whatever boundaries I ran into were self-imposed, mostly because I lacked the time.

                  I’m certainly not feeling constrained right now while I push forward (slowly) on Community IT Ops which I do believe, at the end of the day, will help further the Mission & support the Manifesto.

            • I don’t think the set of projects Mozilla is working on is ‘narrow’!

              If you say these boundaries are created by focus, and ‘shouldn’t exist’, then you are basically saying that it’s wrong for Mozilla-the-organization to have a focus. I disagree. Lack of focus is the quickest route to irrelevancy.

              I still think that, in your mind, you have a strong separation between “MoCo” and “community” which should not be there. It’s not the case that Mozilla consists of MoCo, working on a defined set of projects, and everyone else, working on whatever takes their fancy. We are one community. Individual volunteers can, of course, use their time to do whatever takes their fancy, but they shouldn’t expect to be able to necessarily do it under the Mozilla banner.

              • Gerv,

                It’s not wrong for the Organization to have focus. It’s wrong to carry this focus into the volunteer space (as I outlined before). Because by preaching volunteers what the focus is (on events etc.) you’re creating the misunderstanding that this is the only thing volunteers “should” work on (or the preferred way). Going easy with volunteers would be the best option (as I also said before).

                And what’s “narrow” is defined by each individual. As I said: The Manifesto defines an indefinite number of projects. Engaging volunteers to take part in only some of the focus areas is “narrow”.

                As “MoCo” works on focus areas, and creative people who have a vision beyond that of the corporation care about their own projects, I feel it’s necessary to have that distinction between MoCo and volunteers. Otherwise we’d all be agreeing to help push the current set of projects which is, let me repeat myself, “too narrow of a choice”.

                Also, I assumed that everything that aligns with the Manifesto and was created with mozilla’s core values in mind can be set under the Mozilla banner. If that’s not the case anymore, you’re casting out a number of projects that are not focus areas (anymore?), like any community-governed projects.

                And if that’s the case, I’d find that very disappointing, as would many of my fellow volunteers!

                • Also, I assumed that everything that aligns with the Manifesto and was created with mozilla’s core values in mind can be set under the Mozilla banner.

                  I don’t think that’s true of everything. However, it is a reasonable question to ask: how do we decide what new things are done under the Mozilla banner, and what are done elsewhere? Is it a factor of how much we trust the people who want to do the thing; is it a factor of what the thing is; is it a factor of the resources required; or some combination?

                  That is a good question, and one I hope we can work towards an answer for.

                  • Gerv,

                    thinking about this deeper, I believe part of the problem is the fast pace the transition was being done. Community moves slowly. It’s hard to engage community for new projects, at least people like me are VERY skeptical when it comes to this.

                    It’s something to keep in mind, perhaps. People are not really willing to give up their area of contribution so easily and something like *bam* Thunderbird abandoned, *bam* focus on new technologies, *bam* different layers of community is something that needs to be grasped by the community as a whole and that needs time.

                    In an ideal world where community matters, a plan would’ve been found to help community members make the transition easier.

                    • Thunderbird has not been abandoned. In fact, it’s moved to more like the model you want, which involves slower development that’s easier to get involved in.

                      What specific things do you suggest could have been done to “make the transition easier”?

  5. Some random thoughts:

    MoCo managers should make sure, if employees don’t do it themselves, that
    goals related work doesn’t take too much time. I’d say anything over 50% of the work time is way too much. We have enough work-that-just-needs-to-be-done which isn’t in the goals. And when working on your goals, don’t do it behind the closed doors.

    Also, (at least engineering) managers themselves should spend some non-insignificant time to do coding or reviewing and such. Be active on IRC,
    newsgroups, standardization etc. That would keep them more active in the community and not focus only on MoCo-only things.

    Employees should be discouraged to use Yammer (not that I know what all is discussed there. I’ve explicitly decided to not use it because it is not open to the community).

    I think one problem is also that communication happens in so many different places. Even if decisions are made in public, it is possibly hard to know where, which newsgroup, IRC channel, mailing list…

    • I agree with 2 and 4, and perhaps 3 if we get the alternate mechanism I mention in my post. But 1 seems unrealistic to me. Why have a planning and goals process if it doesn’t cover 50% of what you do? Surely it makes more sense to make the planning and goals process reflect what is actually important?

      • “Surely it makes more sense to make the planning and goals process reflect what is actually important?”

        It depends at what level the goals are set. I think the assumption is that the goals of MoCo’s engineering/product managers don’t include community-building things. Is it realistic to think that they should?

        The suggested alternative is to leave some resource “spare” for delivering wider goals outside of that management structure, rather than trying to deliver the wider goals within it. Doesn’t seem unreasonable to me – with MoCo becoming larger and more hierarchical, it isn’t necessarily a good structure for managing the wider community.

        • How would you decide how much resource to leave spare? A flat amount per person may not work very well. And if you do it on a per-person basis, then it’s effectively in the plan, whether you call it that or not.

          In the end, I don’t mind too much how we make this stuff more important. I suspect that getting it included in the goals process is the easiest way, but I’m wrong, that’s fine.

  6. Some good points Gerv.

    I don’t see the things you mentioned as “problems” though, but rather as a natural evolution of a vertical structure mixed with some decisions made in the past (and I don’t say it as negative, there are plenty of good results because of this).

    Pascal, the idea of “volunteer leadership position” is absolutely obsolete (and I heard it various times from Mozillians).

    Having leadership in a project means making decisions. To make decisions means you have to spend time on talking to people, solving problems, writing code (sometimes), organizing, assuming responsibility for success or failure. This requires time and skills. And in a healthy community/organization/society, spending time on something means you get paid for it (or you get a concrete benefit).
    Otherwise, the result is mediocrity with eventually people wanting more and more power instead of knowledge and personal development.

    • @Alina
      Of course I disagree with you. There are just too many examples of successes in the Mozilla projects made by volunteers (private mode in Firefox, most of our addons, the 80+ locales we support for out products, all of our early marketing and QA programmes…). It doesn’t mean that these people shouldn’t be hired, but discriminating community members on their employment status is in my opinion a problem, not a solution.

    • I think it’s harder for volunteers to be in leadership positions, for some of the reasons you state. But I don’t think it’s impossible, and I don’t think the idea is obsolete at all. In fact, I think it’s vital if Mozilla is to continue to grow and develop as an organization.

      How could we get to a place where we have X employees and 20*X committed volunteers without giving those volunteers significant autonomy and decision-making power? If we get to a place where all significant decisions must be made by employees, then that will put a significant limit on our growth.

      • I think in an ideal world, employees are all managers of some kind, the leaders Alina pointed out. I think if we really picked apart the responsibilities and the time we would need for leaders to put in, then it starts to become incompatible with the amount of time we should be expecting from a volunteer. We shouldn’t expect volunteers to put in full-time hours after they have a full-time job already. Yes, there are people who do it, but I think we lose diversity by relying on contributions from just the people who are willing to spend the rest of their waking hours on a computer.

        We also need to try and slow the pace down. There is a lot of pressure to deliver, but we have to give people time to think, to be creative, to build relationships, build momentum. Anecdotally, I think it takes at least a year to launch something worth doing. Reps are hitting their stride now, but the program was conceived in 2010. We were very lucky in not being driven early on by targets, we were able to explore, and build a sound foundation to the program.

        And on the flip side of that, I think a slower pace also allows better chances to capitalize on the serendipitous. We’ll never anticipate every opportunity, but sometimes one comes along and it wasn’t on any road map or goals, some volunteer just comes up with some awesome idea in response to a current event. We need to be able to capitalize on those moments without having to disrupt the long term work.

        I think we also should take some time to explore the differences between employees and volunteers. There are differences and there should be differences, and I think by ignoring that we end up in bad situations, like where one person is being paid to do a job identical to what someone else is volunteering to do. Or a role that someone would have been happy to volunteer for is contracted out.

        • I think we also should take some time to explore the differences between employees and volunteers.

          On reflection, I think you are right about that. I think we need to have a conversation about how Mozilla allocates responsibility, and what part being employed does or should play in that. My historical answer has been “employment shouldn’t make a difference”, which if you are only hiring out of your community might be true, but we don’t just do that. Perhaps that answer is no longer adequate.

  7. You mentions FirefoxOS as a place where decisions needs to be made in secret due to NDA with manufacturers. But often time decisions, that could have been made in the open, are made without proper community input.
    Personally I was very disappointed with how tab groups became a build-in functionality of Firefox. There were (and still are) plenty of advance tab-management extensions for Firefox when development of Firefox Panorama began, yet it got included in nightlies ahead of mature alternatives before it had even reached 1.0
    The Firefox community has build literally 100’s of products to solve the issue that Tab Groups tries to solve, yet the community was not even consulted while an employee gets to build a solution from the ground up.

    • Just because I say that some decisions have to be made in secret, doesn’t mean I am arguing that all decisions which were made in secret should have been made in secret.

  8. Regarding goals –

    I’m reminded of a post Lukkas had a year and a half ago or so ~ http://crashopensource.blogspot.com/2012/01/growing-company-structuring.html ~ in particular her second to last paragraph,

    “Until we require Directors to create annual and quarterly goals that include measurable goals around volunteer growth, retention, participation, and effectiveness we will only see people (like myself) trying to do this ‘off the corner of their desks’ which means it’s not a part of your paid work and thus less likely to be sustainable and effective.”

    Curious what sort of reactions people have to this.

  9. “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?”

    I was thinking about it tonight and I can’t think of a significant project created by non-employees in the last years (let’s say 5 years), that has Mozilla resources behind, do you have examples? The only thing I can actually think of is Mozilla paying the server bills and occasional meetups for a few communities, which is great, but shouldn’t we see more stuff backed up by Mozilla? Other projects I am missing? Aren’t we actually suffering frim the NIH syndrom?

    • I was thinking about it tonight and I can’t think of a significant project created by non-employees in the last years (let’s say 5 years), that has Mozilla resources behind, do you have examples?

      I am not familiar with the genesis of a lot of Mozilla project, but possible candidates for that list include: DXR, Rust, popcorn.js and MCS. The chat code was created by non-employees and then bound into Thunderbird.

      I agree it’s not a long list. But we would need to have a discussion to decide whether we should expect it to be long, given my points about the leaders being people who work for MoCo (and therefore any idea they have not being on the list) and about having a focus.

  10. Mozilla is hardly meritocratic anymore when we talk about non-paid people and influence on decisions. That has already been pointed out by Pascal, and with the fast pace, sprint and goal driven approach contributors will very unlikely become module owners. This development isn’t new, but with Mozilla’s focus broadening to e.g. services and products a contributor can’t simply download and use (like not being able to install Firefox OS on his or her phone), the incentive to contribute, see, use and benefit from it personally has diminished. This can be measured by numbers of e.g. add-on developers, l10n contributors, support people. You can also see this as part of Mozilla’s success, especially as maturity of the desktop products. But then less people would be frustrated. The feeling has been expressed by several people to me in the last months, and isn’t restricted to my locale community. A member of different one said that “Mozilla doesn’t care about us [the community]” without objection from other people.

    In this case, I am talking about people already involved for some time, but which still lack an efficient way to stay up to date on the short to long term roadmap, defined by products (the Mission Statement and Manifesto are too ambigous for that). https://wiki.mozilla.org/Firefox/Roadmap gets few updates and https://wiki.mozilla.org/Features/Release_Tracking doesn’t get updated anymore. More insights (especially on desktop where less restrictions due to partners exist) would be helpful.

    The stream of information in the other direction could also be improved and both the contributors and the corporation can benefit – it’s not the aim of us contributors to suffocate Mozilla’s fledgling new ideas. In the post, you say “a larger set of people provide input, but they can’t take input from everyone”. If the contributors would know any contributor who was involved by being given the opportunity to provide input and influence the decision, that would likely quieten many of these claims.

    Well informed community members will also have opinions, e.g. if the want to contribute to product X or not. It’s okay to ask them if they want to join the project, but a No should be accept straight. Repetition leads due frustration (also depending on cultural background), especially if the demands of the person you try to convince in your product vision are ignored.

    Issues of contributors:
    – The number of contributors hasn’t scaled with Mozilla, sometimes even going down in absolute numbers. This is a problem on community-only tasks with deadline: Some people “fix” these because they have to be done, not because they want to do that. Exposing contributing more prominently on all Mozilla sites and even more important, education how to do things (yes, C++ coding somewhere at the end of that list), better services and documentation (saw yesterday someone who succeed in checking out the source code from mozilla-central on fourth try; we should advise people to download the bundle by default). In the last 5 months, more than 600 mails have been sent through the form for German speaking people who want to become contributors (already issues and suggestions excluded), they get auto-responders and a subgroup also manually written mails. I have no idea how many of these tried to do something or have contributed for a longer time. I also feel uneasy if a Windows user interested in localizing Firefox for desktop has to download more than one gigabyte if the localization should also be tested before checkin.
    – Getting ignored by employees: This can happen for a variety of reasons, from not understanding what the contributor wants, to opposing it, to that idea/task having very low priority and/or much to do. Replying with the truth seems the best, ignoring can make people think the other person doesn’t like one personally.
    – Working with employee 1 on something, employee 2 gets involved in the final stage and makes changes to the contribution without explaining and consulting the contributor.
    – NDAs: Mozilla needs something done by a contributor, but can’t tell a deadline.
    – Finding the right project to contribute to or stay up to date with launched projects. Who knows all the services and tools being worked on?

    (Likely) Issues of employees:
    – Outside of checkin permissions, there is no fast, lightweight possibility for them to check the credibility and expertise of a contributor if both persons don’t know each other for some time. Maybe a tag/badge like approach with vouching which would also be exposed in common places (e.g. Bugzilla) could help (extended user information popup), e.g. if someone reports a bug with language X and is a native speaker of that language and trusted contributor, trust the input she or he provides; if the person has already done remote debugging, the employee can easily ask for information which require that, else provide a link; same thing applies to tests.
    – The amount of time available to deal with contributors is too scarce or it doesn’t feel worth the time (patches which get never ready to land, vanishing contributors). This dependends on product and component, e.g. Firefox Mobile, addons.mozilla.org when it was still about that site and mostly Firefox are nearly perfect when triaging bugs by filed contributors. Gaia 1.1 was different, some obviously blockers (e.g. for localization) got no attention until late in the game.
    – You already mentioned the quarterly goals, but often without knowing them, it’s often unknown if the employee/team lost interest or only lowered the priority.
    – If they had been a contributor before getting hired, some contributors don’t understand that they want to non-Mozilla things after work.

    • “- Getting ignored by employees” <- this.
      Person writes a patch, set request review flag, but reviewer(s) constantly ignores request (example – Bug 301988). Users reports about problem, provide all necessary steps and data to reproduce, developer said "I was able to reproduce problem" and disappears (example – Bug 594407)

  11. Gerv,

    I am not sure what would’ve made the transition easier. But blueskying that every contributor of Mozilla makes the transition without problems is mental and something that I would’ve not expected from such a huge corporation, such as Mozilla.

    Given that contributors like me have spent their free time working for the project I find it very disrespectful regarding community that Mozilla hasn’t spend at least one minute to think about what such a huge transition would do to the contributor base and now even disregards that there’re problems in that aspect (at least a very big part of it).

    –Tobbi

    • To which transition are you referring? The one where we decided to do Firefox OS?

      I think your hyperbole is not helping your argument. Do you really think no-one at Mozilla pays any attention at all to the effect that particular changes have on the community?

  12. Gerv,

    there’s much more going on than Firefox OS. But I’m talking about changing focus in general.

    I am sorry, but I currently don’t see any progress towards letting community members keep their independence from the project, we’re rather moving into a “People who have signed NDAs (and are therefore linked closer to the corporation) get the better opportunities and better support” way of dealing with community. This scatters community apart (only one of the issues).

    Now, Mozilla certainly had a better way to deal with those things (or to try to minimize the other issues that I mentioned in my blog post that make me feel very unhappy with Mozilla right now). I am not the only one who feels this way, I am only that one person that speaks up about those. Contributing to Mozilla is just not fun anymore when you feel you are encouraged to do a certain thing.