This year, Time magazine named “The Protester” its “Person of the Year”. Inside, they cover several key people in the 2011 protests around the world, among them linguistics teacher and blogger Lina Ben Mhenni (“A Tunisian Girl”). In the picture, she’s carrying her “sword” — the laptop she uses to write her influential blog. To my delight, she decorated it with a Firefox sticker, along with various others about privacy and political activism.

Hat-tip to Lina: Thank you for standing up for civil rights in your country and everywhere in the world.

Diverse News-Seiten im Internet haben heute gemeldet, dass StatCounter (eines von mehreren Internet-Marktforschungsunternehmen) im November Google Chrome beim weltweiten Marktanteil erstmals knapp vor Mozilla Firefox gesehen hat.

Dass manche Statistiken Chrome auf etwa gleichem Marktanteil wie Firefox sehen, ist ein Erfolg für Mozilla.

Der Stiftungszweck der Mozilla Foundation ist, für die Offenheit des Webs einzustehen, und für die Freiheit der Benutzer, das Web so zu verwenden, wie sie es möchten (nicht: so wie man es ihnen vorsetzt). Die Tatsache, dass Google dazu in der Lage war, einen Browser zu erstellen, und diesen erfolgreich an den Markt bringen konnte, ist ein unmittelbarer Effekt des unerbittlichen Kampfes von Mozilla und seiner Community, den Browsermarkt aus einem Monopolmarkt in einen Markt mit mehreren Konkurrenten zu verwandeln. Es wäre scheinheilig von Mozilla, nun zu behaupten, das hätten wir nicht gewollt, oder “als wir offenes Web sagten, meinten wir eigentlich ein Firefox-Monopol”. Offen heißt offen, und wenn Benutzer Chrome verwenden wollen, dann müssen sie dazu in der Lage sein.

Das alles heißt freilich nicht, dass wir nicht noch immer Firefox für den besten Browser für die Benutzer halten: Schließlich ist es der einzige Browser, der die Interessen des Benutzers ohne Wenn und Aber in den Mittelpunkt rückt. Dass Google ein Konkurrent ist, der mit Chrome ein technisch starkes Produkt mit zweifellos innovativen Eigenschaften hat, ist nicht weniger, sondern um so mehr Grund, Firefox ständig weiter zu verbessern.

Foto: “fully open, duh”, CC by-sa-nc licensed by morgamic

Alex writes:

I would LOVE to see PyPI become a place that Mozilla felt confident it could use to deploy Python software.

I am happy about this conversation-starter and would like to contribute some of our reasoning for using a “vendor library” over pip requirements files. I, too, am not a huge fan of the vendor library, but understand how it solves some of the problems we’ve been having with plain PyPI at Mozilla.

Let’s discuss some of our main concerns and how the vendor library solves (or does not solve) them for us.

Risky dependence on PyPI and other third-party servers

In the past, PyPI has not always been the most stable of services. Even though PyPI has been vastly improved meanwhile, not all libraries we use can be pulled from PyPI, some come from code repositories on various services. Pulling in files at deploy time from numerous places all over the Internet is a huge risk, particularly if your deployment requires downtime and you need to be done as soon as possible. In other words: A setup that doesn’t allow us to (mostly) bundle one neat package before actually performing the deployment to our servers is a huge risk we’re not willing to take lightly.

Some, but not all of this, could be mitigated with a private PyPI mirror, though that comes with a maintenance overhead and does not help for non-PyPI libraries at all.

We deploy to, potentially, many servers

Second part of the “one neat package” issue: Running pip install on one server is fun and games. On 50? Not so much. It takes a long time, even if you run it on all of them in parallel. Quite possibly, a few of them will have hiccups (network trouble, for example) in the process, so good luck finding out which ones failed and manually fixing those before moving on.

Package “migrations”

Imagine an upgrade to an already-deployed application. How do you add two libraries, remove three, and upgrade five existing ones? Installing and upgrading might work with pip, for uninstalling we’d (probably?) need to write some sort of migration script, hope it all runs smoothly on all servers, then carry on. Or we blow away the virtualenv altogether for every push and reinstall all libraries from scratch.

This is many things, none of which is elegant.

Contributors

We want it to be reasonably easy for contributors to set up our code and start developing. With the vendor library, it basically boils down to a few git commands, while pip install is a much longer process. In addition, the “migration problem” is present here too: The developer has to constantly monitor changes to the requirements files (or realize that the source of an unexpected, new error is a missing library) and run pip as appropriate. In contrast, updating the vendor library is part of the regular pull-from-git process any developer has to do anyway to stay up to date with the main repository.

