This is the latest in a series of limited perspective movie reviews. These reviews, inspired by a Letterman bit, look at only one narrow aspect of a movie, related to software engineering or software business.

SPOILER ALERT: These reviews assume you have seen the movie.

Here’s Inception, Twilight: Eclipse, Twilight: Breaking Dawn, Star Trek, and Alien.

Before I wrote this review, I researched the novels of Frank L. Baum, and I was surprised to learn that he came up with the idea of augmented reality in his book, The Master Key. Following that thread, I found another AR reference in his writing—this time in The Wizard of Oz. It turns out that in the book, when Dorothy enters Emerald City, she is given glasses that only make it look like the city is made of emerald. Unfortunately, Oz is a faithful prequel to the movie, not the book, so its Emerald City is actually made of emerald too, which sucks because in my head, I was already photoshopping Google Glasses onto a picture of James Franco.

Instead, I’ll concentrate on the one big use of advanced technology, the wizard’s “ghostly head” effect. If you remember the Wizard of Oz, we first see the wizard as a ghostly head appearing in smoke.

Later, this is revealed to a projection from a complex machine operated by a man behind a curtain.

In Oz, we get a little insight into this machine. It’s implied that it was inspired by the Projection Praxinoscope.

He combined the idea with Phantasmagoria, which is the projection onto smoke.

The thing is, in both of these technologies, you need to put the image on a transparent slide to shine light through. In the wizard’s case, he was able to project his live head (not a series of still images). I see no reference to this technique anywhere, but it’s a plot point that he’s being helped by The Master Tinkerer (who, in the novels, created the Tin Man), so we can assume that he could invent something.

The only thing I can think of is using a one-way mirror somehow. When I researched that, I found Pepper’s ghost:

In this case, you are looking through a view-port (red rectangle) at an angled one-way mirror (green rectangle). The left area is out of view, and shows up in the mirror when it is lit.  You make the ghost appear and disappear by raising and dimming the light in the off-stage area as compared to the area through the mirror.

So, it’s not a projection, but I could imagine a master tinkerer and Oz (who is himself a master in prestidigitation), could figure out some way to combine these technologies (all available in the late 1800’s) to a new live smoke projection effect.

What I can’t imagine is how the older wizard is able to upgrade this to show the green, bald head instead of his own.

When I read this about Climber (a new iPhone app that lets you post short videos to App.net):

Our video pages simply rely on App.net post data to retrieve links to video files contained in personal App.net file storage. If a user chooses to delete their App.net post, or even just delete the video file in their file storage, then it can no longer be viewed on our website.

It struck me that the full cost of the back-end of this app was being paid for by the user. Until this, developers typically paid for a back-end or relied on free services.

When the developer paid, they had to deal with their app having a low, fixed life-time value, but unbounded costs. They either added a premium subscription service (Evernote), in-app currency (mostly games), or ads. Another common solution was to get acquihired before it imploded and have the new owner assume the costs (Instagram) or shut down the app (nearly everything else, but recently, Summly).

If they relied on free services, then they risked the service going away. Mobile RSS readers that treated Google Reader as a sync-service now have to either create their own or see what develops. Twitter client developers got hit with limited user-tokens.

App.net is offering another choice — Bring Your Own Back-end (BYOBE) — where they sell the user on the benefits of a backend and deliver less value to the developer (for a lower cost).

BYOBE isn’t new with App.net. Salesforce users have Apex, where they can find 3rd party apps that run on Salesforce servers. Apex app developers do not have to build out infrastructure for their applications if they can stay within Apex guidelines. In some sense, Evernote premium is also BYOBE for 3rd party applications. In fact, any app developer who solves their business model issue with a subscription service, can also transition to being a BYOBE provider. I’d put Github, Dropbox, and many others into this category.

But, App.net is nearly a pure-play BYOBE and is planning on something more general purpose than what we’ve seen. In the founding documents of App.net, Dalton Caldwell wrote:

As I understand, a hugely divisive internal debate occurred among Twitter employees around this time. One camp wanted to build the entire business around their realtime API. In this scenario, Twitter would have turned into something like a realtime cloud API company. […] I think back and wish the pro-API guys won that internal battle.

The price for developers is a flat $100/year. App.net gets its variable revenue from the app’s users as they must subscribe in order to use any app on top of the infrastructure. It’s tempting to think that they are paying for Alpha (their Twitter clone), but that’s just an app built on the infrastructure — they are paying for API usage, not Alpha.

