Is Firefox Unforkable?

The indispensable ingredient that binds developers together on a free software project, and makes them willing to compromise when necessary, is the code’s forkability: the ability of anyone to take a copy of the source code and use it to start a competing project, known as a fork. The paradoxical thing is that the possibility of forks is usually a much greater force in free software projects than actual forks, which are very rare. Because a fork is bad for everyone, the more serious the threat of a fork becomes, the more willing people are to compromise to avoid it.

— Karl Fogel, Producing Open Source Software

Is Firefox actually forkable? In one sense, clearly, yes – there have been several pseudo-forks, from Beonex to Flock to Iceweasel. But Firefox is much more than just a codebase – it’s also a well-loved brand, a movement, and a connection with 400+ million users. Anyone taking the Firefox code and starting their own project doesn’t have that – as Flock discovered. “Firefox”, in its widest sense, is pretty much unforkable.

So if, as Karl suggests, the possibility of forking is actually a force which binds developers together and makes them willing to compromise when necessary, does the Firefox community actually lack that safety valve, leading to a lack of necessity to compromise from those with power within the project, and greater frustration for those without it?

Or, to look at it from another angle, does the lack of forkability actually give leaders (who have meritoriously risen to the top) the opportunity to execute on a single-focussed vision without the risk of fragmentation of their community?

As my accidentally-leaked scratchpad put it, “Discuss…”.

How I Got Involved With Mozilla (And Why That Might Not Work Today)

[Another response to David Boswell’s post.]

I got involved with Mozilla in January 2000. The previous October, I had switched courses at university from Chemistry to Computation (now called Computer Science), straight into the second year of a 3-year course. (This is practically unheard-of; it was a real work of God that it was possible.) After taking a term to get up to speed, I decided I wanted to get involved in a real software project. As I was thinking this, I read this comment from Mozilla UX contributor ‘mpt’ on Slashdot, which said in part:

Join the Mozilla effort. Do it now. It doesn’t matter if you don’t know C++. It doesn’t matter if you’re stuck on Windows. It doesn’t matter if you only have two hours a week to spare. Just join in. Download binaries. Report bugs. Suggest enhancements.

I’d like to think that the Slashdot readership were actually interested in the future of both Linux and the Internet. I don’t want Linux to be a second-class end-user operating system, simply because it doesn’t have the world standard Web browser on it. And I don’t want Microsoft, or any company for that matter, to control the Internet.

Do you?

I decided I didn’t want Microsoft, or any other company, to control the Internet – so I followed the links and signed up to help. (And at the time, I was still ‘stuck on Windows’ – Windows 95 OSR 2, because I thought Windows 98 was too unstable. Not long after, I switched to Linux.)

My first point of contact was the BugAThon – which still lives on today, I believe. Why was it appealing? It was a simple idea – make reduced testcases for layout bugs – with clear instructions on what to do, and a reward at the end :-) I still have one of the two stuffed green Mozilla lizards (some lizards were green, way back then) that I earned. At a later point, I ended up running the BugAThon for a while.

After a month or two’s involvement, I felt part of a community – with Asa and Eli and others – and before long, I was recruiting people and running the daily smoketesting of the previous night’s build. This was way before automated testing – we ran through a list of 60 tests to check things like “pages load correctly”, “email downloads correctly” and so on. I felt part of something bigger than myself, something important, and I was hooked.

Asa got hired, and then arranged a post-university internship for me in the group at Netscape in the autumn of 2001. That’s when I became part of the ‘staff’, and the rest is history. Although apart from that internship, I didn’t start getting paid to be involved in Mozilla until 2004/2005 or so. As the Corporation and Foundation split, Mitchell asked me to be part of the Foundation side and be the watch-over-the-whole-community guy, while most other people focussed on Firefox.

