The recent hype about Skype, and in particular surrounding the Verizon deal has been blown WAY out of proportion, IMHO. It’s time to set perspective here.

First, Skype was supposed to have killed off traditional telecom by now. Last I checked, that hasn’t happen (still a trillion dollar business).  In fact, Skype actually PAYS traditional telecoms a significant amount per month, thus helping them stay in business.

Second, Skype was supposed to revolutionize everything. Ok, they’ve done some cool stuff, especially if you like video.  And they introduced the world to HD Voice.  On the other hand, if you look at where Skype gets revenue, oh gee, it’s from traditional telecoms services – like phone calls, and phone numbers, and voicemail!  Where is the new and revolutionary business model? At the end of the day, Skype is not all that different that other Chat applications with Voice and video.

Third, lets not forget that Skype still is a black eye for E-bay and (now candidate for Governor of California) Meg Whitman. Meg paid (at least) $3 billion US in 2005, then wrote off $900 million. And of course now E-bay sold 65% of Skype to a PE group at a valuation of roughly $3 billion. That’s zero percent growth in valuation over 5 years. Not quite the wonderful story it’s perceived to be.  What’s more, not only did it not appreciate in value, but Skype added no strategic benefit for Ebay either – it was simply a distraction- a bad deal all around.

So before we go rewriting history, and (once again) claiming how Skype will tear down the telecoms world, maybe a little grounding in fact is in order.

Much of this has come with the great patience of my friend Mark Petrovic who has helped me immensely in this endeavor. It has been an overall very positive experience, to the point that Java is now my first choice starting point for server-side and web-app projects.

So here’s the rant:

What is it with Java tool developers that they like to “improve” their APIs in non-backwards compatible ways on a semi-regular basis?

Perhaps I’ve just been “lucky” but I’ve experienced this with many of the key packages I’m using, such as Jetty, Twitter4J, and Lucene.  It’s almost like it’s part of the culture to break things, just to shake things up.  Maybe it’s a “purity” thing and they always think their API needs to be cleaner and the only way to get there is to break it (again).

One of the biggest hassles that come with this culture is that it makes it really hard to come up to speed on a tool because you have to also study the full history of it, scattered across countless message boards, blogs, and websites (oh my!).  When you run across examples showing use of the package, they often only work with the specific version of the package/tool from some point in the past. Of course these examples seldom state which version they were written for nor are they updated to bring them current to the latest version. Coming out of the blue, being new to one of these packages, it’s really hard to tell when the package diverged and in what way the rules changed.

It seems like every Java tool developer thinks their users are, or should be, spending every waking minute on their specific development-talk forum.

Is it just me? Am I really the only one who struggles with this?

Google’s celebrated algorithms may power the Web’s most popular search engine, but they have not yet been programmed to answer a call when a customer has a problem. …

Some analysts said that Google appeared to have misjudged the service demands that come with being in the business of selling sophisticated gadgets.

Time will tell whether Google’s historic “we don’t provide support, we’re Google, we don’t have to” attitude is going to carry over from search to U.S. cell phone users.

Okay, so it’s Google, so it will make a bit of a splash, but for now at least, it is a mostly inconsequential moment.

When the news was finally broken that the event was about the Nexus One, nobody in the audience applauded–it seems even the journos in the crowd weren’t enthused.

It’s sort of a hybrid of the iPhone strategy and Nokia strategy. The phone can be purchased bundled with a plan from T-mobile for $179 with two-year contract (the iPhone way) or it can be purchased “unlocked” for $529 (the Nokia way).  We’ve seen all this before – the only difference is this time it has Google’s name on it.

In the future, Google says you’ll also be able to buy the phone with a Verizon plan (Spring 2010).

This is the difference between Apple and Google. When Apple releases a new product, it may not have all the features yet, but the features it has are really slick and polished – it is fully baked and ready for prime time on day one. With Google, everything is half-baked. At some point Google might finish the product, but in many cases they never do, and the product hangs around in limbo “beta” mode forever (take Google Talk for example, or even the Android “Marketplace” store). They just don’t seem serious about most of their products.

I think Google sees mobile telephony as strategic and so they probably want to move Nexus One forward – question is, can they? - Do they have the right stuff to do it? GOOG has made it pretty clear that their enemies are telecomm carriers and Apple – I guess they’ve gotten bored with Microsoft.

For now, Nexus One is a “wait and see” for me. Google is going to have to show me a little more, show me that they’re serious this time.

Needless to say, I grew up in a TV generation. My wife is even worse. The whole reason we have BOTH Cable and Satellite TV is because the cable lets us hook up the “extra” TVs in spare rooms and such around the house without a cable or satellite box. We use DirecTV in the three “main” TV rooms. We have TVs everywhere – it is so 1992 around here.

So that makes me odd (I’m sure you’re surprised) and not exactly a model use case, where the real reason that I continue to just grin and bear it is laziness and habit. But even without these lame excuses, I’ve looked at some of the reasons why it’s harder to quit than I’d like and I think some of these may apply more generally.

