I think that the infrastructure for the next generation of interesting network-aware applications is being built right now, and that it’s going to change the way people think about data, collaboration, and connectivity.
What are these projects? Simple: the distributed storage and merging tools. The most successful example is probably Git, but a bunch of other interesting related projects (CloudRCS, Google Gears, Prophet, etc.) are all exploring a similar space. Basically, the proposition is that, given the right kind of atomic update operations, data can be modified on a bunch of different nodes, and merges can happen asynchronously (if at all) when time, connectivity, or workflow permits it.
To explain why I think these tools are important, and where I think the opportunity exists for the next crop of interesting applications, let me offer examples from two different conferences I’ve attended in recent months.
First, an example of where distributed authoring tools succeeded: at RubyFringe, almost every presentation which featured code included a GitHub link and invitation to fork the project and push back changes. In fact, one of the presenters introduced Gist, a tool designed to allow even throw-away “pasties” of code to be version-controlled and shared using Git as a backend.
Anyone interested in checking out a copy of the code, making some tweaks, and pushing them back to the original author just needed a copy of Git. They didn’t have to do the work online, and didn’t even have to use GitHub if they didn’t want to, and their work would still be version-tracked and shareable with other developers.
In contrast, while at the NITLE Moodle User Meeting in Tacoma back in June, I struggled to share an outline for a presentation I made with my co-presenter. The hotel where the conference was happening had effectively useless ‘net access, so Google Docs and other online services were out of the question. We eventually just had to sit down next to each other the night before the talk in front of my laptop and edit the outline as plaintext, and then copy the file as a whole to his machine for conversion to Keynote slides.
Now we have a simple text file containing the outline, and a PDF generated from the Keynote slides, but no way to show the evolution of the presentation over the days of the conference, or to track changes for future adaptations of the material. Furthermore, if one of us wants to make changes and share with the other, we’re stuck with email attachments (or the glorified Web 2.0 FTP-clones like Dropbox) to keep up to date.
Programmers have figured out the value of distributed authoring, and understand the necessity for sane merging and conflict-resolution practices from long, painful experience. Knowledge workers in other fields have been using the “track changes” features in Word for just as long, but haven’t yet made the leap to fully-shared authoring. Even when they do, it tends to look more like a Wiki than an offline, sync-able tool like Git.
There’s a huge potential in this space for applications other than source code and other plaintext formats. Tabular data like spreadsheets, outline editors and presentation tools, and PIM and calendaring systems could all benefit from asynchronous, distributed authoring and merging. There’s some work being done at the OS level, (iSync/SyncServices, Live Mesh, etc.) but I think that the really interesting stuff is going to happen out at the edge, amongst the startups and small app developers.
Recent Comments