There’s a lot of info about Mozilla Drumbeat available, and I felt the need for an overview. Here is mine. Mark also posted a summary over the weekend.

Drumbeat is Mozilla’s nascent effort to find, energize and build a Mozilla community of people who are — or want to be — working with technology to build participation, understanding and control into Internet life. This is a complementary effort to building the core technologies themselves, as we do with the Firefox and Thunderbird.

Drumbeat will have tools for interested people to try ideas out — much as Spread Firefox, our product extension framework, and the Mozilla Labs efforts provides ways for interested people to try out ideas closely related to our products.

With Drumbeat we also expect to identify a few projects as an initial focus of the Drumbeat effort, much as we have identified a browser and communications client as the focus of our technology efforts. These Drumbeat projects are areas where the Mozilla Foundation will actively be working to build communities and create impact. Drumbeat projects may vary in their life-span; some may be quick and sprint-like, some may be longer projects.

Drumbeat will use many of the components we’re familiar with at Mozilla — a massive online presence, with work done in the open; lots of local and regional communities and gatherings. One difference is we’re thinking of an annual event as a very significant aspect. We’re thinking that this may be more important since the efforts aren’t likely to be as tightly coordinated as a product team, which becomes very tightly bound during the latter part of a product release.

More detailed thinking on Drumbeat can be found at the wiki, and of course there is an open invitation to get involved.

Most of us receive messages from many online sources — email, instant messages, tweets, Facebook messages, links. Raindrop is a new, experimental Mozilla project exploring how to manage all these sorts of messages. Raindrop aims to make communications more about the person and less about the technology in which the message was created. It’s the brainchild of the team responsible for Thunderbird.

You can find Raindrop over at Mozilla Labs, among a range of other projects exploring how to innovate at scale.

Today the European Commission announced a formal settlement proposal in the Microsoft tying investigation. The ultimate effectiveness of this remedy depends in part on the implementation specifics and can only be determined over time. Once the EC and Microsoft have agreed to a final settlement, Mozilla hopes to work closely with Microsoft and the EC to implement the settlement in a way that creates the best user experience possible in the ballot setting.

Mozilla will continue our work to help internet users across Europe understand the choices available to them and why it is important to make an informed decision about the software one uses to access the web.

Last week Google released a new product in the browser space called “Chrome Frame.” Chrome Frame aggressively address a serious pain point for Web developers. However, the overall effects of Chrome Frame are undesirable. I predict positive results will not be enduring and — to the extent it is adopted — Chrome Frame will end in growing fragmentation and loss of control for most of us, including Web developers. Here’s why.

The Chrome Frame plugin is essentially a browser-within-a-browser. Chrome Frame inserts an alternative “rendering engine” into your browser, and allows websites to determine which rendering engine you end up using. (The “Why Chrome Frame” section below has a slightly longer description of the problems developers face and of Chrome Frame, for those not so familiar with browser technology.)

Chrome Frame and Loss of Control

Once your browser has fragmented into multiple rendering engines, it’s very hard to manage information across websites. Some information will be managable from the browser you use and some information from Chrome Frame. If the Smart Location Bar in the “browser” doesn’t show the sites you’re trying to return to, then you need to find a way to open Chrome Frame and search there. Your “browser” can no longer aggregate information for you across websites. This defeats one of the most important ways in which a browser can help people manage their experience.

For many people Chrome Frame will make the Web even more unknowable and confusing. Image you download Chrome Frame. You go to a website. What rendering engine do you end up using? That depends on the website now, not on you. And if you end up at a website that makes use of the Chrome Frame, the treatment of your passwords, security settings, personalization all the other things one sets in a browser is suddenly unknown. Will sites you tag or bookmark while browsing with one rendering engine show up in the other? Because the various parts of the browser are no longer connected, actions that have one result in the browser you think you’re using won’t have the same result in the Chrome browser-within-a-browser.

Getting different results will be awkward even for those of us who understand clearly what is going on. Then imagine someone who isn’t immersed in browser technology. Imagine trying to explain to a neighbor that one day he went to a website, clicked on a button to “add Web capabilities to your browser,” ended up with a duplicate “rendering” technology that surfaces and disappears based on website controls, and this now means that the search bar, location bar and other basic UI elements will work in different ways at different times. This affects individuals directly, and Web developers indirectly. It doesn’t help Web developers if basic ways of interacting with the site be
come awkward, for example if I don’t know where my password was stored and how to access it.

