There is so much to discuss around this and it’s not even out of the lab yet. In a rare display of focus, I’ll devote my first post on the topic to one of the more obvious questions – Can they (or do they need to) get 400 million people to migrate away from Facebook?

The idea of a decentralized, open source social network where you truly own your data appeals to many a privacy-concerned geek, but I think perhaps the announcement of Diaspora and their rapid public funding is timely more than anything. After the F8 conference Facebook are predictably under the spotlight again – this time there’s even infoporn - See: Mat McKeon and the New York Times.

So we’re all ‘concerned’ about our privacy, and maybe even what Facebook are up to in general, but as Fernando Rizo muses on his blog today, are you going to quit? No, of course not. Well, not without a decent alternative, because you don’t want to miss out. (See FOMO). Well let’s assume for a moment that Diaspora becomes that alternative – what then?

Tipping the other way

In theory I don’t see a reason the Network Effect can’t work in reverse. It takes early adopters to populate a site like Facebook in the first place – perhaps a trend in rejection could result in a tipping point in the opposite direction. If you joined Facebook because your friends did, and they went somewhere else – you’d eventually go too. Somebody has to go first of course.

I grumble about Facebook all the time, but I use it as much as the next guy – in fact more than most of my friends. I don’t want to shut my account down. Going cold turkey would be a serious commitment. I think for this to happen for me there would have to be some kind of transitional phase.

If Diaspora allowed me to view and publish content to and from Facebook, that would surely defeat its primary function. You could argue that it depends what the content was, but it would still mean keeping my Facebook account active. It might however be a way to soften the blow, and at the same time entice my peers into migrating too.

I don’t have the solution, (and I probably don’t understand the problem), but many of us are far too attached to our digital homes for this to be a clean break. As Fernando points out we’ve seen mass migration before (away from MySpace) but I’d say it’s a bigger deal this time. I remember quitting MySpace (~2007) and I really didn’t miss it. I had a handful of photos and about 30 friends. It was also incredibly annoying. Despite my moaning, I really like Facebook, it’s a very usable site and there’s vastly more content than I had access to three years ago.

Would an exodus be necessary?

Diaspora are proposing a hosted, turn-key option for their software (a la WordPress) and perhaps, as is common with open source products, providers will be permitted to package up and sell the product themselves in a healthy, competitive fashion. To move 400 million people over to Diaspora, this would surely be essential – how many Facebook users know what a GPG key is?

I joked earlier (complete with typo) that if Diaspora took off, perhaps Facebook could move to a hosted-Diaspora revenue model. Perhaps this wasn’t such a joke. Facebook need your data to profit, if you’re going to abscond and not give them any more data and not look at any more ads, then a premium service where you can interact with your friends without getting ‘graphed’ seems reasonable to me. The privacy concerned few could pay, while the complacent masses continue to trade their personal lives for a free ticket.

I’m thinking out loud and probably sound like an idiot, but I’m hungry and need to go home…. just gotta check my Facebook.

If you haven’t read part 1, it’s there for the reading, and puts this post in context.

I figure the best place to start is where the title of this series comes from: I am a control freak; in life and so in code. This is not a very positive thing to say, but in terms of my personal skills development I feel it’s important. I don’t like things that just work; I have to know why.

There is a button on my washing machine that says “anti-crease“. This bugs the hell out of me: When would I not want this setting on? What’s the trade-off? If it creases my clothes less, then what is not doing? Is it cleaning them less?

The knowledge gap

When I’m using a third-party code library I often at some point hit a brick wall. I’ve read the manual, I’ve done the examples and maybe even had some great success with it. And yet all of a sudden there’s an error; It means nothing to me and it’s coming from a part of my program that I did not write. I might try uncomfortably to debug the code, I may at a stretch even resort to hacking it, but most likely of all I’m going to hit the forums. I do not like spending my day on forums.

So there is a rational side to my reluctance to use third party code: when you write your own libraries you are investing in priceless knowledge that empowers you to fix bugs, and generally take more control of your product as a whole. Obviously this is at a massive time cost, and that is generally the biggest factor to weigh up. Do I want to write my own 3D library for Flash? No thanks! What about a light-weight template system for PHP? Yeh, maybe.

Whether this argument stands up or not, as I investigate deeper into my control-freakery it gets much less rational and just plain personal.

An anecdote about AMF (Action Message Format).

AMF is magic. You send a request off from Flash and bingo – your PHP code has executed and Flash magically has a response in its native tongue. Everything in between that made this happen just worked. This is abstraction at its finest; the problem is I just can’t stand it!

To make matters worse AMF is binary; that is to say that it is not human-readable. Using (the divine) Fiddler proxy you can switch to hex view and make out some of the text characters being sent, but in general the protocol is not friendly for this level of debugging. When something goes wrong you need the tools and the knowledge to be in control of this mysterious beast.

Enter the third party: The obvious choice of AMF library for PHP used to be amfphp. This project has since been absorbed by the Zend framework, but I’m afraid my anecdote is a year old.

What I wanted from amfphp was literally a library; just a set of functions like amf_serialize, amf_get_header, stuff like that, so I could build a request gateway into my wider application. What I got was something that behaved more like a framework providing what appeared to be a totally sealed end-to-end process. My application ran on its own framework, so what I ended up with was two code bases, both saying “I’m the daddy!”. I’d set up an error handler; amfphp would override it, breaking my code. I’d start a session; but amfphp has already started one, breaking my code, and so on.. and don’t get me started on __autoload!

Looking under the hood of amfphp, it did not look like I could easily separate its infrastructure from its superstructure. I guess I just didn’t know nearly enough about AMF. This gave me an itch I just had to scratch.

Should I build my own?

I agonized over whether this was the right decision and came to the conclusion that it wasn’t.

So I did it anyway.

Work started by reading the (rather sketchy) AMF specifications published by Adobe. I did this on the tube for a week. After reading them several times I predictably decided that it was very doable and I would learn a lot from it. A small Flash project kicked off at work with an AMF back end, so every evening for a week I hammered out my own library.

By the end of this project AMF was no longer a mysterious, magical thing that just worked. It made actual sense, I could control it better, and I was able to add features to our projects such as debugging tools. I even discovered that I could harness parts of the protocol that I would not even have known about simply by using amfphp.

My library was never fully completed, and I’m in no doubt that it is inferior to amfphp in many ways, but that’s not the point. It was a reminder to myself that this is why I’m a control freak – to be in a position of power and not a slave to tools available.