Issue 1: The Social Side of TV

One of the positives of TV, especially TV series, is sharing with friends – Laughing together about the latest 30 Rock etc. You lose this if you haven’t seen the program yet because it hasn’t come out on DVD yet. One of the problems with using the Internet or VOD, or worse, Netflix, to watch TV series shows is that you won’t see the show until it’s “old news” – you miss out on that sharing experience while it’s “new” and “hot”.

I think this is a much bigger deal and I have not seen it come up much in the “dump cable” discussions.

Issue 2: HD

We all have paid for that fancy HD TV – it would be nice to watch HD content on it. Today, there is barely SD content on the Internet or in streaming video.  And HD uses a lot of bandwidth, so one needs a good pipe and good pipe provider to get HD over the Internet. That’s even worse if there are people watching different shows on multiple TVs.

Issue 3: User Interface

Internet TV is still too clunky and difficult to use. It’s getting better, but it’s not there yet. You can’t get enough content in one place with one interface (no matter what the marketers tell you). A mouse and a keyboard are still the only practical answer if you want to really get to the best content, and a mouse and a keyboard are simply not the ideal TV watching tools. Nobody has a good TV-simple one-thumb remote interface yet. This will be a big factor in crossing the chasm to mass adoption.

Some Good News

There are some areas where things have really improved in recent years.  One is sports. There is a lot of sports TV available on-line. These guys know where the money is and I think they are really leading things (well, after porn that is).

Another is Live TV News. Here in the San Francisco Bay Area, pretty much all the local channels have live feeds of their main news broadcasts. I suspect this is true in most reasonably sized markets.  And of course, you can also get out-of-area “local” news, which is something you can’t get with Cable TV.

I’m so locked into the old way that I personally may never fully drop Cable/Sat TV – but I can see how close this is to bursting wide open. What happens to Comcast, DirecTV and DISH etc. in this scenario?

Leopard OS X Theme for Windows 7

But regardless of how similar the UI becomes, it can never offer what Mac OS X can in one respect: real UNIX underneath.

Even if you clone all the UNIX command-line tools (which is something I was doing way back in the 1980’s), you still don’t have OS-level compatibility. For instance, here’s some UNIX bliss:

if((sockfd = socket(AF_INET,SOCK_DGRAM,0)) == -1)
 {
     perror("sockfd");
     exit(1);
 }

 if((setsockopt(sockfd,SOL_SOCKET,SO_BROADCAST,
 &broadcast,sizeof broadcast)) == -1)
 {
     perror("setsockopt - SO_SOCKET ");
     exit(1);
 }

 sendaddr.sin_family = AF_INET;
 sendaddr.sin_port = htons(port);
 sendaddr.sin_addr.s_addr = htonl(INADDR_ANY);
 memset(sendaddr.sin_zero,'\0',sizeof sendaddr.sin_zero);

 if(bind(sockfd, (struct sockaddr*) &sendaddr, sizeof sendaddr) == -1)
 {
     perror("bind");
     exit(1);
 }

 recvaddr.sin_family = AF_INET;
 recvaddr.sin_port = htons(port);
 recvaddr.sin_addr.s_addr = inet_addr(DEST_ADDR);
 memset(recvaddr.sin_zero,'\0',sizeof recvaddr.sin_zero);

Isn’t it pretty?

Due to compatibility libraries, the above code actually does work on Windows. But the ugliness creeps in with stuff like the following:

#ifdef WINSOCK
        send(svr_sock, Osvr, strlen((char *)Osvr), 0);
#else
        write(svr_sock, Osvr, strlen((char *)Osvr));
#endif

#ifdef WINSOCK
                closesocket(svr_sock);
#else
                close(svr_sock);
#endif

Yep, the fact that it’s not really UNIX underneath creeps in. Microsoft can only fix that by doing what Apple did in 2001, starting over with a UNIX-derived core. This was painful in many ways, but in the end, look at the turnaround of Apple prior to 2001 and since, where Apple’s brand awareness today has never been higher and market penetration is up ten-fold.

Microsoft is never going to do this. Of course they don’t have to. They still hold a huge market share – Steve Ballmer calls Mac’s growth a “rounding error” – but when people ask me why I use a Mac, it’s not really because it’s more reliable, has fewer viruses, or has a better GUI. You can crash a Mac too, if you want to and I really don’t care about those GUI arguments. The GUI is exactly “fine” – for my tastes, the overall design seems so much more polished, clean, and nicely integrated than Windows (or Linux GUIs for that matter too) – but for me, it’s “good enough” and that’s all that matters (the most important must-have for me is virtual desktops, which Windows still doesn’t have native yet). The GUI is just one part of the experience of the machine. I use a Mac because of the whole picture. It gives me:

