close search bar

Sorry, not available in this language yet

close language selection

Rocket.Chat: Enabling privately hosted chat services

Synopsys Editorial Team

Jun 13, 2016 / 8 min read

This is the eighth year we’ve run the Black Duck Open Source Rookies of the Year. Each year we review the world of open source and recognize top new projects launched during the past year, be sure to check out the top new projects of 2016. Today, we’re excited to share the story of the Rocket.Chat project, which enables privately hosted chat services.

How did the Rocket.Chat project get started?

Originally Rocket.Chat was just a submodule of another project. It was created as a live chat extension to an internal CRM product.

Essentially a customer wanted a platform where their team could collaborate internally and also chat with their website visitors externally, and nothing like it existed. There are tools for collaborating, and tools for live chat, but nothing that does both well — together.

So we rolled our own. On a whim, we published the code on GitHub as proof of concept, and it went viral almost immediately in the developer community. The rest is history!

Is there a champion behind the project?

No.

One unique thing about Rocket.Chat is that there is no single champion. The contributors community formed almost magically within a very short time. I had the initial vision for the project and wanted it to exist, but as soon as we launched it on GitHub, it became a global community project, and took on a life of its own.

From the very start, we had internal contributors working three to four hours a day. Once we launched, contributing developers (as well as plenty of people) wanted to help promote what we were up to. One of those early contributors was Sing Li, who dedicated a good part of his day fixing bugs and coding features. He had tried to create a similar system a couple of years prior with older technologies that just didn’t deliver, discovered our project and never left. We hired him as soon as it was feasible.

As with any open source project, many have come and gone since the start, and different people have been heroes at different points. Pierre Ozoux, from IndieHosters, was instrumental to getting our official Docker image published alongside famous projects such as WordPress and Apache Web Server. We had a contributor, Reid Wakida, who (while working as a contractor to the Department of Defense) built the foundation of our roles and permission layer. Bradley Hilton built our data import framework; Aaron Ogle handled bots integration with Chat-Ops and helped to build out our all-important community, and many others made major contributions that are simply indispensable, looking back. But above all, it’s the collective effort of the community, pushing the project forward. Looking back, it’s really unbelievable to see that kind of dedication and how far we’ve come.

I think a difference between our open source project and some others is that we have always had a much larger proportion of contributors. On other projects, they have a much larger proportion of users. There are not enough contributing workers and too many people asking for help, and projects can sometimes lose steam or stall. In our case, we are fortunate enough to always have a large influx of people wanting to join us, committing improvements and bug fixes.

What other open source projects are you leveraging?

Right now, some of the building blocks of our project includes MeteorNode.js MongoDBElectron, and Cordova. They aren’t the only ones, but they are probably the most important ones.

What other technologies is your project aligned with?

We could be seen as complementary with programs like Hubot, Web RTC, Docker, Cordova, and Node.js.

Hubot is an engine for building intelligent bots, executing tasks etc. Hubot integrations have been defining our process and goals really from day one.

WebRTC is a new technology that enables browsers to run real-time communications, and can handle real-time video and audio calls.

Docker is a new way to deploy applications; with Docker containers it becomes much easier to deploy Rocket.Chat at scale compared with what it was with other process managers. Most people are now deploying Rocket.Chat within Docker containers.

Node.js is the language we’re using to code. It’s a very open language, so it makes a big difference in terms of flexibility in how we use it and what we can achieve. It’s also used by the largest number of people, which is good for growing our developer community.

How did you build your community for the project?

Building our community was almost effortless, to be honest. We published a proof of concept, hoping a few people would take a look and give us some feedback. Within three days, it went viral, and tens of thousands of people were commenting and discussing and starting to work on it. It was in the collective consciousness I think, that people wanted this thing to exist; there was a latent need for a better communication and collaboration tool. It gathered a lot of momentum because of this. At the same time, there was no open source version of this kind of tool that people were comfortable with.

Node.js also has a very large community — it’s the most popular coding language on the web — which helped us reach far more people.

As we’ve grown, we’ve spent a lot of time structuring the project to make it very easy to collaborate, all the while listening to the feedback of our community and fine-tuning our approaches. Our contributors also spend a lot of energy on building out and maintaining the growth rate of the community.

The way the project is structured makes it really easy to collaborate. We have developed a culture aimed at being helpful, open and responsive. Jumping in quickly to help people write extensions, help them fit the requirements and get things achieved. We saw it as our duty to essentially be mentors to foster and build the community, rather than dictatorial leaders.

It also helps that we have a demo server. When first becoming aware of the project, people can join the demo server and get to meet the developers, see the conversations happening, get a glimpse into how it works and who is involved.

An interesting part of it, too, is that as a contributor, you’re collaborating as you build a tool for collaborating, using the tool and creating it at the same time. With that in mind, it becomes very easy and cyclical to spot bugs, fix them, suddenly we’re collaborating better — there’s a lot of reward and effectiveness built into that feedback loop. For our community, it’s like living in a city in which you help to build the roads and add improvements every single day.

