THE BABEL TOWER OF COLLABORATION TOOLS

As a consultant I am often required to utilize my clients’ official collaboration tools. Whether it is Slack, MS/Teams, Cisco WebEx Team, Google G Suite, WhatsApp for Business, Workplace by Facebook, among others, one soon comes to realize that these tools offer similar functionality. They all provide a managed working area for teams to engage via impromptu chats, shared documentation, and other services such as video conferencing, calendars, and so forth.

We are dealing with a suite of commodity services, and that is precisely the conundrum. Almost by definition a commodity should be standardized, but current collaboration systems force us to commit to a proprietary vendor solution; one that will not integrate with other systems. Imagine if we could only call the people that use the same cellphone and carrier as ours. iPhone with AT&T only able to call other iPhone users, and Android users with T/Mobile only able to call like systems.

It gets even worse. In my experience, many companies have a hard time having their employees use the “official” collaboration system. The chosen tool ends up being used only on an intermittent basis with employees continuing to use their favorite best-of-breed tools. Sure, the company may have MS/Teams, but people still use Zoom for Videoconferencing, WhatsApp for quick chats, Dropbox or Box or Google Cloud or OneDrive for file sharing, and Email and Outlook calendars for messages.

I don’t believe this situation is sustainable. Ideally, the market will eventually whittle down to one or two leading systems. However, if you check the many reviews in Google-land, you will soon see that, as of today, no one tool is particularly superior to another. Natural convergence to a single best of breed choice is not likely anytime soon.

This situation is not unlike earlier times when network protocols were part of a vendor’s product offering: IBM’s SNA vs Dec Net, Token Ring vs Ethernet, etc. It took the introduction of a superior spec, available for free, to align network computing around TCP/IP, practically by acclamation. Eventually all vendors were pressured to abandon their proprietary protocols and move to support TCP/IP. It was then, and only then, when the networking layer truly became standard and pervasive that the right conditions for the expansion of the Internet were created.

So, imagine how wonderful it would be to use a common environment that allow us all to collaborate transparently regardless of platform?

For that, we need standards. But how exactly do standards occur?

Before TCP/IP took hold there had been an attempt to establish a networking standard by an international committee: The Open Systems Interconnect standard (OSI). In the end, OSI was not successful because its spec was bloated and mostly unimplementable. It was a camel; a horse designed by committee.

That is not to say that standards established by committee never work. The electric grid is an example of an industry-designed standard godsend. As the electric grid grew at the beginning of the last century, regions used a variety of electrical specs. From the original AC grids versus DC grids, and with the help of governmental standards, the country eventually settled on 120 Volts of Alternate Current at 60 Hertz. Other countries ended up adopting different standards (220 V 50Hz in England), including different electrical outlets and connectors, but it was only recently with the popularity of international travel that this became an issue. Enter the use of adapters to allow connecting our equipment in different countries. And indeed, there is software that purports to integrate various collaboration tools, but most of them focus on the instant messaging portion only. I don’t believe this adapter software method is transparent and universal enough to become a solution. Having said this, if your company uses two different tools (maybe the result of a M&A), such adapters may be handy for transitional purposes.

Another way to achieve standardization is through the power of monopolies. An example is the original land-based Telephony system in the US which became standardized by virtue of AT&T’s dominance in that market during most of the 20th Century.

However, that ship may have sailed when it comes to collaboration tools. There was a time, for example, when standardization by monopoly could have occurred in this area when AOL dominated the chat market. Had American Online chosen to open their IM system and its APIs, there is no doubt that the technical successor of AOL Chat would now be the universally recognized way for everyone to do IM.

Controlling the central user directory with potentially billions of users could have been worth a fortune to AOL, but they missed that opportunity. Instead, AOL’s IM went down with AOL, and a veritable zoo of chat solutions emerged. Today we chat with Facebook, LinkedIn, WhatsApp, Teams, Google Chat and many others. Wouldn’t it be nice to just have a single contact list and journaling capability? You know, the way it was back in the days when the only game in town was AIM?

Another way standardization occurs is when vendors realize no one will attain supremacy, and that as a commodity, the only way to reduce costs is by partnering with other vendors. This type of standardization by Industry has been the main driver around cell phone signaling standards. Because it is driven by vendors still hoping to gain market share by offering unique competitive features, this type of standard typically covers only elements of the platform while allowing some incompatibilities to remain. Even if unlocked, your phone still needs specialized SIM cards to connect to different carriers.

So, what is the most likely road for a future collaboration systems standardization? I believe, the current situation is unsustainable, and that there is a chance that major vendors will eventually conclude their collaboration systems will need to integrate with others. They may then get together and agree to, at a minimum, define integration standards to achieve interoperability between their solutions. Still, I do not believe such an outcome is ideal. Such integration will not be so transparent, and it is unlikely they would try to standardize the actual products.

Another possibility is the emergence of an Open Source collaboration system that overtakes the market the way TCP/IP did. In such a scenario, vendors would be obliged to integrate with this emerging tool at first, and ultimately abandon support for their own tools. There are several open source collaboration tools in GitHub today, but there is no reason, so far, that anyone of these would have the overwhelming acceptance of TCP/IP. To be fair, TCP/IP had the strong sponsorship of some large vendors such as AT&T to stake its claim; so unless a major vendor adopts and pushes for an open source system, the utopian unified collaboration world I envision, might take years to occur.

On the other hand, Microsoft, Google, if you are listening. How about volunteering your system as open source? That would be a daring move that would practically force your stack as THE ONE.

Do you agree? I am also curious about your own experiences regarding this type of tool.