Diaspora's own explanation is not so concise, but here it is:
Diaspora aims to be a distributed network, where totally separate computers connect to each other directly, will let us connect without surrendering our privacy. We call these computers ‘seeds’. A seed is owned by you, hosted by you, or on a rented server. Once it has been set up, the seed will aggregate all of your information: your facebook profile, tweets, anything. We are designing an easily extendable plugin framework for Diaspora, so that whenever newfangled content gets invented, it will be automagically integrated into every seed.
I've been looking for something like this to come along for a while. There have been a few feeble attempts so far, but none have gained any traction in the wild yet... and I'm not expecting this one to either.
Here's my take on it...
The Diaspora project has gotten a lot of media attention recently including a feature story in the New York Times. The reason it has gotten so much coverage is mostly just lucky timing. They happened to launch a $10k request for donations on kickstarter.com right as privacy and security concerns with Facebook became a mainstream press issue. Being lazy, the media just latched onto Diaspora as the underdog counter-story to Facebook, rather than do something rash like actual journalism.
Diaspora, thanks to the coverage spike, has accumulated over $175,000; much more than the mere $10k they'd originally asked for. If the donations keep rolling in, they can just skip code and go straight to being famous, rich, and retired.
I'm always pretty excited by these kinds of projects though, and I love the general idea of an open source social network. And, really, who doesn't like a good under-dog?
But, despite my enthusiasm, I am not all that impressed by what I've seen and read about Diaspora so far. I don't have a good feeling about the technical approach, nor the fundamental concepts.
Fundamental Concepts:
The project's fundamentals are subtly flawed in at least two very important ways.
The first is related to the design architecture; that Diaspora will be a distributed multi-node system.
The idea of distributed systems itself is quite solid of course. Spread storage and processing out to as many machines as possible, each fully responsible for their own information domains. This is the principle upon which the web itself operates, so it is well proven.
Diaspora's flaw is the assumption that every user will "own their own server".
This isn't 1994!
Social networking users are regular people, and regular people do NOT want to manage a server node. It doesn't matter how easy you make node management!
Users can barely manage copy and paste, and you want to put them in charge of a distributed information server?
I think the team has completely misunderstood the user's requirements here. Users "want control of their data". They never said that they "want to control their data". This isn't just semantics; it is the critical distinction between what they want, and what Diaspora is proposing to build.
For several years, the trend among users, even the technical ones, has been away from user owned software. Today's users don't want to install or configure anything themselves. They use pure internet apps almost exclusively. The same is true with user data. They don't want to have to deal with keeping track of it, or backing it up, or moving it around. In short, they don't want the responsibility for all that technical crap. They just want to use the software, have the data, and have someone else to blame when things break or data gets lost.
You can see this user trend clearly in the rise of gmail, youtube, flickr, google apps, etc. Wherever possible, people are steadily switching to web supplied software, and are moving data off of their own vulnerable machines into the cloud. All the users have been asking for is a sense of control over what the cloud does with the data once it gets there.
The second conceptual flaw is more subtle. It is the simple lack of focus on end-user features. Their explanations of the user features are, at best, vague; when they bother to mention them at all.
Their focus seems confined to the technical back-end details. Even worse, they use the term "feature" to label the various plumbing aspects of the system. These are not features, these are mechanics. Mechanics are just the means to the ends; it is in the ends that the features hide.
My concern here is really that the team just doesn't seem to understand their true goal well enough to build towards it reliably. They seem focused too narrowly on "how", but not enough on "what".
The plan appears to be to design and build a framework first, and deal with user features later. They say so on their blog in some detail actually, but frameworks are not applications.
I like the iterative and pragmatic approach they describe, but they are already building a framework and still they don't provide coherent explanations of actual user facing features. They only describe them in abstract vagaries; and this is what concerns me.
This kind of thinking is tragically common in application design, and it rarely turns out well. If you don't clearly define the user features you are aiming for, in quite some detail, then you cannot know if you are building the *right* framework; one that will usefully support the user features you'll layer on top later. The framework is likely to be too generic to be very useful during the real feature development stages. When developing front-end code, nothing is harder than having to code against an abstract framework's limitations and constraints, but not getting much help with the very concrete requirements you are faced with.
There is nothing wrong with building a great framework of course, but the team is getting donations based on the promise of a better social-networking application; not just a social networking framework.
Perhaps the fault just lies in the public's misconception about what Diaspora is proposing to build.
The Technical Approach:
Distributed systems are difficult, but distributed systems with a variable number of member nodes, coming and going at will, are many orders of magnitude more so.
Then there are the problems of distributed document and NoSQL database systems, which are still rather new and immature technologies. Even the best of these still have serious limitations.
Performance is a significant concern in such a system. Nodes have to be able to locate and query other nodes for data very quickly, and a social network will need to hit a large number of peer-nodes for even the simplest user features.
And then there is the problem of fault-tolerance in such a highly distributed system. When a member node is down, slow, or unreachable, the system has to gracefully degrade, without error, and without significant disruption in the user's experience.
Any of these areas present the kind of technical challenge that even companies the size of Google struggle with, but few systems combine so many such elements as Diaspora would. Their back-end architecture is up against some of the nastiest technical challenges the field has to offer, plus competing with established players whose centralized systems do not suffer the same.
To me, the worst part is that, after having overcome the design problems, the system itself will have gained almost nothing that would add any value for the users. I can't think of anything this design allows Diaspora's users to do, that a centralized social network doesn't also provide. Even the promise of giving users control over their data is not in any way unique to this design. Facebook can give users the same control, and with little technical effort (though, it would have a severe impact to their business model).
Despite my misgivings about the architecture, I still think Diaspora should try this approach. Just because I shat all over it, doesn't mean it's wrong to give it a try. If nothing else, they might advance the applied sciences of distributed system design. Even if Diaspora doesn't succeed with a distributed social-network, someone eventually will.
Whether real users will care or not is an entirely different matter. With the team putting so much effort into the complex back-end architecture, they will likely not have the resources left to do a bang-up job on the front-end features; at least not quickly enough to still be relevant.
The front-end features have to be amazing, or the system will not have much user interest. They are up against well-established competition that has had a lot of time to evolve and design their UIs. Creating a compelling experience to compete with them will be quite a daunting, and non-trivial, technical challenge all by itself.
Next...
It isn't fair to spend this much text bashing someone else's project without at least doing them the courtesy of providing constructive suggestions or alternative ideas. But, I'm going to save the constructive ideas for another post.
No comments:
Post a Comment