Fishpool

Diverging slightly from my usual topics, Koushik Dutta's post prompted me to put into writing what I've been thinking for a while about the future of both public and private transportation. People reading this blog have probably all heard by now that driverless cars are coming along nicely, and that Google has already demonstrated a vehicle capable of autonomous road traffic, at least while being supervised by a human. This was announced a year ago.

Now, the technology certainly isn't perfect yet. It's debatable how perfect it needs to be, in order to be better and safer than a human driver, but we can probably agree it's not quite there yet. It's also quite clear that communities and regulation will have a hard time swallowing the idea of 2-ton lump of metal going about without a driver in a city at deadly-to-pedestrians speeds (anywhere 40km/h upwards would qualify), let alone perhaps while carrying children. This is not happening in the near term.

At the same time, there are problems the technology already is capable of solving, and I'm not talking about reducing highway inter-car braking distances or autonomous warehouse navigation, both of which are already in place for some high-end models, and factory automation, respectively. No, I mean daily problems on the streets of every metropolitan area.

In my home town of Helsinki, traffic isn't really a problem. There are a few places where, for 25 minutes in the mornings and 30 minutes in the afternoons, traffic slows to an average of 15km/h rather than 30. However, downtown parking IS a problem. I've long conjectured that if only 10% less people wanted or needed to park in downtown, there would be no parking problem. Where you now have to drive around a couple of blocks to find a space, there would be 5 free spaces in every block. That's more than enough. This is the nature of bottlenecking issues - you don't have any, until you do, and then it's bad immediately.

Public transportation will not fix parking, because public transportation will go from every place to every other place, and allow people to conveniently transport more than they can carry themselves. People need cars for these purposes, as well as for many conveniences. Yet every private car spends an overwhelming majority of its lifetime parked. This is why parking is such an issue. In a city like Helsinki, we don't really need less cars, we need less parked cars, and that can also be solved by having more of them on the road. The bottleneck would obviously move toward traffic conditions, but there will be a sweet spot.

What if you could have a car of the size you needed, at the time you need it, at costs much lower than constant taxicab use? If you are an in-city occupant, as I am, would you care to own a car, with all the associated worries of insurance, maintenance and so forth, even if parking was no longer a problem? I would not. Well, I don't own a car as it is, so I don't qualify for the question, but what about you?

Collective car services have sprung about in the recent years in many municipalities. We have City Car Club, Zipcar is known across USA, and so forth. Yet a problem with these services is that the parking spots the cars are at are not immediately adjacent to most people, and the companies need relatively complicated logistics for making sure cars are available in all places. This means that the customers need to often reserve a car ahead of time.

But what if cars could take themselves from where there are too many, to areas where there are fewer, and to customers who need one immediately? You could have exactly the kind of car you need at a couple of minutes of notice, just like you can have a taxicab in most places where there are enough of those.

And what does all of this have to do with community acceptance? Well.. Lets accept as a given that it'll take a while before we'll be ready for automated cars carrying passengers around on streets where people are driving, moving at regular traffic speeds. But what about having empty cars move themselves through preassigned routes, on specific lanes, at lower speeds, yielding to all human traffic? How many municipalities suffer from too many cars around bad enough to consider arranging for those special routes? I'm guessing there are a few.

This is a disruptive thing, and to many different industries at once. Car companies will need more service capability and less manufacturing capacity, if more and more of private cars resemble taxicabs in their replacement and maintenance schedules. Taxis will be challenged by automated cars, but only when the passenger is willing to do some driving themselves - and many taxi customers are specifically looking for not just a car, but also a driver. But public transportation will also be challenged, because for many, the choice between a car and public transport is a balance between the inconveniences of longer pedestrian distances and indirect routes versus finding a parking spot.

It's been about a year since I put my prognosis skills on the line and tried to predict where technology and consumer products are heading. Since today is National Fail Day in Finland, perhaps it's time to try again. Lets see how right or wrong I end up being.

Last year I noted a couple of things about mobile platforms and of the software environments best suited for creating apps on them. While this year has seen a lot of development on those fronts, little of it has been in surprising directions. HTML5 is coming, but not here yet. If WebGL and Intel's River Trail project were supported by the Big Three (IE, Firefox and WebKit, ie Safari/Chrome), that'd make an amazing game platform - but at least the latter is research-only at this point, and IE9 isn't going to support either. In the meantime, Adobe finished Flash 11, which now has hardware-accelerated 3D in addition to a pretty good software runtime, and, after only 10 days out, already has 42% reach for consumer browsers (at least judging by stats on habbo.com). Like I've said a long time, Flash gets a lot of undeserved crap due to the adware content created on it. We won't get rid of that by changing tech, and platforms should be judged by their capabilities in the hands of good developers, not by mediocrity. And, as far as mobile goes, the trend continues -- iPhone and Android battle it out, now also in courts as well as in consumer markets, while everything else falls under the wagon. If you're creating an app -- do it either with a cross-platform native toolchain, or with HTML5. If you're doing a game, do it with Unity or Flash, and build a native app out of it for mobile.

