Posts Tagged with “technology”

Late in July we got together close to 400 extremely active Mozilla contributors for a face to face gathering known as the Firefox Plus Summit. This gathering was partly acknowledgment and celebration of our work so far, and mostly preparation for the future. The Summit has caused me to reflect on the future of Mozilla. In short, that future is bright.

The overriding reason for this is the strength and vibrancy of the Mozilla community. We’re growing, we’re effective and we’re expanding the types of activities that live within Mozilla. The Summit made this very clear.

There are other reasons as well. Mozilla combines the abstract goals of Internet openness, participation and decentralized decision-making with the concrete task of building great products. This combination is working. It attracts people to Mozilla, and it gives us a way of building products that reflects the Internet itself. The values of the project bring meaning and guide the way we do things. The software allows us to make those values tangible, and put their manifestations in the hands of millions of people.

Another important element is the financial resources Mozilla enjoys. We’ve just renewed our agreement with Google for an additional three years. This agreement now ends in November of 2011 rather than November of 2008, so we have stability in income. We’re also learning more all the time about how to use Mozilla’s financial resources to help contributors through infrastructure, new programs, and new types of support from employees.

Finally, the quality of our technology, products and innovation also holds great promise. In the few weeks since the Summit we’ve already seen a new approach to vastly improving JavaScript performance, the launch of “Snowl,” the introduction of the browser concept series, developer releases for Thunderbird, and video moving into the browser via Firefox 3.1. There’s much more coming.

We have large challenges ahead of us, there’s no question of that. There are many ways in which Internet life could become closed, manipulated and decidedly unpleasant. And Mozilla itself is not perfect. Many improvements are possible in how we work and what we accomplish. To be effective we’ll need to do our best, and then do even better.

Our challenges are real, our opportunities are real, and our strength is real.

Put those together, and the future is bright.

Yesterday Robert Accettura made an interesting post about the range of SQlite today titled “The Winner For Most Embedded Is: SQLite.” This reminds me I’ve been wanting to talk about SQLite Consortium for a while. Robert points out thatSQLite is an element of “Adobe Air, Mozilla Prism, Google Gears, Android, iPhone SDK (likely through Core Data API), Ruby On Rails (default DB in 2.0), PHP 5 (bundled but disabled in PHP.ini by default).” I personally would probably say Firefox as well as Prism. In addition, SQLite is an open source (actually, public domain) piece of software. At Mozilla we view SQLite as important both for our product and for advancing transparency, openness, innovation and participation in the Internet.

Last December Symbian and Mozilla became the charter members of the SQLite Consortium. Last week Adobe announced that it has joined the SQLite Consortium, demonstrating Adobe’s recognition of the importance of Sqlite and its participation in various open source projects. Hopefully other organizations that rely on SQLite will do the same.

Here’s a bit more on the history.

A while back Richard Hipp contacted Mozilla to see if we had some time to talk to him about sustainability models. He had a problem we at Mozilla were familiar with — difficulty in getting organizations to fund the development of the core. At Mozilla we have seen this repeatedly — many companies understand why it’s important for them to fund development of the particular aspects of Mozilla that specifically benefit their business. It was much harder to find companies that would fund the core development applicable to all users of Mozilla code.

Dr. Hipp was facing the same issue with SQLite. Many companies were willing — eager even — to enter into contracts to enhance SQLite to meet their needs. But few were funding the fundamental core of the offering. I was embarrassed to learn that Mozilla itself belonged to this group. We had entered a contract with Dr. Hipp some time before to do some work related to full-text indexing support. I knew about this of course but it never occurred to me to ask if the SQLite developers needed funding to maintain the core capabilities. (I should note that Richard didn’t raise this point with us; I asked directly and thus learned of my failing ). Fortunately the folks at Symbian were more perceptive. They had realized that providing stability and sustainability for long term development of the core of SQLite is important and were talking with Richard about how to do this. As a result Richard contacted Mozilla to see if any of our experiences could help him with his thinking.

Once I got over my embarrassment I spent some time talking to Richard to understand his goals for SQLite and to see how best Mozilla could support Richard and SQLite. Richard was clear about the main goals: keeping SQLite an independent project, and freely available for anyone to use. On behalf of Mozilla I expressed a strong interest in the current developers (Richard and his colleague Dan Kennedy) retaining technical direction over the SQLite project and in developing a sustainability model that does not diminish the effectiveness of the technical leadership. The Symbian folks agreed completely, and Symbian and Mozilla became charter members of the Consortium, which was launched on December 12, 2007. The Consortium is described in general terms on the SQLite website, and the form of Consortium Agreement is also available online.

