contrarian startups

applications, internet, startups View Comments
Nov 302011

Most batches of startups tend to ride a common set of waves. But there are also opportunities for startups that chart their own course. As the waves change, these contrarian-minded startups sometimes end up in front of the past waves. Though we can’t predict the timing or nature of the next blitz of waves, we do know they are always coming. And going.

Peer-to-peer work and the component software industry
Christina Cacioppo has a nice post up on what comes next for the software industry. It is focused on start-ups and consumer focused business models but many of the concepts stretch across the industries.

Christina writes very well about two trends – software as a component industry and peer-to-peer type workflows. We’re seeing this across early stage technology companies as Christina describes, and I believe we’ll see both trends in the forms of disruption of traditional product shops, as well as different models for “companies”, e.g. as transient flocks. This is the current set of tidal waves of the software industry, interwoven with Lean Startup principles. Some startups will no doubt ride these powerful waves to incredible success. But some startups will also go against, through or around these waves and it is sometimes more interesting to think about those opportunities.

Startup turtles swimming upstream
Some companies will take the contrarian path. For example, some companies will succeed by minimizing their use of other platforms and components. Near heresy today, which may mean it is more likely to be true. Wait, if I don’t take advantage of these platforms and components, then how do I race the hares to market? You don’t. You lose that sprint but may win the marathon.

Sustainability
I love the Lean startup concepts, and I practiced some of them, but we may be starting to over-emphasize the speed parts. Sustainability for example may include slowing down and minimizing the use of today’s powerful platforms, robust web services and third-party components, as crazy as that may sound against the deafening roar of today’s tidal waves.

