The Four Principles of (Open) Knowledge Development
[Further discussion and elucidation of the ideas in this piece can be found in the follow-up: What Do We Mean by Componentization (for Knowledge)?]
Open knowledge means porting much more of the open source stack than just the idea of open licensing. It is about porting many of the processes and tools that attach to the open development process — the process enabled by the use of an open approach to knowledge production and distribution.
The Four Principles
Open knowledge allows (and requires for its success) a development process that is:
- Decentralized (and asyncrhonous)
- Componentized (and ‘packagized’)
Incremental implies a process that allows for lots of gradual improvement and contribution. Like all of the the four principles this applies to the development of closed as well as open knowledge. However it operates more powerfully in an ‘open’ situation where the boundary between participants and non-participants is porous and it is easier for ‘just anyone’ to get involved.
Open knowledge allows for a decentralized (and asynchronous) development process. This greatly reduces rigidities and also allows for a far wider participation in a given project. At the same time it demands a more sophisticated set of development tools and processes.
Just like code, knowledge can be developed by a single individual but its real strength is that it can be developed collaboratively. The collaborative aspect of open knowledge is strongly related, and dependent upon, the the principles of decentralization and componentization.
This probably the most important feature of (open) knowledge development as well as the one which is, at present, least advanced. If you look at the way software has evolved it now highly componentized into packages/libraries. Doing this allows one to ‘divide and conquer’ the organizational and conceptual problems of highly complex systems. Even more importantly it allows for greatly increased levels of reuse.
The power and significance of componentization really comes home to one when using a package manager (e.g. apt-get for debian) on a modern operating system. A request to install a single given package can result in the automatic discovery and installation of all packages on which that one depends. The result may be a list of tens — or even hundreds — of packages in a graphic demonstration of the way in which computer programs have been broken down into interdependent components.
We are currently at a point where, with projects such as wikipedia, we have powerful examples of the first three principles in action but little or none on the fourth.
In the early days of software there was also little arms-length reuse because there was little packaging. Hardware was so expensive, and so limited, that it made sense for all software to be bespoke and little effort to be put into building libraries or packages. Only gradually did the modern complex, though still crude, system develop.
The same evolution can be expected for knowledge. At present knowledge development displays very little componentization but as the underlying pool of raw, ‘unpackaged’, information continues to increase there will be increasing emphasis on componentization and reuse it supports. (One can conceptualize this as a question of interface vs. the content. Currently 90% of effort goes into the content and 10% goes into the interface. With components this will change to 90% on the interface 10% on the content).
The change to a componentized architecture will be complex but, once achieved, will revolutionize the production and development of open knowledge. Along with the other three principles of incrementalism, decentralization, collaboration it will characterize the process of open knowledge development.