Vagrant mitigates some of these concerns by automating the setup process, but not all.

Compiled packages

One thing neither PyPI nor vendor solve is the deployment of packages with binary components (usually: C libraries with a Python wrapper). For that reason, we keep those libraries to a bare minimum and prefer pure Python variants wherever feasible. The few unavoidable compiled libraries (such as Jinja2 or py-bcrypt) we deploy to our servers through RPM packages (by sticking these requirements into a common Puppet file shared by all our webservers). That’s not too elegant, but as these cases are somewhat rare, it works. In any case, a server running the actual pip command to install these packages needs to have a full compiler toolchain, which production web servers are unlikely to have.

What it boils down to

The base concerns here circle around robustness and scalability, both for deployments to real-world servers and for various, globally distributed developers.

Really, the key is minimal human involvement: We love our developers, and we love our sysadmins. Any part of a requirements system with a high chance of repeatedly requiring human involvement is broken and needs fixed.

If you have any suggestions on how to improve this setup, I am all ears. As always, Mozilla’s code and processes are Open Source so we are happy to listen to your ideas!

This is me, reading a Firefox-themed QR Code with my cell phone.

After getting the idea from this excellent blog post, I made a QR code pointing to mozilla.org/firefox, sporting a nice little Firefox logo in the middle.

For the geeks among you who would like the 411, this works because QR codes have a certain degree of redundancy for error correction. The logo in the middle is considered an “error” and thus, the rest of the code is used to puzzle together the information in the code anyway.

Try it out with your smart phone (on Android, with an app like Barcode Scanner), it really works!

There once was an old man. He lived alone in a big house with a nice yard. In the yard, there was a big cherry tree. Old as he was, the man needed help around the house, so he asked the kids in the neighborhood to mow the lawn for him, buy him groceries, and run many other errands he needed done. In return, he paid them a few dollars, but he also allowed them to pick cherries off the tree whenever they wanted.

The children loved it.

Sure, many people in the neighborhood needed jobs done, some of them promised to pay more, too, and the old man’s cherry tree wasn’t the only one either (in fact, many of the children had cherry trees in their own back yards at home). Still, they would always happily come back to the old man’s house, either to help him out, or to eat some cherries off the tree, or sometimes even just for a little chat when passing by.

The old man was happy: Not only did the kids give him all the help he needed, he also liked their company. So he gladly spared the money for the errands and the cherries that the children ate in exchange for not being so alone all the time.

One afternoon, the children came by the old man’s yard to get some cherries. To their dismay, the man had suddenly put a big fence around the tree. They couldn’t get cherries anymore. “I have cherries at home anyway”, said one, “I’ll just go buy some with my allowance”, decided another.

Disappointed and hurt, they walked off. Over the next few days, they tried to find out what had happened. The old man never said anything to the ones that worked for him during that time, but rumor had it that the old man had put up the fence after someone had taken a whole bunch of cherries, many more than a single person could eat. The man had gotten upset about it, the rumors went, and decided to only let the children get cherries now when they asked for them, and only when he felt like it.

Over the next few weeks, the kids visited the man more and more rarely. Some still ran errands for him, but they got them done as quickly as possible and went home. Hardly anyone stopped by for a chat, even the ones that didn’t like cherries in the first place.

The old man was confused and a little sad to see how little the children seemed to care for him. Then finally the old man had the heart to ask one of the boys why no one would keep him company anymore. “Is it about the cherries?”, he wondered, “But I’ll still give them to you when you ask!” As the boy left, he just said: “It’s not about the cherries, man, it never was.”

The old man pondered these words for a long time while he looked at himself in the mirror. Then he finally realized it. The children hadn’t come to him for the money he gave them for running errands–any other job around the neighborhood would do. They hadn’t come because of the cherries, they could all get cherries elsewhere. They had come to him because he had trusted them. He had trusted them to run errands for him and not shortchange him along the way. He had allowed them into his home without fearing they might steal something. And finally, he had trusted them to pick cherries off his cherry tree, plenty but not too many, without his supervision or knowledge.

When he had built that fence after someone had taken too many cherries, he might have had the best intentions, to protect his cherry tree, their cherry tree! But it did not matter, because he hadn’t just taken away their right to pick cherries, he had taken away the trust, and with that, the very thing that made their relationship special.

But it was too late. Now he was just a lonely old man.

My Facebook session is SSL-encrypted by default, but Words with Friends requires me to disable this encryption. This is wrong on many levels. Most notably, if I disable “secure browsing” on Facebook altogether, even only for this session, my session cookie will be sent in plain text over the wire (or worse, on Wifi, over the air). If I do this at a coffee shop or airport, this is a great invitation for every evildoer in the general vicinity to hijack my Facebook account.

