I was meaning to write something about Skype, Linux and WebRTC. But never got around to it. Until now.
[UPDATE: This post has been modified to the request of a few people]
The reason why I decided to write about it eventually? This tweet by Alex:
While some like this plugin, others don’t. They tried it and decided that the warning messages it pops up when being installed aren’t worth the effort.
But do we really need a WebRTC plugin in 2016?
The Electron WebRTC app approach
What did catch my eye was the Skype for Linux announcement. This is an alpha release of the Skype app for Linux – something that Microsoft have been neglecting for quite some time now.
The interesting bit isn’t that Microsoft is actively investing in a Linux version for Skype and acknowledging this part of the user base, but rather how they did that and the stance they have.
Here are a few lines from the announcement on the Skype community site:
The new version of Skype for Linux is a brand new client using WebRTC, the launch of which ensures we can continue to support our Linux users in the years to come.
[…] you’ll be using the latest, fastest and most responsive Skype UI, so you can share files, photos, videos and a whole new range of new emoticons with your friends.
The highlighted text is my own addition.
Here are my thoughts:
- This is implemented on top of WebRTC and not ORTC. In a way, we’ve gone full circle with Microsoft – from ORTC, to adding WebRTC support in Edge to using WebRTC to develop their own products where needed
- Microsoft gives the best reasoning behind using WebRTC in its own development: to ensure continued support for Linux
- For the most part, using WebRTC equates better support for more devices and platforms than any other technology out there today
- Yes. You still need to put some effort into getting it working on some platforms – but with a lot less of a hassle than any other technology and at a lower cost
- Responsive Skype UI = HTML5. So there’s some browser engine / rendering engine for HTML in there somewhere
- Latest and fastest…
It turns out Microsoft decided to use Electron.
What is Electron? It is a framework around Chromium that can be used to created desktop apps from web apps. And it is the most popular platform for doing it these days.
The irony.
Microsoft. Who owns, develops and promotes IE and Edge. Who was against WebRTC and for ORTC. That Microsoft used Chromium (effectively Chrome) to bring its Linux Skype app to market.
A few years ago, that would have been unheard of. Today? It makes too much sense – it actually increased the value of Microsoft in my eyes. Making the most practical decision of all and putting the ego aside.
Back to a WebRTC Plugin
So.
Would you invest in a WebRTC plugin these days?
Writing and maintaining a WebRTC plugin is hard work. It gets updated too frequently to be considered a one-time effort, so maintaining it comes at a cost – a type of cost that usually makes little to no sense. Doubly so with the current trend of browsers to kill off the plugin route.
I believe it will be hard to maintain such a plugin by a vendor or a consotrium, and if the idea is to open source it to the larger community so the external community can take it up and continue to work and maintain it then that’s just wishful thinking. Open source projects are not synonymous with community development – they don’t all get picked up, adopted, used and maintained by the masses. The webrtc-everywhere project on github shows that – 2 contributors, a few forks, but not much of a collaboration or community around it.
Furthermore, do we really need a WebRTC plugin?
Yes. I know. Safari. Important. IE. All those poor enterprise guys forced to use it. You can’t live without it and such.
But guess what? That same target market? How receptive do you think it will be for a plugin? What will be the install rate and usage rate for a plugin in such environments?
What to do in 2016 with WebRTC on IE/Safari?
There are two use cases here:
- I need to use the service daily
- I just want to get on a URL and do whatever needs to be done (call a doctor for example)
The first one can be solved with an installed PC app. A quaint choice maybe, but one which seems to be popular by comms vendors who started from the web. Think Slack or even Whatsapp – they both have a PC app. If you are using a service daily, the idea goes, you might as well just have it somewhere handy in the background of your PC instead of having to have it opened in a browser tab all the time.
The second one is where things get nasty. Asking for a plugin installation for it is just like asking for an app installation for it. Maybe worse if the installer of the plugin comes with a large set of browser warnings (because browsers now hate plugins). So you might just rethink the app option – or just ask the user to come back with a better browser.
My suggestion?
Explore the option of using Electron instead of a plugin.
Where is WebRTC available? There’s a free cheat sheet for that! Check out the
Microsoft has already been using Electron for other new products (Visual Studio Code for example)
IMO the distinction between WebRTC and ORTC is not a big one after they have influenced each other so much.
I still think that a Safari/IE plugin is still very relevant for many services and platforms based in WebRTC and will be for another 2-3 years at least. I’m not an expert on IMTC but I appreciate everybody’s effort to help on this space.
The IMTC has no project relating to WebRTC plugins.
However, the IMTC does support work by Philipp Hancke to enhance WebRTC test frameworks. See: https://github.com/fippo/testbed
As part of this work, Philipp is enhancing adapter.js to improve video interoperability.
Bernard Aboba
Member, IMTC Board of Directors
Interesting read as always Tsahi! Here at 24sessions we struggle daily with this issue. My experience however is that adding a browser plugin feels less obtrusive than installing isolated software for most of our users. I do however agree with you that factually it’s more or less the same and from a developers point of view, a web-app is preferred. We currently offer both and so far our clients almost all choose the plugin.
Thanks for sharing this observation Rutger – it is always good to see what vendors are seeing on their end.
Praying for the day where we can ditch the plugin though! ps. Have you seen our api?
Now I have 🙂