It sure sounds like a match made in dev heaven.
The fun didn't stop there. While Gitter will continue to run as-is, GitLab's long-term goal is twofold: Integrate Gitter more tightly with Gitlab, and "open source the whole of Gitter, allowing members of the community to contribute and improve the product for everyone!" (Exclamation Gitter's.)
You'd be right if this sounds like a shot across Slack's bow, just like GitLab itself has been firing salvos GitHub's way on and off -- offering enterprise code hosting, Docker registry support, and plenty of other features. But Slack's got mindshare and first-mover dominance and it has proven to be tough to dislodge -- especially now that it has an enterprise edition in the offing.
Even looming competition from Microsoft and Google aren't guaranteed to make any dents in Slack's empire of glorified IRC. No, Slack didn't invent group chat, but with any technology, it's not about who gets their first, but who does it best and who makes it most appealing. And as far as Microsoft goes, its Teams product doesn't look like anybody's idea of a Slack replacement (or even a replacement for IRC, for that matter).
Given all that, how could GitLab make Gitter a convincing alternative to Slack, especially for the enterprise developer community that's GitLab's mainstay?
1. GitLab's niche for Gitter may already be there
If you can't knock an incumbent off its pedestal, the least you can do is carve out a niche.
Slack's total userbase is estimated at around 5 million, while Gitter's Git Lab acquisition blog post states there are some 800,000 Gitter users. The difference is that Slack's base consists of a mix of developer- and non-developer users, as Slack's been pitched as a general enterprise productivity tool. Gitter's focus is developers, not a generic business audience.
And Gitter built that developer audience through direct integration with services where developers already are -- from GitLab and GitHub users alike. GitLab wouldn't have to do nearly as much work to draw people in as another service might. Gitter already built it, and they have already come.
2. Open source means fewer barriers to innovation
By now, few people are deluded into thinking that open sourcing something automatically promotes its development, or for that matter makes it worth bothering with in the first place. But open source does lower the bar of outside access. A developer with a feature idea can implement a working version of it and either rally support around including it in the original product or make their own derivative of it.
All this goes double when the product in question is aimed specifically at developers. Gitter is squarely in that category. Open sourcing it means having it go from "for developers" to "by and for developers."
3. More developer-centric features, rather than enterprise-centric ones
When developers are the key supporters of a particular tool, they end up having a more direct say in what ends up in the final product. Many features that appeal to enterprises are there mainly to satisfy the needs of the enterprise as a whole, and aren't always there to make enterprise developers happy.
Since Gitter is, again, aimed mainly at devs and not necessarily at a more general enterprise audience, there's a better chance here of the future feature mix staying true to the user base that's most drawn to it.
4. Less "Github guilt"
One of the truly curious things about GitHub is how a proprietary service ended up becoming the go-to place for open source projects to set up shop and live. It seems downright counterintuitive -- even embarrassing -- to the truly open-source faithful. Sure, you can always export from GitHub and move to another service if you need to, but it's about the principle of the thing (in theory, anyway).
GitLab's made a point of this as part of its pitch to draw developers to its side of the fence. Adding Gitter to the GitLab platform and making it open source is another avenue for GitLab to expand its overall portfolio without retreating from this ideal.