Chrome Frame and Fragmentation

Google is not the only website developer that would find this idea useful. Google is providing the set of features it believes are helpful for making powerful websites. Other websites will have browser features they would find useful for their applications. Imagine having the Google browser-within-a-browser for some sites, the Facebook browser-within-a-browser for Facebook Connect sites, the Apple variant for iTunes, the mobile-carrier variant for your mobile sites — all injected into a single piece of software the user thinks of as his or her “browser.” Each browser-within-a-browser variant will have its own feature set, its own quirks, and its own security problems.

The result is a sort of browser-soup, where a given user action serves up some sort of response, but it’s not clear what the result will be: are my passwords and history stored in chrome frame? Some other variant? In what I think of as “my” browser? This makes the Web less knowable, less understandable, and certainly less manageable.

Why Chrome Frame?

Web developers and website applications face a painful and seemingly never-ending problem: wanting to implement capabilities that some browsers don’t support. The degree of pain this causes is high. Imagine trying to cook a really fine meal with an oven that can’t get above 250 degrees F. In some cases it’s just impossible, in other cases it requires rearranging ingredients, cooking time and the order of preparation. Web developers go through this regularly.

One way of fixing this is to get people to use a new browser. This is effective, but hard. Mozilla Firefox has reached some 300 million people, but hundreds of millions more continue to use the browser that came on the machine they bought, sometimes years ago. Google began offering its own browser — “Chrome” — a year or so ago, but this has yet to gain significant traction. This week Google offered a different solution — a version of Chrome repackaged as a plugin for IE.

For those not familiar with the ins-and-outs of browser architecture, you can think of a browser as having two essential parts. One part we humans don’t see — it’s the part that “speaks” computer languages and talks with Web servers. This is often called the “platform” or the “rendering engine.” The other part is the set of things that human beings see and interact with, which is often called the “front-end” or the “application layer.” The application layer includes the basic browser user interface — the window around content, the buttons, menu items, search box, etc. It also includes parts of the browser that appear based on what you are doing — the dialog boxes, the download manager, the password manager, the security warnings and the other messages.

Chrome Frame breaks this connection by inserting a separate rendering engine into your browser, and allowing websites to determine which rendering engine you end up using. If you download Chrome Frame you see the basic front end of your previous browser, but websites cause your browser to toggle back and forth between the rendering engine of Chrome and the rendering engine of the browser you selected. The application layer of your browser and the platform part of your browser are no longer connected.

At first glance this looks like it might be a useful option, offering immediate convenience to website developers in alleviating a very real pain. But a deeper look reveals significant negative repercussions.

A while back I wrote a post about Firefox that concluded with the idea that each one of us should be the center of our online lives — not a company, not an application, not a business plan. One common response has been: That sounds awesome, but how do we get there? Where do we start?

Well, no surprise — I start with the browser. The browser is the piece of the web that human beings interact with directly; it’s the tool through which people “touch” the web. I have an immense degree of control over my browser. With a website I have the degree of control the website chooses to offer. I am one of many users at a website, but the browser is mine.

These traits make the browser the logical tool for a user-centric (”you-centric” ??) world.

An early step was customizing the browser by hand, adding extensions, bookmarks, settings, themes and personas. More recently browsers have begun offering automated customization as well. For example, the Smart Location Bar (aka the “awesome bar”) automatically offers easy access to websites we’ve visited before, automatically tuning to each person’s browsing habits.

The awesome bar presents automated customization to the user. It aggregates information about my usage across many websites and presents the information back to me. It’s immensely helpful. One area to explore in building a user-centric web experience is other examples where this sort of automated customization would help the user. For example, perhaps knowing my own search history across many website would be helpful to me.

Another form of automated activity to explore is the presentation of customized or individual responses outward, to websites. For example, the browser could automate the current dysfunctional process of logging into and out of websites. There are unquestionably other things we do regularly that the browser can automate and run in the background. Sharing of information is becoming increasingly common. Perhaps the browser could automate response to certain types of requests. There are obviously privacy and control issues with sharing information. That’s why the browser — where I have the most control — is a logical choice.