1. The apps I need, store-bought like PhotoShop and tons of freeware apps
2. Compatibility apps like Word, Excel, and Powerpoint so I can easily work with the rest of the world without hassles or even telling them I’m on a Mac
3. Terrific development tools (oh yeah, and the development tools are free with the OS btw, not $300 extra)
4. and… usable UNIX underneath.  You can argue whether it’s “real UNIX” or not, but it’s UNIX-enough such that most anything will work, including (again, free) seamless support for X11 apps.

On a more minor note, Apple includes a lot more apps – yeah one can (usually) go find equivalent apps for Windows, download and install them – but it’s nice that Apple includes so many common apps with the machine, both GUI apps like iMovie and hundreds of UNIX command-line tools.

Over on the PhoneGnome blog, we look at where it is, and where to go from here:

http://www.phonegnome.com/blog/2009/12/02/phonegnome-participatory-marketing-challenge/

I’m not sure if these wireless companies were in denial at the time, or whether they really believed Apple and their little toy iPhone was not much of a threat. I got the sense, they really believed it.  And I have to admit, I was guilty of a little underestimation of the iPhone’s potential at the time myself – that changed pretty fast for me (see this post, or this, or this).

I wonder if now, the tables have turned, and is it now Apple who is underestimating Verizon and Motorola’s new Droid that was announced today?

In my experience so far with Android-based phones, they are a lot more like the pre-iPhone “smartphones” than they are like iPhone – I call them DIY phones. They are more clunky to use, less intuitive, and much less consistent between apps.  Apple rules with an iron fist and that has it’s problems, but it also means the user experience is more consistent, even when using third-party apps.

However, in the U.S. iPhone has the AT&T Albatross around its neck. Verizon has created the perception that their network is better. Certainly, iPhone users know the AT&T data network is bad, bad, bad (and the voice calling ain’t a whole lot better).

Time will tell how this plays out of course, but my advice to Apple is don’t be like those companies you leapfrogged just a few short years ago. Don’t underestimate your opponent.

This small package (less than 1000 lines of Java code) was developed to provide a small and simple package for rendering text into an image (bitmap). It was developed for Google App Engine use where AWT and BufferedImage et al do not exist. This small utility can be used to render text on App Engine within the constraints of the JRE Class White List. This is derived from the “pbmtext” utility from NETpbm Copyright (C) 1991 by Jef Poskanzer.

These are crude black-and-white bitmap fonts – no anti-aliasing. A small number of BDF fonts in fixed-sizes are bundled into the package: Courier, Lucida-Bold-Italic, Lucida-Medium, Lucida-Medium-Italic, LucidaBright-DemiBold, LucidaTypewriter, LucidaTypewriter-Bold, and a default serif font.

The following code snippet demonstrates use of litetext on App Engine:

You can grab it via SVN at http://code.google.com/p/litetext/

There are docs on the project site for adding fonts and an example demo servlet is included. See the Live Demo.

Use this command to check out the latest project source code anonymously over HTTP:

You can actually compare the difference side-by-side by comparing the performance on a native Java web server (Jetty) platform vs. the exact same code running on App Engine:

Java Jetty –> http://twitmart.org
Google App Engine –> http://twitmart.appsport.com

This shows pretty clearly that the performance issues aren’t Twitter (most of the time) nor are they in my Java webapp implementation. The same code is running on both platforms. Nor is it hardware – the machine running Twitmart.org is a very modest server that is hosting a large number of other sites.

The showstopper problem for Twitmart on App Engine is that Twitmart.org is a Twitter mashup using the the Twitter API. It turns out that Twitter API calls from App Engine fail frequently. I’m not sure why. It should not be due to throttling as the app uses authentication but on the other hand it could possibly be that Twitter is overwhelmed by API calls from the App Engine platform and therefore throttles the entire Google infrastructure. I think the most likely answer is just that App Engine has problems making API calls (HTTP requests) in general, because I’ve seen this same problem to other APIs besides Twitter from App Engine, such as the issues we had with the Taglets API.

Regardless, it’s bad for App Engine and Twitter Mashups. It means Google’s platform is not useful for Twitter mashups or any kind of mashups. That sucks and makes the platform much less useful in general.

Beyond that showstopper issue for Twitmart.org (and all Twitter mashups considering using Google App Engine), is the performance / consistency in general. For no clear reason, about 20% of requests just take a ridiculous amount of time on App Engine, even to do the simplest thing. E.g. a url that simply renders a template, that usually takes sub 100ms, will about 20% of the time, take 3-5 seconds or more. That’s simply too high of a “near-fail” rate for a “serious” application.

I hope that Google does address these issues and start to take serving “important” applications seriously. The idea of cloud computing in general, and Google’s “App Engine” approach specifically, is really cool. It’s very attractive to have someone else taking care of the servers, the network, patches, etc. However, there is a certain performance bar the service has to meet too, and unfortunately, Google isn’t making it yet, even for the price of “free”.