Comment by gregdoesit
10 years ago
The problem was the avalibity when the sender was offline. You send a message from your iPhone to your friend who has an Android. Your friend doesn't have reception, and after sending the message you kill Skype b/c of the battery drain (otherwise it is being part of the p2p network).
Your friend now gets reception and will get your message... between a minute and a couple of hours. Most likely when you turn your phone back on, as the p2p network was not designed to store and propagate offline messages.
Meanwhile someone at Whatsapp built a key value pair on a server and if you had reception, you got the messages immediately and reliably. Oh, yeah, because the read and unread message states in Skype also propagated via the p2p network and also got took a while to arrive...
I'm really surprised that Skype didn't just build a separate system for mobile. It seems even a simple evaluation of the facts (needing hundreds of engineers to alter an already stable product) pushes things more to the server side than the P2P side.
hindsight is 20/20. It would be quite easy for a team of developers and product managers to get together to discuss "how we take what we have and extend it to cover the new use case" rather than "what is the best approach for the new use case".
But even before reuse, the "DNA" point can't be overlooked, though. Success breeds a belief that "our differentiators" need to be considered and baked into subsequent products. More often than not, those constraints lead to situations where you're fitting a square peg into a round hole, as with Skype and P2P messaging.
What saves some companies from this is a core DNA that can be interpreted in a very liberal and malleable fashion. For instance, Amazon is about distribution--be it products, bits, computing power. Facebook is about social connection (not P2P or a particular narrowing of tech). Of course, maybe that's just survivorship bias...no one keeps a good directory of the graveyard of corporate DNA that was as similarly broad.
Now whether that is a function of articulating flexible DNA, or the flexibility of the decision makers...I don't know. Either way, fixed mindsets close down adaptivity to new opportunities.
We did acquire GroupMe with the same thinking: take that startup with a good group messaging product and integrate them into Skype.
Except this never happened, GroupMe is still a standalone app and pretty much a standalone team. I am not sure why we didn't or could't integrate them, the Microsoft aquisition of Skype, and the subsequent integrating with Lync (and the birth of Skype for Business) probably had higher priority.
Reusable components is a mantra within software engineering. People deciding on product direction want to reuse what's available and has been tested: known quantities increase confidence levels. Unfortunately, the reuse in the large vs. reuse in the small dilemma gets lost in the decision-making. At a certain job level, applications become components represented by geometric shapes on a whiteboard or electronic diagram. At that level, components look like good candidates for reuse.
Unfortunately "the devil is in the details". Reuse, in this case, hurt the messaging app because of a fundamental difference between connection and connection-less communication. I'm sure the engineers working on the messaging app understood the problems. But, they were most likely not a key part of the decision chain.
This whole Skype/P2P thread makes me feel very pleased and very optimistic about what we have built already and are building for release relatively soon.
You can do P2P on mobile and you can even do P2P with central server fallback without sacrificing reusable components and with standard network protocols. You just have to do the hard work at the lowest layers first and you have to think about the problem from an SDN perspective instead of an app-centric-P2P perspective.
(Intentionally cryptic response, yes. Grin.)