Gitter is a GitHub-based chat tool for developers

0 Comments

I pinged Mike Barlett of Gitter, a GitHub-based chat tool, now in limited beta, and we chatted about the tool which is geared to use by developers. Gitter is a shining example of deep and narrow social tools that serve a specific sort of constituency very, very well. In more than a few ways it reminds me of Slack, which I wrote up last year (see It’s getting even more real time: Slack and Skwiggle).

As I recently wrote, we will see a steady departure from horizontal, shallow social layers grafted on top of enterprise applications: the social collaboration architecture. This migration is happening because that architecture is not based on the shape of our work, but instead, 20th century structures of control:

Stowe Boyd, Beneath the chatter about the Future Of Work lies a discontinuity

By the ‘shape of the work’ I mean two things: 1/ it doesn’t reflect the work activities or products, necessarily. Consider a piece of software under development in GitHub, or a magazine issue being developed in Adobe Creative Cloud: the environment for work is built-to-hand: it fits the form of the work being done. And 2/, it doesn’t necessarily reflect the way that each individual spins a working set of cooperators to get their own work done, and how these sets combine to form scenes, in which large numbers of overlapping sets are connected, socially, toward emergent ends.

We will see more cooperative work, supported by loosely connected, small and simple apps, a break with the model of enterprise software vendors. Not because people want apps that remind them of Snapchat or Foursquare, but because people are doing work at local social scale, not across an enterprise, in general.

So Gitter perfectly matches this observation, since it immediately inherits the shape of the social groups operating around GitHub instances. It simply relies on the social identity within GitHub, and them creates IRC-like chat rooms for public and private repositories. And its UX is organized specifically around sharing things that developers care about, like sharing and commenting on code and GitHub’s notion of issues.

In this screenshot you can see the issue number #32 is mentioned, and mousing over pops the description into context. (Click on image to enlarge.)

gitter

And here, below, you can see code pasted into context, with the formatting and styling retained.

gitter2

I only had a short demo, but there are a long set of integrations — like that with Trello, the task management solution — and other features. Here’s a list from the website:

Know who’s seen any message. Edit messages after you’ve sent them. Webhook integrations with Jenkins, Trello and more. Automatically embeds content like YouTube, pictures of cats and other stuff. Did we mention our smart notifications?@mentions. Batched notifications. Won’t annoy you by making your phone beep on every message. Awesome emotigifs. Infinite chat history stored in the cloud. Searchable too, naturally. Oh, and a unified activity feed. Phew, that’s a lot.

I found it interesting that Bartlett started the parent company Trou.pe with the goal of building a more general tool — the sort used to communicate and work socially across the spectrum — like a Yammer, IBM Connections, or the like. Then, for the needs of the developers building it they did a loose integration with GitHub, but then realized that they would be creating more value for a narrower community  by deeply integrating with GitHub. And Gitter was born in one two week experiment. The response has been very supportive, Barlett says, and they signed up over 30,000 after announcing the beta.

I can’t be sure that Gitter is the one-Github-chat-tool-to-rule-them-all (yes, I saw the Hobbit the other day), but I am pretty confident that this sort of solution — those that are shaped by the work and not the outmoded structures of organizational control — will grow in use. And over the next year or so, the major enterprise software players will do more than pay attention: they will reformulate their product strategies around small-and-simple tools that are loosely connected, but which support deep and narrow work.

Comments are closed.