Advanced Search

Please click here to take a brief survey

Collaboration Manifesto
Jamais Cascio, 13 Apr 04

Eugene Eric Kim of Blue Oxen Associates has written a "Manifesto for Collaborative Tools," published both online and in the May 2004 edition of the programmer publication Dr. Dobb's Journal. In this manifesto, Kim argues for a few simple rules intended to improve collaborative software. Some are based on lessons learned from the classic work of Doug Engelbart, and some are derived from newer experiences. He gives plenty of examples of how these concepts can be built into collaborative software. But while his focus may be on the applications, his ideas apply much more broadly.

  • Be people-centric. This applies both to how we design our tools, and how we market them.

  • Be willing to collaborate. We all belong to a community of like-minded tool developers, whether or not we are aware of it. Working together will both strengthen this community and improve our tools.

  • Create shared language. Our tools share more similarities than we may think. Conversing with our fellow tool builders will help reveal those similarities; creating a shared language will make those similarities apparent to all. As a shared language evolves, a shared conceptual framework for collaborative tools will emerge, revealing opportunities for improving the interoperability of our tools.

  • Keep improving. Improvement is an ongoing process. Introducing new efficiencies will change the way we collaborate, which in turn will create new opportunities to improve our tools.

    Finally, never forget Doug Engelbart's fundamental tenet: Computers should help us become smarter and work together better. Remembering this will keep us on the right track.

  • Replace "tools" with "movements" (and "tool builders" with "activists") and Kim's argument clearly applies to not just to those who are making the technology, but also to those who are using the technology to build a better world.

    Bookmark and Share


    These principles are nice, but vague. How, for instance, would they tell that ThinkCycle sucks, and tell you how to improve it if you wanted to make a better version?

    Posted by: Jer on 15 Apr 04



    MESSAGE (optional):

    Search Worldchanging

    Worldchanging Newsletter Get good news for a change —
    Click here to sign up!


    Website Design by Eben Design | Logo Design by Egg Hosting | Hosted by Amazon AWS | Problems with the site? Send email to tech /at/
    Architecture for Humanity - all rights reserved except where otherwise indicated.

    Find_us_on_facebook_badge.gif twitter-logo.jpg