I think the trickiest thing to figure out is the business model. But I'm not a businessman, so I can't contribute any insight.
I do know a lot about tech, though, and it seems that most persons who are skeptical have misconceptions about what would be happening under the hood if this tech actually worked.
(ok, here's the part where I reveal that I've been an IT manager for 8 years but prior to that worked as a game artist, and I teach game art/graphics classes on the side. Oh, and I worked in a graphics research lab for a while too).
First, Streaming HD "video"...
OnLive says it's going to be 720p, not 1080p, which is more than twice as many pixels. They also offer to stream the games at 480p if your 'net connection can't handle the 720p.
But the more important thing to know is that is not streaming video. It's streaming graphics.
Video compression algorithms are very complex. Their job is to take a *flat* moving image and figure out what in there is an object, so to speak, and try to use that to make "layers" so that can further break down the image until it consists of rudimentary moving "parts", the motion of which are easier to describe. Anyhow, to the computer a video clip just looks like a bunch of animated paint smearing around; it cannot see it the way human vision can, which makes its job hard. In essence, the compression algorithm tries to reconstruct "the scene" in a video, because the video was, at one point, actually 3d (if we're talking filming actual reality).
Streaming graphics, on the other hand, is much easier since *you already have all the actual 3d information of what is contained in the image*. 3d games contain real 3d coordinates, and descriptions of how light interacts with the surfaces draped across those points in space.
If you've got that info, you can render frames in your game's engine directly to compressed video, instead of projecting on to a flat image, and then ask a video compression algorithm to "figure out what just happened" in that image compared to the previous one.
So streaming graphics, like streaming video, only sends the changes that occur between the current frame and the last (so entire frames are not sent every 30/sec), but streaming graphics knows exactly what is going to change, whereas streaming video has to make "an educated guess". And when is guesses poorly, you see video compression artifacts like macroblocks, fuzzy edges, degraded quality et al.
In short, much much more efficient, which is why the streaming aspect of OnLive is feasible, in my opinion.
Second, yes the interaction is two-way, whereas passive media is one-way, but it's not symmetric. The amount of data you send is *extremely* small in comparison to what is sent to you. You're only sending controller data (orientation of the analog sticks and button on/off state each frame). That's nothing.
Now to the server aspect of OnLive...
In order for this to work and take the load, not only will they have to have the most cutting-edge virtualization technology *and* clustering technology, they will have to have figure out how to extend such technology (which currently exists and works well and is magical) to the GPU.
Not to go into too much detail about virtualization and clustering, but in essence you can make a bunch of machines act as one machine, or one machine act as multiple machines. You put those together, and you've got a system where the total load of all the games being played can be distributed among all the machines in any combination or slicing you want, and that configuration can be changed in the blink of an eye.
For instance, one of these beefy servers could probably host 10 simultaneous games of Lego BatMan (keep in mind, these server computers are well beyond any desktop PC you could build, which is pricey, but that pays for itself with the load sharing).
This system could also go the other way if someone is playing Crysis, and the demand of the game eclipses the capabilities of one physical server, another server that has 20% of its CPU free (because it's only hosting 8 games of Lego BatMan at the moment) could contribute its last 20% to help render some of the terrain in that game of Crysis.
What if one server is hosting 10 games at once, which is its max load, and the players in 3 of those games all get to the same crazy boss at the same time, which has more complex graphics? Would the server catch on fire? Would it reduce the framerate for everyone else being hosted? Not necessarily.
In a move related to the "over-commit help" scenario I described with Crysis above, the virtualization monitor could move one of the hosted Lego BatMan games from the overloaded server to another, unloaded server within in a split second, without interrupting the action as perceived by the player on the other end. This is known as live migration, and has been around for a while for servers. Can they do it with a game? Perhaps they can with the right support from the GPU manufacturers.
Next up is the problem with hardware getting old and the continuous upgrade problem. This is actually one of the easier things. New servers can be put in every year that have twice the power as the previous ones. You install them ahead of the projected need, and then (because you already have super amazing virtualization & clustering in place), you move all hosted games onto them, seamlessly, then ditch the old servers making room for even more new ones, and so on. Plus, any game popular enough to stick around (like Lego BatMan, for example) will become even less of a burden on the system as time goes on (new servers in the future could host 40 games of Lego BatMan at once).
Finally, latency. Ah yes, this is the biggest *technological* sticking point. If they can't solve this then OnLive won't be worth it. Some games deal with latency well (non-twitch action games, turn-based games, etc). But others demand low-latency. Supposedly you can't tell if the latency is under 30ms, and that latency up to 90ms is "acceptable". I can't really say, it depends I guess.
Regardless, it has to be low and stay low. Obviously there's the argument that commodity internet link speeds (and latency) will continue to improve, which is true, but how fast?
The best thing OnLive can try to do in the short term is try to become an ISP, or at least set up their server farm right next to an ISP. So instead of signing up for Internet service with Comcast or Verizon, you sign up with OnLive, or an OnLive partner. This could spell disaster for ISP's who don't partner with them, if OnLive actually takes off, creating a terrible situation for consumers.
Ok this post was long, but I've been wanting say all that for a while, and so I picked this site it seems to dump out my thoughts.
As for my personal feelings, they're mixed. I would be sad to see the end of hobbiest building monster PC's just to play Crysis, but I think the potential advantages would probably outweigh those feelings in the long run.
