Posts Tagged with “technology”

The Mozilla Foundation’s Statement of Direction describes two complementary techniques for advancing the Open Web. One is to nurture a broad set of technology and community building efforts, centered around the Mozilla platform and values. The second is to focus more precisely on those areas with the greatest leverage for change. Today, this second technique translates into a focus on Firefox, the platform technology that underlies Firefox, and the Firefox ecosystem.

It is extraordinarily difficult to create the kind of impact that Firefox and the Firefox ecosystem now enjoy. The Mozilla community has done this, and the Foundation feels an acute responsibility to live up to the opportunities this creates. We have a rare point of leverage and must not let it slip away.

Because Firefox has such leverage today, the bulk of the Foundation’s resources are devoted to promoting Firefox, the Firefox ecosystem, the underlying technologies that make modern browsing possible, and the various communities that participate in these efforts. In more concrete terms this means:

• Focus most where we have the greatest impact — Firefox and “browsing” broadly defined — that is, browser-based access to web content and applications
• Focus on the XUL platform that underlies Firefox to keep the Open Web competitive against closed/proprietary platforms
• Assist other Mozilla participants and projects, but not equally with Firefox and not at significant cost to Firefox
• Be exemplary Mozilla participants (this has historically been explicitly not doing whatever people ask for, but providing evaluation, review, module ownership, etc., with a focus broader than a single product)

Clearly these expectations are very broad — what does it mean to “focus on the XUL platform that underlies Firefox?” How much is specific to Firefox? To what extent are more general platform needs incorporated as “assist other Mozilla projects, but not equally with Firefox and not at significant cost to Firefox?” This level of detail should generally be worked out by the technical leadership through the module ownership system.

And clearly there are a range of other activities which the Foundation could undertake to promote the first goal above — encouraging a broad set of Mozilla-based participation, whether or not any particular effort becomes a global general consumer product. As noted in the Statement of Direction, the Foundation intends to do so. There will be more on this topic before too long.

One night not long ago I got home from work before the rest of my family. I was off setting my laptop up for another work session when suddenly I heard an odd noise, and then another. I froze, trying to figure out what it was and where it came from.

After a minute another noise. These noises were clearly from inside the house. But they made me feel a bit better — they sounded much more like an animal than a person. Then I noticed the door to the garage was open. Ugh, I thought. I wonder if somehow the neighborhood raccoons found a way into the garage and are now in the house. (The raccoons have been a big problem this year. My neighbors routinely exchange tales of how we try to secure our garbage cans so the raccoons don’t open them and make a giant mess.)

I got a tool and went carefully around the house looking for animals. Silence. And of course, just as I relax I hear more noises. Odd, odd noises. They seem to be coming from around a particular chair. The noises seem louder than the sounds made by the lizards that sometimes come inside, but lizards are my new best guess. I walk around the edge of the chair and suddenly there is a set of loud noises — exactly at my ear height.

I jump, jump backward, and look around. Right exactly at ear height I see them — the little speakers hooked up to our kitchen computer. There’s no question they are the source of the sounds. After some investigation I learn that my son likes the notification sounds that my husband’s Instant Messaging Client makes when people log on. So they have selected the “best” sounds, turned the volume way up, and left. The monitor has long since gone into power saving mode and is completely black.

There’s only sounds. Odd, animal-like sounds at inconsistent intervals. Live with computers — isn’t it great?

When I came back home from some recent travels I learned that my husband and son had had some trouble getting to school on time. How did I know this? No one said much about it, but the family computer gave the secret away.

Our “family computer” lives in the kitchen. It’s a combination of a Mac mini (the little box) with a Dell combination TV / monitor. My husband has long wanted to be able to watch the football while we’re in the kitchen. So a year or so ago he hooked up this system. It turns out that we still rarely turn the TV and we use the computer a lot more than the TV. (It’s not enough to have both our work laptops in the nearly dining room and various other bits of computer gear through the house. No, we really “need” an extra computer )

The morning after I got home I was groggily dragging myself around the house trying to wake up when a giant booming voice came rolling out of the kitchen. After a bit I realized it wasn’t my son yelling, it was a distorted computer voice announcing “School Departure Blast-off! Five minutes and counting!” Followed by a loud and perky version of Devo’s “Time-out for FUN.” After 5 minutes of Divo, it is time to get out of the house. Weeks later, it’s still working. Periodically we change the voice. My son is horrified by the idea of an alarm clock, but finds this approach completely natural.

Traditionally, our Roadmap has been a short, very high level document that identifies the key issues of an era and sets direction in those areas. I’d like to see us try out a new approach to our roadmap going forward.