The Consortium Agreement makes it clear that technical direction of SQLite remains solely in the hands of the developers. Consortium members receive access to the developers for support if desired. I noted that Mozilla would join without the support offering solely to provide support to the core developers to do what they think best (and I suspect the other early members might feel the same way). Dr. Hipp felt that it would be easier to attract additional members over time if the support component was retained. I don’t know that Mozilla will make use of this. But I hope that other organizations that use SQLite in their products will find this significant enough to help justify participating in the Consortium.

Joining the Consortium was an easy decision for Mozilla. We use the technology, it advances the Mozilla mission and — most importantly — the SQLite developers themselves are people who combine a fierce dedication to the openness and technical excellence of their work with discipline and structure. Like many great open source (here, public domain) and free software projects, the key developers have enormous commitment to their work. In my discussions with Richard I’ve come to understand that this commitment is combined with integrity, modesty, and an exceptional consistency of focus and quality.

It’s great to see the SQLite Consortium come to life. It’s great to see this grow out of Symbian’s very forward-looking thinking in supporting Dr. Hipp so early on; and great to see Adobe’s quick decision to join the Consortium. And I certainly hope that other companies who aren’t already supporting SQLite development will look closely at keeping SQLite independent and vibrant by becoming Consortium members.

Before long I’m going to try to take the comments to my last post about standards and weave the comments together. But first I want to respond to the comment worrying whether this discussion about standards reflects a change (or coming change) in Mozilla’s interest in web standards. The answer is no.

The goal of is the discussion is to think about whether we can improve the setting. It’s because this is so important that I want to focus on it.

For example, can we encourage more openness and transparency in the creation of web standards? We’ve proved that openness and transparency work well for code: they encourage discussions to focus on technical merit; they allow everyone who is interested to understand the details; they encourage participation. Why not do this with the creation of web standards?

Similarly, can we create a good means of input for both the “implementors” (in our case, the browser and other software vendors) and the web developers in the standards creation process? Browser makers and web developers are two sides of the same coin — both are needed to have a high quality, interoperable web. And each group can make life miserable for the other.

Are there ways we can improve communication between browser makers and web developers during the creation of a web standard? Not afterward, when the standard is done. Communication at that time makes web developers “consumers” of the standard, not participants in its development.

The earlier post and perhaps a few more are intended to develop a context for this sort of discussion and then action. We can jump into the discussion immediately, but it’s often useful to have shared vocabulary and framework.

I’ve been working on getting this post together for a while. Originally I had hoped to have more specific suggestions regarding mechanisms for interacting with other XUL developers. But the conversation about investing in the Mozilla platform is happening now, so I’ll start with this and we can think through specifics together.

Recently there’s been a fair amount of discussion about platforms for building “Rich Internet Applications.” Adobe’s Apollo demo and Microsoft’s Silverlight (WPF/E) effort generate significant attention. And Mozilla’s XUL offering is ever more widely used, in both relatively high profile projects like Joost and Songbird and in less well known but very interesting applications.

Here’s an outline of where the Mozilla Foundation plans to spend resources with regard to XUL and XULRunner. The plans below relate to the next 18 months or so as we develop an updated version of core Mozilla technology known as “Mozilla 2.” One of the goals of Mozilla 2 is to make it an easier technology to embed. We will revisit our XUL and XULRunner plans as Mozilla 2 comes to fruition.

Overview

• The Mozilla Foundation will continue to invest significant amounts in XULRunner and the Mozilla “platform.”
• The Foundations’ focus for XULRunner work for the next 18 months or so will be on browsing, Firefox and the Firefox ecosystem.
• In addition, the Foundation will work to increase communication with XUL developers — both general understanding and specific API requests — and drive relevant information into our overall planning process.
• Contributions that broaden XULRunner are more than welcome; these will be managed according to Module Ownership and other Mozilla policies.

Terms

