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

[Rufus Pollock]

Saul Albert wrote:
> 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.. 

No problem. Thanks for taking the time to give such detailed feedback.

> 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.

I would agree with you about the specificity while pointing out that 
this can still allow a lot of commonality (e.g. of tools) in certain 
areas. All kinds of different projects use websites, wikis, databases 
etc though adapted to their needs.

> 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..

Interesting. So what is your perspective on the open knowledge definition:

   http://www.okfn.org/okd/

I entirely agree that guideliness/principles are better than some strict 
legalistic thing but in this context 'definition' really just comes down 
to this and we do need something reasonably clear otherwise it can be 
stretched until meaningless.

> 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.
> ----------------------------------------------------------------

All your criticisms are spot-on and I think this is a great improvement.

> 
>>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.

Good point: let's dump the items in brackets.

[snip]

>>
>>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:

Good idea again. I wonder if we can think of any more examples other 
than the 2 we now have (apt and bibliographies). This also prompts me to 
bring up the idea of doing a simple 'hello-world' type knowledge package 
-- more of which in a seperate post.

[snip: saul's 2 examples]

[snip]

>>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.

Agreed.

> 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.
> ------------------------------------------------------------------------

Although academic models have rarely produced componentized knowledge 
(unless we count papers we are only reused in the sense of being 
combined together in collections of papers).

> Would help bring in that angle.
> 
> Again, well done Rufus for taking the time to expand on these thoughts.

Thanks and thanks for all this feedback.

> I look forward to the wiki version! Perhaps a join okfn contribution to

I've put up a page here:

   http://www.okfn.org/wiki/Four_Principles

with my original version. Next thing is to fold in your changes ...

> the freedomdefined project would be a useful contribution to that
> package :)

Good idea. I've already been in contact with the freedomdefined project 
(Erik Moll, Benjamin Mako Hill etc) and been contributing to the wiki. 
As I said above we took a stab at the issue back in Sept/Oct last year 
with the OKF: http://www.okfn.org/okd/ but I don't think it was 
publicized much.

Regards,

Rufus