Mozilla

Posts Tagged with “technology”

Firefox Summit Reflections

August 26th, 2008

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.

The SQLite Consortium

February 27th, 2008

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.

Importance of Standards

January 17th, 2008

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.

XUL and XULRunner investment

May 13th, 2007

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.

Application vs. Platform Focus

May 11th, 2007

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.

Skip past the sidebar