Slashdot Mirror
Open Source Code Maintainability Analyzed
gManZboy writes "Four computer scientists have done a formal analysis of five Open Source software projects to determine how being "Open Source" contributes to or inhibits source code maintainability. While they admit further research is needed, they conclude that open source is no magic bullet on this particular issue, and argue that Open Source software development should strive for even greater code maintainability." From the article: "The disadvantages of OSS development include absence of complete documentation or technical support. Moreover, there is strong evidence that projects with clear and widely accepted specifications, such as operating systems and system applications, are well suited for the OSS development model. However, it is still questionable whether systems like ERP could be developed successfully as OSS projects. "
This might sound too removed from the "real world" but as you will see very soon, I will give a perspective that is more practical than what I will assume to be a procedure used in a lot of development groups.
Every function must have an expectation specification that defines what the mapping of the said function is. The expectation specification must also define the domain of the function as well as the co-domain. Whatever variables that unchanged, up to an isomorphism, by the mapping can be excluded from both the domain and co-domain.
The expectation specification defines a Platonic object that is given an element from the domain and maps it to an element in the co-domain. The two important points here are that the specification is definite and that it is Platonic.
We never ever destroy an expectation specification. This point can not be stressed enough. An expectation specification defines everything about a function. If one were to destroy an expectation specification, then the associated function must never be reused. Therefore, one must never destroy an expectation specification.
We will now discuss the practical formulation of an expectation specification of a function. Each function accepts a subset of the entire system state and maps it to a new subset of the system state. One can give any isomorphism of an element of the domain. The isomorphism and the function makes the general form of the function become g^{-1} (f(g(x)). Here, f is the function and g is an isomorphism. Note that we have never mentioned how we should represent the mapping, domain, or co-domain or elements of the latter two.
One can assume that the result of the mapping will replace the element from the domain in most practical computer installations.
We have established that a function is defined by an expectation specification that is Platonic. This Platonic object is what developers will strive to emulate in any implementation of a function. Notice now that we have invoked the concept of an implementation. An implementation must never take precedence over the specification in the minds of developers. One function can have many implementations. Furthermore, a function can exist as an expectation specification with the specification represented somehow. Note, however, that an implementation is almost meaningless without a specification.
In conclusion, the specification is the function. A function may adopt various implementations for any number of reasons. The important point is that when one develops a function, it must endure. It might be used or kept somewhere, but a function must never be destroyed or changed.
With regards to the beginning statement, one must never omit the Platonic function. A very common mistake made by a lot of developers is the destruction of specifications. While their intentions might be benign, even a slightest change in a function must always lead to a branch into a new function. One can call the new function anything in the implementation language, and in a lot of situations, it is recommended. However the specification must always endure. The strict adoption of the approach where one develops an expectation specification, forbids any destruction of a function, and develops implementations based on the expectation specification, is crucial to the development of any project.