Maciej,
A couple of comments:
Maybe in relation to the your licensing email, the LGPL statements
should be updated.
Is there a tool or tests that can be used to ensure that Performance
doesn't regress?
With 'Hackability', maybe add something about automated tests help
ensure rapid progress.
Please post on webkit.org
On Jul 24, 2007, at 8:04 PM, Maciej Stachowiak wrote:
I sent this a while ago with not much comment. Any thoughts? Should
I post this on webkit.org somewhere?
- Maciej
On May 10, 2007, at 3:34 PM, Maciej Stachowiak wrote:
Hi Everyone,
I recently watched a video on the topic of preventing poisonous
people from hurting an open source project. One of the practices
it recommends for a large open source project is to have a
"mission statement", so it's clear to everyone what is and isn't
in scope for the project. I'm not too fond of the name "mission
statement" (it sounds a little corporate) but I do think it's
important to write down our goals as a project.
Ultimately I'd like to put this on the WebKit site, but I wanted
to throw out some ideas for discussion. I'd like to hear if anyone
thinks I have missed any project goals, if any of these are worded
badly, or if it is worth calling out more non-goals.
WebKit Project Goals
WebKit is an open source Web content engine for browsers and other
applications. We value real-world web compatibility, standards
compliance, stability, performance, security, portability,
usability and relative ease of understanding and modifying the
code (hackability).
Web Content Engine - The project's primary focus is content
deployed on the World Wide Web, using standards-based technologies
such as HTML, CSS, JavaScript and the DOM. However, we also want
to make it possible to embed WebKit in other applications, and to
use it as a general-purpose display and interaction engine.
Open Source - WebKit should remain freely usable for both open
source and proprietary applications. To that end, we use BSD-style
and LGPL licenses.
Compatibility - For users browsing the web, compatibility with
their existing sites is essential. We strive to maintain and
improve compatibility with existing web content, sometimes even at
the expense of standards. We use regression testing to maintain
our compatibility gains.
Standards Compliance - WebKit aims for compliance with relevant
web standards, and support for new standards
In addition to improving compliance, we participate in the web
standards community to bring new technologies into standards, and
to make sure new standards are pratical to implement in our
engine. We use regression testing to maintain our standards
compliance gains.
Stability - The main WebKit code base should always maintain a
high degree of stability. This means that crashes, hangs and
regressions should be dealt with promptly, rather than letting
them pile up.
Performance - Maintaining and improving speed and memory use is an
important goal. We never consider performance "good enough", but
strive to constantly improve. As web content becomes richer and
more complex, and as web browsers run on more limited devices,
performance gains continue to have value even if normal browsing
seems fast enough.
Security - Protecting users from security violations is critical.
We fix security issues promptly to protect users and maintain
their trust.
Portability - The WebKit project seeks to address a variety of
needs. We want to make it reasonable to port WebKit to a variety
of desktop, mobile, embedded and other platforms. We will provide
the infrastructure to do this with tight platform integration,
reusing native platform services where appropriate and providing
friendly embedding APIs.
Usability - To the extent that WebKit features affect the user
experience, we want them to work in accordance with good human
interface design principles, and to mesh well with platform-native
HI conventions.
Hackability - To make rapid progress possible, we try to keep the
code relatively easy to understand, even though web technologies
are often complex. We try to use straightforward algorithms and
data structures when possible, we try to write clear, maintainable
code, and we continue to improve names and code structure to aid
understanding. When tricky "rocket science" code is truly needed
to solve some problem, we try to keep it bottled up behind clean
interfaces.
Non-Goals
WebKit is an engine, not a browser. We do not plan to develop or
host a full-featured web browser based on WebKit. Others are
welcome to do so, of course.
WebKit is an engineering project not a science project. For new
features to be adopted into WebKit, we strongly prefer for the
technology or at least the use case for it to be proven.
WebKit is not a bundle of maximally general and reusable code - we
build some general-purpose parts, but only to the degree needed to
be a good web content engine.
WebKit is not the solution to every problem. We focus on web
content, not complete solutions to every imaginable technology need.
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo/webkit-dev