Why wouldn’t this work today? Well, it might – but it seems unlikely in today’s setup that a new community member, after only a few weeks, could acquire such significant responsibility. And it’s trusting people and giving them responsibility which gives them a stake and binds them into a community. Also, I don’t think we are as good at loudly articulating publicly the threats to the Internet which might inspire people to participate. Mozilla itself as an organization has never been awesome at that, although various Mozillians have been.

On the other hand, until recently, we were short on ways to get involved as simple and as well-defined as the BugAThon – but the great work of Contributor Engagement seems to be changing that, which is awesome. I look forward to seeing what the Mozilla Stewards program achieves in this area.

State of the Browser Q & A

Paul Rouget and I represented Mozilla on the Q & A panel at “State of the Browser” in London last Saturday, along with representatives of Chrome, Opera and RIM (Blackberry browser). (The Microsoft guy was unable to attend at the last minute for entirely legitimate personal reasons.) The session is about 50 mins long.

Panel Q&A Discussion (State of the Browser) from London Web Standards on Vimeo.

You can watch it in higher definition if you click through. Sadly and ironically, it’s not using open video – Vimeo doesn’t support WebM or Theora, although they have an h.264-based HTML5 player in beta. And it’s a bit large to host myself.

If you hear me saying anything factually incorrect, let me know and I’ll try and get a corrective comment added to the Vimeo page.

Major Browsers: UI Language Coverage Stats

With the Firefox 4 release almost upon us, Google having quietly shipped Chrome 10 last week, and IE 9 released yesterday, it’s time for another comparison of how the different browser makers support language communities. Here’s the headlines:

Browser Language
Firefox 4 (predicted) 73 93.7%
Firefox 3.6 68 95.1%
Chrome 10 45 91.6%
Opera 11.0 40 86.0%
IE 9 38 89.7%

For those just tuning in, these stats come from an large spreadsheet where I take the internet population of each country, divide it as best I can among that country’s language communities, and thereby try and predict what percentage of the world’s internet users have first language support in the UI of each browser. The standard disclaimer: I have adopted a possibly controversial and idiosyncratic definition of what is a language; please don’t beat me around the head with it, but focus on the big picture.

There’s a load of interesting stuff behind the headlines:

  • There are 37 languages whose speakers are out of luck if they go and see Microsoft, but who we cater for. Every single translation we have is done by volunteers in our community. The power of open source!
  • Firefox 4.0 has more languages than Firefox 3.6 but a lower percentage. That’s because, sadly, we were unable to get Serbian and Vietnamese on board for the Firefox 4.0 final release. Vietnamese accounts for 1.32% of the world’s internet population, and Serbian another 0.25%. These two languages account for the drop, and also mean that our language set is not a strict superset of those provided by IE (and why the figure above is 37, not 35).
  • However, since Firefox 3.6 we have gained Akan, Asturian, Breton, Bosnian, Gaelic, Armenian, Lugandan, Mailithi, Sepedi, Songhay, and Zulu. A strong African contingent there :-)
  • IE gets to a higher percentage than Opera with fewer languages primarily because Opera does not have an Arabic version (worth 3.2%).
  • Between Chrome 8 and 10, they seem to have lost Tagalog, Kazakh and Hebrew, which makes a big difference to their percentage (-2%). It could be that these languages will come along post-release; I don’t have a window into their process.
  • None of the browsers now has a Tagalog version, despite it being (as far as I can see) a very large market. Do Philippines computer users just use the English versions?

Feel free to look at the numbers and post about anything interesting you find :-) Updates to the data which splits a country’s internet population into language groups would be particularly welcome.

IE Blog Video “Fallback”

I’m very appreciative of the IE team’s attempts to make IE 9 more standards-compliant and implement some of the new stuff. But I don’t think they’ve quite got the hang of this “fallback” thing yet. This is their latest blog post on my Linux machine:

Screenshot of MS blog, with Install Silverlight button, then 'Note this video uses the HTML5 video tag (with the H.264 codec) if your browser supports it, and falls back to other methods otherwise. It’s a good example of same markup in action.'