• “XUL” (pronounced “zool”) stands for “XML based User Interface Language” and is the language in which Mozilla applications like Firefox, Thunderbird, Sunbird and the multitude of extensions are written.
• “XULRunner” is a packaging of the core Mozilla codebase including XUL, HTML, XML, CSS, Javascript and the rest of the Gecko rendering engine. In other words, XULRunner is the core runtime, including a set of libraries and APIs that provide basic functionality required by Web applications, but which does not include any actual user interface or “application” layer.
• “Pre-packaged” or “productized” or “stand-alone” XULRunner. These are terms that have been used to describe an instance of XULRunner that various applications would expect to find on a machine and would share once found. This would allow distribution of a thin “application layer” only, which would then take advantage of a stand-alone XULRunner already on the target machine.
• “Mozilla Foundation” as used here includes the Mozilla Corporation.

Mozilla Foundation Plans and the Role of Module Ownership

The Mozilla Foundation plans outlined below live within the content of Mozilla policies relating to Module Ownership, code review, source code commit access, etc. These policies state that individuals to whom authority has been delegated have responsibilities to the Mozilla project itself, unrelated to employment.

The policy on Module Ownership is particularly relevant to this discussion. Module owner responsibilities are outlined in the Module Owners Roles and Responsibilities document. I’ve excerpted a particularly relevant paragraph below:

Module owners are not tyrants. They are chartered to make decisions with input from the community and in the best interests of the community. Module owners are not required to write code because the community wants them to. (Like anyone else, the module owners may write code because they want to, because their employers want them to, because the community wants them to, or for some other reason.) Module owners do need to pay attention to patches submitted to that module. However “pay attention” does not mean agree to every patch. Some patches may not make sense for Mozilla; some may be poorly implemented. Module owners have the authority to decline a patch; this is a necessary part of the role. Mozilla.org asks the module owners to describe in the relevant bug their reasons for wanting changes to a patch, for declining it altogether, or for postponing review for some period. We don’t ask or expect them to rewrite patches to make them acceptable. Similarly, module owners may need to delay review of a promising patch due to an upcoming deadline. For example, a patch may be of interest, but not for the next milestone. In such a case it may make sense for the module owner to postpone review of a patch until after matters needed for a milestone have been finalized. Again, we expect this to be described in the relevant bug. And of course, it can’t go on very often or for very long without some review . . . .

It is an explicit expectation of the Mozilla Foundation that all its employees (whether employed by the Foundation directly, the Mozilla Corporation, or any other Mozilla entity) who are module owners or have other authority (super-review, etc.) exercise this authority as stated in relevant policy documents.

Mozilla Foundation Plans

1. XUL as language

The XUL language remains fundamentally important to Mozilla. The Mozilla Foundation will continue to invest in the development of the language. We will also continue to work towards standardizing key aspects of the language, such as the “flexibile box layout” which is in process with the W3C. Our focus with XUL language development will be what’s necessary for Firefox, but of course all Mozilla module owners have a responsibility to respond to contributions that address other products and broader needs. That responsibility is described above. Specific examples of how this works in practice have been the inclusion of thread-safety patches and graphics patches beyond Firefox requirements in order to meet the needs of the Songbird project.

2. XULRunner to Support Firefox and Browsing

XULRunner also remains fundamentally important, both for Firefox itself and for our efforts to keep the web itself competitive as a platform against closed / proprietary platforms. The Mozilla Foundation will continue to invest quite seriously in developing XULRunner. The primary focus of Mozilla employees will be developing XUlRunner as a robust platform for the open web as viewed via the browser. In other words, on developing XULRunner to meet the needs of the Firefox ecosystem. XULRunner improvements should benefit a range of other applications but the focus of Mozilla employees will be on browsing. This focus will remain for the next 18 months or so.

3. XULRunner to Support Other Applications

For the next 18 months or so the Mozilla Foundation plans a targeted investment here. (This is not a commitment to invest heavily here after 18 months, it is a statement of what we know today.) For the next 18 months or so, we plan to do the following in addition to work related to Firefox needs:

A. Develop a mechanism to:

• Improve two way communication with the XUL application developer community.
• Gather undocumented requirements, information about bugs and desires for new or improved APIs for XUlRunner.
• Help developers get these bugs, API and feature requests into the Mozilla development worldview. In more concrete terms, get this information turned into discussions in the appropriate Mozilla newsgroups, and /or turned into “bugs” in our bug tracking system.
• Monitor progress and response level of requests, prod developers when appropriate. For example, clearly understood bug fixes should be a good candidate for immediate check-in whether or not the bug affects Firefox or any other Mozilla Foundation application.
• Assist XUL developers to evaluate whether their work could / should be contributed back to the main development effort and if so, how to do so effectively.