The interesting thing, to me, is playing out on the Internet. Google+ came out as a very nice product with well-balanced feature set, but (fairly predicably, though I was rooting for it) failed to catch the early adopter fancy for long enough to displace Facebook in any niche. Facebook, on the other hand, scared (or is going to scare) 40% of their audience by announcing Timeline (eek, privacy invasion!). Brilliant move -- you can't succeed today without taking such leaps that nearly half of your audience will be opposed to them, at least initially. Smaller changes simply aren't meaningful enough.

So, I'm betting on Facebook. I'd also guess that once they get Facebook Credits working outside of the Canvas, they're going to demand that any app using Facebook Connect log-ins will accept Credits for payment. I'd hazard a guess they're even going to demand FB Credits exclusivity. They'll fail the latter demand, but that won't stop them from trying it. Having your app's/game's social publishing automatically done by Facebook simply by feeding them events, and not having to think about which ones are useful to publish, is just such a big time saver for a developer, no one will want to miss out on it.

Not even Zynga. They're doing this destination-site, we're-not-gonna-play-inside-Facebook-anymore strategy, but continue to use Facebook Connect for log-ins. That's not because FB Connect is so much more convenient than own username and password (though it is), but because even they can't afford to let go of the "free" access to people's social network. That's the power of Timeline and the new, extended Graph API.

The chips are still in the air. When they fall, I think Facebook will be stronger than ever, but strong enough to displace the "rest of the Internet"? No. As a developer, I want to push Facebook the data for in-game activities, because that saves me time doing the same thing myself. As a publisher, I'm unsure I want Facebook to have all that info, exploiting them for their purposes, risking my own ability to run a business. As a consumer, it makes me uneasy that they have all that info about me, and while I can access and control quite a lot of it, I can't know what they're using it for. I don't think that unease will be enough to stop me or most other consumers from feeding them even more data of our lives, likes and activities. Still, they're only successful doing this as long as they don't try to become a gatekeeper to the net - nor do they need to do that, since they get the data they want without exerting control over my behavior. Trying to fight against that trend is going to be a losing strategy for most of us - possibly even for Google. Apple and Microsoft won't need to fight it, because they're happy enough, for now at least, to simply work with Facebook.

Apparently today the pundits and analysts around have come up to reviewing Zynga's ARPU figures from their S-1 filing (Inside Social Games, Eric von Coelin). Something seemed fishy in these calculations, and since I'm home for a day, I had the opportunity to review the filing figures on a computer, rather than just a tablet. Yep, people, you're comparing apples to oranges. Zynga's monetization rate is improving, but it's nowhere as dramatic as you're making it look. Did you already forget, they defer revenue? You can't compare GAAP deferred revenue to non-deferred DAU/MAU figures! Use the bookings data instead.

This is what the S-1 filing states about the difference:

"Bookings is a non-GAAP financial measure that we define as the total amount of revenue from the sale of virtual goods in our online games and from advertising that would have been recognized in a period if we recognized all revenue immediately at the time of the sale. We record the sale of virtual goods as deferred revenue and then recognize that revenue over the estimated average life of the purchased virtual goods or as the virtual goods are consumed. Advertising revenue consisting of certain branded virtual goods and sponsorships is also deferred and recognized over the estimated average life of the branded virtual good, similar to online game revenue. Bookings is calculated as revenue recognized in a period plus the change in deferred revenue during the period. For additional discussion of the estimated average life of virtual goods, see the section titled “Management’s Discussion and Analysis of Financial Condition and Results of Operations—Revenue Recognition.”

Zynga is of the opinion that bookings more accurately represents their current sales activities, and I fully agree. After all, this is not subscription business we're talking of! If you're as hard-core geek about these things as I tend to be, the description of when a booking turns into revenue is discussed on pages 62-63 of the filing: 

"Durable virtual goods, such as tractors in FarmVille, represent virtual goods that are accessible to the player over an extended period of time. We recognize revenue from the sale of durable virtual goods ratably over the estimated average playing period of paying players for the applicable game, which represents our best estimate of the average life of our durable virtual goods"

That deferring means that during periods of rapid growth, ARPU monetization appears to decline, while on the other hand periods of flat or declining traffic would seem to improve ARPU, due to the recognition of earlier deferred revenue against current, not earlier userbase. 

