The anticipation
I was having high hopes since the first day the Diaspora Project has been announced. I don’t like Facebook’s attitude towards privacy and I have soft spot for distributed networks in Jabber spirit. That’s why I was keeping track of their official blog, promoting the name and idea amongst all of my friends and waiting for the first code release. The fact it was going to be built in Ruby made me even more excited — I wanted to hack on the thing!
And so, a few hours ago, the developer preview release has been announced and the code put on GitHub.
WTFs per minute
So I’ve cloned the repo (mind you, it was a few hours and a lot of commits after the announcement) and started going through it.
And, fuck, I am disappointed.
Licensing
AGPL. Affero GPL. To those who haven’t heard of that before: it’s the GPL of GPL-based licenses. Basically viral exactly like GPL, but worse: any code using AGPL library or tool (not only linked, also merely using!) has to be AGPL licensed too. And also: web application has to have its full source code easily downloadable if the code is AGPL licensed.
Seriously, what the fuck?
This way you, dear Diaspora developers, have just cut off any commercial potential of Diaspora. No company is going to fork it and offer customized (or in any other way “premium”) version. Nobody is going to extract any solution (think: protocol implementation) from the code and release it, because basically AGPL makes a library or tool unusable for anyone.
As a homework you can try to think where Ruby On Rails would be today, had it been released under AGPL.
This is even more surprising considering the fact it’s been written in Ruby on Rails — an ecosystem where MIT license is the standard thing. You’re using a toolset and ecosystem grown on and thanks to stuff released on MIT license and suddenly shit in this environment with your ridiculous uber-viral and unusable AGPL?
Code quality
But hey, it’s Ruby on Rails project, and considering how good these programmers boasted to be, they for sure have a decent test suite that could be used in writing one’s own implementation of at least the protocol. A test suite covering all the code that’s so awesome that in fear of having it forked and not released they had to AGPL the shit out of it.
Libraries, gems and “gems”
I’m not going to rant about specifying Bundler version in the Gemfile — it’s dumb and redundant, but only since recently and maybe they just play safe.
But let’s go further into Gemfile.
Devise for authentication? Cool! Unfortunately not the original one from Jose Valim but some BadMinus fork that’s already three months behind the upstream.
And these two entries from Gemfile kind of speak for themselves:
gem 'mongo_mapper', '0.8.4', :git => 'http://github.com/jnunemaker/mongomapper.git'
gem 'jnunemaker-validatable', '1.8.4', :git => 'http://github.com/jnunemaker/validatable.git'Using a released version of given gem while, at the same time, manually giving path to git repo (the official repo from which gem is released on rubygems.org)? Could someone explain that to me? I don’t consider “so that you can clone the whole github repo instead of using a gem already installed in your system gems” a rational answer.
Test coverage
There are some tests (rspec, to be precise). I haven’t read them thoroughly, but the test suite seems kind of sparse. A few tests are better than none, anyway. Still kind of weak for a statement “all commits must be tested” being placed on the first page of README file — how about you, dear Diaspora team, adhere to these rules first?
Focusing on what’s important
Data storage
Diaspora uses MongoDB as its primary data storage. Now I’m all hyped about MongoDB and absolutely love it’s approach to interfacing and storing data, but let’s get it straight: MongoDB doesn’t have any implementation of single-server durability as for now and countless flamewars have been burning recently on the internet about that. It’s been scheduled to be implemented though (I guess as a result of these flamewars: that was really some bad press which slowed MongoDB adoption), but still not there.
MongoDB documentation basically recommends using replication as a mean for durability. And this is a sound of thousand DBAs facepalming when hearing about such reliability model.
Now, I know social network isn’t a bank, but not having a single-server durability is a show-stopper for me. I’m not going to deploy Diaspora with two MongoDB servers — Diaspora was supposed to be distributed as in “you can run it for yourself and few friends on a inexpensive VPS”.
I’d prefer to have a SQL db as a primary data storage (tested, reliable, bulletproof and elastic technology) and MongoDB (if having to be used) as some sort of frontend-data/caching/denormalization layer (think wall post with all the comments and authors embedded etc.). Currently MongoDB just isn’t reliable enough for being a primary data storage for a serious service running with single DB server, period.
Protocol
There is no specification of the Diaspora Protocol — a basic thing required for any other diaspora-compliant social networks. While, as far as I remember, there were a few — including Facebook — wording their interest in being a diaspora-compliant application.
Now, I understand being Agile and shit, but not specifying the protocol that is supposed to be the killer-feature of Diaspora up-front?
Oh yes, I’ve tried to guess the specs from the code. Which made me stumble upon such “gems” like XML built with string concatenation:
def to_diaspora_xml
xml = "<XML>"
xml += "<post>#{self.to_xml.to_s}</post>"
xml += "</XML>"
endSeriously, it’s 2010. Ruby XML::Builder (or, at least, XML ERB templates) being a de-facto standard in the Ruby world since at least 2006.
This XML is also not XMPP. Which is even more disappointing.
Apologies
I now oficially apologise all the people I’ve been advertising Diaspora to. I guess I got my lesson on being excited with unreleased software.
Soothing balm
It’s a rant, but don’t get me wrong and don’t throw Diaspora away. I am not, as it’s still a very promising software.
It’s not that the Diaspora team hasn’t released anything: the guys have released a basically working proof-of-concept. All the technical issues mentioned above are solvable and the codebase has the potential for being great. Hell, I’ll gladly hack on Diaspora and help improve the codebase (I’m still excited by the idea).
Under one condition.
Change the goddamn license. Throw the brainfucked AGPL in favor of something usable like MIT.
Edit
The disenchantment is pretty wide on the internet, mostly about the batshit insane license choice — here’s one from Jarin Udom,