Collaboration is one of those emotional technologies that always has a new "it" product that nonetheless gets little adoption. Think of the endless parade of "email done differently" and "email is dead" products that have burst on the scene then quickly faded over the last few years. Or the gazillion messaging tools and steady of stream "collaboration should be based on discussions tied to X" products.
At best, these are just fads, and most go nowhere after the obligatory blogger celebratory post. But some do take root and address real user pains -- Slack is an example. And some initially poor takes do mature into useful products that address real user pains -- Google Apps and more recently Microsoft Office 365 are examples.
Collaboration is an innately human activity, and thus a very personal one. That's why there's always a new solution on offer, to appeal to specific individuals' idiosyncrasies. But collaboration is not a an individual activity; it's a group one. That means a personal fit may not be good for the group, and the group is unlikely to make major changes to satisfy the personal preferences of a few.
That's why so few of these tools stick around.
Email is too entrenched and useful to be thrown out for some other communications venue. Whether or not you like Microsoft Outlook, it's going to remain the center of the email universe, and successful alternatives are going to have to fit into its worldview, as Apple Mail and Samsung Email do and Google Gmail increasingly does.
Likewise, collaboration over fragments of workflow -- over just documents, over just metrics, over just videos, and so on -- is all but doomed to fail because so few workflows are that limited. I get a steady stream of pitches for such content-segmented collaboration tools, but I've yet to see any get adoption precisely because collaboration in the real world is not segmented that way.
But there are natural segments for collaboration. That's why tools like Atlassian's Jira have quickly become entrenched: Projects are natural segments for collaboration. So a tool like the annotated-documentation-oriented Jira can thrive even if general-purpose (messaging-based) collaboration happens over a well-designed tool like Slack or Atlassian's HipChat, which focus on people segments. In fact, it makes a lot of sense for an organization to use both Jira and Slack (or HipChat) -- it's like using both Excel and a database product, addressing different needs despite some overlap.
In fact, I'd argue that collaboration needs to be segmented. Another fad we see is the "everything" style of collaboration tool that claims to do everything in one place. That's a recipe for confusion, at best. We have natural clusters in our workplaces (we call them departments and business units) and even those clusters have subsets (teams and functional groups). Deep collaboration tools align to such clusters and subsets.
To the extent that collaboration should be broad (company-wide), we're really talking about messaging -- that broad "collaboration" is really about announcements with perhaps some ability to reply and discuss. Email handles that quite well, of course. But if you have a messaging-oriented tool like Slack, HipChat, or Microsoft's terrible Yammer that is widely used for discussions within groups, then you can use their "all hands" channel for such announcements.
It gets trickier when you turn to collaboration around actual work products. This is another area where there's been a long parade of "it" products that have gone nowhere.
For common documents, Google does this kind of collaboration best. Its Google Apps sharing and co-editing tools have long been easy and intuitive. Microsoft has tried to introduce such approaches in Office and SharePoint, but the tools have been much too heavy and complex to be effective. (The latest incarnations of Office 365 and OneDrive, however, are finally giving enterprises a real alternative to Google Apps.)
But work-product collaboration needs more than good tools. It needs a real purpose. One mistake tech vendors repeatedly make is to assume that everyone can and should participate in work products as equals. That's a Millennial disease, of course. Hierarchy is both good and necessary because, done correctly, it reflects and even imposes responsibility and experience.
Having multiple people simultaneously write a proposal, spec, or budget is a recipe for a muddle. You know the saying that a camel is a horse built by committee? Well, a horse built by an equal real-time collaboration approach would make a camel look like a racehorse. There needs to be prioritization on what to do and not do, what to explain and not explain, what to accept and not accept. You don't get that with everyone trying to drive the car at the same time.
All of this is why that the old-fashioned kind of work-product collaboration remains the one that is actually used: commenting. Sharing drafts with other people to get their feedback, proposed revisions, and details is a very good thing. And we've been doing that in documents for more than a decade. Work-product collaboration is effective when done this way because whoever is ultimately responsible for the outcome has the best thinking of everyone available without having to accept the poor thinking as well.
We can always use better collaboration technologies. But they need to be actually better for the situations in which they will be used. There are many such situations, so there's room for multiple products and approaches -- but not for an infinite number of variations. We'll still end up with a handful of tools at the end of the day at any given organization. Established tools have the advantage in that reality, but new tools can break through (and have) because they really do something meaningfully useful.
Keep that in mind when you are pitched some new collaboration tool. Those built on emotional factors ("we like to work this way" or "we don't like working that way") or on artificial segments ("collaboration for Millennials," "collaboration for photos," or "collaboration for Mac users") have the least chance of going anywhere. Only those that are simply minor variations on existing tools (which will eventually adopt the good minor ideas) have less chance of gaining traction.