Chris Anderson, who is mentioned in my previous post on Everyblock, has penned a very thoughtful blog post The Nuances of the Everyblock Sale to MSNBC. He sums up the debate so far and raises some interesting new points. It provides a great summary of some basic legal points in conversation with the particular case.
His conclusion included below:
I’d like to see all future versions of code devloped under the Knight grant remain open, whoever buys them. I think this is an ethical use of Knight grant money — and a good business strategy as well.
ps– a number of folks have told me that “grassroots” is def not the way they would describe Everyblock, even among those who think it is a pretty neat project.
update: (linked fixed) Here is another exxxceelllent blog entry about code. community, and foundations by John Eckman’s who finishes with this important insight:
Put differently, communities are great at creating (and maintaining, supporting, extending) code: code is not great at creating communities.
[...] In Detail: The Nuances of the Everyblock Sale to MSNBC [...]
Pingback by The Knight Foundation News Challenge, Open Source, and the Future of Hyperlocal | Open Parenthesis — August 18, 2009 @ 2:21 pm
The link to the second post is broken.
Comment by James — August 18, 2009 @ 11:19 pm
Put differently, communities are great at creating (and maintaining, supporting, extending) code: code is not great at creating communities.
I don’t see that this an important insight. Firstly it essentializes ‘community’ – what type of community? how is it formed? how does it change? what is the structure? When was it founded? etc.
And, of course, it essentializes ‘code’ – who wrote it? what language? when was it written? what agency does it have (was it delegated)? etc.
In any case to describe such a binary between community/code is problematic, I think it is much more helpful to think about code-community as an assemblage, especially when thinking about software/code as the community could not function without the code (both source, but also version control systems, web infrastructure, os, etc.) to support it in the first place. Code is therefore, in Serres’ terms a ‘quasi-object’ in that it is a socio-technical agencement (Deleuze). This means that we should be cautious of modernist attempts to strictly delimitate entities in this essential way and look for the ways in which the agency of the community AND code are mutually reinforcing (or not) in particular code-community projects.
Comment by David Berry — August 19, 2009 @ 2:49 am
David,
In the context of his post it makes a lot of sense (albeit my link did not work, it does now). You just can’t throw code out there and bang expect the type of social norms and practices to develop around them that sustain a thriving open source project.
Sure if you are writing a whole book on Code, your comments fly fine. In the context of his post, it is a great insight. Context also matters for writing words, not just code
Comment by Biella — August 19, 2009 @ 3:04 am
Hi Biella,
But neither can you expect the opposite, that is that a great community will produce a wonderful thriving open-source project. My point is that it is the interplay between the community and the code, that is the respective agencies of community AND code that are required (and a whole bunch of other actors too, of course). Code does not write itself, clearly, but neither does community. The social norms and practices that are materialised in open source projects are within the code that they are working on, not just as pictures in people’s heads.
So it is important to highlight the importance of abandoning all a priori distinctions between code and the community. That is that we should reject the hypothesis of a definite boundary which separates the two and see the way in which they are mutually constructed (i.e. as an assemblage). This is where copyleft licenses and other entities enter into our analysis, of course, but to assume an asymmetric priority to the community seems to me to be idealistic (not to mention not borne out in any critical analysis).
In any case, even if code were ‘thrown out’ into the world (a useful Heideggerian analogy) it would still be thrown into a world of pre-existing meaning, that is existing open source project, source code libraries, users, hackers, netbooks etc. The social practices and norms, in other words, predate the project and are changed in the process of further developing it. Nowhere was there a pure community, nor pure code that came together – even where a project grows out of the community (lets use ‘created’ very carefully) it will still use pre-existing code (GNU/Emacs/Libraries) and #includes that make it more of a vast jigsaw of interrelated (interdiscursive) code fragments knitted together. But crucially, when pulling in these pieces (together with others such as the GNU GPL) the community is importing materialised norms which are difficult to ascribe to the agency of the community alone. Hence the importance of the notion of assemblage, and the idea that mapping social practices and norms has to move beyond the reliance on ‘intentionality’ of the human actors..
Best
David
Comment by David Berry — August 19, 2009 @ 3:36 am
David – I’d certainly agree that, as you put it:
My attempt to be epigrammatic obscures some of the detail. In order to arrive at a functioning open source project you certainly need both people and code, and the complex interplay between them.
I’m tempted to say that a real community without a single line of code is more likely to ultimately result in success that a significant volume of code without even a small community interested in working on/with it – but maybe that too reinforces the binary distinction between “code” as a monolithic, inert construct and “community” as an equally monolithic dynamic construct.
(What’s the old quip about love and money? A marriage based on love without money will survive hard times better than one based on money without love?)
Comment by John Eckman — August 19, 2009 @ 8:16 am