Global Posting Privileges on the Mozilla Discussion Forums

Have you ever tried to post a message to a Mozilla discussion forum, particularly one you haven’t posted to before, and received back a “your message is held in a queue for the moderator” message?

Turns out, if you are subscribed to at least one forum in its mailing list form, you get global posting privileges to all forums via all mechanisms (mail, news or Google Groups). If you aren’t so subscribed, you have to be whitelisted by the moderator on a per-forum basis.

If this sounds good, and you are looking for a nice low-traffic list to use to get this privilege, try mozilla.announce.

FirefoxOS 3 Ideas: Hack The Phone Call

People are brainstorming ideas for FirefoxOS 3, and how it can be more user-centred. Here’s one:

There should be ways for apps to transparently be hooked into the voice call creation and reception process. I want to use the standard dialer and address book that I’m used to (and not have to use replacements written by particular companies or services), and still e.g.:

  • My phone company can write a Firefox OS extension (like TU Go on O2) such that when I’m on Wifi, all calls transparently use that
  • SIP or WebRTC contacts appear in the standard contacts app, but when I press “Call”, it uses the right technology to reach them
  • Incoming calls can come over VoIP, the phone network or any other way and they all look the same when ringing
  • When I dial, I can configure rules such that calls to certain prefixes/countries/numbers transparently use a dial-through operator, or VoIP, or a particular SIM
  • If a person has 3 possible contact methods, it tries them in a defined order, or all simultaneously, or best quality first, or whatever I want

These functions don’t have to be there by default; what I’m arguing for is the necessary hooks so that apps can add them – an app from your carrier, an app from your SIP provider, an app from a dial-through provider, or just a generic app someone writes to define call routing rules. But the key point is, you don’t have to use a new dialer or address book to use these features – they can be UI-less (at least when not explicitly configuring them.)

In other words, I want to give control over the phone call back to the user. At the moment, doing SIP on Android requires a new app. TU Go requires a new app. There’s no way to say “for all international calls, when I’m in the UK, use this dial-through operator”. I don’t have a dual-SIM Android phone, so I’m not sure if it’s possible on Android to say “all calls to this person use SIM X” or “all calls to this network (defined by certain number prefixes) use SIM Y”. But anyway, all these things should be possible on FirefoxOS 3. They may not be popular with carriers, because they will all save the user money. But if we are being user-centric, we should do them.

Unanimity Is Not a Requirement

People sometimes wonder how to best involve all of the affected/important/relevant parts of the Mozilla community in a decision. The prospect of doing this can lead to a certain amount of fear – of criticism, bike-shedding, etc.

At the last All Hands in October 2013, at a session in Brussels, we produced a Best Practices document called “Productive Discussion” to help with exactly this problem. Given Mitchell’s keynote at the recent All Hands, I thought it was worth reflagging its existence.

An Invitation

Ben Smedberg boldly writes:

I’d like to invite my blog readers and Mozilla coworkers to Jesus Christ.

Making a religious invitation to coworkers and friends at Mozilla is difficult. We spend our time and build our deepest relationships in a setting of on email, video, and online chat, where off-topic discussions are typically out of place. I want to share my experience of Christ with those who may be interested, but I don’t want to offend or upset those who aren’t.

This year, however, presents me with a unique opportunity. Most Mozilla employees will be together for a shared planning week. If you will be there, please feel free to find me during our down time and ask me about my experience of Christ.

Amen to all of that. Online collaboration is great, but as Ben says, it’s hard to find opportunities to discuss things which are important outside of a Mozilla context. There are several Christians at Mozilla attending the work week in Portland (roc is another, for example) and any of us would be happy to talk.

I hope everyone has a great week!

Search Bugzilla with Yahoo!

The Bugzilla team is aware that there are currently 5 different methods of searching Bugzilla (as explained in yesterday’s presentation) – Instant Search, Simple Search, Advanced Search, Google Search and QuickSearch. It has been argued that this is too many, and that we should simplify the options available – perhaps building a search which is all three of Instant, Simple and Quick, instead of just one of them. Some Bugzilla developers have sympathy with that view.

