Memebrand is a draft OLPC publishing philosophy. An introduction to the sharing and knowledge-flow we are attempting to enable, and the principles behind our efforts, is presented here. Feel free to edit this page directly and discuss it on its talk page.
Publishing has recently become a free service. People who have access to a network connection are able to share their writing and artwork with billions of others for the price of a few Watt-hours of electricity. Whereas it once took careful revision, salesmanship, and personal connections to get a small work published, with thanks given for every channel available for distribution, the burden is now one of choosing what to publish, where, and how; or of making material available with enough context that among the billions who have access to it, those interested in it can find it.
There used to be many interactions and hoops necessary to publish anything. Today one can with a single effort, announce that something is to be published, make it available to others who wish to see it, and propagate it throughout the world. As a result, there are tools that empower authors to publish their works without requiring them to pick a restricted forum or location for publication. File-sharing services such as Appletalk, and more specific peer-to-peer services, show directories of shared files to everyone visible on a local network. Web servers show files to everyone who can reach the server over a global Internet.
We are working to build a networked platform that provides faster and better versioned publication, and more reliable and persistent collaboration on shared works, than is currently available. The Memebrand system is designed to make publishing as easy as possible, so that there are no extraneous hurdles to publishing or sharing a work.
We distinguish the synchronous act of sharing, in which all sharing parties to be present and active at one time, from the asynchronous act of publishing, in which a work is made available for all in a certain group to see and use. When one has shared an activity or creative process with a group, the resulting work is generally published so that the same group can access it.
- Write once, publish anywhere
- Something published in one activity or context must be publishable independently of that context. A work once created should be publishable in many different ways at once.
- No data lock-in
- Systems for publishing works must be open; the author as well as any readers must be able to separate the work and its metadata from the database describing it. Activities that store authored works in special formats should also export to standard interchange formats.
- No specific reader required
- Publishing must not depend on the software or activities a searcher is using to find available materials. While it may be helpful to read a published work with the same activity that was used to create it, it must be possible to see or get the work even without that activity.
- A work must not be separated from its attribution, save at the explicit request of the creator.
- Large works must be separable and publishable in many pieces. Publishing should be done at the smallest useful level of granularity, and should be possible independently of the design of a unifying structure for a meta-work.
- Local sharing
- A default publishing mode must be one's local network, without material being published to people on the other side of the world. A clear distinction must be drawn between this and publishing to the world, with a desire for propagation wherever possible. On the other side of the same coin, one should be able to publish to the local network in every context that supports synchronous sharing with that network.
- Intentional publication
- The act of publishing should require explicit choice by the author, including the choice of sharing context while creating or collaborating. At the same time, this choice should be part of the creative process, and not onerous or repetitive.
- Persistent versioning
- All works should have versions and permanent identifiers for each version that can be used to find exactly the work one was looking at before -- or to determine that that specific version is not available.
- Persistent discovery
- If a work can be found once, it should be findable again in the same fashion. Links to works or revisions of works should never break entirely. Local caches and indexes of material should support persistent use of published works among groups who are only intermittently connected to one another.
- Explicit licensing
- Wherever possible, a work should indicate explicitly the license under which it may be used.
- Out-of-the-box publishing
- The laptop should be usable as a publishing tool when it arrives, regardless of the local network connectivity, without the need to download updates or special publication software, and without the need to change default preferences.
- Support for low-bandwidth networks
- Publishing should be possible and reliable even when only short segments of works can be exchanged at a given moment. A précis should be accessible when the whole is not; a title should be accessible when the précis is not.
- Support for multiple views of works
- Publishing should be independent of how works are viewed or categorized. Providing for publishing in small units, and for viewing or publishing nested collections of works/units, offers better searchability and better use of storage space.
- No permanent loss of work or attribution
- Published works should never be entirely lost, nor should they lose the details of their attribution and origin, even if the computers used to initially create the works disappear.
- Graceful link degradation
- Many works are composed of small pieces linked internally; and also linked to external sources. Works linked together should indicate external links differently from internal links; and should be able to either transparently connect to and include related works when both are available to a reader, or to degrade gracefully and continue providing useful information when the related works are not present.
 For more information
More detailed specification is forthcoming. You can see some of the use cases for more goals, and for features not yet covered by the envisioned implementation... in particular, limits on abuse and hints for prioritizing caching and propagation.
Feel free to also join the OLPC library mailing list for further discussion.
 Related links
- vaguely related : sharememe.com - aiming to be a "write once to list, make sure it gets to them" service. relevant questions are how to capture the intent of the sender and recipients re: single v multiple copies, push v pull, archiving v transient...