O'Reilly's Radar: Remix Patterns

Tim O'Reilly delivers O'Reilly's Radar (click to enlarge)

Tim's keynote was on patterns for remixing. Patterns consist of three parts: an issue, a prescription, and examples. Here are some of Tim's patterns (I missed much of it):

Issue: A successful open source project consists of "small pieces, loosely joined."

Therefore: Architect your software or service so as to be used easily as a component of a larger system: keep it modular, document your interfaces and use a license that doesn't hinder the recombinations.

Example: missed it

Issue: There is great benefit to sharing your development efforts with users

Therefore: release early and often. Set up mechanisms for user feedback, bug reports and so on.

Issue: On today's web you no longer need to build or own all the components of your application.

Example: isbn.nu

Therefore: don't lock away the interfaces to your ecommerce application.

Issue: When devices and program are connected to the Internet, applications are no longer software artifacts, they're on-going services.

Therefore: don't package up new features into monolithic releases, rather, fold them in on a regular basis. Let your users into the process. Engage your users as real-time testers and instrument such that you know how new features are faring. Operate as if you're in perpetual beta.

Examples: Google, Flickr, del.icio.us, Safari U.

Issue: The key to competitive advantage in networked applications is the extent to which users augment your data with their own.

Therefore: Architect for participation beyond design and development.

Example: Amazon using its user's intelligence to create new value. Adding user data to their own.

Issue: Only a small percentage of user will go to the trouble of explicitly adding value.

Therefore: make participation the default, aggregating user data as a side-effect of their using your application.

Example: Flickr's defaults for sharing is for "everyone." The default for annotation is "open."

Issue: Many of the limiting factors from the physical world are absent on the Internet.

Therefore: Use the power of the computer to monetize niches formerly too small to be commercial.

Example: Google Ad Sense.

Issue: The PC is no longer the only access point for networked applications.

Therefore: Design your application from the get-go to integrate services and share data on multiple devices.

Example: iSync.

Issue: Social networking are a by-product of social application like email, instant messaging, photo sharing, and book buying.

Therefore: Architect your application to capture and share the social fabric underlying you application (rather than artificially constructing another.

Example: The ETech Attention Stream (which is displayed on a flat panel in the lobby).

Issue: As demonstrated by container shipping, IP packages, and HTML pages, a standard content-agnostic packet is the most effective way to ship for good and data.

Therefore: Understand the optimum "packet size" for your application domain and devise products that fit it.

Example: Books don't fit on a Web page. O'Reilly Make and the new Cookbook series are examples of repackaging content in an effort to more closely match the right "packet size."

Issue: When content is digital, it lends itself to being broken down and remixed.

Therefore: Create your business model so that it make money from the atomic units of your products.

Example: Safari U.

Although they're not patterns, Tim also mentions AJAX and Ruby on Rails.

Please leave comments using the Hypothes.is sidebar.

Last modified: Thu Oct 10 10:47:19 2019.