[okfn-discuss] The Four Principles of (Open) Knowledge Development (v0.1)

Sun May 21 09:33:12 UTC 2006

On Mon, May 08, 2006 at 02:06:26PM +0100, Rufus Pollock wrote:
> I've been talking for a while about the 'other' aspects of open 
> knowledge -- i.e. those other than licensing and here's a first stab at 
> getting my thoughts down on paper. Comments/critiques/additions 
> *greatly* appreciated.

hi Rufus,

Sorry it's taken me such a long time to get back to you on this. I
really appreciated getting this text and having a think about it but
have been buried in other things.. 

My feeling after last year's events - WSFII.org and other activities more
geared to pushing ideas of 'open knowledge' outside of the software world
was that each domain has an extremely specific relationship to the
knowledge exchanged through it - and are built on highly specific and
historically layered infrastructures for that exchange that necessitate a
case-by-case analysis.

That's why I found the 'freedomdefined' project interesting but
problematic - (http://freedomdefined.org/) - because although I can see
the value of a discussion about 'definition', and appreciate the
wiki-nature of the definition process, I'm really not sure how useful a
definition is. Principles seem more useful. Laws rather than rules..

Anyway, find my comments inline, I hope the detail is useful. I'm
assuming this is for public (general) consumption - so my comments are
adjusted accordingly.

> The Four Principles of (Open) Knowledge Development
> ***************************************************
> 
> 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.

Why use the word 'porting' and 'stack' If the aim is to apply these ideas
outside of the software domain? I think translation into something more
vernacular would be useful. I also think the 'open development process'
in this sentence seems defined tautologically - I've tried to make a
more specific version:

----------------------------------------------------------------
Open Knowledge means much more than transposing legal frameworks from the
world of Free Software into other areas of culture. It means creating an
open development process for each domain by analysing, adapting and
reinventing many of the processes and tools that underpin the tremendous
success of Free Software.
----------------------------------------------------------------

> The Four Principles
> ===================
> 
> Open knowledge allows (and requires for its success) a development 
> process that is:
>   1. incremental
>   2. decentralized (and asyncrhonous)
>   3. collaborative
>   4. componentized (and 'packagized')

Why the brackets? They seem weird. Also, I spy a typo on asynchronous.
I'd get rid of asynchronous - it can be assumed that by decentralized we
also mean unbound by the production level control of one
body/group/person, which implies asynchronous development.

> 
> 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 significane of componentization really comes home to one 
> when using a package manager (e.g. apt-get for debian) on a modern os. 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.

I think these are very good and clear, the only worry I would have is
that many people have no idea what a package manager is, and perhaps
there are examples of componentized knowledge that are more widely
understood. However, I do see the very real value of the apt-get example
because it is so amazingly well done (apt-get install anarchism!).
Perhaps another example to go alongside it - or another section called
'examples'. This section could look something like this:
----------------------------------------------------------------
Examples
--------

Debian's package manager: apt-get:

Package managers such as APT amply demonstrate the power and significance
of open knowledge principles, especially componentization.  A request to
install a single software 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, automatically
downloaded from servers all over the Internet, then automatically
security checked, installed and updated. For more information see:
http://www.debian.org/doc/manuals/apt-howto/

Bibliographical reference:

Academic writing has always relied on bibliography as a way of packaging
knowledge: each writer attributes sources for their ideas and writings
with standard rules. National copyright libraries such as The British
Library, The Bodleian Library, and Cambridge University Library attempt
to act as universal repositories, allowing access to the dependency chain
of citations. However, the slow pace and formalised processes of academic
knowledge production can be obstacles to it's openness.
----------------------------------------------------------------

> Conclusion
> ==========
> 
> We are currently at a point where, with project such as wikipedia, we 
> have powerful examples of the first three principles in action but 
> little or none on the 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.
> 

I'm not sure about the Content / Interface bit. Pseudo-statistics are
not very helpful argument props imho. I'd just lose that second half of
'The same evolution' paragraph - it's stronger on its own.

Bringing in the academic knowledge packaging example would, I think,
round out the argument somewhat. It's important to see how these systems
have developed in the past, and how they are no longer sufficient.
Perhaps adding something like:

------------------------------------------------------------------------
With the pace and media diversity of information produced and distributed
via the Net, academic models of knowledge production - which most closely
resemble 'open knowledge' struggle and fail to keep up.
------------------------------------------------------------------------

Would help bring in that angle.

Again, well done Rufus for taking the time to expand on these thoughts.

I look forward to the wiki version! Perhaps a join okfn contribution to
the freedomdefined project would be a useful contribution to that
package :)

Cheers,

Saul.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.okfn.org/pipermail/okfn-discuss/attachments/20060521/3cb5924e/attachment.sig>