I, however, having caught the mood of the times, feel that Mozilla is all about choice, and there is still not enough choice in Bugzilla search. Therefore, I have decided to add a sixth option for those who want it. As of today, December 1st, by installing this GreaseMonkey script, you can now search Bugzilla with Yahoo! Search. (To do this, obviously, you will need a copy of GreaseMonkey.) It looks like this:

In the future, I may create a Bugzilla extension which allows users to fill the fourth tab on the search page with the search engine of their choice, perhaps leveraging the OpenSearch standard. Then, you will be able to search Bugzilla using the search engine which provides the best experience in your locale.

Viva choice!

Bugzilla for Humans, II

In 2010, johnath did a very popular video introducing people to Bugzilla, called “Bugzilla for Humans“. While age has been kind to johnath, it has been less kind to his video, which now contains several screenshots and bits of dialogue which are out of date. And, being a video featuring a single presenter, it is somewhat difficult to “patch” it.

Enter Popcorn Maker, the Mozilla Foundation’s multimedia presentation creation tool. I have written a script for a replacement presentation, voiced it up, and used Popcorn Maker to put it together. It’s branded as being in the “Understanding Mozilla” series, as a sequel to “Understanding Mozilla: Communications” which I made last year.

So, I present “Understanding Mozilla: Bugzilla“, an 8.5 minute introduction to Bugzilla as we use it here in the Mozilla project:

Because it’s a Popcorn presentation, it can be remixed. So if the instructions ever change, or Bugzilla looks different, new screenshots can be patched in or erroneous sections removed. It’s not trivial to seamlessly patch my voiceover unless you get me to do it, but it’s still much more possible than patching a video. (In fact, the current version contains a voice patch.) It can also be localized – the script is available, and someone could translate it into another language, voice it up, and then remix the presentation and adjust the transitions accordingly.

Props go to the Popcorn team for making such a great tool, and the Developer Tools team for Responsive Design View and the Screenshot button, which makes it trivial to reel off a series of screenshots of a website in a particular custom size/shape format without any need for editing.

Rebel Alliance Ideas

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:

  • The internet, in global average, is getting less reliable, slower and more laggy. Finish Janus and persuade our mobile partners to deploy it and default to it. Your Firefox OS phone now accesses the net faster than an Android phone.
  • Make Firefox OS connect by default to openwireless.org access points, and encourage Firefox OS users to run them. There’s a virtuous circle here. More net in more places; a global movement of being generous with net access.
  • Finish Daala faster, by finding people other than the core team to do everything except design the codec and write the algorithms (e.g., testing, speed optimizations, fuzzing, writing Windows Media plugins). We need to get the word out that this project is critical.
  • Show the core free software community, who have great influence over tech choices and who should be our natural allies, that we care about them. Be the first organization ever to make a free-from-bottom-to-top mobile phone (running Firefox OS) and give some help to the Replicant team to port to it as well, just to prove we mean it and it’s real.
  • Make it possible to search for specifically open source software in the Marketplace, and show we believe it “promotes the development of the Internet as a public resource” by promoting apps which are open source.
  • Ship Collusion (which has been in the works for years), even if there’s not a perfect mapping between what it shows you and what’s actually bad. Make sites feel they have to justify all their 3rd party links.

What are your ideas?

Licensing Policy Change: Tests are Now Public Domain

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.

Survey on FLOSS Contribution Policies

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.

Accessing Vidyo Meetings Using Free Software: Help Needed

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?

Spending Our Money Twice

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.

Success Is Not Inevitable

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.

To Serve Users

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.

How We Should Be

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:

  1. Attacks on Mozilla’s inclusivity and diversity will only come from group B;
  2. Anyone who supports exclusionary practices in some other sphere (i.e. those in group B) is likely to want to see them in Mozilla;
  3. The key thing is to keep support for exclusion out of “Mozilla spaces”, so they remain safe for people who would otherwise feel or be excluded.

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.