Feed Pandora a few of your favorite artists or songs and Pandora creates a custom music station for you, delivered over the Internet.  Listen via web browser, Android, iPhone, etc.   Rate songs a thumbs up or thumbs down as Pandora plays them to curate your personal radio station on the fly and improve/customize your mix accordingly.   One critical component of Pandora’s success is their ability to deliver completely individualized radio stations (playlists) to us over the Internet, but would Pandora FM broadcast radio stations also make sense?

Pandora FM: why? Listener perspective:

  • Am not in front of PC or tablet and need to use my mobile phone for purposes that conflict with Pandora
  • Mobile low on battery
  • Prefer the Pandora FM mix than the local FM stations (and can’t listen to my personal Pandora station due to reasons like the ones listed above)
  • Prefer wider variety mix at times (compared to my personal Pandora stream)
  • Want to hear what local people are listening to
  • Better quality sound than listening on my mobile or computer
  • Better experience listening with a group of people to an FM station
  • Want to hear local traffic, weather or news (assumes Pandora FM adds that content)

Local Pandora FM radio stations: what to play?
Each local Pandora FM radio station would play what its broadcast area listeners want to hear:

  • Could be an aggregation of all the local Pandora listener playlists
  • Algorithms could weight towards artists and songs that show up the most frequently, receive the most thumbs up and/or are trending up at the highest rates
  • Pandora could enable us to request certain songs or artists for local FM broadcast via Pandora or other apps (Twitter, Foursquare, etc.)
  • Algorithms could incorporate data passively mined from other sources as well, e.g. bands and songs trending on Facebook, Twitter, etc., especially if the data includes location information.
  • Different hours of the day could focus on different genres of music

Pandora FM: what is local to each Pandora station?
If Pandora FM 100.7 broadcasts in the Nashville, TN area, then local for 100.7 might be defined as a mix of:

  • Playlists from Pandora users that live in Nashville
  • Pandora users that are currently in Nashville (determined using location data automatically gathered from Pandora’s mobile app, or from listeners choosing to check in to Pandora, or checking in to apps such as Foursquare and Facebook).
  • Listeners that tell Pandora that they are currently in Nashville and listening to Nashville’s 100.7 (tell Pandora via Pandora, Facebook, Foursquare, Twitter, web, text, email, etc.).

This would likely result in different, customized mixes in different hours, e.g. if Nashville has a heavy commuter population, then 100.7 might have a very different music mix during the day than at night.

Pandora FM: why? Pandora perspective:

  • Improve Pandora product
  • Reach more people
  • Sell more ads, including local advertising
  • Build better data on user base
  • Set the stage for getting into local events, potentially very lucrative for Pandora
  • May be able to offer more customized mix in future with technology and regulatory changes in digital radio, software defined radio, spectrum distribution, etc.

Pandora FM: concerns, unknowns?

  • Competencies associated with running an FM station and potentially a local ad sales force may be too much of a distraction or too far from Pandora’s core to invest in (though Pandora likely run these differently than today’s FM station).  Of course doesn’t need to be a complete Pandora buy or take-over, Pandora could partner with current FM stations in full or partially, e.g. Pandora-powered blocks of time throughout the day, and could do similar for local ad sales in terms of partnering w/ others, offering their own self-serve ad buying/placement capabilities, etc.
  • Hard to get the mix right – skews too much towards “hits” when using aggregated data and listeners prefer stations that focus solely on certain music genre
  • Overall business model – don’t know how Pandora pays royalties or licensing rights today – would that change for broadcast radio?
  • State of current market on buying frequency or existing stations?   Assume available at a decent discount but that’s just a guess, perhaps it is seller’s market right now.

What do you think?  Would you listen to a Pandora FM station in your area?  Does it make sense for Pandora?  Will we ever listen to Pandora local FM radio stations?

