Mission Statement

To give sense of direction to an open source project, it's good to have a mission statement.

The Mission Statement

The aim of The Good Suite is to provide a richly featured framework that provides tools to minimize the effort required to create a (secure) website, to decouple the application from the underlying technologies and to make the different parts or aspects of the website loosely coupled. The Good Suite aims to promote proper design and fully cater both to more traditional websites and to web applications, while keeping a special focus on both modularity and universal usability.

Notes

Because the mission statement is rather dense in meaning, there is a number of notes that help with its interpretation. All in all it is a rather long read, but worth it in the sense that it creates a clear direction for the project.

• The mention of being richly featured means that the framework aims to simplify as many tasks that are shared by many websites as possible as well as to provide easy access to features that are less commonly used but are complicated to use or require a lot of code without using the framework. These latter features should generally be not too uncommonly used or possibly hindered mostly by the fact that they are this complicated or require that much code.
• When talking about minimizing the effort, creating a (secure) website is mentioned. This means both that the effort to create a website should be minimized and that making that website secure should also be minimized.
• Minimizing the effort is first and the foremost about making it possible to write code while expending less effort on things other than the content and special features of the website or web application. An example of this is abstracting the writing of SQL queries, which possibly leads to more code, but makes the code easier to write.
• Though it takes a backseat to how much thought needs to be put into the code, reducing the amount of code required is a secondary aim.
• One way the framework decouples the application from the underlying technologies is to provide a layer of abstraction between the required functionality and the underlying technology, so that swapping the layer for a different one changes which technology is used without any (further) change to the code.
• Another way to decouple the application from the used technology is to have the framework provide functionality based on the task a user wants to accomplish while the framework chooses the best available technology. This strategy may be a good approach when the task adds semantics to the particular use of the technology, when users have little reason to change which underlying technology is used, when it is clear which technology is best and the availability is the main decision point and/or when users are known to not always make a good choice when tasked with choosing a technology themselves.
• Promoting proper design involves but is not limited to neatly sticking to the specifications (eg. providing a domain name when changing the location header), using the best technology available (eg. using proper hashing for passwords, with a separate salt for each password) and not providing functionality that the web is and never was meant for (eg. trying to force cookies through methods like flash cookies).
• Traditional websites and web applications are mentioned separately. This is because the more traditional website has different requirements than a site designed to function as an application inside your browser. The latter often has only a single page, usually is heavy on the javascript, tends to use ajax a lot and generally is about instant interaction with either your computer or other humans. The aim of The Good Suite is to provide shared functionality as well as functionality specifically for both types of websites. Any mention of the word website outside of the original mention of those two types and this explanation should be taken to mean both traditional websites and web applications.
• Modularity is achieved through a system of modules which can be installed individually. The aim is to decouple the usage of the modules wherever possible, so that users can cherry pick the features they want to use. However, modules may freely use other modules internally wherever that does not require the users to do the same.
• Universal usability refers to making sure that users are able to use the framework in almost any setup. This is achieved by choosing widely supported languages and not relying on certain extensions or functionality to be present when possible. When such extensions or functionality are required it should be limited to a single module. Furthermore, providing alternatives for when certain functionality is unavailable can also be used as a way to increase the usability.
• From time to time certain functionality might be lost to other aims. Examples would be losing SQL features because it is abstracted in a way that's broader than SQL and losing some flexibility when using the framework's method to change the session storage system compared to defining your own session handler. This is a direct result of the other aims of the framework. It should be avoided when possible without compromising the other aims. However, it is an acceptable side-effect because the framework can be used alongside normal PHP, which means that if the provided functionality isn't enough for the user, he can use normal PHP to supplement what we provide.
• It should be noted that no language is mentioned the mission statement. One of the reasons for this is that multiple languages will be involved, such as PHP, javascript, html and css. Another reason is that the framework isn't limited to a single language. PHP is chosen server side because it is an industry standard and thus nicely fits in with the aim to be universally usable. It is not completely unthinkable that the framework will one day (also) target another language entirely. Much more likely would be a version of the framework that is a PHP extension, which allows it to run much faster for those who can install it, while the same interface will be available to those who can't through the php version. This too is not an aim for the near future at all.
• It should also be noted that there is no mention of speed or performance. Being a framework it is still a requirement and drives design quite a bit. General guidelines on this issue are that no complexity should be added unless it is needed to provide extra functionality. When it adds extra functionality, it still shouldn't add complexity when the usage is typical. Optimizations reducing the overhead of using a framework that can be done opaquely to the user should be done, though if the gain isn't too big or the required effort is big, it should have quite a low priority. Additionally, compiling to php can be done to make sure a big performance hit is only done once instead of upon each request. Also, the modularity of the system should be optimally used for performance, meaning that files shouldn't be included unless used.