Please Like, Tweet, Digg, Slash, Blog, and otherwise share this project!
Collaborating usually involves sharing documents - our projects and
teams are held together by action item lists, meeting agendas, plans,
reports, design documents, and so on.
But making changes, and keeping track of them, causes us a lot of pain,
confusion, and wasted time.
We think we have a better way to share documents - one that
is easy to adopt, comfortable to use, and that doesn't tether us to a
continuous network connection.
Shared Documents Lie at the Heart of Collaboration
most complicated projects are usually held together by marks on paper - a football
playbook, a theatrical script, a musical score, a set of construction plans. A group of people, working off the same
document, staying on the same page.
we work in the same place, it's easy enough to print out copies - of a meeting
agenda, a set of presentation slides, a report, a design document. We mark up our own copy as we discuss
ideas and issues, update each other on status, make decisions, and assign action items. We can also make private notes, and we
each walk away with our own copy.
It's a lot harder across the net. Send documents as email attachments, or via Dropbox, and suddenly we can never find the most recent copy. So we turn to Google Docs, or SharePoint, or set up a Wiki, or turn to a team-support system like BaseCamp or RedMine... now we have the problems of setting up and configuring accounts, convincing everyone to adopt the same tool, administering the tool... and if we're on an airplane, working in a remote area, or otherwise disconnected from the net, we're out of luck.
Building a Better Shared Document
We really do prefer having our own copies of things - be it paper documents, music on our iPods, eBooks, smartphone apps, our calendars and address books, and computer files - rather than relying on a network tether to servers somewhere in the cloud.
The challenge is distributing and keeping track of updates. We want the simplicity of writing and sending an email, the editing and change tracking of a wiki, coupled with our own copies of things. We want to build on tools we already have - email, web browsers, RSS reader, calendar, chat - no new software to install (or force on others) - just compose and email an initial document - everyone then saves a local copy, views and edits via their web browser, changes flow transparently via a peer-to-peer protocol running behind the scenes. Change notifications show up as an RSS feed and calendar updates (when a document is associated with an event).
been fascinated by how people use the Internet to organize - dating back to
having a front row seat to the early days of the ARPANET - the first virtual
teams, the evolution of Internet governance - and later working on lots of different
aspects of online coordination - ranging from command and control systems to
online town meetings to online marketplaces to selling email list services for a while. (http://www.linkedin.com/pub/miles-fidelman/2/980/516)
also been struck by how little progress we've made toward re-engineering our
economy around the net. In the early days, we predicted that networks of small
companies would replace larger organizations. That's sort of happened in some
sectors, like academia. But in the wider world, we've seen outsourcing and electronic
sweatshops, not networks of electronic cottage industry. It strikes me that
lack of tools and a supporting ecosystem are a big part of the problem - so I
keep looking at ways to attack that problem - to enable ad hoc collaboration on
larger and larger scales.
the way, I've been struck by the power of the net to connect us, and allow us
to work in new ways; and at the same time by how our tools get in our way. I've
also been struck how every time somebody comes up with a "better"
tool, that translates to either "so complicated that nobody uses it"
or "centralized and proprietary" with all the problems that go with
it. Meanwhile, I've been impressed by how often we instinctively resort to
older techniques (e.g., checklists), malleable software (e.g., spreadsheets),
and flexible communications tools, notably email and chat. About the only
"groupware" that actually seems to add value, and get used, are
wikis, bug tracking systems, and version control systems - and that ultimately,
we prefer to have our own copies of things (e.g., Git).
the advent of HTML5, it strikes me as time to put the pieces together -
a really simple way to keep groups of people coordinated that is open,
distributed, peer-to-peer, runs with our existing tools (browsers, email). And
then couple that to some financial infrastructure to enable better
collaboration where "real" stuff and money is involved. I guess I'm
also motivated somewhat by doing something that technically cool. :-) I started working on this as part of two military funded R&D projects (talk about large scale, networked collaboration), and now want to pull together open source tools for a broader audience. That's what this Kickstarter effort is about.
those of us with grey beards, I think of it as HyperCard, retooled as a group
tool, running in a browser, with stacks linked by a peer-to-peer protocol. For
younger folks, the analogy is linked spreadsheets, running in browsers, where
the links use an open protocol and actually work across the net. Other inspirations include TiddlyWiki (a personal wiki that runs entirely in a browser, saved as a local file (http://tiddlywiki.com/) and EtherPad (http://en.wikipedia.org/wiki/Etherpad), a distributed, collaborative editor.
Four design principles lie at the core of our approach.
1. Simple, Powerful, Elegant
We believe in the KISS principle (Keep it Simple Stupid). We
are striving for the simplicity, power, and elegance of a notebook, sketchpad, or DayRunner -
not another complicated "groupware" system that nobody will ever
look to spreadsheets as a model for easy-to use but powerful tools; and to
HyperCard, the stacks of "smart index cards" that shipped with early
Macinotoshes - but open, and designed for groups working across the net,
rather than individuals. Think HyperCard, retooled for groups,
running in a web browser. Or perhaps an electronic DayRunner on steroids.
notebooks that talk to each other... a simple, yet powerful tool for keeping us
on the same page, as we think and work together
2. LOCKSS: Lots of Copies Keeps Stuff Safe
Our model is Smart Documents
that Talk to each Other (as opposed to a single central copy, such as provided by GoogleDocs).
Most of us prefer our own copies of documents - we can work
offline, and we really don't trust proprietary vendors who keep our stuff
somewhere in the cloud. That might
be OK for backups, but we keep important files on our personal laptops, our own
copies of eBooks on our tablets, and our own copies of songs on our iPods. Software developers have come to favor
distributed version control systems like Git, where every developer keeps a
working copy on their own computer.
As librarians say, "lots of copies keeps stuff safe."
We are firm adherents to principles that guided early
Internet development - everybody is a publisher and
"intelligence" is at the edges of the net, not in network devices or
central computer systems.
Along with replicated copies of documents, we believe in peer-to-peer protocols - documents that exchange information with
each other, rather than through a central "choke point" that can
fail, become congested, or go out of business.
[Design Note: In
practice, there are limits to pure peer-to-peer protocols. Endpoints are not always on-line, and there
are scaling issues with large numbers of endpoints. Thus we envision a two-level network, much like email - with
smart documents talking to a distributed network of backbone servers, much like
email clients talk to a network of mail servers. To the extent possible, it's our intention that smart
documents be able to communicate
over existing email and chat networks.]
4. No Walled Gardens: Open Standards, Open Software, Open Ecosystem
Collaboration requires openness - it's hard to work with
someone when we're in one walled garden, and our teammates in others. In the early days of email,
CompuServe users could only exchange email with each other, AOL users, only
with other AOL users, and so on. Connections to the Internet brought us a world where we all can exchange
email with each other.
Our software and document formats are being built on open
standards - enabled by the new HTML5 family of standards, and by browsers that
support these standards. We will use standard
protocols for document-to-document communication, and support interoperability
with other systems using open protocol standards (e.g., exchanging calendar
events using iCal, using X.12 standards to tie smart documents to financial and
We are building on open source software libraries, and all
our code will be released under an open source license (probably the GPL). After our initial release, we will
turn our focus to building a user and developer community, and a formal
organization, for ongoing support and enhancement of the code base.
In addition, as we develop server-side software to support
smart documents - a protocol fabric, identity and directory services, and so
forth - we will also package that software for open source release. Just as email flows over a
loosely coupled federation of email servers - some on people's personal
machines, some in enterprise data centers, some run by ISPs - we envision a
similar federation of servers supporting smart documents.
After our initial release, we will focus attention on
defining a governance structure and formal organization to act as a steward for
the software, and a coordinating body for the federation of servers.
Building The Internet's Back Office: An Open Ecosystem for Collaboration:
This effort is not just about software. It's about developing an ecosystem for collaboration. We are already seeing the beginnings of
an ecosystem supporting virtual businesses - marketplaces like eBay
and Amazon storefronts, incubators and co-working spaces, a myriad of logistic
and financial services, funding sources like Kickstarter.
But there's far less support available for business-to-business
and "back office" functions.
It's easy to set up an Amazon storefront; not so easy to set up a
virtual supply chain. A lot of
this has to do with limitations of current information technology. Large enterprises spend huge sums on
custom information systems, tailored to their specific operations - travel reservations,
financial trading, supply chain automation, customer relationship management
systems, and so forth. And they have the scale and clout to arrange electronic links to their customers and vendors - for a seamless flow of information, good, and money.
enterprises make do with a mix of off-the-shelf software (e.g., QuickBooks),
on-line services, home-grown code, and a lot of old fashioned paper - all of
which is difficult to integrate, leading to a lot of manual steps (ever try getting QuickBooks to work with a non-Intuit product or service?). And it's a major undertaking to link systems across
organizations - say for a one-time collaborative project. We tend to revert to paper, email, and
Today, it's easy to start a collaborative project - if its a
software project and no money changes hands. Just set up an account on SourceForge or GitHub, and maybe
arrange for the Apache Software Foundation to act as steward for intellectual
property rights. Our goal is to go a step further - creating anecosystem
that supports a broad range of projects, and where money can change hands. We see smart documents providing an framework for
linking people and organizations together - defining the information, work, and money flows for a
specific project or relationship. But we need more than software. We need a platform that supports fluid contractual and
financial relationships among collaborators - a way to manage tasks and funds
across a network of individuals and small firms. If you've worked in a matrix managed company, you recognize
the idea - starting a new project is as easy as opening a new charge code -
essentially a set of books for the project. Funds from sales flow into the
charge code. Any authorized
person, across all departments, can charge time and expenses to the charge
code. We envision opening up the matrix - establishing a
cooperative legal and accounting structure that spans organizations. Today, people can join PayPal and move
money through it. We envision
something similar, with a business-to-business focus, and owned cooperatively by
its members - join the cooperative and you can move task and money around.
We also see this framework as a vehicle for engaging service
providers to support smart documents - by defining a common API for making
services available to projects using smart documents (in the same way that
FaceBook provides a platform that lots of other service providers work through). If you provide services to virtual enterprises, we hope to create opportunities for you.
With Your Support: Alpha in December, Release 1.0 by the Spring
Supporters will get access to Alpha and Beta releases, along with identity and crypto credentials. We're particularly looking for a couple of larger sponsors with projects that need a smart document like capability, who have near-term scenarios we can design and test against. (But,
please don't let this dissuade anybody from a smaller contribution - remember
that Kickstarter is all-or-nothing, if we don't meet our goal, we're back to
Our goal is a 1.0 release by next Spring - providing two
useful templates and their supporting infrastructure.
The concepts emerged from an Air Force project at a previous
employer. When my last employer
was sold, Peter Schmidt, Art Mellor and I started a small R&D company to
pursue the idea, and obtained a small grant from the Army to build a
proof-of-concept prototype. We're now beginning to move forward - from military focused
prototypes to open source tools that can support a wide range of virtual teams
and projects. Along the way, we've
begun to collaborate with Tony Garnock-Jones - who was lead developer for the
initial releases of RabbitMQ - Tony is working on complimentary technology as
he pursues a Doctorate at Northeastern.
Kickstarter funding will allow me to focus full-time on
getting a release out the door (developers gotta eat!), cover data center costs, and support legal fees for pulling together a formal governance model and organization.
If we reach our basic goal of $65,000 (and remember that
some of this goes to Kickstarter), we'll be able to release two single page
templates. The first, BrowserCards, will provide a "blank canvass" that we're modeling
after HyperCard. The second will
be a who-what-where-when-how_much checklist - a fundamental tool for managing
any project - that can become a shopping list, trouble ticket, action item
list, meeting agenda, assembly instructions, a construction "punch
list," etc. Most of our effort will focus on the underlying libraries for document distribution and inter-communication - building blocks that will support more templates in the future.
We'll host an
initial code repository, bug tracking system, community email list, and initial
protocol support on our current computing cluster. After the initial release, we'll turn our attention to building a user and development community, and a federation of servers.
We're shooting for an Alpha release in December, Beta in late
January, and Release 1.0 in March.
As capabilities come on-line we'll "eat our own dogfood" - testing the software as we organize hackathons and a launch party. And we'd be really excited to work on one or two larger scale applications for larger sponsors.
If we receive additional funds, they will allow us to move
forward after Release 1 - developing a template editor (write your own
templates without coding), a work-flow composer to generate a set of
inter-related documents, a multi-page/multi-project notebook (Electronic DayRunner on Steroids), and get moving on the business-to-business cooperative.
And.... Please Like, Tweet, Digg, Slash, Blog, and otherwise share this project!
Yes! All code, source and object, client and server, will be released under the GPL or a similar open source license. During early development, we're only releasing code to contributors - we don't want to inflict buggy, rapidly changing software on the whole wide world - but anyone will be free to redistribute code they download. We're also restricting access to code running on our servers - to limit load - but those who download the server-side code will be free to run their own servers. Once we get to our first public release, all code will be available directly from us, for free, under an open source license. (We'll still charge for access to our server, but anybody will be free to set up their own.)
Access to server side code on release date plus 5-year membership in service provider association/cooperative. If you provide project-support services (co-working space, contract services, etc.), or provide enterprise IT services - this is the code and relationship you'll need to host server-side code for your users, take orders, process payments, etc. via smart documents.
Access to server side code during alpha & beta tests plus 5-year membership in service provider association/cooperative. Help define the overall cooperative governance model for business-to-business transactions using smart documents. Get an early leg up as a service provider.
Custom templates for your project! We're starting with a blank page and checklists - but envision more detailed templates in the future. We'll work with you to define up to 5 templates to support a specific project or work flow.
Custom installation. Have a project or venture in mind that needs organizational tools - a flash performance, a conference, a distributed supply chain? Want to use smart documents to provide enterprise services? We'll work with you to build a custom set of smart documents to support your project and support installation of all server-side code at your site.