Who is using it and who is contributing?

We have more than 20,000 Rocket.Chat servers deployed in 20+ countries, and this number is growing rapidly.

We have a fairly diverse user base, from small startups to large communities, in addition to quite a few educational institutions, government agencies, and enterprises. Often larger companies might sponsor a feature or a set of features; for example, Deutsche Bahn, the German train authority, has sponsored features this month.

So has MoviePilot—they’ve sponsored several UI improvements, and they’re using Rocket.Chat to create something called Creators, for people involved in the film industry, which is going live later this week. MoviePilot has a white label version of Rocket.Chat, and I see this becoming more common as we go on.

Because you can host Rocket.Chat data on your own, it’s popular with organizations where privacy is a major issue—for example, we have Stitch, an entire healthcare messaging system, built on top of Rocket.Chat, and we’re used by some departments in the government of Brazil for similar reasons related to data privacy.

The Arizona State University (ASU), ranked most innovative school in the United States, is currently working closely with us to deploy a system enabling over 90,000 students to communicate and collaborate with one another, their advisers, and success coaches this fall. ASU and their partners are contributing applicable code back to the Rocket.Chat project.

The Ural Federal University in Ekaterinburg, innovations leader in Russia, is creating a system that ties together their students and professors via mobile and web applications for this fall. The system will be further developed into a national Massive Open Online Courses (MOOC) system, combining the courses of the best universities in Russia. Enhancements made to Rocket.Chat are made directly available through the open source project.

Research teams from Stanford, Columbia, Oxford, and Bocconi University are piloting a social networking experiment this fall with Rocket.Chat to enable 5,000 sub-Saharan African entrepreneurs in major cities of Ghana, Uganda, and Kenya to collaborate, hone, and collaborate on business ideas and opportunities via Rocket.Chat over mobile phones.

What were your thoughts on launching Rocket.Chat?

Our initial priority wasn’t really to launch anything—we just wanted to get feedback from other developers on the way we were doing this little side project. We wanted other eyes on it, to crowdsource solutions to some of the structural decisions we were trying to make at the time. One day we were fooling around with a pet project, literally 72 hours later we essentially had a major open source product on our hands. That’s how long it took for someone to post about us on Hacker News and for tens of thousands to start getting involved.

Still, even after we reached this critical mass of contributors very quickly, our goal has been to make Rocket.Chat better, to constantly integrate feedback and improve functionality. That was the motivation behind the launch, if you want to call it a launch, and that is our motivation now.

Where do you see the biggest opportunity for growth?

You can have proprietary tools and get a lot of traction, but you’ll never get a big part of the market if you have a closed system. This is where Rocket.Chat is different, and this is why we’re growing. With a closed system, you inevitably create barriers that keep some people from adopting; with open source, and as a main driver for how we run Rocket.Chat, you can be extremely inclusive. We’re giving people as many options as possible concerning, for example, how you host or what you use Rocket.Chat to do. We use the most popular language. We’re trying to knock down all the barriers so that there is no reason why you can’t use Rocket.Chat. The idea is to become a new, inclusive standard for communication. That is a large gap, and we are positioned well to fill it, so why not?

Chat is just a perfect contemporary way for communications. It is not as slow and verbose as email, yet more full featured and expressive than plain old SMS/text. It has the archival and history tracking feature of a forum or BBS, yet offers the immediate interactivity of a messenger. It is the coming-of-age of the collaboration hub.

In terms of new things people will be using Rocket.Chat for, I see it becoming a new way for people from different organizations, multiple organizations, to reach outside of their organization and talk to each other, to create shared projects and to use shared channels. This is something that doesn’t happen enough, and doesn’t happen efficiently; we can change that by adding federation to Rocket.Chat.

We’re also adding a video conference layer that’s much more robust than our alpha version. It has all the functionality for video conferencing and sharing, including sharing with thousands of users, streaming publicly or within just a single project or organization, recording to view later, and so on. It will be exciting to see how people respond and what they use that functionality for.

We’re also creating a bots and apps store, so that users can build new extensions and functionalities, and then publish those and share them with other users very easily. The result, I hope, will be a new level of proliferation of extensions and features, people making and sharing rapidly, continuing to build on the snowball effect that served us so well up to now.

At the same time, Rocket.Chat is almost custom-tailored for Internet of Things (IoT) applications. We run well on small, inexpensive IoT devices, including the $5 Raspberry Pi Zero system-on-a-stick; our message delivery engine, together with Hubot-based technologies, enable IoT devices to communicate and collaborate with one another on a level not possible with the currently popular MQTT based networks.

Once again, this just opens up a world of possibilities for what can be done with the platform to enable privately hosted chat services. We can’t wait to see what the community does next!

Continue Reading

Explore Topics