This project's funding goal was not reached on September 1, 2012.
This project's funding goal was not reached on September 1, 2012.
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.
The 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.
When 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.
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).
I've 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)
I've 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.
Along 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).
With 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.
For 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 use.
We 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.
Smart 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 logistic systems).
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.
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.
Smaller 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 fax.
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 an ecosystem 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.
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 square one!)
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!
Thank you for your support!
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.)
- (33 days)