It would be very helpful for the Platform roadmap to become more of a working document, one that sets a global framework for what we’re doing, and is also tied structurally to other, more detailed planning documents. It should help engineering contributors relate their work to the overall plan, and should help everyone see what’s planned and how the pieces tie together. We should have an explicit plan for the Mozilla “platform” (often known as “Gecko”) and we should have an explicit plan for the products, starting with Firefox. Perhaps the two plans together are the Roadmap, or perhaps we have a product roadmap and a platform roadmap, I’m not sure. But in any case the two must be closely related.

I’ll outline here a plan for the platform piece, with the understanding that the product piece will follow closely. Mike Shaver, with Brendan’s encouragement, has started the effort to produce a platform roadmap along the lines I describe below.

More specifically, here’s a plan:

The Platform Roadmap remains a short, high-level document, but would provide a level more detail than our current and past roadmaps. For example, the next iteration should describe the technology capabilities of the Mozilla platform in the 1.9 release. It should have an outline of the major areas of technology that we know we’re working on for our 1.9 release, plus a summary of the rationale for these areas and a general statement of what we hope to accomplish in the 1.9 cycle. This document must have an owner who is responsible for the overall integrity of the plan, for including the correct areas of technology, and for figuring out how they relate together and for the ongoing vitality of the document. In my mind, this person is Mike Shaver, in close collaboration with Brendan Eich. By close collaboration I mean that Brendan is integral to the process and the document isn’t complete until Brendan signs off on it. By designating Mike Shaver as the owner I mean that it is Mike’s job to drive this process, to make sure the document gets written (either by writing it himself, or getting others to write pieces) and to sign off on the content as well. This means Mike is responsible for getting the deliverable done while needing key input from others. It’s a bit of a juggling act, and one for which Mike is uniquely suited.

The Platform Roadmap should provide pointers (links, references, etc.) to the more detailed planning and implementation work being done by the contributors. For example, there should be pointers to more detailed information on the state of our graphics initiatives such as cairo and SVG integration. The goal would be that someone can look at the Platform Roadmap, see that we’re working on a set of initiatives, follow pointers to those projects and get more detailed goals, schedules and status.

This detailed project-based information would be maintained by the contributors working in this area. This should help give the groups of contributors a way to describe what they are doing, and to have greater involvement and ownership in determining the deliverables, a reasonable schedule, etc. This second level of information will take some work to get pulled together. Perhaps not as much as might be expected, since many of the contributors working on major initiatives have documentation and status information available already and we can point to that information from the Platform Roadmap. In some cases we will have more planning to do. And in all cases the contributors will need to make sure that the description and status of their initiatives remains accurate. But of course, we need to do this in any case. I’d like to see the Roadmap become an organizing framework that allows us to get the most use out of that work.

This means that the Roadmap becomes something that the organization as a whole works on, works with, and relies on. That allows other organizations interested in Mozilla technology to rely on it as well, and to get better, more up to date information about what we’re doing than we currently provide.

This type of “roadmap” is something different from the past. It combines the high-level direction setting of past roadmaps with a new operational role. Mike Shaver is ready to take this on, Brendan is working closely with him and pushing to make this successful, and they plan to have a draft Platform Roadmap posted in the next couple of days. It will be a draft, it will undoubtedly need revision and have plenty of room for improvements. But I’m optimistic we’ve got a plan that lets us make progress. And that’s good news.

For months I’ve said I’ve been optimistic that the Mozilla Foundation would be able to reach an agreement allowing us to host and improve the materials from the former Netscape DevEdge site. I’m very pleased to report that my optimism was well founded.

We’ve reached an agreement with AOL that allows us to post, modify, and create new documents based on the former Netscape DevEdge materials. The agreement is done. I want to thank AOL for making this happen. Netscape DevEdge was a great resource. We’re very pleased those materials haven’t been lost and that the Mozilla Foundation can host their continued development and use. I also want to thank the many people who wrote to offer encouragement and help regarding the DevEdge materials — your encouragement was very helpful.

What happens now? Well, we probably won’t be able to simply recreate the site — we don’t have the build scripts for one thing. Naturally, we’re eager to get the data sorted out and the most important documents posted asap.

Starting next Monday we’ll have a new person working full time at the Mozilla Foundation to help with just this activity. On Monday Deb Richardson joins the Mozilla Foundation as a Technical Editor and Project Manager for DevMo. DevMo is our community based project focused on developer documentation and resources. We have a group of people interested in working on this, and are thrilled Deb can join us to provide the overall coordination, support and project management for this effort, working very closely with our volunteer community. Deb comes to us with extensive documentation and open source experience, having founded both Linuxchix and the Open Source Writers Group. She has also worked professionally as a technical writer, freelance editor, web designer and developer.

One of the first things we’ll ask Deb to do is to work with those familiar with the DevEdge material and sort out the most important documents, get those posted asap, and then develop a plan for handling the rest of the material. We want to make critical resources available asap and also build a coherent site. We already have a website at the developer part of mozilla.org that is hard to navigate, not well designed, and filled with material that is or may be outdated.