Waves and innovation
Certainly I’m not recommending that all start-ups slow down. Some turtles will drown going against the current. Some rabbits will iterate into long-term sustainable businesses with indispensable platforms. But I think this current set of waves is so powerful – so hard to not ride if you are a startup – that it creates a contrary opportunity for some startups that go the other way and focus on sustainability, business model innovation and go to market innovation.

    Tagged with: , , , ,

    verizon wireless announces API for turbo bandwidth

    applications, internet, mobile View Comments
    Nov 052011

    Let’s hope no mobile app developers actually implement the Verizon API for turbo bandwidth. There are a thousand reasons why this is a flawed idea, even without getting into core net neutrality issues. Below are three macro-level issues and one counter-offer to Verizon.

    1. Verizon Wireless is basically a monopoly
    If it was a truly competitive market, then Verizon can offer turbo, nitro and nuclear and I’d have no issue with it. I’d just go elsewhere. Unfortunately this is a monopoly/duopoly situation in most of the US.

    2. Hitting turbo could be taking Pepto-Bismol for a headache
    Consumers don’t know why their app is “slow”. Maybe it is last mile bandwidth. Maybe not. There are many causes for “slow” apps. You ready to hit “turbo”, pay Verizon and then not get the desired result because of a client issue on your mobile phone or iPad, a third party ISP’s congested Cisco router queuing packets on the route between your app provider and Verizon, or some database issues that your app provider is dealing with? The articles suggest the user will hit the turbo button but it is problematic even if it the app requesting more bandwidth on behalf of the user.

    3. Verizon may be the source of the problem
    Last mile bandwidth issues are not always caused by too much demand. What if Verizon Wireless has a problem causing the available local bandwidth supply to be cut in half? Should you pay for that by hitting the turbo button and (maybe) getting enough priority to get more packets through? What if Verizon does some poor design or engineering – should you pay for that? By the way, this type of data prioritization implementation isn’t easy – it may not work well even if everything else is in line – MPLS schemes, designed for similar purposes, often fail.

    Counter-proposal: we get what we pay for…both ways
    Verizon Wireless can add the turbo feature…if Verizon credits its customers each time one of our apps is slow due to the bandwidth being less than we are paying for and there is proper visibility for credibility. If I want priority, I’ll hit the turbo button. If I actually get the improved performance, improved to a transfer rate higher than I am paying for, then I will gladly pay for it using the credits I built up during all the times Verizon was giving me less bandwidth than I was paying for. And I’ll happily collect money from VZW each month when the balance is in my favor.

    A variant of this counter-proposal to consider could be a two-way API between Verizon and the app providers – they maintain this bandwidth SLA of sorts and true up each month. I’ve heard folks like Aswath suggest similar (I believe) though I haven’t thought through it enough. They can explain it in more detail and have thought through the positives and negatives.

    The best “solution” would really be no solution. Instead of investing in bandwidth prioritization technology, instrumentation, reporting, regulation, DPI, metering, billing, governance, etc…invest all that time and capital in minimizing the amount of time that bandwidth is an issue to begin with. Bandwidth really shouldn’t be the limiting factor – there is more value for everyone and more revenue in the ecosystem for all the players if assumed bandwidth constraints aren’t somewhat artificially throttling demand.

      Tagged with: , ,

      enterprise LAN elimination and communication revolution

      applications, internet, telepresence, video calling, video conferencing View Comments
      Nov 022011

      If we can eliminate the enterprise LAN walled garden concept, it may be the most significant single catalyst to the next blitz of application, product and service innovation. LAN elimination would overhaul inter-enterprise communications – VoIP, video, telepresence and messaging. It would help enable the complete realization of the potential of VoIP and communications over IP, including the integration of real-time communications into all enterprise apps, workflows and processes ["enterprise LAN" refers to the way the LAN is administered and managed as a private walled garden (combination of firewalls, ALGs, policies, addressing, routing, etc.), rather than to any specific technical implementation of the LAN itself].

      Enterprise LAN islands often completely prevent effective, universal, inter-enterprise real-time communications (most frequently in video and telepresence), and in other cases the LAN reduces island to island communication to least common denominator type approaches such as PSTN bridges (most often in VoIP and messaging). This is a problem today and is even more important tomorrow as real-time communication becomes increasingly embedded in applications, e.g. true real-time video communication.

      We take the existence of the enterprise LAN paradigm for granted – a necessary evil to work around – the LAN walled garden is assumed in all standards-body work around enterprise VoIP and video, vendor roadmaps, service provider offerings, etc. But maybe the LAN can be eliminated, at least for most cases? In general, I think this means distributing “security” to the individual applications and devices, each of which has drastically different security requirements, rather than trying to first wall off the island the island of apps and devices. Specifics for future posts.

        Tagged with: , , , ,

        WebRTC

        applications, telepresence, video calling View Comments
        Oct 202011

        Dan York posted one of the best rants I’ve seen on an IETF mailing list in some time, probably really targeted at both the IETF RTCWEB work and the W3C WebRTC work. Hit his link for full text and some context he added on his blog. My abstraction on a couple key points:

        Real-time communication and WebRTC
        A large chunk of real-time communications (voice, video, telepresence, IM, etc.) belong embedded in applications. Many of those apps will be web apps. This is already happening despite the current friction (proprietary implementations, browser plug-ins, etc.). WebRTC and RTCWEB, done correctly, and adopted by the (mainly telephony focused) vendors that expose libraries to web devs, has the potential to remove much of that friction. Note: IMO this includes moving towards true real-time voice and video, not calls, but continuous sessions. In Dan’s words, “It’s the opportunity to move real-time communications into the very fabric of the Web”.

        Who are we building WebRTC for?
        Dan highlights this as the key question and is one reason his missive his so powerful. In this case, and so often, the key question is often not asked or focused on enough as we jump into solutions. As Dan says, an awful lot of good work from great people will mostly be an academic exercise if we don’t focus on the core question. In this case, WebRTC / RTCWEB needs to focus on the masses and on the future. Not traditional carriers and vendors, not standards optimized for different use cases (SIP, H.323), not extinct business models. Need to aim ahead of the bird and this bird is flying quite quickly.

          Tagged with: , , , , , , ,

          replace your kitchen cordless phone with a home Android?

          applications, internet, mobile View Comments
          Aug 172011

          Google could leverage their new Motorola Mobility assets to get to their goal of mobile carrier independent Androids via the back door that will soon be left open by our landline PSTN carriers. We know the PSTN is facing extinction; Google could be a part of the replacement.

          Motorola set top boxes as base stations
          Google would use enhanced versions of the Motorola Mobility set top boxes, about 50% of the set top boxes in the US, to provide you with home phone service. You’d get a home Android phone that would replace your current home phone, your Motorola Mobility set top box would essentially serve as its base station, and your home calls would be VoIP, using the cable ISP pipe on the other side of that set top box. Maybe more importantly for Google, it could put you on a path towards carrier independence, even for your mobile phones.

          Home phone service with limited roaming
          Your home phone service would, at minimum, and minimum might be desirable in many cases, be what it is today. While not being mobile on day one, your home Android could do some limited roaming. Limited is not the issue it would be if it was competing against fully mobile phones; it is a feature compared to the zero roaming on your current home phone. How would this work?

          Home Android roaming
          Your phone could authenticate with any Motorola set top box and also hop on WiFi and similar networks. Some security measures would need to be taken for these roaming type options, both to protect you from compromising a home Android that may be your only connection at home, and to protect folks from external threats if they enable their set top boxes to function as public (with restrictions) access points.

          Roaming to independence
          Over time, the roaming coverage will increase and in aggregate represent a lot of traffic. Enough to “peer” in some way with other providers of network, e.g. mobile carriers. Google could then open those options up to other Android handsets – not just home Androids – for example taking a lot of load off of Sprint’s network and giving Sprint users better signal in buildings. Sprint might then in return provide roaming radio access to the home Androids. The lines between your home Android and your Sprint Android have changed and both Androids become much more carrier independent.

          VoIP for dummies
          Home phone service is one area where tight integration between phone and service does make sense. Much of the home phone market is quite simply used to it, and any change is perceived as involving work and risk. For example, much of the above could be done with various VoIP options, but it isn’t as easy as PSTN/POTS. Google would be positioned to make this plug-and-play. Take your home Android phone out of your box and use it. Very possible if Google controls the set top box and the phone – would need some cooperation from the cable providers and Google could make it worth it for them.

          Food for future thought
          There are also interesting peer-to-peer and content delivery optimization possibilities between the set top boxes and Androids, especially if enhanced set top boxes have enough wireless range to reach each other directly, but even if they go to the same router at the edge of your neighborhood. One of my favorites – always-on voice and video – is one area. Entertainment is another. If you just pulled down a movie, or are streaming it, my set top box might grab it from your set top box, instead of going out to a CDN server a few router hops away. Also scenarios in which your Android is the remote for all your content in the cloud, using whatever video and audio outputs become more viable. I’m at your house and my Android triggers your set top box to pull up a movie that I have rented/purchased and display it on your big screen at a near zero incremental cost to Netflix as your set top box streams parts of it peer to peer from a couple of other set top boxes in the neighborhood. On the (near-zero?) chance that Google takes the Motorola hardware stack and successfully completely open sources it, many more interesting doors could be opened. Food for further thought.

          Back to home phones
          Will Google be your new home phone carrier? I have no idea, but it is a fun to think about because it is viable, and it might be worth the investment (in addition to the technology investment, they would likely need to become an FCC licensed carrier, which is not trivial) if Google can use it as part of a strategy towards complete carrier independence for Androids.

            Tagged with: , , ,

            Android isn't free but that doesn't mean Google will sell iPhones

            mobile View Comments
            Aug 172011

            Fascinating to think about the motivations for an the implications of Google’s purchase of Motorola Mobility. Read the experts in the Techmeme memes from day one and day two for excellent analysis, opinions and predictions around Google’s purchase of Motorola Mobility.

            Two quick thoughts from the sidelines to add to the more expert analysis:

            Google isn’t Apple and doesn’t want to be
            Farhad Manjoo writes a nice article for Slate that theorizes on Google’s motivations for the purchase, describes how Google couldn’t continue to license Android for free, and concludes that Google will now move to an Apple iPhone like model for Android based phones. I like the analysis but disagree with that set of conclusions.

            • Android is a means to an end for Google whereas iPhones are part of the end game for Apple. Two very different business strategies and the resultant products need to be considered in that context.
            • Google cares about dominating search and organizing the world’s information. The way to accomplish those goals is maximum Android distribution on mobile computers and tablets – the most important source and destination of tomorrow’s information.

            The goal is maximum Android distribution
            So, if we agree Google’s end game is maximum Android distribution, then why the purchase of Motorola Mobility? A pet peeve I have in the engineering world of debugging, analysis and troubleshooting is the temptation to jump on the single cause. Rarely the case in complex troubleshooting, and I’d guess even less rarely for $12B purchases.  Some possibilities do stand out, especially if we narrow our focus to variable that most help Google achieve their ultimate goal of maximum Android distribution:

            • Ensure intellectual property doesn’t become an Android roadblock. We know from the Nortel patent bidding that those patents themselves are very valuable and deemed necessary by the big players. Perhaps Google has always known this and is why they licensed Android for free, as opposed to charging a small nominal amount?  This is an obvious motivation and probably the driving one, but can’t be the only motivation.
            • Make Android independent of carriers. I also believe Google still wants Android to be carrier independent. See Tom Evslin’s excellent summary here for more on that front. I’d add to that possibly using all those Motorola set top boxes as routers of a sort. Maybe enable them to provide enhanced WiFi (or similar) and do some peer-to-peer networking with other “set top boxes” and Android powered devices to form more non-carrier dependent wireless network access.
            • Make Android better. I don’t think we should underrate Motorola people and expertise; some of the best in the world for mobility. Those folks and expertise can help make Android a better platform, especially when you (virtually) put the hardware, firmware, OS and application experts in the same room.
            • What’s missing? Motorola Droid handsets taking on iPhones. I think in enough time Motorola branded handsets are history. Google’s goal is maximum distribution. Even if you can argue that a tight integration between Motorola and Android would enable Google to compete better at the top of the market, you could also argue that the ramifications on Google’s Android partner ecosystem would net overall less Android distribution.  What will Google do with the handsets? Open source the whole stack and pivot Motorola Mobility into the Red Hat of mobile hardware (not that this would be the same as open source OS or software)? In other words, it is anybody’s guess, but I just don’t think Google wants much to do with the hardware business itself, at least not directly.

            So my net feel is Google was probably pushed to act by the IP issues but they would have acted differently if that was the only driver. We don’t know how Google will now act to use Motorola Mobility to meet their goals, but ironically I don’t think the handsets themselves will directly be a big part of the picture, at least not long-term.

              Tagged with: , , ,

              Bezos enabled EFOs in P-Games

              applications, mobile View Comments
              Aug 122011

              GeekWire has post about Amazon CEO Jeff Bezos and Greg Hart submitting a patent for “a system and method for protecting devices from impact damage.” The disclosure includes listing protection via parachutes, springs, airbags, and gas expulsion.
              phone parachute
              So moving a bit outside of the serious box on a Friday, could this help start P-Games (phone games)? Like ESPN did with the X-Games, but phone powered.

              Take any object you could throw, kick or launch in a competition (e.g. javelin, shot put, softball, frisbee, rocket, hacky sack), replace it with your phone, tablet or Kindle of choice, and adapt the game to fit your electronic flying object (EFO).

              Your phone, now an EFO with landing gear, will record its own flight path, distance, velocity etc. and post it online to track P-game activity, history, wins, records, etc. You can bet Samsung and HTC will be warring over more aerodynamic phones in no time. I’m also sure there will be integration to auto-update – in mid-flight – Twitter, Facebook and Google+.  Not to mention re-definition of phone crashes.

              Boom, P-Games, unintended but fun consequence of the Jeff Bezos and Greg Hart patent on protecting mobiles and tablets.

                virtualizing water coolers via video

                applications, internet, telepresence, video calling, video conferencing View Comments
                Aug 102011

                A remote worker taps a team member on the shoulder via her touch screen display to instantly continue an always-on video session – as if she was talking with her co-worker at a water cooler – minus the planes, trains and automobiles to get them both to that same water cooler. Continual visual presence of each team member is sent to her Brady Bunch type display so she’s not blindly tapping on shoulders. She doesn’t video call each member – this is real-time, always-on video – she instantly resumes each interaction via a touch on her screen. This is the future of distributed work teams and other real-time video use cases. Getting to this distance independent interaction paradigm is the key to the long awaited hockey stick curve actually materializing for the enterprise video and telepresence market.
                brady-bunch

                We need three main developments to get to an always-on video paradigm: (1) a replacement or overlay to protocols such as SIP and H.323 protocols and their precepts; (2) expansion of personal network enabling services; (3) visual or multi-dimensional presence.

                Moving beyond SIP, H.323 and calling models

                Calls are transactions, not real-time interactions
                Phone and video calls are transactions – find number, make call, wait for response, hope other party picks up, connect the call. Transactions involve friction such as time, uncertainty, error and overhead. Friction deters communication; less friction = more communication. Always-on video is designed to eliminate that friction and make video interaction much closer to water cooler interaction. However, SIP, H.323 and related protocols are designed for transactions, not real-time interaction.

                SIP and H.323 are designed for the exception rather than the rule
                When you make a call or video call and are waiting for someone to pick up on the other side, SIP or H.323 is setting up the session (voice or video), which includes aspects like authentication, capabilities exchange, codec negotiation, opening of ports through firewalls, etc. All good but also not all needed for a high percentage of voice and video sessions, mainly because at least 80% (80% is my estimate) of voice and video sessions take place between endpoints that have previously talked or can be proactively assumed to desire to talk, which enables us to do some engineering to pre-build the video session, so the session is ready before you tap me on your display.

                SIP and H.323 however are essentially are designed for the ~20%, not the ~80%. Even WebRTC – which I love and believe has a bright future – does much of the same and leaves much of it to the endpoint or UA (user agent) to deal with. Always-on video needs to be designed for the 80%. We will increasingly demand the always-on paradigm, rather than the wait-for-someone-to-pick-up-a-phone paradigm. IM (instant messaging) and mobile push-to-talk (referring to the type of service that Nextel pioneered in the US) are good examples of the usefulness of the always-on paradigm. Now to extend it to video.

                The new paradigm means not setting up each and every call as if it was the first call attempted
                Proactively building the video session can be potentially done in many ways, including via protocols that replace SIP or H.323, or with methods that are an overlay to SIP or H.323. It is not trivial, and I won’t engineer it here, but to list a few representative pieces of the puzzle:

                • Endpoint software can proactively broadcast (or make available to query) the capabilities that are shared during today’s SIP or H.323 call setup. One capability that can’t be predicted is future availability but we can address that one with presence. Another problematic one is dealing with firewalls, NAT traversal and any B2BUAs and that one requires some work. Those two items need to be accounted for in all of these options.
                • When endpoints are added to a personal network (see below for personal network description), the endpoints can do a SIP or H.323 type negotiation to discover the necessary call setup info. Not when the first call occurs, but when the endpoints are added to a personal network. That info is then cached, periodically updated via similar methods, and shared with other endpoints in the personal network (and made available within a security wrapper to external endpoints).
                • We could do a SIP or H.323 type negotiation on the first call attempt, and then cache the necessary information so the setup doesn’t need to be repeated for subsequent sessions.
                • We could do an actual SIP or H.323 call setup but then keep the session alive “permanently” via other elements in the signaling path and wake it up when necessary.

                The evolution of online presence

                How would the remote worker / Brady Bunch example at the top of this post work? How does presence work in the physical world? I walk by you and judge whether you are available for a conversation. I see and hear what you are doing or not doing, your expressions, any activity going on in the background, etc. Most of the time, I can accurately determine your presence because I have signals from multiple dimensions to process based on what I see and hear. Online presence however is still mainly one dimensional, e.g. a “green light” by an icon that means I’m online on some device. That by itself was great – this flat indication of availability is one of the killer features of IM. But we can do better than that. We can have visual or multi-dimensional presence, even when we’re not face to face.

                For the past seven or so years, I’ve managed large, multi-location, international teams, mainly from my home office. My tools have improved dramatically, especially for video. I now have a powerful Cisco Telepresence EX90 – high-definition quality (1080p, 30 FPS) video calling and video conferencing, a touch-screen control for normal use, a web UI and CLI for more robust functionality. The EX90 has decent interoperability with other video units – can run SIP or H.323, uses standard H.264 AVC media, works with many standard VC endpoints and newer software versions interoperate with Cisco CTS telepresence units. But visual presence would make my current EX90 paradigm seem like a fax machine.

                Visual presence is the water cooler for the virtually co-located world
                In the upcoming visual presence powered world of always on video, my EX90 will periodically broadcast a “snapshot” within my personal networks. Let’s say for example my EX90 broadcasts a low resolution snapshot every 60 seconds (higher resolution, more frequent snapshots will make sense in some cases too). The snapshot could be a still image or could include a few seconds of video. All members of my personal network, my work group in this example, receive that snapshot, and broadcast their own similar snapshots. So, at any time, I can scroll through and see you with a maximum of 60-second delay (in this example), or play a few seconds of video to see and hear you for a slice of time. Perhaps if it is known that you are already in an audio or video session, an indicative icon shows along with your visual presence snapshot.

                So I tap your snapshot on my screen and our video session, already connected via methods like the ones described above, is instantly on. Note: I don’t wait for a ring and answer and hope for a connection; that would be a huge deterrent even though it may like seem like it. So it is just like walking by your office and making contact; perhaps I can tap different icons to initiate IM (like waving to you), voice (like saying “hi”) or video (like walking in your office). We will have the proverbial water cooler conversations that we currently only have when we happen to be in the same building, which in tomorrow’s world will be even less frequent.

                I can barely quantify what this would mean for improving effectiveness of distributed teams, and enabling folks to work from remote areas that otherwise don’t do very well in that environment. I think it would be an order of magnitude “larger” than the sum of all the technology and process improvements that I’ve seen in my experience managing distributed teams. The third major component we need in order to get here is the personal network enabling services – the service that enables me to build my work group as a personal network.

                Personal video network enabling services are the new black

                What is a personal video network enabling service?
                Wish I had a better name for it. And, no, not another acronym, please. Marketing folks, help, please. Skype, Google, now Facebook Messenger (via Beluga), and most consumer-oriented video products enable users to build our own networks – the key is they have integrated directory, personal network building and presence functionality to enable users to quickly build their own networks with anyone that has a network connection, share status (presence) across those networks and easily communicate across those networks. They enable us to build our own open networks with no barrier to entry, which means I know I can reach you on that network, and that you can easily join it. I know the traditional enterprise video and telepresence products don’t have personal network enabling capability, but they will lose the war and become the minority of video endpoints (even in the enterprise) if they don’t add personal network capability (or partner to add it), so I think they will add it.

                Personal network enabling services will increasingly offer more functionality and features within each personal virtual network. For example, I might belong to six personal networks, and my video endpoints may share different information with each of them, according to my preferences and in some cases according to algorithms. In my work group personal network, my endpoints may share the cached call setup type information described above, and may share different dimensions of presence within that work group personal network, than within another of my personal networks.

                What does this mean for the enterprise video and telepresence market?

                According to Infonetics Research, one of the relatively conservative sets of research, 2010 enterprise videoconferencing and telepresence system revenue was $2.2 billion, up 18% from 2009, with $5 billion forecasted by 2015. I’ve seen other industry forecasts that exceed $10 billion in those time frames, especially ones that try to forecast service revenue. Billions of dollars means plenty of analysis on who will win the market, and the important variables in the war. Some of the most cited variables:

                • Internet-video vs. managed private network video
                • High-definition quality video vs. lower resolutions and less bandwidth
                • SIP vs. XMPP vs. WebRTC vs. proprietary
                • Different encryption and security paradigms
                • AVC vs. SVC
                • Varying frame rates and methods for application sharing
                • Unified communications integrations
                • Etc.

                All are important variables and there are plenty of experts to tell you which vendors or service providers will win in each area and why. And just as many smart people will present logical arguments with the opposite conclusions. Which experts are correct? Wrong question. The real question is how to get to always-on video with personal networks and visual presence. Only then will video and telepresence really enable distance independent interaction, which is the only way the market will really explode.

                Great, how soon for this always-on, personal network, visual presence world?

                I don’t know but it isn’t far. It can be hacked together today, just not very elegantly, efficiently or cost effectively. Different video services enable parts of this to be done – main issue being cost and user experience as you’d need to leave the session running full video continually to a centralized MCU or bridge in order to get the always-on function. At the other extreme, I could also take a few iPads or Android tablets, make a Hollywood Squares type display from them with some positioning work to get their cameras pointed at me, launch Skype video calls with different people connected to each tablet, leave the sessions running on mute, and un-mute yours when I want to video with you. You can come up with more examples – most of the building blocks are there.

                I look forward to seeing you at the water cooler, anytime, anywhere, instantly.

                  Tagged with: , , , , , , ,

                  skype 2.1 for android *supports* video calling

                  applications, mobile, video calling View Comments
                  Aug 042011

                  Good news: Skype 2.1 for Android now *supports* two-way video on about 20 Android devices. Details here on Techmeme.

                  Bad news: I tried it on my Charge and found out “support” is being very loosely defined, and likely not in a way you’ll be happy with, unless your Droid has at least an Android 2.3.x Gingerbread release (only about 20% of people).

                  Skype 2.2 video experience on Android Froyo releases:
                  Most of us are still limited to an Android 2.2.x release (Froyo). For me, that severely limited my Skype Android video experience on my Samsung Droid Charge, and it seems like the rear-facing camera issue hits everyone not on Gingerbread. Not sure yet if the other issue is specific to my Charge or the video session I did.

                  • My beautiful, crisp, colorful ~400,000 pixel display was limited to a few pixels in terms of seeing the person I was video calling with. If I video call you, I will only see you, or whatever is in front of your camera, in a tiny picture-in-picture type square in the corner of my screen. Possibly a bug? Other party was on an iPad though I’ll assume for now the send side didn’t have anything to do with it. Will need to look into further. What takes up the rest of my great display? Whatever my Charge’s rear facing camera is pointing at. Not much video *support* there, Google/Android/Samsung/Skype…
                  • The video from my rear facing camera is what you’ll see if you video with me. It did show full screen on the other side. No front facing camera support on the Droid Charge until Gingerbread. This is a known limitation but it doesn’t make it any more palatable and IMO it is a severe stretch to say video chat is supported when the front facing camera is not.
                  • On the positive side, video and audio quality were good, over both 3G and 4G, though I’ll need to get a few more pixels to really judge the video quality on the receive side.

                  I have seen leaked Gingerbread updates “in the wild” but haven’t grabbed one to this point, and also haven’t seen an official release date from Google, Samsung or Verizon. The GB update is also supposed to include support for Google Video on most Droids, presumably including my Charge (Google Talk video chat).

                    Tagged with: , , , ,

                    Younified communications

                    applications, internet, telepresence, video calling, video conferencing View Comments
                    Jul 262011

                    Unified communications will never happen. In fact, we’re further away today then we were five years ago. There will not be a replacement for the PSTN. So where does that leave the future of communications? Hiring lots of different milkshakes to build Younified communications solutions.

                    We’re no longer seeking a single milkshake
                    The development of new voice and video communication services has been based on the premise that any-to-any communications capability via universal, standards-based interoperability is critical. But the world has changed; any-to-any is no longer critical for communications services. We’re not going to hire a single communications network milkshake, we’re going to hire many milkshakes (Read Clayton Christensen if not familiar with hiring milkshakes) .

                    We’re hiring multiple personal communications network enabling milkshakes
                    Do we hire Skype because of some promise of any-to-any interoperability or unified communications? No, Skype has closed, proprietary media, signaling and control protocols, and offers no direct connectivity with other communications services (putting aside gateway solutions for the moment). We hire Skype for many reasons but a key is that Skype enables us to easily form our own personal VoIP and video calling networks and communicate across them with minimal perceived pain and cost. Similar reason we hire others like Skype. Providers that enable us to build personal communications networks are the silent assassins of the former need for universal networks and interoperability.

                    Combinations of personal networks are the new universal communications solution
                    If I want to talk or video with you, I know we can do it on Skype. I don’t know or care which of your various communications devices or apps supports Skype. I might not know if you are already on Skype or not. I don’t know your service providers. I do know I can easily add you to my Skype network, you can easily join from some device or app, and we can then easily communicate. I’m also not concerned that I can’t hire Skype for every use case or job – there are many communications devices, apps and services available to me, and I’ll hire the best candidate for each job. I’ll hire multiple personal network enabling milkshakes. You don’t want to Skype? Fine, how about a Google Hangout video shake. Or do you prefer a Tango shake? Or future HTML5, WebRTC and Node.js flavored personal communications network enabling milkshakes? No single shake will be the solution but the shakes in aggregate provide universal communications.

                    Key ingredients in personal communications network enabling milkshakes
                    Personal network enabling services include directory and presence functionality to enable users to build their own networks. Winning personal communications network enabling services will also leave one ingredient out: perceived pain. In environments of over-supply and attention scarcity, perceived pain is more important than perceived value. Want to know how relevant a communications solution will be? Is it easy to use with no perceived barriers to entry? Great, it has a chance. Now, run it through the network-building, directory and presence litmus test. Still kicking? It could be a winner. Not THE winner – those won’t exist – one of many winners, one of many personal communications network enabling solutions. Update: I didn’t originally mention the services and apps that will increasingly embed voice and video communications via solutions such as Phono and Twilio; those apps are another reason why communications is becoming increasingly distributed, and those apps don’t always need to support personal networks if we have other reasons for using them, e.g. LinkedIn, Amazon, etc.

                    The future of communications
                    The value of the network is still proportionate to the number of nodes. But new communications services, along with ubiquitous broadband IP access, will increasingly enable us to each be our own personal supernodes. Supernodes that connect multiple disparate solutions as if they were one interconnected network, virtually creating a universal, interoperable, any-to-any network. We can therefore gain a multiplied Metcalfe effect of sorts. Unified communications? No, younified communications. Multiple communications solutions and networks, interconnected by you and me and the personal communications networks we build across the fabric.

                      Tagged with: , , , , , , , , , , ,
                      Older Entries
                      © 2011 NextBlitz Suffusion theme by Sayontan Sinha