Diasappointment

Diasappointment

16 Sep 2010 – Warsaw

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!

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.

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?

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:

Seriously, it’s 2010. Ruby XML::Builder (or, at least, XMLERB 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.