Paying for Social Networks

This week I was introduced to – and in turn introduced some others to – Branch. In case you're wondering what it is (I did, my first comment was "what is it?"), Branch is a new conversational tool, i.e., somewhere to hold conversations easily, in public or in private, with a branching model borrowed in spirit from Git (the revision and source control system). It's not Just Another Social Network, like one of my friends feared ("who has time to check another social network?"), but another comment indicated that it does have some things in common with social networks: "how is it going to be paid for?". This question lead to a discussion about how, and if, we should pay for social networks, that took place largely on Branch. Here, I've summarised what I said and what I learned. I realise this may go against the point of Branch in some people's minds, but for me this is exactly what it's great for: a place to hold a discussion where ideas can bubble and formulate.

I began the conversation with three ways I'd be happy to pay for a social network: 1) Pay for a good native client(s) (and leave the web version free) 2) Pay to have no ads (and allow others to use for free with ad/sponsored stuff) 3) Pay to have read/write access (allow others to read-only for free).

The main issue with the first of these was sustainability: once everyone's bought the client, how do you continue to fund the service? I'd be interested to know how Instapaper's model of an optional subscription charge works for this: I suspect that for a niche app with a cult following this could work, but it probably isn't a model most companies could follow.

Two main points arose from number two: firstly, if you're opting out of ads, are you also opting out of being mined for advertising data? Secondly, current print and broadcast media charge and show you ads anyway, and have been doing so for years.

The opting-out of being mined point is interesting: I know that some people would want to be able to opt out of this for privacy reasons (although I don't really see how you privacy is being challenged: perhaps for 'moral' reasons is a better way of putting it). Personally, though, I don't think I care if my data is mined, so long as I don't see the results, i.e. ads or promoted stuff in my news or social feeds. If a company wants to work out that in general people who talk about smartphones also talk about coffee, and so start to make cool phone-coffee holders, or billboards showing phones with coffee, I'm not sure I really care. As long as I can pay a small fee and not see an advert for CoffeePhone in my inbox, I'd be happy.

The second point about paid-for services also having ads: I'm not so sure. It's true that newspapers charge and also carry advertisements, it's also common knowledge that the cover price of a newspaper doesn't cover it's cost: the advertising does, so I'm not sure they are really doing both. HBO have proven there is a market for a premium price point with no sponsorship. One issue here though is that there is nothing stopping a service from starting with some pricing tier for 'no ads', and this then morphing into 'some ads', and a new tier of pricing being introduced for 'no ads' again.

The final option – pay for read/write access but allow for reading – is I believe what App.net do right now. When I first suggested this idea, I didn't know that they allowed this, and this unfortunately negates my idea. I haven't read a single thing on App.net since realising I could, and so it's hardly sucking me in to their world. And as someone else noted, this was the model Friends Reunited used. ("Nuff said.")

We shouldn't completely discount the model though, App.net got 10,000 backers before launching (and has already grown to around 17,500 now that they have launched) so some people clearly are happy to pay.

Which brings us back to the original proposition: should we be paying for social networks at all? I think that now we have them, we're going to be using these sorts of services – social networks and conversational tools – in one form or another, for the foreseeable future. But wouldn't it be a shame if we are constantly moving from one to the next like we are now, trying to stay ahead of the latest companies evil profit-making ways? Wouldn't we be better instead to agree on the protocols, then pay our personally chosen provider for a decent service? Like we do for landlines, and broadband and electricity. The U.S. has been plagued for years by non-standard services, and here in the U.K. for the most part we've been spared that (although that has been because of nationalisation). I don't want to live in that frontier world where the train gauges don't match up and I can't connect across to another phone because it's on another network. And I don't want to have to keep jumping from service to service riding the free-wave: I've got better things to do with my time (no, really!). We're getting to the age where social networks are growing up, and maybe our attitude to paying for things needs to grow up with them.

Thanks to Steve Pettifer (@srp), James Lewis (@jameslewis), Tim Marshall (@pixelcellar), Simon Dell (@simon_dell) and Claire Miller (@RedDread) for participating in the discussions this post was based on.

Update:

Here's a link to the original branch!

Making UIManagedDocument a little safer

On a recent iOS project, we had an issue with relationships between managed objects disappearing at the moment the document saved itself. The problem, it turned out, was that we were holding onto an object after immediately after creating it, and then later on setting up relationships between it and some other new objects. The ID of the object changed at the moment the document saved, and so the relationship no longer held. I found the crux of the issue by way of an excellent suggestion from Steve Tibbett's blog, which gives some great tips on troubleshooting UIManagedDocument's autosaving. The solution we came up with was to call:

+ (BOOL)obtainPermanentIDsForObjects:(NSArray *)objects error:(NSError **)error]

