The load time for viewing bugs on bugzilla.mozilla.org has got 2x faster since January. See this tweet for graphical evidence.
If you are looking for a direction in which to send your bouquets, glob is your man.
Chris Beard has been encouraging us to think like the rebels; what can we do that other people won’t do? How can we make an impact?
Here are some of my thoughts:
What are your ideas?
I’ve updated the Mozilla Foundation License Policy to state that:
PD Test Code is Test Code which is Mozilla Code, which does not carry an explicit license header, and which was either committed to the Mozilla repository on or after 10th September 2014, or was committed before that date but all contributors up to that date were Mozilla employees, contractors or interns. PD Test Code is made available under the Creative Commons Public Domain Dedication. Test Code which has not been demonstrated to be PD Test Code should be considered to be under the MPL 2.
So in other words, new tests are now CC0 (public domain) by default, and some or many old tests can be relicensed as well. (We don’t intend to do explicit relicensing of them ourselves, but people have the ability to do so in their copies if they do the necessary research.) This should help us share our tests with external standards bodies.
This was bug 788511.
In the “dull but important” category: my friend Allison Randal is doing a survey on people’s attitudes to contribution policies (committer’s agreements, copyright assignment, DCO etc.) in free/libre/open source software projects. I’m rather interested in what she comes up with. So if you have a few minutes (it should take less than 5 – I just did it) to fill in her survey about what you think about such things, she and I would be most grateful:
http://survey.lohutok.net is the link. You want the “FLOSS Developer Contribution Policy Survey” – I’ve done the other one on Mozilla’s behalf.
Incidentally, this survey is notable as I believe it’s the first online multiple-choice survey I’ve ever taken where I didn’t think “my answer doesn’t fit into your narrow categories” about at least one of the questions. So it’s definitely well-designed.
For a long time now, Mozilla has been a heavy user of the Vidyo video-conferencing system. Like Skype, it’s a “pretty much just works” solution where, sadly, the free software and open standards solutions don’t yet cut it in terms of usability. We hope WebRTC might change this. Anyway, in the mean time, we use it, which means that Mozilla staff have had to use a proprietary client, and those without a Vidyo login of their own have had to use a Flash applet. Ick. (I use a dedicated Android tablet for Vidyo, so I don’t have to install either.)
However, this sad situation may now have changed. In this bug, it seems that SIP and H.263/H.264 gateways have been enabled on our Vidyo setup, which should enable people to call in using standards-compliant free software clients. However, I can’t get video to work properly, using Linphone. Is there anyone out there in the Mozilla world who can read the bug and figure out how to do it?
Mozilla Corporation is considering moving its email and calendaring infrastructure from an in-house solution to an outsourced one, seemingly primarily for cost but also for other reasons such as some long-standing bugs and issues. The in-house solution is corporate-backed open source, the outsourced solution under consideration is closed source. (The identities of the two vendors concerned are well-known, but are not relevant to appreciate the point I am about to make.) MoCo IT estimates the outsourced solution as one third of the price of doing it in-house, for equivalent capabilities and reliability.
I was pondering this, and the concept of value for money. Clearly, it makes sense that we avoid spending multiple hundreds of thousands of dollars that we don’t need to. That prospect makes the switch very attractive. Money we don’t spend on this can be used to further our mission. However, we also need to consider how the money we do spend on this furthers our mission.
Here’s what I mean: I understand that we don’t want to self-host. IT has enough to do. I also understand that it may be that no-one is offering to host an open source solution that meets our feature requirements. And the “Mozilla using proprietary software or web services” ship hasn’t just sailed, it’s made it to New York and is half way back and holding an evening cocktail party on the poop deck. However, when we do buy in proprietary software or services, I assert we should nevertheless aim to give our business to companies which are otherwise aligned with our values. That means whole-hearted support for open protocols and data formats, and for the open web. For example, it would be odd to be buying in services from a company who had refused to, or dragged their feet about, making their web sites work on Firefox for Android or Firefox OS.
If we deploy our money in this way, then we get to “spend it twice” – it gets us the service we are paying for, and it supports companies who will spend it again to bring about (part of) the vision of the world we want to see. So I think that a values alignment between our vendors and us (even if their product is not open source) is something we should consider strongly when outsourcing any service. It may give us better value for money even if it’s a little more expensive.
Last week, the Policy, Legal and Business Development teams had a 2-day get-together, and one thing I came to understand much more clearly is something I think that many Mozillians need to take to heart: success is not inevitable.
For the first few years of Mozilla’s life, we didn’t have much success. Then, a combination of good code, good grassroots marketing, sleeping or absent competitors and favourable market conditions saw Firefox take off and reach a desktop market share north of 25%. That was five years ago, and we’ve been trying to hold on to it since. We haven’t entirely succeeded, but it might be easy to imagine that Firefox on the desktop will be around and relevant forever.
But working really hard, and knowing that what you are doing is the right thing for the world, are not enough by themselves to guarantee that you succeed. There’s no law of the universe which says that Google have to keep giving us a search deal on better (or even the same) terms, particularly if our market share falls. That may happen, or it may not. And there’s no law which says that Firefox OS has to be a success. If what we build isn’t the right thing, carriers will stop stocking and promoting Firefox OS phones, and the world will be left with a choice of Apple, Google or Microsoft.
Mozilla’s way of working has always been to get market share by making great products, and use that to make our voice heard. We aren’t an advocacy-only organization.
Back when we did Firefox, our future, and our ability to get that market share, was in our own hands. If we wrote great software, users could download and install it themselves, and that was it. No-one was stopping consumers from installing any software they wanted. No-one was stopping OEMs from shipping copies of Firefox with their machines. We didn’t have to worry about proprietary hardware. There were no web features which couldn’t be implemented in open source code.
In the new world, our future and our ability to gain market share are not entirely in our own hands. We need partnerships to reach consumers. Business partnerships involve giving someone something they want in return for something you want, and they mean that usually you don’t get everything you want, but have to compromise. The need to partner and the need to compromise are relatively new and difficult things for Mozilla. Such agreements often come with obligations – which, in its most general form, is the loss of the ability to choose exactly what we are going to do because we are constrained by our promises. As an organization, particularly as an engineering organization, we don’t like that.
But operators are only going to carry and promote Firefox OS phones if they think it’s in their best interests to do so. And consumers are only going to buy them if they think they are better for what they want to do than the alternatives. “Why this rather than Android?” is a question to which we need a good answer.
If we want Firefox OS to be a success, we need partners, and we need to provide what those partners want, while holding on to our principles. What they want may well not be “software for us”, or even “software for people we know”. And that means we need to listen to the people within Mozilla who talk to them and report back to us. That’s the Business Development team – who currently have a pretty low community profile. Perhaps that needs to change.
Success is not inevitable – but it is still possible, if we carry on producing software that succeeds in the market. But how we find out what that means has changed, and we as Mozilla need to make sure we adapt to that, and listen in the right places.
My honourable friend Bradley Kuhn thinks Mozilla should serve its users by refusing to give them what they want.
[Clarificatory update: I wrote this post before I’d seen the official FSF position; the below was a musing on the actions of the area of our community to which Bradley ideologically belongs, not an attempt to imply he speaks for the FSF or wrote their opinion. Apologies if that was not clear. And I’m a big fan of (and member of) the FSF; the below criticisms were voiced by private mail at the time.]
One weakness I have seen in the FSF, in things like the PlayOgg and PDFReaders campaigns, is that they think that lecturing someone about what they should want rather than (or before) giving them what they do want is a winning strategy. Both of the websites for those campaigns started with large blocks of text so that the user couldn’t possibly avoid finding out exactly what the FSF position was in detail before actually getting their PDF reader or playback software. (Notably missing from the campaigns, incidentally, were any sense that the usability of the recommended software was at all a relevant factor.)
Bradley’s suggestion is that, instead of letting users watch the movies they want to watch, we should lecture them about how they shouldn’t want it – or should refuse to watch them until Hollywood changes its tune on DRM. I think this would have about as much success as PlayOgg and PDFReaders (link:pdfreaders.org: 821 results).
It’s certainly true that Mozilla has a different stance here. We have influence because we have market share, and so preserving and increasing that market share is an important goal – and one that’s difficult to attain. And we think our stance has worked rather well; over the years, the Mozilla project has been a force for good on the web that other organizations, for whatever reason, have not managed to be. But we aren’t invincible – we don’t win every time. We didn’t win on H.264, although the deal with Cisco to drive the cost of support to $0 everywhere at least allowed us to live to fight another day. And we haven’t, yet, managed to find a way to win on DRM. The question is: is software DRM on the desktop the issue we should die on a hill over? We don’t think so.
Bradley accuses us of selling out on our principles regarding preserving the open web. But making a DRM-free web is not within our power at the moment. Our choice is not between “DRM on the web” and “no DRM on the web”, it’s between “allow users to watch DRMed videos” and “prevent users from watching DRMed videos”. And we think the latter is a long-term losing strategy, not just for the fight on DRM (if Firefox didn’t exist, would our chances of a DRM-free web be greater?), but for all the other things Mozilla is working for. (BTW, Mitchell’s post does not call open source “merely an approach”, it calls it “Mozilla’s fundamental approach”. That’s a pretty big misrepresentation.)
Accusing someone of having no principles because they don’t always get their way when competing in markets where they are massively outweighed is unfair. Bradley would have us slide into irrelevance rather than allow users to continue to watch DRMed movies in Firefox. He’s welcome to recommend that course of action, but we aren’t going to take it.
Four weeks ago, I posted about Who We Are and How We Should Be. I wrote:
As I see it, the principle behind the [Community Participation Guidelines] was, in regard to non-mission things: leave it outside. We agreed to agree on the mission, and agreed to disagree on everything else. And, the hope was, that created a safe space for everyone to collaborate on what we agreed on, and put our combined efforts into keeping the Internet open and free.
Is that CPG principle still the right one? Are the CPGs the best expression of it?
Following on from Who We Are, here is my answer to How We Should Be.
I think the principle is still the right one, but the CPGs could express it better.
The CPGs have many good things about them, and I think that they did a good job of defusing the difficulties in our community at the time they were written in 2012. But they still very much bear the marks of the worldview of the person who wrote them. (This is not surprising or in itself worthy of criticism; it’s very difficult to write in a way which does not show one’s own worldview.)
The world the CPGs conjure up is one where there are two groups of people. There are those who are wholeheartedly for “inclusion and diversity” in every way – let’s call them group A. And those who “identify with activities or organizations that do not support the same inclusion and diversity standards as Mozilla” – let’s call them group B.
The CPGs seem to have the following assumptions:
Therefore people in group B need constraining, such that “support for exclusionary practices in non-Mozilla activities [is] not … expressed in Mozilla spaces”. And so that is what the CPGs say.
However, in the recent series of unfortunate events, the attacks on Mozilla’s inclusivity and diversity came from people who would self-identify with group A (not matching assumption 1) and were directed at someone who, by long example, clearly did not match assumption 2. Support for exclusion (or, at least, for restriction) was expressed by some Mozillians in a very public way, but it was not in a specifically Mozilla space – yet it clearly resulted in exclusion, and in damage to the project and its mission. So assumption 3 didn’t really hold either.
It is true that the CPGs also restrict people in group A, in that they are conditionally asked to “treat [support for exclusionary practices outside Mozilla] as a private matter, not a Mozilla issue”, and that was not done in this case. That is a matter of deep regret. But I don’t think the consequential and conditional statement here gives full and clear force to the strong need for both sides to understand that disagreements of this kind within Mozilla are deeply damaging to our unity and capability as a project.
So, I think we would do well to redefine our alliance as a community. This would involve rewriting the CPGs in a way which expresses the principle of “agree to disagree on non-mission things” more evenhandedly and broadly, and making it clear that it applies to everyone, in all the Mozilla-related communications they make, wherever they are made. I think we must abandon the distinction between Mozilla and non-Mozilla spaces. It clearly wasn’t useful in staving off the damage in this case, and as a definition it always had boundary problems anyway. On today’s internet, it doesn’t matter where you express something – it can be around the world in an instant. And if we move to that model, in order to avoid unfairly restricting people’s speech wherever they may be talking, we would also need to change our attitude to the content of what people say. Instead of “don’t talk about that here”, we should instead affirm the principle of “I disapprove of what you say, but I will defend to the death your right to say it”.
That is not to argue for carte blanche for people to fill up Mozilla communications channels with political advocacy of one sort or another. Most of our channels have a concept of “off-topic”, and that would not change. But only a project dominated by a small group of people from a single consistent political ideology could ever hope to have and maintain a policy of “do not ever even expose me to ideas with which I disagree”. And, as an international project with big growth ambitions, Mozilla is and should not be such.
Respectfully expressing opinions – in any space – should be fine; calling for exclusion from or demotion in Mozilla due to those opinions – in any space – should not be.
Milestone bugzilla.mozilla.org bug 1,000,000 was filed on 2014-04-23 at 01:10 ZST by Archaeopteryx (although rumour has it he used a script, as he also filed the 12 previous bugs in quick succession). The title of the bug was initially “Long word suggestions can move/shift keyboard partially off screen so it overflows” (a Firefox OS Gaia::Keyboard bug, now bug 1000025), but has since been changed to “Celebrate 1000000 bugs, bring your own drinks.”
The winner of the sweepstake to guess the date and time is Gijs Kruitbosch, who guessed 2014-04-25 05:43:21 – which is 2 days, 4 hours, 33 minutes and 5 seconds out. This is a rather wider error, measured in seconds, than the previous sweepstake, but this one had a much longer time horizon – it was instituted 9 months ago. So that’s an error of about 0.95%. The 800,000 bug winner had an error of about 1.55% using the same calculation, so in those terms Gijs’ effort is actually better.
I’m Dutch, recently moved to Britain, and I’ll be celebrating my 10th “mozversary” sometime later this year (for those who are counting, bugs had 6 digits and started with “2” when I got going). Back in 2004, I got started by working on ChatZilla, later the Venkman JS debugger and a bit of Firefox, and last year I started working on Firefox as my day job. Outside of Mozilla, I play the piano every now and then, and try to adjust to living in a nation that puts phone booths in its cycle paths.
My name is Håvard Mork. I’m a Java software developer, working with Firefox and web localization to Norwegian. I’ve been involved with localization since 2003. I think localization is rewarding, because it is a process of understanding the mindset of the users, and their perception of IT.
I’m surprised that my estimate came that close. I spent almost an hour trying to figure out how much bug numbers grow, and estimate the exponential components. Unfortunately I lost the equation, so need to start over for the 2,000,000 sweepstakes…
I’m Mark Banner, also known as Standard8 on irc, I work from home in the UK. I came to Mozilla through volunteering on Thunderbird, and then working at Mozilla Messaging. I still manage Thunderbird releases. Alongside those, I am working on the Loop project (formally Talkilla), which is aiming to provide a real time communications service for Mozilla products, built on top of WebRTC.
Gijs will get a Most Splendid Package, and also a knitted thing from Sheeri as a special bonus prize! The other winners will receive something a little less splendid, but I’m sure it’ll be worth having nevertheless.
Two weeks ago, I posted about Who We Are and How We Should Be. I wrote:
But before we figure out how to be, we need to figure out who we are. What is the mission around which we are uniting? What’s included, and what’s excluded? Does Mozilla have a strict or expansive interpretation of the Mozilla Manifesto?
Here is my answer.
I think Mozilla needs to have a strict/close/tight/limited (whichever word you prefer) interpretation of the Mozilla Manifesto. To quote that document: we need to focus on “the health of the Internet”. We need to work on “making the Internet experience better”. We need to make sure “the Internet … continue[s] to benefit the public good”. As well as the 10 principles, the Manifesto also has a Mozilla Foundation Pledge:
The Mozilla Foundation pledges to support the Mozilla Manifesto in its activities. Specifically, we will:
- build and enable open-source technologies and communities that support the Manifesto’s principles;
- build and deliver great consumer products that support the Manifesto’s principles;
- use the Mozilla assets (intellectual property such as copyrights and trademarks, infrastructure, funds, and reputation) to keep the Internet an open platform;
- promote models for creating economic value for the public benefit; and
- promote the Mozilla Manifesto principles in public discourse and within the Internet industry.
Some Foundation activities—currently the creation, delivery and promotion of consumer products—are conducted primarily through the Mozilla Foundation’s wholly owned subsidiary, the Mozilla Corporation.
I think that’s an awesome summary of what we should be doing, and I think we should view activities outside that scope with healthy suspicion.
It seems to me that this logical fallacy is common:
It can also appear as:
Given the diversity of Mozillians, these cannot be good logic if applied equally and fairly. Mozilla would end up supporting many mutually-contradictory positions.
Some people believe so strongly in their non-open-web cause that they want to use the power of Mozilla to attain victory in that other cause. I can see the temptation – Mozilla is a powerful weapon. But doing that damages Mozilla – both by blurring our focus and message, and by distancing and discouraging Mozillians and potential Mozillians who take a different view. Those who care about Mozilla’s cause and about other causes deeply may find it hard to resist advocating that we give in to the temptation, but I assert that we as an organization should actively avoid promoting, or letting anyone use the Mozilla name to promote, non-open-web causes, because it will be at the expense of Mozilla’s inclusiveness and focus.
We are Mozillians. We need to agree on the Mozilla Manifesto, and agree to disagree on everything else.
Thanks to glob, we’ve got some interesting stats from BMO as it crosses the 1M bug mark.
UNCONFIRMED 23745 NEW 103655 ASSIGNED 8826 REOPENED 3598 RESOLVED 640326 VERIFIED 220235 CLOSED 1628
DUPLICATE 119242 EXPIRED 10677 FIXED 303099 INCOMPLETE 30569 INVALID 58096 MOVED 27 WONTFIX 36179 WORKSFORME 82437
DUPLICATE 64702 EXPIRED 27 FIXED 108935 INCOMPLETE 1746 INVALID 17099 MOVED 150 WONTFIX 6105 WORKSFORME 21471
2014-04-01 519 2014-04-02 531 2014-04-03 620 2014-04-04 373 2014-04-05 133 2014-04-06 132 2014-04-07 544 2014-04-08 622 2014-04-09 597 2014-04-10 571 2014-04-11 467 2014-04-12 156 2014-04-13 170 2014-04-14 573 2014-04-15 580 2014-04-16 574 2014-04-17 619 2014-04-18 356 2014-04-19 168 2014-04-20 118 2014-04-21 445 2014-04-22 635 2014-04-23 787 2014-04-24 562 2014-04-25 498 2014-04-26 173
2013-12-30 1360 (bulk import from another tracker) 2013-12-29 1081 (bulk import from another tracker) 2008-07-22 1037 (automated security scanner filing bugs) 2012-10-01 1013 (Gaia bugs import) 2014-02-11 805 2014-04-23 787 2014-02-04 678 2013-01-09 675 2013-11-19 647 2014-04-22 635
Bugs filed 4351 Comments made 148493 Assigned to 4029 Commented on 56138 QA-Contact 8 Patches submitted 8080 Patches reviewed 14872 Bugs poked 66215
(You can find these stats about yourself by going to your own user profile. If you are logged in, you can search for other users and see their stats.)
email@example.com 349671 firstname.lastname@example.org 16385 email@example.com 15056 firstname.lastname@example.org 13350 email@example.com 11974 firstname.lastname@example.org 10995 email@example.com 4768 firstname.lastname@example.org 4697 email@example.com 4672 firstname.lastname@example.org 4273
email@example.com 8037 firstname.lastname@example.org 6129 email@example.com 5032 firstname.lastname@example.org 4789 email@example.com 4351 firstname.lastname@example.org 4348 email@example.com 4038 firstname.lastname@example.org 3680 email@example.com 3651 firstname.lastname@example.org 3528
email@example.com 347695 firstname.lastname@example.org 148481 email@example.com 65552 firstname.lastname@example.org 58588 email@example.com 50560 firstname.lastname@example.org 48840 email@example.com 48704 firstname.lastname@example.org 47453 email@example.com 43596 firstname.lastname@example.org 42885
email@example.com 8080 firstname.lastname@example.org 4879 email@example.com 4502 firstname.lastname@example.org 4397 email@example.com 4079 firstname.lastname@example.org 3930 email@example.com 3890 firstname.lastname@example.org 3739 email@example.com 3659 firstname.lastname@example.org 3530 email@example.com 3411
firstname.lastname@example.org 15581 email@example.com 14869 firstname.lastname@example.org 9424 email@example.com 8352 firstname.lastname@example.org 8103 email@example.com 7272 firstname.lastname@example.org 6198 email@example.com 5983 firstname.lastname@example.org 5499 email@example.com 5346 firstname.lastname@example.org 5126
“Every kingdom divided against itself will be ruined, and every city or household divided against itself will not stand.” — Jesus
It has been said that “Mozilla has a long history of gathering people with a wide diversity of political, social, and religious beliefs to work with Mozilla.” This is very true (although perhaps not all beliefs are represented in the proportions they are in the wider world). And so, like any collection of people who agree on some things and disagree on others, we have historically needed to figure out how that works in practice, and how we can avoid being a “kingdom divided”.
Our most recent attempt to write this down was the Community Participation Guidelines. As I see it, the principle behind the CPGs was, in regard to non-mission things: leave it outside. We agreed to agree on the mission, and agreed to disagree on everything else. And, the hope was, that created a safe space for everyone to collaborate on what we agreed on, and put our combined efforts into keeping the Internet open and free.
That principle has taken a few knocks recently, and from more than one direction.
I suggest that, to move forward, we need to again figure out, as Debbie Cohen describes it, “how we are going to be, together”. In TRIBE terms, we need a Designed Alliance. And we need to understand its consequences, commit to it as a united community, and back it up forcefully when challenged. Is that CPG principle still the right one? Are the CPGs the best expression of it?
But before we figure out how to be, we need to figure out who we are. What is the mission around which we are uniting? What’s included, and what’s excluded? Does Mozilla have a strict or expansive interpretation of the Mozilla Manifesto? I have read many articles over the past few weeks which simply assume the answer to this question – and go on to draw quite far-reaching conclusions. But the assumptions made in various quarters have been significantly different, and therefore so have the conclusions.
Now everyone has had a chance to take a breath after recent events, and with an interim MoCo CEO in place and Mozilla moving forward, I think it’s time to start this conversation. I hope to post more over the next few days about who I think we are and how I think we should be, and I encourage others to do the same.
As part of our discussions on responding to the EU Copyright Consultation, Benjamin Smedberg made an interesting proposal about how copyright should apply to software. With Chris Riley’s help, I expanded that proposal into the text below. Mozilla’s final submission, after review by various parties, argued for a reduced term of copyright for software of 5-10 years, but did not include this full proposal. So I publish it here for comment.
I think the innovation, which came from Benjamin, is the idea that the spirit of copyright law means that proprietary software should not be eligible for copyright protections unless the source code is made freely available to the public by the time the copyright term expires.
We believe copyright terms should be much shorter for software, and that there should be a public benefit tradeoff for receiving legal protection, comparable to other areas of IP.
We start with the premise that the purpose of copyright is to promote new creation by giving to their authors an exclusive right, but that this right is necessary time-limited because the public as a whole benefits from the public domain and the free sharing and reproduction of works. Given this premise, copyright policy has failed in the domain of software. All software has a much, much shorter life than the standard copyright term; by the end of the period, there is no longer any public benefit to be gained from the software entering the public domain, unlike virtually all other categories of copyrighted works. There is already more obsolete software out there than anyone can enumerate, and software as a concept is barely even 50 years old, so none is in the public domain. Any which did fall into the public domain after 50 or 70 years would be useful to no-one, as it would have been written for systems long obsolete.
We suggest two ideas to help the spirit of copyright be more effectively realized in the software domain.
Proprietary software (that is, software for which the source code is not immediately available for reuse anyway) should not be eligible for copyright protections unless the source code is made freely available to the public by the time the copyright term expires. Unlike a book, which can be read and copied by anyone at any stage before or after its copyright expires, software is often distributed as binary code which is intelligible to computers but very hard for humans to understand. Therefore, in order for software to properly fall into the public domain at the end of the copyright term, the source code (the human-readable form) needs to be made available at that time – otherwise, the spirit of copyright law is not achieved, because the public cannot truly benefit from the copyrighted material. An escrow system would be ideal to implement this.
This is also similar to the tradeoff between patent law and trade secret protection; you receive a legal protection for your activity in exchange for making it available to be used effectively by the broader public at the end of that period. Failing to take that tradeoff risks the possibility that someone will reverse engineer your methods, at which point they are unprotected.
Separately, the term of software copyright protection should be made much shorter (through international processes as relevant), and fixed for software products. We suggest that 14 years is the most appropriate length. This would mean that, for example, Windows XP would enter the public domain in August 2015, which is a year after Microsoft ceases to support it (and so presumably no longer considers it commercially viable). Members of the public who wish to continue to run Windows XP therefore have an interest in the source code being available so technically-capable companies can support them.