Science 2.0/Web 2.0 analogy

This is a parallel effort to work on the document at hand. Here, I am going to take lessons gleaned from the transition from Web1.0 -> 2.0, and for each lesson draw relevant parallels to the biological community (and also if OWW has ways to deal with some of those issues). The lessons will be taken directly from the Oreilly paper on Web 2.0. Though this process, maybe we can better understand the extent the analogy makes sense, and what we can expect to gain by applying a similar transition in the biological sciences.

The Major Lessons

1. The Long Tail
   • Small sites make up the bulk of the internet's content; narrow niches make up the bulk of internet's the possible applications. Therefore: Leverage customer-self service and algorithmic data management to reach out to the entire web, to the edges and not just the center, to the long tail and not just the head.
   • In biology, there is a tremendous diversity in the problems, approaches, and for that matter conclusions that researchers study. Currently, these diseparate groups interact, for the most part, at conferences and publications. The question is, can we make that better. How do we increase the level of communication along the edges?
   • Perhaps something like OWW, or other wiki's could provide forums for those people to interact.
2. Data is the Next Intel Inside
   • Applications are increasingly data-driven. Therefore: For competitive advantage, seek to own a unique, hard-to-recreate source of data.
3. Users Add Value
   • The key to competitive advantage in internet applications is the extent to which users add their own data to that which you provide. Therefore: Don't restrict your "architecture of participation" to software development. Involve your users both implicitly and explicitly in adding value to your application.
   • This will definitely be true in biology. The extent at which data, protocols, and results are accessible, the faster that scientific ideas can build on one another. However, there are significant barriers to actually disseminating results in addition to real or perceived disincentives to sharing of these ideas.
   • OpenWetWare is an attempt to making the process of dissemination and organization easier for scientists. However, it will be useful only to the extent that people are willing to be open about their science.
4. Network Effects by Default
   • Only a small percentage of users will go to the trouble of adding value to your application. Therefore: Set inclusive defaults for aggregating user data as a side-effect of their use of the application.
5. Some Rights Reserved.
   • Intellectual property protection limits re-use and prevents experimentation. Therefore: When benefits come from collective adoption, not private restriction, make sure that barriers to adoption are low. Follow existing standards, and use licenses with as few restrictions as possible. Design for "hackability" and "remixability."
6. The Perpetual Beta
   • When devices and programs are connected to the internet, applications are no longer software artifacts, they are ongoing services. Therefore: Don't package up new features into monolithic releases, but instead add them on a regular basis as part of the normal user experience. Engage your users as real-time testers, and instrument the service so that you know how people use the new features.
7. Cooperate, Don't Control
   • Web 2.0 applications are built of a network of cooperating data services. Therefore: Offer web services interfaces and content syndication, and re-use the data services of others. Support lightweight programming models that allow for loosely-coupled systems.
8. Software Above the Level of a Single Device
   • The PC is no longer the only access device for internet applications, and applications that are limited to a single device are less valuable than those that are connected. Therefore: Design your application from the get-go to integrate services across handheld devices, PCs, and internet servers.

Other issues brought up by the text

1. the value of the software is proportional to the scale and dynamism of the data it helps to manage.
2. leverage customer-self service and algorithmic data management to reach out to the entire web, to the edges and not just the center, to the long tail and not just the head.
3. the service automatically gets better the more people use it.
4. Users add value
5. Support lightweight programming models that allow for loosely coupled systems
6. Think syndication, not coordination
7. Design for "hackability" and remixability