No, suggesting I install Silverlight is not within the spirit of HTML 5, standards and correct fallback. Certainly not without first providing Ogg or WebM versions of the video.

If I click the “Install Microsoft Silverlight” button, it gives me a big scary message about Silverlight not supporting my browser, and sends me off to install Moonlight. To see what would happen, I did install the latest stable Moonlight. That worked, but then I got a warning about this being a Silverlight 3 app which Moonlight may well not support properly yet. After that, I got a prompt to download the Microsoft Media Pack of codecs (presumably H.264, and proprietary software). So I stopped there. Hardly the seamless web experience that <audio> and <video> are supposed to provide… <sigh>

Do they really think that it will be some sort of earth-shattering precedent-setting or some sueable event if they were to provide Ogg or WebM versions? Come on, guys, flex a little bit.

IE 6 User Wanted

Believe it or not, I am looking for someone who uses (or perhaps, has access to for testing purposes :-) a copy of Windows XP running the standard IE 6 it shipped with – before XP SP2, which made a number of changes. If you are that person, and would be willing to help me with a little research (5 minutes) then please get in touch. Thanks!

IE 8 and the Public Suffix List

It has become important in recent years for web browsers to know something about the de facto ‘shape’ of the DNS – e.g. to tell the difference between (someone’s domain) and (a registry-specified suffix under which people register domains). This is used to stop cookie leakage between domains, to highlight the important parts of a domain name, and for other things too.

To do this, Mozilla started the Public Suffix List project, a cross-browser initiative which tries to maintain such a map. This list is used by Opera and Chrome/Chromium. Thanks to some heavy lifting at the start of the project by some very hard-working volunteers, the list is pretty comprehensive (although we tweak it regularly).

IE 8 also needs to know this type of information, to power things like its domain highlighting in the URL bar. The excellent Eric Lawrence’s post on the IE blog details what they use it for and how their code works. You can see there the algorithm that IE used in all versions prior to IE 8.

