The name of this project is used to focus attention on source of problem before proposing a solution. The big-O notation is widely used as measure of software complexity in terms of required computing resources (memory and cycles). At the most basic level - writing software always involves reduction of quadratic complexity as close to linear as possible. However, the problem of reducing algorithmic complexity is only an example of general "O(n2) problem".
General "O(n2) problem" is simple to explain using search engine software as an example: if each page on the Web needs to be related to another page, in order to discover possible relevance (however small it may be), then it will require calculating n*(n-1) relations, where n is total number of pages. The simple (but not perfect) solution is an index, representing each page by set of keys so that all other pages represented by the same key are automatically related. Since the number of keys is much smaller than the number of pages - the problem is reduced to kn, where k is proportional to the number of keys.
However, the "O(n2) problem" would not go away easily. Set of keys in the example of Web search needs to be constantly updated as pages change, and the number of keys can not be large. Therefore, the entire content of the Web would have to be approximated by a limited number of keys. And even though there are many better ways to approximate the Web content (such as ranking pages and employing sophisticated heuristics to improve precision of search algorithms), - it is simply not enough to keep up with changing content.
Another good example of "O(n2) problem" in software development comes from distributed computing - when multiplicity of different software agents has to communicate with each other over network. In this case every message has to be translated between each pair of agents, with n*(n-1) translations required to keep all agents "on the same page". There is also a good solution if the number of agents kept fixed or limited -"Hub and Spoke" toplogy. And again the problem would not go away easily.
Finally, there is a problem of maintaining "truth" - as required, for example, to support multiple commitments between parties in all unforeseeable events. Each new event could have implications that would require re-evaluating each commitment with respect to the event and all other commitments, taking O(n2) revisions in case of n commitments.
It can be argued that the only thing in common between the examples above - is merely a mathematical expression, and that there is no such thing as "O(n2) problem" - instead there are many separate problems. There is, however, one common approach to solving these problems. It is based on understanding of "combinatorial explosion" as a phenomenon that is characterized by its large spatial extension, much like explosion in a physical space. The extension of logical statement consists of all situations or 'states' that it covers.
Software application developers usually avoid complete enumeration of all possibilities. They do it by focusing on a much smaller extension (a.k.a. 'use cases') and treating all other situations as exceptions, thus hiding a large stretch of the state-space behind it. "O(n2) problem" arises when the original point of view is later shifted as application evolves - exposing "hidden dimension". Conceptually the problem can be avoided if extension is not "frozen" but instead is "projected" via some spatial transformation that includes given point of view, or in logical terms - intension.
"O(n2) Space" is a conceptual modeling and development framework that allows a two-way mapping between given application intension and extension by means of meta-modeling. To that end "O(n2) Space" defines container architecture that automatically translates models between data (extension) and program (intension). Each container performs as a kind of spatial "projector" that reflects component's extension as a proper image of its intension.
For example, in database applications the intensional information, present in a form of data integrity constraints, can be mapped to its use cases by "O(n2) Space" container. A prototype tool developed at Next Generation Software, "OntoBase" demonstrates how it is possible to define and maintain a single set of constraints for both: data and programs.
