A Few Lines of Code?

Is WebRTC easy to implement in a few lines of code, or not? The question may not have a simple answer but it helps us get to a deeper question that I recommend we take more time to consider. That is: for whom do you mean to make it easy? Or, how much do we really know about the current and future audience?  

Last month at the WebRTC World Expo, Kelcor’s principal analyst, Brent Kelly, goaded the marketers, pointing out that WebRTC is not implemented in “a few lines of code” as some marketing suggests. Tongue in cheek, the demo team from Weemo (exclusively a WebRTC API builder) responded to the challenge and showed the audience how programmers can code a video module with fewer than twenty lines of Weemo-built API code.

Twilio did a similar trick in its demo, coding a phone system on the fly to respond back to an incoming call with: “get off the stage: your time is up”. TokBox bragged that developers at a RadialPoint hackathon built a functional live video and screen-access customer care module like Amazon’s Mayday in just three days using OpenTok. These are only a few examples – all of them very real and very convincing.

I think that Dr. Kelly and the third-party WebRTC services are actually saying the same thing from different directions. On one hand: no - doing interesting things (i.e., scalable, reliable, well-designed, or customer-facing things) with WebRTC tools is not “easy” for many JavaScript programmers. In the subtext here, however, I think Dr. Kelly is actually suggesting that finer tools are needed. In fact I asked him, because I work with him, and he confirmed. On the other hand: yes, WebRTC can be implemented in a few lines of code but with the important caveat, "if you use our tools”.  Third-party packages (Weemo, Twilio, TokBox and many others) are, of course, showing us that they make WebRTC easy to implement with API code. Dr. Kelly and the presenters I have mentioned end at the same place: there is value in making life more simple for people who want to use WebRTC tools. Perhaps Oracle summed up this value when, in their keynote, they vowed to "take the burden off the backs of developers”. Certainly, there is demand for such relief. 

The question that remains on my mind, however, is: where, exactly, is the future demand? Certainly not just with developers. Of course I am encouraged by the energy of third-party offerings filling in the space between WebRTC’s possibilities and its magnifying user-demand, but we have all seen great companies and services emerge around new web-based advances in the past. Some of those are going to fail. I think companies can find more secure footing by taking time to think through their notion of end-users and end-user demand more carefully.
 

Everyone at WebRTC Expo had some working sense of where the demand for WebRTC-enabled offerings rests. Each company will take a different approach. I would like to draw attention to one of the most clever variables in that equation: the demand shift driven by people’s awareness of what is even possible. Many companies will succeed by meeting the obvious, existing demand for communications tools but companies working with WebRTC tools are keyed-in to the rising tide. That is Step 1. Step 2, where other fortunes will be made and lost, is to track the places where awareness is growing. Who is learning and getting excited about WebRTC tools? So far, some developers. Then, of course, a lot of companies that want to help build WebRTC implementations. To whom will they offer it? Some companies clearly have “engagements” in the pipeline. We saw at WebRTC Expo some mature examples of Fortune 500 companies launching implementations. Who is next? Which big companies are looking at Amazon’s MayDay and saying to their customer support teams: how can we do that? How are people first becoming aware of WebRTC? What is finally prompting them to explore implementations, partnerships, purchases? If Step 2 is to ask these questions and position for shifting demand, Step 3 is to spark this demand ourselves.

When attempting to spark demand, “a few lines of code” may be an oversell that can miss its mark (unless the mark is developers, which it just may be). I imagine some developers hear that and think about trying out some WebRTC-based offering. Yet Billy Chia (Digium/Asterisk) commented recently that many developers still hardly know what they could do with WebRTC. And think of all the companies that will really value WebRTC in the future. Their value will derive from concierge engagement, from unifying video, PSTN, databases, and mobile lines, or from not-yet-invented wearables and IoT devices with WebRTC functions baked-in.

The companies that will work for and pay for those capabilities are not yet aware, in many cases, of what is possible for them. If marketing oversells by not catching customers in their familiar range of what is possible, those customers are often dubious. Can we show them and not tell them?

Dr. Kelly and third-party services may agree more than their jousting let on that there is a great need for third-party services to keep coding simple - but why stop at coding? Why stop at developers (not that I don’t think this is a good place to start)? While these future users and consumers of WebRTC-based communication tools may not find us, we can spark their demand by meeting them where they are. We can show them what is possible (not just tell in marketing-speak) in the sphere of what they already know and do. Marketing has to be savvy enough to grab target customers where they are and take them in small steps to where they could be. More to the point: this will take a lot more expertise than marketing and coding. We need to take time to learn, or work with the researchers and advisors who know, how our future customers operate. We might know a little but the best successes will follow companies that know a lot. If your main target is developers, paint the vision in their terms. If you want to reach small businesses, attend to their daily workflow and the relief you provide for it. If you want to reach enterprises, show them what is being done or at least mock-up what they could be doing – not in grandiose ideals but in the context of their current practices and customers. 

Many future customers, if they have seen WebRTC-based video-service portals at all, probably have no clue what technology is in the background (and don’t care). Demand from developers for burdens-off-their-backs or from customers for workflow-simplifying tools is real, as the WebRTC community clearly agrees. We should then think harder as a community about how to activate latent demand hiding behind awareness of what is possible. This will benefit everyone in the ecosystem. Companies that can isolate the triggers of latent demand and position themselves only one or two steps beyond what users now consider possible are most likely to gain traction in the dynamic churn of demand and offerings of the present-day WebRTC market.