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.
Nice. You may also want to mention accessibility, public advocacy (i.e. to web devs) and a high degree of visual polish (e.g. anti- aliasing), though the latter may come under "platform-native HI conventions". You may also consider sorting them into priority groups or an ordered list. I recall when Safari was announced Performance was give as the number one goal and Usability coming lower down (which is why WebKit has no kerning, for example). Explaining this would help newcomers understand some of the prior design decisions. I suspect Security is the current topmost priority. Non-prioritised "goals" such as Open Source should probably come under "Non-Goals", and the current list thereunder be retitled "What WebKit Is Not" The bit I like least about WebKit was mentioned in your post:
sometimes even at the expense of standards
I'd rather websites were fixed instead of browsers adding workarounds, but it seems I'm in a minority there. Many others seem happy to allow and perpetuate cruft. :-( - Nicholas.
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 webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
On Jul 24, 2007, at 5:05 PM, Darin Adler wrote:
On Jul 24, 2007, at 5: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?
I think you should!
All right, done. I made a few changes as suggested by others: On Jul 24, 2007, at 11:27 PM, Benjamin Hawkes-Lewis wrote:
Would it not be worth making an explicit goal of accessibility, or at least explicitly bracketing it under usability?
I added mention of accessibility to the usability goal. On Jul 25, 2007, at 4:34 AM, David Carson wrote:
Maciej, A couple of comments: Maybe in relation to the your licensing email, the LGPL statements should be updated.
I made it specifically mention LGPL 2.1+.
Is there a tool or tests that can be used to ensure that Performance doesn't regress?
We use a number of benchmarks internally at Apple, sadly most of them depend on things that are not freely redistributable. There are however some publicly available JavaScript and DOM benchmarks.
With 'Hackability', maybe add something about automated tests help ensure rapid progress.
I added mention of automated regression tests. On Jul 25, 2007, at 10:35 AM, Adam Roben wrote:
Here's a possible additional goal:
Community - We strive to create a courteous, welcoming environment that feels approachable to newcomers. WebKit maintains a public IRC chat room and public mailing list where the ideas of contributors both new and old are heard and discussed with equal weight.
I added this to the "Open Source" goal, because I think it's a key part of being a real open source project.
On 26-Jul-07, at 03:09 , Maciej Stachowiak wrote:
Is there a tool or tests that can be used to ensure that Performance doesn't regress?
We use a number of benchmarks internally at Apple, sadly most of them depend on things that are not freely redistributable. There are however some publicly available JavaScript and DOM benchmarks.
Are there any publicly available tools that we could use instead? I believe it would be of benefit to everyone if we were on the same page with the way we approaching testing. At the very least even if Apple uses a separate test process internally, it would be good if there were some universally available testing process that was part of the WebKit project. Andre
On Jul 26, 2007, at 10:42 AM, Andre-John Mas wrote:
Are there any publicly available tools that we could use instead? I believe it would be of benefit to everyone if we were on the same page with the way we approaching testing. At the very least even if Apple uses a separate test process internally, it would be good if there were some universally available testing process that was part of the WebKit project.
I agree. That would be great. We've had a hard time finding tools like what you describe, though. Any specific ideas? Can you do something to help with this? -- Darin
On 26-Jul-07, at 14:00 , Darin Adler wrote:
On Jul 26, 2007, at 10:42 AM, Andre-John Mas wrote:
Are there any publicly available tools that we could use instead? I believe it would be of benefit to everyone if we were on the same page with the way we approaching testing. At the very least even if Apple uses a separate test process internally, it would be good if there were some universally available testing process that was part of the WebKit project.
I agree. That would be great.
We've had a hard time finding tools like what you describe, though.
Any specific ideas? Can you do something to help with this?
What should the requirements for the tool be, other than being freely available? Andre
On Jul 26, 2007, at 11:13 AM, Andre-John Mas wrote:
What should the requirements for the tool be, other than being freely available?
I'm not sure these are requirements, but here are some of the things I'd like to see: - representative of real world performance - one way to make it a real-world test is to use content from real-world websites, but that's the rub because the copyright owner may not give us license to use it as we wish - easy to run in an automated fashion so we can post results on the buildbots - easy to run with performance analysis tools - possible to run in non-WebKit browsers too - no "axe to grind" -- this wouldn't be a test specifically designed to highlight a particular performance problem - doesn't change a lot over time -- it's hard to judge changes in performance of the engine if the test is changing too There are other more subtle requirements. If we have too many different performance tests, they are no good because we can't run them all. If benchmarks are created by unaffiliated third parties, they are even more valuable because people won't assume they are "slanted". -- Darin
Do the tests need anything special in them, or do standard HTML/JavaScript pages unadorned work? We have a fairly large library of HTML/JavaScript pages that can be donated to the cause at work here, mostly based on real world websites for internal testing of our rich media products. I can probably get permission to release them under an open source license from my manager (it might take up to 2 weeks thanks to the lawyer, but its possible) On 7/26/07, Darin Adler <darin@apple.com> wrote:
On Jul 26, 2007, at 11:13 AM, Andre-John Mas wrote:
What should the requirements for the tool be, other than being freely available?
I'm not sure these are requirements, but here are some of the things I'd like to see:
- representative of real world performance - one way to make it a real-world test is to use content from real-world websites, but that's the rub because the copyright owner may not give us license to use it as we wish
- easy to run in an automated fashion so we can post results on the buildbots - easy to run with performance analysis tools
- possible to run in non-WebKit browsers too
- no "axe to grind" -- this wouldn't be a test specifically designed to highlight a particular performance problem
- doesn't change a lot over time -- it's hard to judge changes in performance of the engine if the test is changing too
There are other more subtle requirements. If we have too many different performance tests, they are no good because we can't run them all. If benchmarks are created by unaffiliated third parties, they are even more valuable because people won't assume they are "slanted".
-- Darin
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Would it not be worth making an explicit goal of accessibility, or at least explicitly bracketing it under usability? -- Benjamin Hawkes-Lewis On 7/25/07, Maciej Stachowiak <mjs@apple.com> 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 webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
On Wednesday 25 July 2007, Maciej Stachowiak wrote:
I sent this a while ago with not much comment. Any thoughts? Should I post this on webkit.org somewhere?
I like both the goals and non-goals. Please put it onto webkit.org. Cheers, Lars
- 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 webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
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 webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Here's a possible additional goal: Community - We strive to create a courteous, welcoming environment that feels approachable to newcomers. WebKit maintains a public IRC chat room and public mailing list where the ideas of contributors both new and old are heard and discussed with equal weight. -Adam 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 webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
participants (9)
-
Adam Roben
-
Andre-John Mas
-
Benjamin Hawkes-Lewis
-
Darin Adler
-
David Carson
-
Justin Haygood
-
Lars Knoll
-
Maciej Stachowiak
-
Nicholas Shanks