File-based sharing based around pushing copies of good stuff to others. That’s what the federated wiki is about.
For that reason I find newer efforts like this that push files around instead of references to be fascinating. This out today from Dropbox, a new product called Carousel:
Photos of events such as graduations and weddings, Houston points out, are spread over the devices and hard drives of multiple guests. It creates pervasive photo anxiety: People are no longer sure they own the best images of the most important moments in their lives. The app, which becomes available this week for iPhones and Android phones—with a version coming soon for desktops—taps into photos stored on Dropbox and allows users to cycle through them quickly and send images to friends and family, so they can add them to their collections well.
Think about how this changes notions of sharing, and you’ll see it as part of a move towards file-based copy systems, and the pull request approach of a GitHub.
Also, read that paragraph again, and tell me if that doesn’t look similar to the educational materials situation we face everyday.
OK, now imagine your wiki exists in a Dropbox account, and you do the same thing — you flip though all your articles and forward the ones that you think are useful to your various federations. Those get dropped into other people’s own dropbox wikis, and the virtuous cycle continues.
It’s a different way of thinking about things. It’s file based, and it sees copies of things as a feature, not a bug. The storage for your project is not seperate from the sharing features of your project. We let the copies happen and we sort out the mess afterwards.
My argument is not that Dropbox rules, but that this is part of a larger trend that rethinks how sharing and forking works on the new web. It’s also a potentially a powerful rethinking of how OER could propagate through a system.
Carousel makes sense given DB’s business model. The debut of their Datastore API last year and their talks at SXSW about the “everything cloud” (or whatever they’re calling it) is an interesting approach that is in some ways the exact opposite model. Clearly they are trying to insinuate themselves across the spectrum. I’m not sure my own MIND is BLOWN, but I think you’re spot-on. But I was under the impression that with a Federated wiki you wouldn’t *need* DB or anything like it in the middle?
Chris — everybody needs some storage in a federated wiki, and you need to symlink up that storage via federation. One way to do that is files on a server connected by a GitHub network. Another might be this.
The key is not really “nothing”, but rather a “small, dumb, something” that handles storage and sharing concerns which is seperated to some extent from the interpreting software. So yeah, DBs are out, but things that function like file systems, or use very general purpose storage APIs could be in.
Dropbox as the better than OER as upload is just using a drive, not even git gets that.