With these covered, what are the actual sales figures? The average daily Bookings to DAU rate is somewhat higher than the Revenue to DAU rate, at $0.051 (B) in Q1 of this year vs $0.042 (R). Both seem to have plateau'd on that level since growing from a year-ago $0.030 (B) / $0.017 (R). Respectable, but not earth-shattering -- and the growth, while impressive, isn't quite "more than doubled".

A week ago Thursday, I gave a presentation in Malmö on Nordic Game Conference's second day on a couple of related topics, slides below. I spoke about the lack of truly social interaction in this generation's "social games", and reflected on what a social game where players actually play together looks like. As you might guess, Habbo has been a social playground for a long time.. 11 years, in fact. The slides themselves are, typically for me, a bit difficult to understand since they're mostly just pictures. You should've been there :)

..and I'm not even referring to the multitude of website passwords this time. I thought earlier OpenID would be the fix to those, but apparently not -- perhaps OAuth 2.0 and Facebook will be, though.

No, this time I'm talking of personal computer passwords. I don't have a huge amount of recent first-hand experience with how Mac and Windows work in this department, but the Linux/GNOME experience, connected to some presumably sensible company network access control, is certainly busted. Or, perhaps it's just me, and I'm doing something wrong - in which case, I would love to hear from someone who knows how to do this right.

I have:

1. an encrypted home/user partition on my laptop hard drive, for which I have to type in a password to get the computer to boot. Never mind that the operating system partition (which doesn't contain anything secret, since the OS is downloaded off of Fedora Project's web site) isn't encrypted, so the computer ought to be able to boot without the user partition password -- it doesn't. That's a separate peeve. This is password #1.
2. a password for my user account, since GNOME login facilities seriously under-appreciate using an account without a password. Never mind that I already proved who I am by typing in a password during boot - well, the last boot that was on average 19 days and 78 suspend-resume cycles and 42 laptop-bag trips ago. As far as I can tell, there is a valid reason for having this password, though I could imagine switching that to fingerpring recognition. Password #2.
3. a password for the GNOME built-in passphrase storage keyring, which automatically collects things like network WPA passphrases, ... well, that's about it, really, but anyway, it makes life somewhat bearable. Password #3. In fact, all that stuff is actually stored in a keyring with a very long random string as a key, and a separate keyring holds a copy of that, locked using the password #2 -- when things work. This is what is supposed to let me type in a password once, and have the system usable.
4. a password for my company account which lets me in to things like the intranet. One of many, many, many work-related passwords in various systems, internal and external (mostly external), which are infeasible to synchronize to one-time authentication at least today. This one is special though, because it's practically impossible to get any work done without it. Password #3 (I didn't count the one above, because it's not supposed to exist).
5. a KeePass keyring pass phrase, because the GNOME keyring a) doesn't have decent UI so it could be used for manually managed passwords b) because of above, there are many of those c) that I need to also use on other devices, so this keyring is synced to those devices. Password #4, for those who are counting.

That's just the start, but without these, nothing works. Now -- password policy best practices often say that passwords must be changed periodically, in order to ensure various guarantees of dubious value. I ask you this - what happens, when one of the above passwords must be changed?

As good as my memory seems to be with random alphanumeric strings of letters and digits, I simply can not maintain four of them in memory along with the credit card PIN, phone number PIN, VPN token password, GMail password, Facebook password, and so on an so on, if I'm supposed to also get any work done. Especially not if one needs to be swapped out to a completely new random thing every now and then. So, I do what any human would do: try to minimize their number.

Because I'm relatively security conscious, I don't do that by using the name of my childhood pet on every system from the most security sensitive to every second web site that appears to require its own password. No, what I do is try to use the same password in all five of the above cases, because a) they're all needed in sequence anyway, b) I can't do effectively anything without access to all of them. I still need to type it way too many times, but at least that keeps the memory fresh.

Except -- changing any one of those places doesn't change any of the others. Not even the supposedly-integrated 1, 2 and 3. So, I end up with 5 instead of 1, and I don't know which is which. New "enter password to keyring 'default'" dialogs pop up on my desktop, prevent anything else from receiving any keyboard input, accept nothing as a valid password, and prevent me from working for 45 minutes. 

I did figure out how to solve it, though -- prevent GNOME Keyring from accessing the 'default' keyring (for which there is no typable password to begin with), force it to change its login password to the new login password, and then re-enable access to the main keyring with all the WLAN pass phrases and other assorted stuff. However, it still wasted a lot of time, and would probably have stumped anyone else I know (I'm pretty hard core with this crap, sad to say).