The Four Principles of (Open) Knowledge Development
May 9th, 2006
[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)?]
Introduction
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:
- Incremental
- Decentralized (and asyncrhonous)
- Collaborative
- Componentized (and ‘packagized’)
Incremental
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.
Decentralized
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.
Collaborative
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.
Componentized
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.
Conclusion
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.
Related posts:
- What Do We Mean by Componentization (for Knowledge)? Background Nearly a year ago I wrote a
- Speaking at Oxford Geek Night on Open Knowledge and Componentization Tomorrow I’ll be speaking with Nat
- Appropedia: open knowledge for sustainability and development Appropedia is a wiki for sharing knowl
- Open Data Going Mainstream? Bret Taylor’s recent post entitled
- New mailing list for open knowledge in development We’ve just launched a new mailing
Related posts brought to you by Yet Another Related Posts Plugin.
October 9th, 2006 at 8:25 am
[...] Demonstration of componentization — see http://blog.okfn.org/2006/05/09/the-four-principles-of-open-knowledge-development/ [...]
November 24th, 2006 at 2:54 am
[...] OPEN : access, content, data, Knowledge [...]
April 30th, 2007 at 11:27 am
[...] Nearly a year ago I wrote a short essay entitled The Four Principles of (Open) Knowledge Development in which I proposed that the four key features features of a successful (open) knowledge development process were that it was: [...]
August 18th, 2008 at 6:56 pm
[...] This breaking down into smaller, reusable chunks is something we at the Open Knowledge Foundation refer to as “componentization.” You can break down projects, whether they are data sets or software programs, into pieces of a manageable size — after all, the human brain can only handle so much data — and do it in a way that makes it easier to put the pieces back together again. You might call this the Humpty Dumpty principle. And splitting things up means people can work independently on different pieces of a project, while others can work on putting the pieces back together — that’s where “many minds” come in. [...]
August 1st, 2009 at 12:58 am
[...] gave an overview of the Open Knowledge Foundation - in particular focusing on four principles for developing open knowledge and knowledge componentization, as well as CKAN and KnowledgeForge and the Open Knowledge [...]