While I appreciate Facebook’s transparency in the matter, I find it upsetting that companies like Zynga wouldn’t account for Facebook users on SSL. By encouraging people to access Facebook over an unencrypted connection, they are foolishly endangering user data and are demonstrating an utter disregard for user privacy.

I wish Facebook enabled SSL encryption by default, and furthermore required third party apps to be served over SSL. You can’t have it both ways: Either you don’t handle user data, then you don’t need to care about encryption. Or you do handle user data (and yes, a session cookie counts!), then you need to properly secure it. I am tired of software makers weaseling themselves out of their self-imposed responsibility.

Update: As pointed out in the comments, moving to HTTPS for apps is on Facebook’s developer roadmap. I appreciate it!

“What, Mozilla makes websites? I thought all you did was Firefox.”

It’s usually followed by a second question: “what, your websites are open source, too?”

The basic misconception here is that Firefox is Mozilla’s mission. This is not true. Mozilla’s mission is outlined, in broad strokes, in the Mozilla Manifesto, and the core of Mozilla’s mission is to make the Internet better for the users (which goes beyond the Web and includes technologies like email, for example). And we believe that the best Internet for the users is one that inherently supports openness and choice.

Now don’t get me wrong. Firefox is important. Because the Web is the most visible thing that people like you and I are using the Internet for nowadays, Firefox is our most important tool to make the Internet better for the users. But it is not enough. The Web is not television. On the Web, the users are also the producers.

And this is why Mozilla’s mission goes beyond Firefox, beyond Thunderbird, deeply into the development and privacy space. A participatory Web based on Open standards, powerful APIs, along with the inherent freedom of choice and users’ control over their own personal data are what Mozilla is all about. Apart from Firefox, don’t be surprised to see Mozilla write state-of-the art, open source web applications and developer tools, be involved in the development of various open standards and play an important role in many other spaces that are relevant to the Internet today.

A few months ago we founded an experimental new “rapid web development” team at Mozilla. Its purpose was to take care of a growing number of short- to medium-term web projects at Mozilla. We nicknamed it the “Flux” team (for its ability to maintain a higher throughput of projects while reducing the overhead of individual projects).

The team focused on two areas in particular:

• software lifecycle management: establishing project management guidelines and driving web software projects from idea to completion (including their eventual retirement). The team also served as stewards for externally developed projects.
• streamlined web development: reducing the amount of nonfunctional overhead when developing Mozilla web apps, while ensuring consistently high quality standards across projects.

The experiment proved successful: Together with a number of internal and external groups, Flux successfully released more than a dozen projects of varying size around the release of Firefox 4 and Firefox 4 mobile.

But along the way it became apparent that the two focus areas mentioned above are different and challenging enough to stand on their owns, so we rearranged the group accordingly, spawning the Web Productions team (led by Ryan Snyder) and the (new) Flux Development Team (led by me, Fred Wenzel).

The web productions team will continue to run Mozilla-internal web projects, but has also branched out into fostering community-sourced projects and similar endeavors.

In the Flux Development group, I am working with a team of (so far) three excellent engineers (Dave Dash, James Long, and Anthony Ricaud) on web development for various parts of the Mozilla community.

The Flux team will be working on:

• Evolving our development platform: compiling and maintaining reusable code (libraries) as well as engineering best practices for web projects. (One tangible artifact of this work is the playdoh application template.)
• Software architecture and development for existing and new projects, among them: mozilla.com/org, Firefox Input.
• Tools and services to be shared by various projects, e.g., ElasticSearch, Grouperfish text clustering, Mozilla Product Details.
• Assisting as technical stewards with Web Productions projects.

Say hi to the new Flux and Web Producers teams!

On the Interwebs, a blog post on behalf of Internet Explorer 10 made the rounds today, trying to coin the term “native HTML5″ for web applications that look like Windows applications, grotesquely turning the cross-platform nature of the Web into a flaw that can only be remedied by ignoring both other platforms and even different versions of the platform in question.

In the community, this curious opinion has been received with humor, which is exactly the kind of reaction this marketing blabber should receive. (This is also in the interest of the engineers at Microsoft who work hard to implement more and more web standards in Internet Explorer, which — remember! — greatly benefits all web users who can’t or choose not to pick a different browser. They are the people who are unnecessarily and ironically ridiculed by the “native HTML5″ blog article).

Final day of the Mozilla All-Hands week! Tons of lightning talks about interesting topics today. Here, Lars shows off his Python development environment.

After I get some sleep this weekend, I’ll have plenty of software and tips and tricks to try out that I collected over the week. Exciting!