<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#ffffff">
    Le 12/11/2011 19:10, Tom Chance a écrit :
    <blockquote
cite="mid:CACD80NQBMUrqNFQYdJ1RdEaA3JjRwLu+vpLL21hWbPqJeS-15w@mail.gmail.com"
      type="cite">
      <div class="gmail_quote">On 12 November 2011 15:35, Serge
        Wroclawski <span dir="ltr"><<a moz-do-not-send="true"
            href="mailto:serge@wroclawski.org">serge@wroclawski.org</a>></span>
        wrote:<br>
        <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
          0.8ex; border-left: 1px solid rgb(204, 204, 204);
          padding-left: 1ex;">
          <div id=":tz"></div>
        </blockquote>
      </div>
    </blockquote>
    [...]<br>
    <blockquote
cite="mid:CACD80NQBMUrqNFQYdJ1RdEaA3JjRwLu+vpLL21hWbPqJeS-15w@mail.gmail.com"
      type="cite">
      <div class="gmail_quote">
        <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
          0.8ex; border-left: 1px solid rgb(204, 204, 204);
          padding-left: 1ex;">
          <div id=":tz">we should<br>
            explore exactly what we want OSMF doing.</div>
        </blockquote>
      </div>
      <br>
      <br>
      <div>I completely agree with Serge's response.</div>
      <div><br>
      </div>
      <div>By the way, I think there's a major flaw in applying Yochai
        Benkler's theory of "commons-based peer production" to
        OpenStreetMap.</div>
      <div><br>
      </div>
      <div>In a free software project there's a clear difference between
        production and use. Participation in its development is
        necessarily technical and difficult, and most communities who
        want to engage more people in production tend to develop
        communities for art work, documentation, translation, marketing,
        etc. In production, everyone really is a "peer" with roughly
        similar skills and aims. Communities that then want to ensure
        their product can be used by a wider range of people take a
        structured approach toward usability.</div>
      <div><br>
      </div>
      <div>OpenStreetMap aims to engage a much wider range of people in
        production, people who aren't all peers in the same sense. So we
        need to take a more structured approach toward aspect of
        production, both in collaborating on our core data and on
        producing useful spin-offs like maps and data analysis.</div>
      <div><br>
      </div>
      <div>Often when I read Frederik's emails I get the feeling that he
        can't recognise any form of organisation outside of Ronald
        Coase's "market prices" or "managerial command" models besides
        an anarchic interpretation of Benkley's "commons-based peer
        production". People don't study sociology and political science
        for nothing.<br>
        <br clear="all">
        <div>Regards,</div>
        <div>Tom</div>
        <div><br>
        </div>
        -- <br>
        <a moz-do-not-send="true" href="http://tom.acrewoods.net">http://tom.acrewoods.net</a>  
        <a moz-do-not-send="true" href="http://twitter.com/tom_chance">http://twitter.com/tom_chance</a><br>
      </div>
    </blockquote>
    <br>
    Thank you Tom for answering on substance.<br>
    <br>
    I disagree with your view that "there's a major flaw in applying
    Yochai Benkler's theory of "commons-based peer production" to
    OpenStreetMap" and your characterization above.<br>
    <br>
    I refer to his article "Coase's Penguin" [1]. By the way, I
    encourage everyone interested to read it if they have not already
    (even though it may be a bit long by current Internet standards),
    and I thank again Schuyler for making me aware of it in a talk at
    Where 2.0 2010 [2]. I know that, even though it was written in 2002,
    when OSM did not yet exist and Wikipedia was just getting started,
    it allowed me to understand better the underlying mechanisms that
    make OSM possible and fitted very well with what I perceived of its
    inner workings. (The article also include a section "Threats to
    motivation" that may be of interest in the context of the numbers
    reported by Kai. The topic of motivation was also mentioned in the
    first replies to Frederik's port, it seems that no answer in this
    thread has taken it in consideration yet. Also my understanding was
    that one of Frederik main worries was with possible mis-allocation
    of resources. Efficient allocation of "human resources" is one of
    the key advantages of common-based peer production according to this
    article).<br>
    <br>
    The example cases covered by Benkler are not restricted to free
    software, and include endeavours with quite a wide range of needs,
    including academic research for example. He also recognizes the
    possible need for structures to support common-based peers
    production, including the possibility of monetary rewards for some
    functions (see p. 64 of the pdf, for example).<br>
    <br>
    It may be that there are better organisation theories that could be
    more useful for OSM. Please feel free to enlighten us about them.<br>
    <br>
    But let us consider for now the framework that he proposes : that
    there are three modes of production, either contract-based in firms
    ("managerial command"), property-based in markets ("market prices"),
    or commons-based peer production.<br>
    <br>
    For me, it is very clear that the third mode, "commons-based peer
    production", is the best one to describe the OpenStreetMap Project.<br>
    <br>
    Mikel's blog post made me realize that the OpenStreetMap Foundation,
    with its Board and the hierarchy of working groups, - or at least a
    part of it -, might be best described as a "managerial command
    system". <br>
    <br>
    There are functions, like finances or central public relations, for
    which this might be the best system. (Though it is not even
    certain).<br>
    <br>
    From a "logic of organisations" point of view, I think that the
    interface between the two modes of organisation, commons-based peer
    production and managerial command system, must be considered very
    carefully, and that risks for clashes are located there.<br>
    <br>
    For example, the OSM foundation might impose terms that contributors
    must accept if they want to remain active in the OSM project. Or
    some "manager" might inadvertently give an order to a participant
    who could considerate it aberrant given that he thought that he had
    signed up for a "commons-based peer production" organisation. (These
    examples are of course purely imaginary).<br>
    <br>
    The question of the best organisation for the particular
    commons-based peer production project that is OSM is certainly not
    easy.<br>
    <br>
    In particular, should its governance be mainly a "managerial command
    system" or "commons-based peer produced"?<br>
    <br>
    Indeed, if commons-based peer production was so successful to
    produce OSM database, could it not also produce OSM governance?<br>
    <br>
    And how? Since this mode of production is so recent, there might not
    be an easy answer, that could be taken off the shelf. But who better
    than the OSM community could collectively discover or construct it?<br>
    <br>
    In this sense, this "Avoid mandate Creep" thread highlights the risk
    associated with a commonly prejudiced view that a "managerial
    command system" is the only possible governance organisation in
    general, and hence for OSM. There is some internal logic that most
    people who end up on the board would share this view. (Otherwise,
    why run?) So it must be especially difficult for them, given their
    (remarkable and never acknowledged) strong commitment, to take a
    step back and consider this possibility. But I am sure they would do
    it if they think it is better for the project.<br>
    <br>
    Again, this is the question I would like to raise here, because I
    think it is very important: should OSM governance be mainly a
    "managerial command system" or "commons-based peer produced"?<br>
    <br>
    <br>
    <br>
    So what do I suggest concretely? (have I been asked in a direct
    mail). I don't know. I do not claim to have an answer. Here are just
    some example suggestions that come to mind.<br>
    <br>
    Mikel describes a simple technique that the OSM-F board uses to come
    to a consensus on a topic, by casting 5 votes on brainstormed
    choices. Could it not be generalised online to all OSM-F members,
    for OSM-F issues? Or even to all OSM community members, for OSM
    project issues?<br>
    <br>
    For example a wiki page created as an exercise by the Strategic
    working group compiles suggestion/comments made by the OSM community
    as to the future direction of the project. The OSM-F board has just
    defined goals for the OSM-F for 2012. Experiments in "commons-base
    peer produced" governance could include asking all the OSM-F members
    what they think of the OSM-F goals, or OSM community members what
    they think of the goals of their "supporting" OSM-Foundation. Or the
    OSM community members which of the suggestions of the global list
    seem more valuable.<br>
    <br>
    If it was so great to share ideas and discussions between the board
    members, wouldn't it be great to do so between the OSM-F members, or
    between the OSM community members? (Which may include sociologists
    or political scientists).<br>
    <br>
    Of course, there is nothing really new here. This is already what is
    happening more or less informally all the time on the lists and
    other communication means. What could be maybe new (at least to
    some, judging by some of the mails in this thread) is the
    recognition that this is a legitimate, well adapted governance mode.
    That respecting it and avoiding to interfere with it (eg by
    reshaping the project, or the community, from the "top") is not
    "doing nothing". And that, on the contrary, supporting and
    developing it might be worthwhile. <br>
    <br>
    Other example suggestions for topics that might be worth of a
    consultation or collective decision might include:<br>
    - what are appropriate modes of organisation, or domains of
    competence for OSM project support structures?<br>
    - what are the biggest problems facing the OSM project?<br>
    <br>
    (When asked what was the biggest problem facing Google, Larry Page
    answered "Google".<br>
    It should be not be a priori excluded that if asked what is the
    biggest problem facing the OSM community, the community itself might
    answer "OSM-F" ;) <br>
    (or at least some tendencies within it).<br>
    <br>
    Thank you for reading this far.<br>
    <br>
    Best regards,<br>
    <br>
    Jean-Guilhem<br>
    <br>
    <br>
    <br>
    [1] Summary: <a class="moz-txt-link-freetext" href="http://www.benkler.org/CoasesPenguin.html">http://www.benkler.org/CoasesPenguin.html</a><br>
    Full text: <a class="moz-txt-link-freetext" href="http://www.yale.edu/yalelj/112/BenklerWEB.pdf">http://www.yale.edu/yalelj/112/BenklerWEB.pdf</a><br>
    [2] <a class="moz-txt-link-freetext" href="http://whereconf.com/where2010/public/schedule/detail/13201">http://whereconf.com/where2010/public/schedule/detail/13201</a><br>
    script translated in French:
<a class="moz-txt-link-freetext" href="http://osm-haiti.blog.lemonde.fr/2010/04/02/openstreetmap-a-contribue-a-sauver-des-vies/">http://osm-haiti.blog.lemonde.fr/2010/04/02/openstreetmap-a-contribue-a-sauver-des-vies/</a><br>
    <br>
    <pre class="moz-signature" cols="72">-- 
"The first rule of tautology club is the first rule of tautology club"
(Thanks to Stefano Zacchiroli, Debian Project Leader)</pre>
  </body>
</html>