on the managed object context after creating each object, to ensure that its ID didn't change later (when saved). I first solved this with a subclass of NSEntityDescription with the following overload:

Solution A

I have, however, just revisited this issue, and I think that a category is a little tidier and safer. Rather than having to remember to always us theNSEntityDescription subclass, you can add the category to your pre-compiled header, and then you always have the new methods available (and the old one, in case there are times you don't want the extra complexity of the permanent ID version).

Solution B

An iOS Developer's View of the New Microsoft Way

A few week's ago I heard about a new meet-up being organised around Metro: I rarely come across Microsoft technologies that excite me nowadays but this one has piqued my interest. For the uninitiated, Metro is Microsoft's new vision for the Post-PC (not their words...) world, and this vision brings the worlds of mobile and desktop much closer than before, hence my curiosity. During the evening we would hear from both seasoned Microsoft developer and writer Matthew Baxtor-Reynolds, and an evangelist from Microsoft themselves. I went along – feeling weirdly like I was a spy infiltrating enemy lines – and here's what I took away from the night. Primarily aimed at .Net developers looking for an introduction to the new world of Metro, the evening was a great way to find out exactly what Metro is and is not, and what Microsoft and Microsoft developers think its role is. Spoiler: these two sometimes disagree.

Metro

Metro is not a new operating system. It is just – albeit a big 'just' – a design aesthetic. You're no doubt familiar with it already, even if you don't realise:  it's what Windows Phone 7 uses. Metro is bold colours, square corners, active tiles, san-serif fonts and naturally-flowing text. It's actually really nice.

So if Metro is just a design, what's so new? What's the exciting OS, the new APIs that will soon span mobile and desktop? That will be WinRT, and WinRT lives inside Windows 8. WinRT is the new Win32. What seemed very clear is that WinRT is the new paradigm that will come to replace Win32, in the same way that Win32 replaced MS-DOS., as Windows 95 replaced Windows 3.1. That's what the developers say, anyway. What I found quite amusing is you will absolutely not here that from Microsoft proper. This is understandable in some respects of course, in 1994 they wouldn't have announced discontinued support for their incumbent system. Microsoft is a company that on the whole likes to have it's old cake while baking a new one. When it suits them, anyway.

Which is king: Devices or Data?

The impression I got from the Microsoft evangelist who spoke at the event was that Microsoft have a clear and bold view of how we should use devices. And it's kind of the opposite clear and bold view of that other large tech company who make operating systems and devices. (Not Google, the other one.) The message I heard was this: one Windows device has many uses. And Windows may have many faces, but it's always Windows. You're on the sofa with your slate (his word, not mine) surfing with the kids or consuming some content (whatever that means). Then,  you remember you've got an email to write and a spreadsheet to work on, so you pop to your desk and plug in keyboard, mouse, printer and monitor. Away you go, spreadsheeting to your heart's content, the same device repurposed for another task. One device has many purposes. But there is only one Windows, even if it looks different for each task.

Apple, by contrast, have a different message, which I interpret as this: pick the device that is right for the task. A phone, a tablet, a notebook; choose what is appropriate and use that. The specific device isn't so important, what's important is that whatever device you pick up your data is always there. In Apple's world, you are your data, and that data will be available to you whatever you pick up or sit down in front of. It's a little like the thin-client that Sun so successfully (ahem) pushed for in the nineties, only the  computing power is now in the device, it's just the data that isn't.

Two different visions. And it's great that there are choices. I was once discussing dancehall with a ska DJ, and he didn't really like it at all. "It would be really boring if we all liked the same stuff, though" he said to me. Very true. Which means it's fine for me to have a strong opinion on which of these plans I think will work. For me, it's crazy to think that the device should be the thing moving around, not the data. Why? Because the device is a thing, and data isn't.

I really enjoyed the meet-up, and for me there were two take-home lessons. First: Metro is actually a really exciting new vision for Windows, and those targeting Windows Phone 8 should be in for a treat as the APIs available will be approaching those available on the Windows desktop: so they're richer than before, and migration to or from the desktop will be easier . Second: the message from Microsoft about what to do in this new Metro future is a confusing one, with no clear direction for current Windows developers. I heard it as: "Go for Metro, but also don't, depending on what your application is and what your market is". Maybe this is just the unfortunate legacy of the enterprise market that Microsoft are stuck with: no matter how great there new vision is, they just can't quite afford to jump toward it with both feet.