Skype Crashing and Supernodes

Sometimes Christmas comes a few days early.  Forgive me for the Schadenfreude, but the fact that PC Mag, TechCrunch, GigaOm, BBC News, and so many other outlets discussed the BUSINESS IMPLICATIONS of Skype’s crash yesterday amuses me.  To quote Om Malik from GigaOm:

…over past few years it has become part of the economic fabric for startups and small businesses around the world. I am not sure we can comprehend the productivity cost of this outage….

The outage comes at a time when Skype is starting to ask larger corporations for their business. If I am a big business, I would be extremely cautious about adopting Skype for business, especially in the light of this current outage.

Extremely cautious indeed.  To make things worse (in my book, anyway), this forced the public discussion of ‘supernodes’ to come out.  Skype acknowledged the supernodes act as directories, and that there was a an issue with some Skype versions (a conflict perhaps?) that caused a bunch of supernodes to not work.  To fix it, Skype is creating ‘MEGA-SUPERNODES’!  I am not kidding one bit.  It sounds like an anime uber-weapon.

This is so wrong in multiple ways.  a) People who experienced processing and network problems after downloading Skype often discovered they were unwittingly a supernode whether they wanted to be or not.  This is potentially a privacy, security AND ownership (of bandwidth and CPU use) issue.  [update: the more recent versions do allow you to turn this off]  b) If people experienced poor other-than-Skype performance as supernodes, who knows what the experience will be for mega-supernodes.  (I’m eagerly awaiting mega-super-galactic-power-nodes.  That’ll be awesome!!!)  c)  I think it’s safe to say that spreading the public directory across a number of private computers is NOT a reliable alternative to redundant hosted public directories that are unaffected by version changes…as most point-to-point services (*ahem*) do.

So, if you’re a business, and you need video calling, why use the guys without certified security, without redundant hosted directories, without collaborative tools (desktop screenshots do NOT count), with supernodes and mega-supernodes, when we have a loooong list of competitors (aside from us) on our blog and homepage that you can choose from instead?

Re: VSee’s video conferencing solutions arrive in Europe

TechCrunch today posted an article on VSee.  We like it a lot and recommend you go read it!  Click here to get there.

However, I’d like to take just a quick second to clear up a couple points:

First:  We don’t actually claim to have more collaborative tools than the rest…only Skype!  Skype has a sub-par desktop share that only works when video is turned off.  And it’s a screenshot rather than a direct share.  Everyone else (WebEx, GoToMeeting, Nefsis, etc.) generally has a full comple Continue reading

The Flash brick wall

Here’s an interesting article on Techcrunch about Chatroulette V2.

Just a quick note: I love the Chatroulette concept – it addresses an addictive side of human nature. Their success finally landed them into the Flash scalability nightmare. Pretty much all the social video conferencing tools are build on Flash (rounds, tokbox, tinychat, etc), and all of them suffers from poor quality as soon as they are successful. The client-server architecture of Flash is fundamentally not scalable – due to the human factors’ findings on people’s tolerance on delay.

It is sad to see another interesting startup run into the Flash brick wall.

Not just “Skype Etiquette”

This was a very interesting post Michael Arrington put up on TechCrunch yesterday.  I myself am guilty of a one of the sins:  I have a two-sentence limit on my IMs before I hit enter and continue…but I’ll explain myself at the end.  The points he makes are very good and not just for Skype, so please check the link.  (However, I suggest ignoring the bit about Skype’s screenshare, which I find abominable.)

Skype Etiquette

Two things to remember when deciding how to use chat vs. video vs. phone vs. email are  intimacy and immediacy.  Video, being both intimate and timely, is often the last link in a chain of communication.  Chat, on the other hand, being potentially asynchronous and less intimate, is often a stepping stonethe links that join other links in that chain.  Or it can be the conversation itself.  Email, by nature, is neither synchronous nor intimate; the recipient can respond whenever at arm’s length…or possibly filter it into their spam folder.  Chat is great for moving in either direction.  IM conversations can indicate needing to move a conversation to a more direct medium (video/phone) or a less direct one (email).  Email can accomplish the same thing, albeit in a slower manner.

Regardless, Michael’s ideas can easily be summed up:  Don’t harass.  If the conversation is already engaged, ask if the other party is willing to escalate or pull-back on the conversation.  Ask yourself what level of intimacy and immediacy is appropriate to the communication and the person in general.  And remember, just because the communication is in an intimate form, don’t assume the environment of the recipient is.  (Remember the example of the Skype call during a presentation?)

Since I promised to say why I often hit ‘enter’ after roughly two sentences:  I sometimes get impatient when I’m involved in a mostly synchronous chat and after an overly-long period of time I receive  War and Peace as an IM.  Then the other person has to wait for me to finish reading this masterwork of American literature before I can craft a response.  Assuming my chat partners feel the same, I serialize my great American novel rather than send it in one chunk.  Unlike Michael’s ‘friend’, though, I at least try and get a couple sentences out…and I always read what they type back!!!

Conference your Engineers into Sales

Back in December, this fantastic post, It’s All About Selling for Survival, by Vivek Wadhwa, showed up on TechCrunch.  Vivek makes an extremely compelling case that the best salesmen in a software organization are the programmers.  And we believe him.

We’ve been including our programmers in sales with phenomenal results, so we decided I’d write a quick blurb on why companies should bring their engineers more directly into the sales process.  (The “how”, obviously, is video collaboration!)

I’ll sum up:  People trust engineers.  Engineers have credibility.  And from a product development POV, you cut out the middle man.  This trust, credibility, and direct exposure to customer needs leads to better products and easier sells.  Also, the direct interaction makes ongoing tech support much more efficient and satisfying to the customer/customer-to-be.

The proof:  A startup where Mr. Wadhwa was CTO gave the engineers sales training and then, with only two full-time sales reps, was doing multimillion dollar deals within months.

Whence comes in video collaboration?  Well, if you’re like us, you want your programmers primarily where they can do programming: In front of a computer.  (Actually, we want everyone in front of a computer!)  Except for certain on-site visits, the most efficient way to include them is through video.

I won’t expound on what the engineers bring to the table when you can simply read Mr. Wadhwa’s article.  However, in this digital age, the collaborative tools allow engineers multiple levels of troubleshooting (“please share your desktop with me”, “let me show you how to do that”), instant distribution of manuals and other documentation, participation in client Q&A, and, better yet, brainstorming directly with clients and prospects on solutions!  That last one is highly valuable.  Assuming your company’s vision has been made clear, engineers who are brainstorming with prospects will know what the technical limitations and estimated timelines are for any solution, and also whether those solutions support your company’s vision.

Ignore this resource at your peril.