App.net is not a paid service for mobile application developers — App.net is a paid service for mobile application users. The closest thing I can compare it to is iCloud, where users pay for iTunes Match or more storage, but developers get a syncing API to build on (or will eventually, when it works).

The benefits to users are clear (they are now paying, so they accrue some value)

• They control their data
• They aren’t sold to advertisers
• They can plan on some sort of longevity and consistency

Developers, who now have lower costs, also get less value.

• They give up control of the user and user data
• It would probably be harder to independently charge the user another subscription

They do get a service they can count on, but they could have that with Parse, Kinvey, AWS, or any number of paid back-end as a service companies. Most of the developer benefits are over free services, which I don’t think make sense to build on.

I certainly see why I’d want to be an App.net user based on this — but, since I don’t want Alpha (or message feed based services), it will make more sense when the app market is more diverse (not a bunch of Alpha clients).

As a developer, this model appeals to me because I think of this space more like a hobby — I would definitely forgo control to not have to think about or pay for the back-end. It would be even more interesting if App.net had a payments option or revenue share. Rather than Twitter’s limit of 100,000 user tokens, App.net is incented to reward a developer who gets that kind of traction. This brings costs to developers even lower (perhaps negative), and transfers value to themselves and users (they keep control of user payment data, and users have one bill).

I certainly don’t think this is the right mix of values/costs for every user — the key will be if the user thinks of themselves as having paid for an app and then get the services (and the other apps) along with it. Then, each different app category brings in different users. For example, it feels like Alpha costs $36/year, but what if you paid $36/year for your (let’s say) project management app, and just got Alpha for free? If Alpha is ever to have an enormous user-base (who all still pay for App.net), it has to be because they think they are paying for apps.

If there’s any kind of model for this, it’s the fact that I buy a data-plan for my phone and bring it to my apps. App developers do not have to sell me a data-plan. I buy electricity for my toaster, water for my shower, gas for my oven — consumers are no strangers to buying infrastructure.

Come to think of it — is this the natural order? The main alternative is turning out to be infrastructure subsidized by ads.

This is part of my ongoing series of extremely limited perspective movie reviews:

Previous Reviews:

• Star Trek from an ECM Perspective
• Twilight: Eclipse from a Social Media Perspective

Like the previous ones: SPOILER ALERT. Inception is the kind of movie where you might not want to know anything going in. So, please don’t read further if you don’t want any part of the plot spoiled.

In Inception there’s an elite team that can infiltrate your subconscious while you’re dreaming and extract secret information while your defenses are down. The plot of the movie is set up when someone asks them if they can do an “inception” where they plant an idea into a victim’s subconscious. Since the idea is detrimental to the victim, they must somehow convince him that it is his, and that it will be good for him to follow through with it.

Obviously, extraction directly relates to data security, and the attacks and defenses that are discussed in the movie have analogous ones in the security world. An obvious one is a honeypot and how it relates to the labyrinths that the dream architects construct.

[Honeypots] computers run special software, designed to appear to an intruder as being important and worth looking into. In reality, these programs are dummies, and their patterns are constructed specifically to foster interest in attackers.

Creating a honeypot is like “taking two minutes to create a maze that takes a minute to solve.”

Things like a “militarized subconscious”, “totems”, and “forgers” have counterparts in the network security world.

But, what about “inception”? After thinking about it for a few minutes, I remembered this story from WWII. In 1943, the Allies wanted to convince the Germans that they would attack through Sardinia, not Sicily, so:

The idea, very simply, was to get a dead body, equip the dead body with false papers, and then drop it somewhere the Germans would find it

[…] And it was an elaborate creation: the fictitious Major Martin was equipped with ticket stubs, keys, a religious medal, letters from an imaginary father and fiancee, and unpaid bills. Cholmondeley and Montagu thought that the more convincing his personal story was, the more likely the Germans would be to believe the ruse. And along with the personal items, he carried carefully faked letters hinting that the Allies were planning to invade Greece and Sardinia, not Sicily.

But, this is not a computer attack. While the idea of data tampering is nothing new, I haven’t heard of a tampering attack with the intent to mislead someone into making a bad decision. Data tampering is often used to gain access for another purpose or to cover up tracks (e.g. log tampering).

But, I suspect that this is a real threat as well. One so good, that it  often goes undetected.