John Hagel, John Seely Brown, and Lang Davison, Defining Common Collaboration Tensions:
Loosely versus Tightly Coupled: One objection you might reasonably raise relative to the collaboration curve is the n-squared problem, in which the expense and effort required for participants to interact in a given environment rises exponentially with the number of participants. In a pull-based creation space, loose coupling provides a way around the n-squared problem by modularizing (and standardizing the interfaces between) resources so they can be flexibly combined and recombined. This sharply contrasts with more hardwired approaches in which the activities people do and the connections between them must be redefined each time the activity or connection changes. Said differently, loosely coupled collaboration scales; tightly coupled collaboration does not.
Sound like a “personal API”?
As I explained the concept of a personal API last month,
…when I talk about “personal APIs” I’m not only talking about accessing or receiving content, I’m also talking about delivering content and context to people; using the term API is a conceptual approach to thinking about how we can “scale” our time, thoughts and value stored inside ourselves to deliver more (quantity) and deeper (quality) interactions to other people; how can we reduce inter-personal transaction costs of interactions to deliver more value?
Right now my websites and my template financial model are the only “personal APIs” I have, but in their current unorganized, unpersonalized, untargeted and “noisy” state they are only a glimmer of a way to “scale me”.
Even worse, my efforts to create signals merely adds to the noise; the web of duplicative content aggregators and republishers hinders our collective ROI on attention and increases our collaboration transaction costs; by trying to help I’m helping make it worse.
Solving this paradox by moving the idea of a “personal API” from conceptual to actual is going to be fun…