Is Mozilla Open-By-Rule?

Simon Phipps, who used to be Sun’s open source guy and now works for ForgeRock, recently devised a set of tests and questions to see if a particular open source community was “open by rule” – that is, that it followed open source governance best practices.

I did take issue a bit with what he said about trademarks, but in general I think his approach is valuable. I submitted the necessary data to him about Mozilla, and he has now published his assessment.

On a scale of -10 to +10, Mozilla scores +6, dropping 2 points in the “open” category, and one each in the “trademarks” and “roadmap” categories. I would be very interested to hear people’s comments on the reasons Simon gives as to why Mozilla does not score full marks.

16 thoughts on “Is Mozilla Open-By-Rule?

  1. What you said about trademark, I think counts similar towards the voting for the board of directors. Who would be eligible to vote? Mozilla “members”? Who constitute a member of such an open organization? I don’t know how other open organizations are supposed to handle such things.

  2. Mads: I suspect Simon would say that the fact that Mozilla has not yet worked out which of its participants would be eligible to vote is not a reason to say it’s OK not to have a voting system :-) Some projects do “everyone with commit access”, other projects have other rules. But it’s not an impossible proposition.

  3. Being constantly pessimistic, I would actually rate things lower on a few points – I suspect that’s largely because I’m paying enough attention that I’m seeing all the warts, though :) I’m still here, since I still believe.

    For example, I can’t think of “examples of leadership from outside the ranks of those employed by the Foundation” off the top of my head. I guess the SeaMonkey folks count, if you believe they have much sway over how things go… That and I sometimes assume people _are_ employed by MoCo because that’s usually a good first approximation :p It would be interesting to see the ratio of code between people who have been employed by Netscape / MoCo at some point, and people who haven’t. (And please exclude localizations this time; it’s an important part of Mozilla’s success, but treating it as code is disingenuous.)

    For the roadmap: I’m going to say it’s not actually useful, given that mozilla-central was in some sort of lock down for six months (since the first Firefox 4 beta). Things are looking up, though, even if there are no concrete plans yet.

    That brings up transparency – apparently there’s some sort of thing being circulated internally about tree management plans post-Firefox-4 (going towards the new three-month releases). I do understand not wanting to distract people doing important things to get the release out, but that still leaves no time between the plan being public and it being executed.

    Forkability: it’s really, really hard to push things upstream that isn’t immediately useful in Firefox. Individually, developers are all pretty nice and willing to help; however, organizationally, it’s all blockers, blockers, blockers. Of course, releasing external apps will never block Firefox… It’s been over a decade, and there still hasn’t been anybody external to Netscape/Mo* who have managed to contribute a significant chunk of code and keep it in…

    It’s not all bad, of course. For one, Mozilla’s still a lot more open than, say, Songbird, and to me the license strikes a pretty good balance (though the upgradability scares me a little). The article does bring up the copyright accumulation thing that I’ve never even though about before; I guess that’s only possible because of the MPL, too. Without the flexibility to base commercial products (Netscape 6) off the code, copyright assignment probably would have been a requirement back then.

    I don’t really like the trademark policy, but I think it’s a function of how trademarks work and not the policy itself. Rather, it’s probably the best around under a crappy set of rules it has to abide by. At least, there’s nothing around I like better either.

  4. Mook wrote: For example, I can’t think of “examples of leadership from outside the ranks of those employed by the Foundation” off the top of my head.

    Here are the examples I sent Simon, taken from one section of our Module Owners list:

    Accessibility: Owned for a long time by Aaron Leventhal, who never has worked for Mozilla. (Once he stepped down, we had to hire someone.)

    Graphics: owned by Vlad Vukicevic, who has just announced he is leaving Mozilla. However, his ownership remains with him until he states he is no longer interested in keeping it.

    i18n: Two owners, one now works for Mozilla, one does not.

    Java stuff: Sun guys own most of that

    JavaScript debugger: Owned by timeless, who works for Nokia

    Networking (Necko): Owned by biesi, who works for Google

    Network Security Services (NSS): Pretty much everything is owned by non-employees

    NSPR: Owned by Wan-Teh Chang (Google)

    Tamarin (JavaScript VM): Owned by the guys from Adobe who wrote it

    I could go on. Lots of things are owned by non-employees. But, given that employees contribute around (roughly) 60% of the code, you would expect them to own a lot of stuff.

    Mook wrote: That brings up transparency – apparently there’s some sort of thing being circulated internally about tree management plans post-Firefox-4 (going towards the new three-month releases).

    There has been discussion about this inside MoCo; if it has not yet moved to dev.planning, then I agree it should.

    Forkability: it’s really, really hard to push things upstream that isn’t immediately useful in Firefox.

    But that is not the same thing as forkability. Forkability is the ability to go and do your own thing, not the difficulty of getting changes reincorporated into the core version. There is no criteria relating to the latter.

  5. I agree with Mook on a few points.

    Just going through the example you (Gerv) gave…

    Accessibility *was* owned for a long time by someone outside Mozilla, but it’s not now. You shouldn’t use it as an example.

    Graphics may be owned by Vlad now, but do you really believe he’ll own it at the end of this year? Last I saw, Joe was doing most of the driving in the Graphics module.

    i18n is a fair point on the surface except last I checked, Jungshik hasn’t been at all involved in the module.

    Java isn’t hardly used at all by Mozilla core. Why is it even on this list? Likewise, the JavaScript debugger doesn’t ship with Firefox or with core at all. While we’re on the subject of things on your list that aren’t shipped by Firefox or part of Gecko at all, I’ll throw in Tamarin here.

    Necko, NSS, and NSPR are all good examples. That’s three modules out of how many? (I will mention that in the case of Necko, *all* peers of the module are MoCo employees, however.)

    As far as transparency…

    There are a lot of things that get discussed internally for weeks or even months before ever making it to the outside world and the community at large. The faster releases are one, which have been casually mentioned here and there but are (as I understand it) mostly decided. The details are being decided now… privately. Maybe one day they’ll be public.

    And what about “Join Mozilla”? It was discussed internally as early as December. Why wasn’t the entire process out in the open?

    I can come up with a dozen examples over the last year of highly important programs and plans that weren’t discussed publicly until well after the details had been decided. I consider that a huge problem that’s getting worse, not better, as MoCo grows in size.

    By my count, Mozilla should get a +3 or +4, at most.

  6. Accessibility is actually an interesting example, because: what should we have done when Aaron moved on? It’s an important area – so we hired someone. Was that wrong?

    If Vlad hands over Graphics to Joe, it’ll be because Joe is doing the work, not because Vlad stopped being employed. Which is as it should be.

    I agree that the release schedule discussion should have got out in the open quicker. But Join Mozilla went open really early – so early, in fact, that we hadn’t quite worked out how to explain what we were thinking of doing, and a load of people got the wrong idea. The program has been considerably modified based on feedback received. I think JM is a fairly good example of community development of a thing.

  7. Gerv, I’m not suggesting that Mozilla shouldn’t fill vacant positions or that Joe won’t deserve module ownership because of his work. I’m stating that, for the purposes of “open-by-rule”, there aren’t that many community leaders *now*. It may well be true that Vlad continues on, but that still only leaves four modules out of how many?

    We’re going to have to agree to disagree on Join Mozilla. (When you say it “went open really early”, I hear “it started closed”. I also disagree that it was truly open early on. From an outsider’s point of view, many of the details had been decided and weren’t up for discussion. I particularly enjoyed the branding/UI update in which almost every comment had a problem with the design, but it still launched as-is. Speaking of which, how many people know it already launched? Where are the stats for the public to see?)

    But, like I said, I can provide more examples.

    How about the fact that SpreadFirefox is going to be shutdown, but no one has communicated that to the SpreadFirefox community yet?

  8. Sam: my list was not an exhaustive list – I just went half way down one of the lists of module owners. There are certainly more. As you know, Camino, Bugzilla, Rhino and SeaMonkey are all entirely unowned by Mozilla employees. So the question is just about Firefox and Thunderbird.

    And then we have to ask: what are our expectations? Is open-by-rule about outcomes (e.g. >25% of module owners must be not Mozilla employees) or about opportunities? I don’t deny it’s hard for someone not paid to do it (by someone, not necessarily Mozilla) to own a module in Gecko, Firefox or Thunderbird, because it’s a lot of work. Given that, and given that other companies don’t often pay people to work on Mozilla because they see we have resources of our own, we would probably expect many or even most module owners to be employees. I think it’s healthy that quite a few are not.

    But what is really bad is if people end up running things not because they have greater competence or time or commitment (something Mozilla employees will usually have – that’s why they were hired) but _because_ they got hired. If we hire people and then immediately give competent non-hired leaders the boot and replace them, that would be bad. And I’d certainly look into any examples of that happening that you have.

    We’re going to have to agree to disagree on Join Mozilla. (When you say it “went open really early”, I hear “it started closed”. I also disagree that it was truly open early on. From an outsider’s point of view, many of the details had been decided and weren’t up for discussion.

    What would you have liked to see discussed and possibly changed that was already irretrievably fixed?

    I particularly enjoyed the branding/UI update in which almost every comment had a problem with the design, but it still launched as-is. Speaking of which, how many people know it already launched? Where are the stats for the public to see?)

    My understanding is that there isn’t going to be a big launch.

    Can you give me a URL for that branding/UI discussion you mention?

    More examples would be helpful, suggestions for how we change processes even more so.

    Gerv

  9. The assessment seems more or less fair to me, as far as the listed criteria go. Whether the listed criteria are a particularly good measure of overall project openness is another matter. Mozilla development is significantly more open than that of some very famous and successful open-source projects (notably, Emacs), so I’m not really convinced that being more open would necessarily be a huge improvement.

    I worry more about whether the leadership and developers are thinking clearly and focused on the right things. It seems to me that lately (since sometime around 2.0) Firefox is more interested in following the latest weird and pointless fads than in overall quality and feature-richness. Except for some new CSS features in Gecko (like text-shadow for instance) and the perf improvements in Javascript, almost all of the user-visible changes since 2.0 are either pointless or actively detrimental.

  10. Gerv: I don’t think it’s fair to include those projects. Heck, *you* don’t include anyone working on those projects when you talk about who is or isn’t a Mozillian. Why are you including them here? (I mean, they weren’t invited to the Summit, therefore they must not be Mozillians…)

    I believe (and Simon can correct me) that open-by-rule is both about opportunities and outcomes. That is, it needs to not only be possible to be an outside leader, there needs to be several examples to show that it’s possible. Personally, I don’t see three modules (or four) as a success. Especially not when the majority were owned by outside leaders just five years ago.

    I appreciate you asking questions about Join Mozilla and how I think that process could’ve improved but I think you’re missing the point. I’m using it as an example. As an “outside” Mozillian (my definition; clearly not yours), I saw it as an example of bad communication. Clearly as an “inside” Mozillian, you didn’t. It’s not about what can and can’t be fixed in the future (it’s all just bits and bytes after all), but rather if the process is open throughout. That most definitely wasn’t the case and I think you’d be hard-pressed to find a non-employee who disagreed. (The design discussion was mostly here.)

    I don’t really find it useful to find more examples since you’re clearly just going to refute them instead of looking into what actually went wrong that makes us outsiders think there’s bad communication. (Except SpreadFirefox? No argument there?) But if you decide you’d like to have an open ear, I’ll gladly think through a more-complete list.

  11. First: thanks for responding. :)

    I think we have a slight difference of opinion here – I am bringing things up as a symptom, not as a cause. As noted before, Mozilla is relatively open; I just want to strive for being even better.

    For module owners: how many have never been employed by Mozilla/Netscape? Vlad is just leaving; beisi had, IIRC, interned at Mozilla one point; NSS/NSPR are all guys who were at Netscape.

    I can’t find any information on jshin, so he probably counts. Timeless, Sun guys for Java, and Adobe guys for Tamarin as well. I will however note that venkman was kicked out of m-c and LiveConnect is just dead (the plugin now uses npruntime). Remember that my yardstick is “lives in the central repository” – previously CVS, currently mozilla-central. That includes NSPR/NSS/JS, since they’re in m-c even though they’re not primarily developed there; they do get unit tests run, which means people are responsible for not breaking them.

    Again, I view this all as a symptom – according to the hall of fame, lots of people have (tried to) build on top of Mozilla. Why hasn’t anybody managed to get a significant amount of code in the tree and make it stick, without the drive of a Mozilla product (Netscape back in the day, Firefox now) using it? Why is it always the same group of people doing the internal products? Compare this with, say, the Linux kernel, where lots of different companies hack on it, all for their own gain.

  12. Sam: Thanks for pointing out that the Domesday page isn’t clear; I’ve updated it. The point there was emphatically not “You are only a Mozillian if you are invited to the Summit” but “The web of trust approach for working out summit invitees would be a good way to seed the pool of people marked as Mozillians”. Clearly, as you say, many people who are Mozillians were not invited to the Summit.

    You say Join Mozilla was an example of bad communication. I agree. In fact, in private, I might use stronger words than ‘bad’. But a big chunk of the badness was that because the entire point wasn’t explained up front, and the idea sort of leaked out of the side of one of Mark’s blog posts, a load of community members got upset. Was the problem not enough communication? Or was the problem, in fact, communicating the wrong way and perhaps a bit too early?

    As far as I’m aware, we haven’t shipped anything using the design which Chelsea posted and which was the subject of the discussion you link. I too hope that the feedback will be taken into account, and I too think the branding needs to be closer to core Mozilla.

    I’m asking questions about the SpreadFirefox thing. But you can’t simultaneously assert that I’m obviously going to try and refute every example you put to me, while pointing out one I have not tried to refute!

    Trying to keep Mozilla open is hard work, because natural forces of friendship, cameraderie and convenience among long-term contributors tend to make things creepingly more closed. And the time needed to be a leader in the Mozilla community means it’s a hard thing to do if you have a day job doing something else. This is something I care a lot about, but I don’t have easy answers.

    We could certainly do with people who constructively point out when things aren’t as open as they should be, and suggesting ways to improve.

  13. Gerv: I hate you for being reasonable. :)

    For Join Mozilla, I think the problem was communication started too late, honestly. If a blog post had gone out months ago (when the idea was first germinating) with “hey, I have this idea” and continued from there until January with updates on the idea, thought forming, and progress towards turning the idea into something great, I don’t think there would have been an outcry at all. Certainly I agree that it was poorly communicated *when* it was communicated. But I can’t imagine many community members getting upset over the sprout of an idea. Maybe they wouldn’t’ve liked the outcome (however it may have turned out), but they would’ve at least felt like their opinions had been heard. To me, this is also why the Firefox team doesn’t make (or announce) drastic, sweeping changes a month before shipping. Sure, early on it makes sense so you can gather feedback and adjust accordingly, but not at the last minute.

    The Join Mozilla design hasn’t completely “shipped” yet (missing CeBIT), but it’s in the final stages and is currently being looked at by QA. I’ll note that very little has changed since Chelsea’s post and, given where they are in the process, I doubt anything will change now. What *has* changed is mostly because of limitations in “BSD”, which is apparently something much more fidgety and lame than the operating system (as bugs in Websites::donate.mozilla.org will show).

    You’re right on my assertion. :) You hadn’t yet refuted SpreadFirefox. I was a bit too presumptuous there. I’ll tone it down.

    I’m more than happy to continue constructively (and in some cases, un-constructively, when sarcasm gets the better of me) pointing out when things aren’t open, but should be. However, I’ve always received push-back for doing that, both when I was at MoCo and now (and before I was at MoCo). Based on my experience, I’m not sure there truly are open ears, ready to hear, but I’ll gladly be proven wrong.

  14. If we hire people and then immediately give competent non-hired leaders the boot and replace them, that would be bad. And I’d certainly look into any examples of that happening that you have.

    I’ve got an example.

    And I’ve got a long email trail to back up that this is exactly what happened, too.

    I point it out not because I want you to do some futile post-mortem, Gerv, but rather to say that if that particular example, plus the rest of the anecdotal ones I’ve heard have even small grains of truth to them, then your assumption that “Mozilla [Corporation] acts always in the best interest of the community[0] with respect to module ownership decisions” ignores the reality of the situation.

    As noted before, Mozilla is relatively open;

    I really, really wish Mozilla’s leadership, including its corporate leadership, would stop conflating “open” with “participatory.”

    One is certainly a prerequisite for the other, but I (and others who are relatively unenthralled with recent “community developments”) don’t particularly care about how much information Mozilla is spewing at us if none of it actionable or it’s “read-only.”

    Time and again, there are programs, efforts, and initiatives that are developed and executed internally, and if/when they eventually do become public (and if/when anyone asks “tough” questions about it), the response is always “Oops, our bad! Sorry about that. We should’ve been more ‘open’ [note: not participatory, but ‘open’]; but everyone had the best of intentions, so if you’re That Guy complaining about it, we can dismiss you, because whoever kept it private had the best of intentions.”

    That oft-used explanation is the hallmark of a systemic problem. If you really want to solve it:

    • Stop conflating “open” with “participatory” (and encourage your colleagues to do the same)
    • Be “open” about what aspects Mozilla has no interest in making participatory; if you think that’s an empty list, you need to look at things more closely.
    • Stop using the “Well, shit happened, but we had good intentions, so just let it drop” as an answer to basically every challenging question a community members has.

    [0] Whatever that’s defined to be right now; did you pay your $5?

  15. Preed: I agree that there’s no point in apologizing for something which happened without intention and action to make sure it doesn’t happen again. You talk in generalities; specifics would help me. Not so I can do post-mortems with the people concerned, but so I can document evidence of a problem to show to people I might want to convince that there is one.

    You are also quite right that open != participatory, and the distinction is important.

    Sam: Thanks for the pointer to the staging site. It does look like the design hasn’t changed much :-|

  16. > I’ve got an example.

    > I point it out not because…

    Actually, near as I can tell, you *didn’t* point it out. I read that comment several times and cannot find any such example.

    Just saying.