B. Utilize this information in planning and implementation of ongoing platform development work, including Mozilla 2. Note that this does not mean all wishes are valid, or even if valid will be undertaken directly by the Mozilla Foundation. This is a focus on learning and evaluating requests, not on necessarily meeting everyone’s wish — lists. And of course, participation by XUL developers will help make things faster.

C. Make incremental improvements and accept contributions that module owners believe are understood, move XULRunner forward and don’t include undue risk.

D. Revisit these plans periodically (but not constantly) to see if changing circumstances should cause a change in plans.

4. Stand-Alone XULRunner.

The Mozilla Foundation does not plan to invest in a pre-packaged or stand-alone XULRunner at this time. We plan to re-evaluate this as we approach the release of Mozilla 2. Specifically this means we are not producing supported XULRunner builds and we do not plan to ship Firefox3 on top of a stand-alone XULRunner. (If someone contributed the patches to make this happen we would evaluate them, but anticipate the risk associated with such patches would almost preclude their incorporation into Firefox 3 unless they landed and tested well during the alpha release cycle.)

The rationale for this decision is that the primary advantage of packing XULRunner as a runtime is to allow for the download and distribution of small applications that can use a pre-installed copy of XULRunner. However, several problems prevent this from being a viable solution in practice:

• As we’ve seen with the JVM, CLR, and DLL settings it is often the case that applications will need to bind to a very specific version of the runtime. In this case the application may still require downloading its own XULRunner version.
• Many existing users of XULRunner are adding their own extensive customizations to the platform and thus could not use a standard build. We are eager for developers to contribute back generally useful customizations so that their work improves XULRunner for everyone. However, we anticipate some patches will be particular to a developer or class of developers. These may not be contributed back, may not desirable for a general distribution, or may involve enough risk that extensive testing and timing requirements will be necessary.

A stand-alone XULRunner is a potentially significant and disruptive amount of work and the practical benefits in the real work setting of the Web are difficult to assess given the versioning problems described above. The Foundation will focus its resources on problems where we’re more certain of the scope of positive impact.

I’ve been working on a statement about investment in the XUL platform. It’s been in the works for a while as I wanted to make sure of the facts. I’ll post it shortly. It wasn’t written specifically as a response but serves pretty nicely as a next step in the conversation that’s underway.

Before then I thought I’d describe informally my own personal views on the question of investment in the platform vs. the application.

The platform is critical. We invest an enormous amount in the platform technologies; probably more than in any other area. The platform technologies — known as XULRunner — are rich, flexible, and open like the web. They are what give Firefox its power. They also provide a powerful foundation for other applications, and we are seeing an increasing number of other applications built on XULRunner.

This is awesome. It provides an ever-increasing number of applications built on open source and shared technology, and increases the amount of the Internet accessible through open alternatives.

This raises the question: should Mozilla focus mostly on the platform as a general purpose platform? Should we drop our focus on “browsing” and focus instead on a platform for any and all web-enabled applications?

To me the answer is clearly “no.” Imagine a world without Firefox, or where we built platform technologies for Internet applications in general. Without the tens of millions of Firefox users, how would we keep web-based content open to multiple browsers? Without the testing of the platform provided by an application like Firefox, how would we achieve the necessary quality? Without an application like Firefox, how could the Mozilla participants satisfy the passion to touch human beings, to improve the Internet experience for actual people? Without touching people how could we build the communities of thousands — in some cases tens of thousands — of people who see and promote the Mozilla mission? How do we build and sustain a community sufficient to provide the technology itself?

It may be possible to find answers for any one of these questions. But touching human beings and helping individual people is a fundamental part of what many contributors do. Take that away and one takes away much of the vitality.

The Mozilla Foundation will continue building the Mozilla platform. And application developers who have high quality improvements to make are very welcome contributors. But the idea of the Mozilla Foundation de-emphasizing applications in order to transform ourselves into a general purpose “platform” organization — giving up the fundamental focus on the human being a application focus provides, reducing our ability to help individuals directly — seems an absolute non-starter to me.

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.