P2P Foundation

Researching, documenting and promoting peer to peer practices



  • Subscribe



  • Sponsors

    Want to advertise? Click here.
  • Recent Comments:

    • james: It is quite ironic that being enmeshed inside peer based silicon enabled...
    • james: You might very well be correct, but i would say that providing the research...
    • ey: what a waste of time not only because it's the money that is being transformed so...
    • solar-cost-solar-homes-solar-panels: With P2P solar energy, traditional power companies...
    • Zbigniew Lukasiak: I would add to that their secrecy.

  • Authors

  • Community and corporation

    photo of Michel Bauwens

    Michel Bauwens
    22nd June 2008


    Ian Skerrett of the Eclipse Foundation has an interesting article at the June issue of the Open Source Business Resource. Some quotes and excerpts below.

    In his lecture on “Building Technical Communities” Ian Skerrret observes:

    In a technical community: i) peers, not vendors, determine the message; ii) developers talk to other developers, not through intermediaries or press releases, and marketers produce content such as case studies that help developers sell up to their managers; iii) people speak to people, not a market or a demographic attribute; iv) employees interact with people who are saying good and bad things about their companies; iv) interactions first build trust and then build value; and iv) you learn to live with your competitors being part of the same community.

    It is a myth that committers are volunteers. The committers for the established open source projects are nearly all paid by companies to commit code to open source projects.

    To successfully interact with a technical community, you should: i) be authentic; and ii) respond and react respectfully, accurately and quickly.

    He adds:

    In order to build a community, you must produce good code that solves a compelling problem and/or decreases development costs. You must also ensure that the conversation about the code is worthwhile. Make it easy to contribute to the community by providing: i) documentation that lowers the barrier to understanding the code; ii) tutorials, white papers and books; and iii) experts who monitor newsgroups and bug databases to provide prompt and accurate feedback.

    Community building also requires transparency. Signs of transparency include: i) maintaining open bug databases; ii) publishing project meetings; and iii) publishing project plans and incorporating community’s feedback into plans. Be part of the community, do not attempt to control it. Provide a governance structure that fits with the aims of the community.

    An architecture of participation includes low barriers to entry for newcomers and some mechanism for isolating the cathedral from the bazaar (http://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar). An architecture of participation allows for a free market of ideas, in which anyone can put forward a proposed solution to a problem. From experience, an architecture of participation that is comprised of a very large run-time system as the platform (cathedral) with plug-ins on top (bazaar) does not work.

    A good architecture of participation supports a small cathedral which enables a bazaar where it is easy for individuals to add their ideas to the platform.”

    One Response to “Community and corporation”

    1. P2P Foundation » Blog Archive » Networked scenius, private patronage, and the partner state Says:

      […] Ian Skerret ‘s (Eclipse Foundation) quote a few days ago ? It is a myth that committers are volunteers. The committers for the established open source […]

    Leave a Reply

    XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>