In IE 8, they made changes to improve the accuracy of the algorithm. Sadly, although the licensing on the data is designed to enable them to, they have chosen not to switch to using the Public Suffix List. Instead, they have kept their old heuristic but added a set of exceptions – ietldlist.xml, which is bundled with IE 8. (If you have IE 8, you can see it by visiting the URL res://urlmon.dll/ietldlist.xml).

This is sad a) because it makes the browsers inconsistent with one another and b) because IMO their algorithm and list combination does not produce results as good as the Public Suffix List. Here are some issues:

  • The IE list contains typos (I’m fairly sure about most of these):
    • (aé
    • (
    • (
    • (
    • (
    • (
    • (
  • The .aero, .pro and .museum gTLDs have a large number of reserved subdomains; these aren’t recognised.
  • There is likewise no attempt to deal with the subdivided complexities of Italy (.it), Japan (.jp) and Norway (.no).

That’s not to say we don’t have things to look into either; I’ve filed a bug to follow up the places where IE has an entry that we don’t.

I’ve written a Perl script implementing both algorithms (PSL courtesy of the regdom-libs project) so people can see the differences for a particular domain. Note that I can’t redistribute ietldlist.xml, so you’ll need to obtain your own copy of that before the script will run.

I hope Microsoft will consider using the PSL for the next release of IE, so we gain cross-browser consistency and can all work together to maintain a single map of the DNS. We are happy to work with them to make that possible.

OpenAjax Alliance Runtime Initiative – Voting Results

The OpenAjax Alliance is “an organization of leading vendors, open source projects, and companies using Ajax that are dedicated to the successful adoption of open and interoperable Ajax-based Web technologies.” MoCo is a member, along with a lot of other companies

Their “Runtime Advocacy” taskforce has spent the last six months canvassing opinion on features they think should be added to browsers, and getting votes on which are the most important. The Summary Report was published today. Here are the top ten feature requests, with a quick analysis of where the Mozilla project is on each:

  1. 2D Drawing/Vector Graphics. This is basically a cry for IE to support SVG. They also ask for SVG 1.1 Full support (I’m not sure what our current state is; perhaps roc can comment?) and text support in <canvas>, for which we have an experimental API in Firefox 3.
  2. Better Security for Cross-site Scripts. We’re proposed Site Security Policies (which may undergo a name change) for feedback; bsterne is currently ingesting it all in order to update the proposal. I’ve also proposed Script Keys.
  3. Better APIs about positioning and styling. This seems to be another “please fix IE” request. The only API mentioned, getBoundingClientRect, is in Firefox 3.
  4. HTML DOM Operation Performance In General. It doesn’t say what version of Firefox they tested, but even if it was 3.0 alphas, the performance numbers for this request were done in January, before the Firefox 3 performance push around beta 4. We still smoked IE in every test they did, splitting first place with Safari. If the author of the page (“Cwei”) could redo the tests against 3.0, that would be useful.
  5. Better Support for Rich Text Editing. As the Summary document notes, “various people in the Ajax community want to move desktop-like document editing into the browser. However, the contributors to this feature request did not outline a detailed strategy for how to accomplish this in future browser.” The page has some useful feedback from Frederico Caldeira Knabben (of FCKeditor) on what he found difficult; we should take note of that. Otherwise, define your requirements more specifically :-)
  6. The Two HTTP Connection Limit Issue. Both IE 8 and Firefox 3 have raised the limit here from 2 to 6, which helps. Having the server specify how many connections it would like is an interesting idea; perhaps our network team could comment.
  7. Better UI Layout Support. They want something like XUL hbox and vbox in HTML. David Baron recently reintroduced the CSS flexbox spec on the W3C CSS mailing list.
  8. Native JSON Parsing. Done for Firefox 3 (docs).
  9. Persistent Connections Issue. Increasing the HTTP connection limit helps to avoid lockup in the short term. We also have offline events and state detection. Exactly what to do in the longer term is still being worked out – it may involve the WHATWG WebSockets spec.
  10. Video and Audio. Patch checked in – should be in Firefox 3.1 :-)

Language Coverage – Version 1.1

I have released an updated version of my language coverage data – its home is now a web page rather than a blog post.

Among the new features are:

  • Several bug fixes and data improvements; the Firefox percentages have gone up but, sadly, so have the IE ones.
  • Information on Opera.
  • A new line showing how IE fares if you don’t include LIPs.
  • A new line for “registered l10n teams”
  • A tab which shows that if a browser team were using this data to guide where to put l10n team effort, what languages they should be focussing on. This data is provided for Firefox, IE and Opera.

Thank you to everyone who gave me useful feedback. Please let me know of any further improvements I could make, within the general parameters of the method.

No JS/No CSS Browser Detection

[Browser detection removed as it broke the validation of my RSS feed. Check the author’s site if you want to try it out.]

This browser detection uses pure HTML 2.0, without any JS or CSS. Here’s how it’s done. It even distinguishes Firefox 1.5 from Firefox 2. Can any parser hackers extend it to further distinguish Firefox 3?

Anchor Markers

We’ve had a bug open for quite a long time about implementing the W3C Common User Agent Problems recommendation from 2001 to highlight the target of intra-page named anchors.

Someone recently posted their ideas in that bug; I don’t think much of their UI, but I think it would be great if Firefox had a solution for this. (It would be nice also to style internal links slightly differently, perhaps with a dotted underline, so people don’t do “Open In New Tab”, and end up with five copies of the same large page.)

Is there an extension which does this? If not, does anyone feel like knocking one up?

One implementation method would be to highlight and then fade out the elements contained in the <a name=””> tag. However, this might not work everywhere because of the following pattern:

<a name=”heading”></a>

People do this a) to make sure the heading is visible on the page, and b) because people used to write bad CSS which caused hover effects to apply to anything within an <a> tag, whether it had an href or not. But maybe this problem isn’t a showstopper.