Note: just using Pandora as an example, as they seem well positioned in this area, but of course any company could try similar.  Similarly, focused on FM radio, but other options such as satellite radio may be viable.

    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.

      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.

        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.

          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.

            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.

              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.

                Justified the $12 for in flight wifi since have 3 hours left and laptop battery already dead so I will get $12 of work done on the iPad. However have already wasted 30 min on non-work, and that doesn’t include a planned future check of Mets boxscore to ensure Reyes tripled in first at bat off DL, so may be first and last time i rationalize the purchase that way. Few quick notes:

                PowerPoint – still the most used single work app on my strolls around plane. Still believe it is deep in red if you measure value companies gain compared to the hours employees pour in from end to end including the death by powerpoint meetings. we dont need ppt to make most decisions and real work is not done on ppt. that said, my laptop battery got drained while i worked on ppt…

                US Air – integrate with ticket purchase. You’ll sell more if you add 1% to my purchase and save us from painful extra registration, authentication, credit transaction. Get crazy and give away free every now and then and you may even get some folks addicted that wouldn’t try otherwise. Here’s your flight confirmation number and congrats you won free wifi, just type in confirmation number and this PIN.

                WordPress – I know its partially Safari’s fault but this is unuseable for real post – give me an iPad app.

                  Came across this article about the Facebook for every phone app and was about to close the tab as I’m not a big Facebook user and in fact believe Facebook as we know it is dead.

                  But what caught my attention was that users of this mobile app are not charged (by their mobile carriers) for the data transfers when using the app. Great!

                  Well, wait. That also implies the carriers are treating Facebook differently than other data consuming apps. Would we say “great” if AT&T charged more for the Facebook app data usage than for their new AT&TBook app data usage? This one can be done with relatively simple URL filtering and packet counting but more sophisticated or comprehensive policies require deep packet inspection (DPI) etc. Mobile net neutrality advocates, heads up!

                  Note, although I agree with Net Neutrality goals, I’m less optimistic that an FCC version of Net Neutrality would meet those goals, so this isn’t an endorsement of them, especially as I believe they are still current leaving the mobile issue on the sidelines.

                    VoIP is the future and is thought to be very close to gaining the global interoperability required to replace the PSTN. Depending who you ask, VoIP is either a standard or two away from global interoperability, or simply requires service providers and vendors to move their proprietary solutions to standards-based solutions. I agree the PSTN is a dinosaur but don’t believe it will be replaced. Not directly – just like the species that filled niches vacated by dinosaurs didn’t directly replace the t-rexes – the entire ecosystem changed.

                    Many communications islands

                    communications islands, skype and google hangouts

                    Communications islands: Skype, Google Hangouts

                    New communications islands are rising, and existing ones are expanding:

                    • Skype’s expansion via Apple iOS and Android apps, recent Facebook integration, likely upcoming integration of some sort with Microsoft Lync, and potential partnership with Polycom video (the Microsoft/Polycom relationship is fairly strong and Cisco is a common enemy in many cases)
                    • The development of Google Hangouts, overnight a top option for group video chat
                    • New mobile and web apps such as Tango and the potential for many more robust apps with emerging programming frameworks such as Node.js and standards such as XMPP, Jabber and Jingle (real-time communications); IPv6 (better P2P communication, QoS and multicast), VP8 (video) and WebRTC (real-time browser-based communication)
                    • Cisco telepresence, Tandberg video and Movi in enterprises, extending into the personal video space, or maybe colliding with it
                    • The PSTN itself. The only island that is globally accessible, pervasive, ubiquitous and interoperable. Very well engineered for its purpose, but not designed for today’s communications use cases, and not able to extend into the future.

                    The new communications islands are attractive, aren’t they? The PSTN island by comparison wouldn’t be on anyone’s honeymoon list. But the allure of the new islands can’t distract us from the fact that the beauty of the new islands doesn’t necessarily easily replace the functions of the plain old PSTN.

                    The communications bridge

                    The only bridge to each island is to go through the largest island, as it also functions as the only universal bridge:

                    PSTN bridge

                    The PSTN bridge

                    However, the PSTN bridge is not very enticing. To cross the PSTN bridge, you’ll need to ditch your bags first (most of your features), and pay a heavy toll. So we assume this bridge function of PSTN will be replaced, just like its communications island function, especially because we can easily design better bridges. Some folks will argue the bridges are already designed. So why aren’t they in place?

                    Is PSTN replacement necessary?

                    The PSTN is going away. As Tom Evslin writes, user behavior changes will result in the end of the PSTN , at least the PSTN as we know it today, possibly in the next 5-7 years in the US. In fact, many other communications islands were born from the same forces that are leading to the extinction of the PSTN – pervasive Internet and VoIP. It is just that the PSTN is still breathing.

                    So what will replace the PSTN? It won’t be replaced. Not with a global, ubiquitous, 100% interoperable (any-to-any), full duplex communications replacement. That’s somewhat painful to write because the concept of global, any-to-any communication over IP is powerful and tantalizing.

                    But perhaps PSTN replacement is the wrong goal, the wrong means to an end? Our goal as users is to easily use voice (and increasingly video and other communications services) whenever, wherever and however we want. Our real goal as a society is to ensure everyone has reliable access to those services. It used to be that we needed a PSTN replacement to meet those goals. Maybe not anymore.

                    Today’s landscape is great for innovation but toxic to interoperability and unification

                    If meteors helped destroy the dinosaurs, they left behind some unlivable conditions, at least for certain species. The Internet and VoIP meteors have done the same, at least for species that rely on interop and unification. As opposed to the PSTN, a pipe to the Internet is a conduit to any IP-based communications service or app, rather than just the one provided by the pipe provider. That’s rocket fuel for innovators. The less recognized side of that separation between transport and service is that it also serves as an obstacle to universal interoperability:

                    • That separation means you don’t win by owning the pipe; you win by innovating. Skype won in retail VoIP due to their innovation…which also meant not using SIP and developing proprietary solutions. Skype wasn’t alone. Cisco, Microsoft and even, gasp, Google didn’t and don’t completely use standards-based VoIP or video implementations.
                    • Since customers are not locked in by the pipe, and because features that may break by enabling interop are often deemed critical to keeping customers, the value of providing interop (not insignificant; see Metcalfe’s Law) is often perceived as less than the costs and business risks.
                    • Infinite use cases can be served by that pipe. Voice or video from within another app (like Facebook is doing now with Skype, web pages do with click to call buttons and enterprise apps will increasingly do). Standalone video, place-based enterprise telepresence (e.g. Cisco CTS-3000 telepresence), person-based video calling (e.g. Tango video). Video group chat, e.g. Google Hangouts. Vertical specific integrations with education and healthcare tools and processes. Etc. You develop very specifically for your specific use case or you won’t get users; interop is thrown off the bus the moment it conflicts with your use case, which is often at the start of the journey

                    Without a replacement for the PSTN, how will I have a universal way to call you or video chat with you?

                    We won’t have a single universal way to call or video, a PSTN replacement. But the sum of our options will be universal:

                    • If we’re not both using Skype, then we’re both using Tango or another standalone video service
                    • We might both use an iPad or Android app. Or we use a mobile WebRTC, browser-based app that works on your iPad and my Droid
                    • If we work for the same company, we launch most of our video call from within our Salesforce.com CRM or Oracle powered workflow software. If we don’t, I might video interview you via LinkedIn
                    • If we’re not both on Facebook, then we’re both on Google+ or GroupMe.
                    • Some islands will interconnect and interoperate, directly or via gateway services. Perhaps one or more platforms will completely open up, enabling some differentiation on clients and app integrations, but exposing the services to the developers that are necessary to maintain critical features and functionality (Google Voice and Google Hangouts?).
                    • Conversations will often start as quasi real-time IM and then get “promoted” to real-time voice or video – either by the IM app, or by launching a third-party voice/video function/service. Global interop/directory/connectivity is much more feasible for IM than voice or video so one path will be to launch voice/video on top of IM services

                    Those are just examples. There are thousands more.

                    The future?

                    We don’t need a single universal service to have universal service in aggregate, and today’s landscape favors distribution, decentralization, differentiation and very specific solutions. We do need universal (not homogeneous) access, but that’s very different from the service layers that can now independently live above. The PSTN will finish its long sunset and we’ll have more robust and powerful communications apps and services. But don’t expect to see another PSTN any more than you might expect to see a t-rex tomorrow.

                      © 2012 NextBlitz Suffusion theme by Sayontan Sinha