The Mattermost Origin Story

Check out our open-source Feature Flagging system - Flagsmith on Github! I'd appreciate your feedback ❤️

Episode Overview

It's interesting to me just how many successful companies have started out in gaming and eventually move to something completely different. Mattermost is the latest example of a company that took this path and eventually landed on offering an open source messaging platform for companies.

With no previous experience in open source Mattermost's founder, Ian Tien, launched their product on open source as a test to see if anyone cared about it. What came back was a massive pull request and traction from the community that was beyond any of his expectations.

Today, Mattermost is the open source slack alternative with over $70M in funding, 165 employees and is growing their customer base quickly. I loved this interview and Ian's excitement for the open source community.

Enjoy!
Ben

Episode Transcript

Joining me is Ian Tien from Mattermost. Thanks again for your time, Ian. It’s great to have you on. Do you want to give us a bit of an overview of yourself and your business?

My name is Ian Tien. I’m CEO and Cofounder of Mattermost. We started as an open-source project. A lot of us called us the open-source alternative to Slack. Over time, we became this messaging collaboration platform that a lot of DevOps, SREs, software builds and operators love to use. You’ll find us a lot in on-prem installations with DevOps communities, integrated with their different CI/CD or software development tools. You’ll find us also with a new cloud product where we’ll host it for you and all the ranges in between. It’s been amazing to start as an open-source project and grow into a business and have venture capital-backed partners like Redpoint, Y Combinator Growth Fund and Battery Ventures. We’re one of those open core venture-backed companies that’s excited to grow and deliver more and more value.

{{divider}}‍

What was the genesis of the project? You went through YC, but with a gaming company?

In YC, sometimes you don’t get it right the first time. We started with this HTML5 game engine and this was back in 2012 when HTML5 was a thing. The promise was we can go across platforms. We can go on Android, iOS, web browsers, and you didn’t have to rebuild for every platform. JavaScript is the new assembly. It’s powerful. It’s not great. It’s not the perfect language, but you can do all these things. We then found out that there wasn’t a market for it. No one wanted to pay for it. They would love it for free but it didn’t add enough value.

We did a real-time strategy. We were able to get it working on desktop and even on iOS. The difficulty was Android. The Android units weren’t strong enough to do the processing. We needed to have great gameplay where iOS and desktop were. As a multi-platform, that technology didn’t quite work out. In that prototyping phase, we built a few games using HTML5 which was a real-time strategy and they started monetizing. We started as this technology company and became a game studio. We ran that for about 3 or 4 years and it was profitable. We were a rising company, but we didn’t need venture funding. We’re getting funded and growing and hiring all these people. My friends like, “Games are cool. Let’s go build more.”

We love games but games are super hard. They’re 24/7. You’re working through all your holidays because that’s when people are playing the most. It’s this incredibly complicated service. You have to keep putting more content into it. It’s fun but it’s a lot. While we were building this, we were about 30 people with a lot of contractors like artists and things like that all around the world. We had a messaging platform that ran our business on. This was before Slack. One day, this messaging platform got bought by a big company and it started having a lot of issues. It had bugs. It would crash. It would lose data. We were so frustrated.

When we tried to leave, this company wouldn’t let us export the data. We had 26 gigs, all our analytics, conversations and art designs were on this platform. We couldn’t get them out. When we stopped paying our subscription, this company paywalled us from our information. This thing inside of us is like, “How’s it fair to lose all of your data because you stopped paying a subscription? You’re renting your data.” We had over ten million hours of messaging on our game platforms. We’re like, “How hard is it to build this messaging client?” As engineers, we built it once, twice and the third time. It was working for us to run the company on it. We decided to open source it. When we open-sourced it, it grew and took off. People who had the same problems wanted to run their messaging platform and they wanted complete control. They didn’t want any outages. They didn’t want any dependencies. They want to depend on themselves and be able to build and expand on it.

The messaging product, which was called Mattermost, grew quickly. We were like, “This is a much bigger opportunity than the video games.” We transitioned the company. This is back in 2015. We were like, “No more games. Messaging is the thing. It’s important.” Around March 2016, we came out with a paid version. That paid version became the core of the company. A couple of years ago, we raised Series A and then later Series B, and we had been growing venture-backed ever since. That’s the story of Mattermost.

{{divider}}‍

Is the trick to starting and scaling a messaging company to start with a gaming company? I noticed that Slack almost has an identical story in terms of their gaming heritage.

That’s probably the right way to go. If you look at Discord from Jason Citron, it was a gaming company. Slack from Stewart Butterfield was a gaming company. If you look at LINE, one of the largest ones over in Asia. It came from Naver Corp, a gaming company. When you build a gaming company, you have to have a game and it’s going to have content. You have to have an eCommerce engine to do free-to-play and buy virtual goods. You do need the messaging piece to have a social connection. You have to have all the security because all these systems are under attack all the time because people love to break into games. You have to run it 24/7. You say, “What does it take to run a messaging company? I don’t need this.” I build the messaging piece and that’s a company. It’s way easier to build a messaging platform than run a games company. With games, it’s similar collaboration. Especially free-to-play, you have to make an environment that people love, that people will want to go in their time and to do things. It makes it adjacent because you’re making collaboration and you’re having places where people can get together and connect and those are related.

{{divider}}‍

You started building a messaging platform for your own use. Whose idea was it? Was it open from day one?

When we started, we had no idea how open-source worked. Me and my cofounder, Corey Hulen came from Steve Ballmer Microsoft. I’ll tell you how big a change it was. One of my former managers at Microsoft had a custom printed poster behind his desk because Linux competes with Microsoft. It was Windows Server share versus Linux share in the enterprise. It was a graph over time. It looked like Napoleon’s march into winter. Linux share is getting pushed down and that was my manager.

{{divider}}‍

I know that map you’re talking about. My wife’s great grandfather has got that map on his wall. It’s famous. It shows seventeen data points. If you don’t know what I’m talking about, google it. It’s cool.

It was this period of time where Microsoft was very anti-open-source. That’s completely changed. Now, Azure runs more Linux than it runs Windows Server. I came from this world of Microsoft. I was at a video game company. I had this product that was not initially open-source. It was a messaging platform for ourselves. I met Sid from GitLab because we’re both YCombinator. This was before or during his Series A raise for GitLab. We were at this outing and we started catching up. I was showing him the early versions of Mattermost. Sid’s feedback was, “You should open-source that.” I’m talking to a guy who left Microsoft. His logic was brilliant. It’s a prototype. If you open-source it and it’s a thing, you can always close source it and just continue building because it’s a prototype. It’s a few months of work. If you open-source it and no one cares, you should give up because it gave away everything and no one’s interested. That was a very powerful logic.

We open-sourced it and what happened was people loved it. Not only did it get super popular and lots of GitHub stars and it engaged with the community. What happened was people were contributing. We open-sourced it maybe in June or July. I think it was November-ish, we had this pull request that was bananas. It was like, “I’ve never contributed open-source before. I would like to offer you a 10,000 line pull request to translate every single string into a localization framework and then translate all of it to Spanish.”

{{divider}}‍

That’s the job that you don’t want to do even if you’re being paid.

This is a person who was down in South America who worked at a company that was using Mattermost at their company and they needed to localize. Because our rate of innovation was quick, we were pushing out builds and builds. The fork had to be reemerged. It took a week to reemerge the build because of all the translation frameworks. It’s much easier to be like, “Let me give that to you upstream, and then my life’s easier.” Those are examples of the power of the community. Once you have this community product fit, those open-source projects take a life of their own. That’s what we found.

{{divider}}‍

Remind me of the timing around this. Slack existed at this point. It wasn’t the juggernaut it is now. Especially in tech, it was growing pretty rapidly. I used to run a software agency. Back in the day, we had an IRC server. I can never quite remember why we turned our IRC server off. We went for a period of not having a real-time chat system and then we started using Slack. If you give people real-time chat, especially engineers, they use it to send each other super-sensitive information like database passwords, TOTP, ID.

{{divider}}‍

We were a small agency, but we were working with larger clients and thinking, “Is this a good idea? Who are these guys?” It’s a ripe thing for open-source. The other thing that Slack did such a great job of was the UI and the UX polish was super high. Was that something foremost in your mind when you were building this? My preconception, which is slowly changing, is if I clone some messaging system off GitHub, it’s going to look like a dog’s dinner. I’m expecting that. Was that something that you were super conscious of straight out of the gate?

Yes. There are two things and maybe I can address them both. Coming from video games, you think, are people having an emotional experience with this? Are they enjoying it? It’s not about UI polish and this or that or the other thing. It’s about, how does it feel? What does the software feel like? For developers, which how we came from open-source, there are a lot of things that they like about us like the compactness of the views, to be able to put a markdown in and have it render the way that you expect, having a lot of compatibilities, having syntax highlighting. A lot of these things are second nature, “What would it look like if you empathize with that developer community and put that into the messaging platform?” That’s how it looks and feels.

The people that work here care about the tools that they use. It’s a little bit of that balance. What you’re going for is not a set of checkboxes. It’s like, how does it feel? I share that with you and that’s one of the differences when you have these messaging platforms built by game companies versus enterprise software companies. Enterprise software companies are like, “What is your use case and benefits need versus what’s the emotional experience?” You need both. We need to get better at those hard ROI use cases and that’s the enterprise things that a lot of other companies in our space are good at. That’s common. The different thing is that feeling. That’s what we think about the experience of the product.

In terms of the other piece, it’s that trust that you have in your messaging platform and what happens when you’re sending private keys and all this information. I’ll take this again to emotion. The emotion is when you have built a SaaS service or a games company, when you have seen your players interact with your software, and when you have seen the logs on the other side. Players are playing a metagame. They’re impersonating people. They’re doing all these funny things in the messaging and the games. You’re reading through all those logs. You’re seeing how these people are sharing a lot of information. They don’t even realize that there are developers on their side. They’re trying to debug these things. They’re reading through the logs to help debug them.

When you start typing in these messages, some engineers are like, “I am typing this and that’s going in someone else’s database, that’s going in someone’s logging system.” It’s a different feeling. A lot of these enterprises say, “I have to control that. I wanted to own that. If I have data retention policies, I want to know that’s deleted.” The SaaS service says they have data retention. They say they’re deleting messages, but maybe there’s a government hold, maybe there’s a lawsuit, maybe there’s some reason why they can’t delete. The things that I thought were ephemeral that was in the moment, there’s a pretty long record of that. I won’t name which one but there’s a messaging system that sent out this notice saying, “We had logging turned on and we have all your passwords in cleartext. Can you please reset your passwords?” This stuff happens all the time.

{{divider}}‍

It’s always the logs. Even Google get that wrong. I’m terrified of logs.

We assume that they’re accidents, but you’ll never know. What is trust? Trust is making yourself vulnerable base on the positive expectation of someone else. There are a lot of people, especially developers, who want to see the source code. They want to see that there are no backdoors. They want to see the architecture. They want to run it themselves. They’ll run their own encryption. You can build trust with other folks but some people want to trust in their own infrastructure. There’s a segment of the market for that and that’s a segment that has chosen Mattermost over and over again.

{{divider}}‍

From day one, was this the obvious go-to-market direction? Did it take a while to bubble up?

We listened to customers. For me, I don’t quite know how things will unfold, but it’s always listening to the market, listening to the needs. Who are the people that are asking questions? What is their need underlying it? A lot of folks are going to be large enterprises and they’re going to be nation-state targets. They’re going to be saying, “I don’t want to put all of my eggs in one basket.” I am a little careful. When you look at some of the other SaaS-based messaging products, they’re like, “Here are the publicly aware endpoints. Here’s where all the ingress and egress happens.”

You’ve got these single points of failure. If anything goes wrong with those points, the system can be compromised. It’s like, “If someone’s going to compromise someone else’s system, mine might be attached to that.” Those are the things that our customers say to us, “Why Mattermost?” They have certain needs that aren’t met by other products on the market. They have certain levels of trust. They have certain risks. They have nation-state targets that other organizations don’t have. It’s about talking to your customers, understanding their needs and serving them well. It’s not about being a genius at these things. It’s listening and responding. That’s how we built the business.

{{divider}}‍

Talk a little bit about the packaging. A well-executed messaging platform has potentially lots of stuff going on. You need to search, data store, real-time, WebSockets. There are probably 3 or 4 other things that you would have as a dependency. Every one of those things makes your deployment story more difficult. How do you deal with that constraint?

Architecture is important. When we started, “Let’s build a real-time messaging system.” We built one already in Python, that is where our video games. We’re like, “What are the contenders?” You’ve got Python. It’s popular, easy to read, easy to build a community around, one way to write things, declare things. The other one was CRC++, optimized, fast, compiles down to a single binary so you’re not installing libraries and get conflicts. Single binary for high performance. You got Erlang, which is designed for real-time, redundancy, and it does all these things. It’s powerful. This is back in 2015, but we even started in 2014. We triangulated across those three languages. This new thing called Golang wasn’t fantastic in 2014, but it had the elements of all three. It wasn’t the best at any one of those, but it had those themes. That bet on Golang has paid off. As the languages matured, it’s paid off both in being the right technology, but also drawing the right community. We still are probably one of the largest, if not the largest, most sophisticated Golang open-source project out there that’s an application. That architectural choice was an example of how we kept things simple.

The other piece is being thoughtful about our audience. Developers want to use us, but it’s the IT admins that want to install us. In our database, you could do a lot of fancy NoSQL stuff, but we’re Postgres or MySQL. It’s like plain vanilla. Put a proxy in front of us and here’s a single Linux binary. You can use either of the most popular databases in the world. Relational, everyone knows how to admin them. Enterprises have approved these decades ago. It’s thinking about empathy for those IT men that runs us and as well as thinking about the developers that love the source code, want to contribute and want to use the product.

{{divider}}‍

What do you do around things like search? Is that something that has another dependency?

We use MySQL text-based search. When you get to 3 million to 5 million then you start getting into Elasticsearch, which is part of our enterprise product. That’s the more sophisticated versions.

{{divider}}‍

In terms of packaging and deployment, did you put a lot of thought into one-click Heroku installs or simple Docker containerization?

We have one line Docker install and then we have a three-node laid out Docker install if you’re running Docker that works. We had Heroku early on. Our community took us over. We’re in everything, Puppet, Chef, Ansible. There are a lot of deployment platforms that have used Mattermost. Mattermost became the demo for almost any orchestration piece. In the end, there’s Mattermost. There’s like, “You got an open-source Slack at the end of the demo.” It’s been great to see all the community rally around that.

{{divider}}‍

In terms of the enterprise product, can you talk a little bit about how you decided on which to camp there?

GitLab has a great buyer-based open core presentation. They might have won the Linux Summit. That was great. I like to quote from that. A buyer-based open core is saying, “For each of your offerings, have a different audience.” We’re free-offering that for developers. For our paid offering, that’s for IT administrators and CIOs. What does that mean? One is generally we don’t want to monetize individual contributor developers. They don’t have budgets to spend. You don’t want to make that experience too janky. What happens is a developer would discover us and they’ll start running the open-source version and they’ll get maybe 10, 12, 15, 25 people onto the open-source version and then they’re happy.

A few months later, they open up the system admin console and there are 50 to 100 people on that instance and they’re like, “What happened?” It’s like, “I realized, I’m running a shared service but I’m a developer. That’s fine. IT, go run this. It’s a shared service. We’ve already vetted it. It’s open-source, just go administrate that. I’m going to add you as an admin. Goodbye.” The IT person looks at it like, “I need user management. I might need eDiscovery. From my financial services, I might need compliance integration with a global relay or Smarsh to run those backends.” They look at our price list and are like, “The paid version has all those things.”

Developers are used to taking open-source, customizing it and building on tools. IT is more trained to say, “How do I buy this and how do I keep it safe?” Developers are like, “Let me fork that for you.” IT is like, “If you fork it, I can’t get support. Let me go buy this thing. Let me go get a budget for this.” Having two different audiences and two different value propositions makes it a clean type of packaging and a clean journey for deployment within an organization.

{{divider}}‍

Is that the most common sales path for you guys? Is that someone who self-installs and runs it? Back in the day, it would have been on a machine under their desk. Is that quite a common path for you guys?

That’s pretty much the main path. That’s probably the majority case. There are other cases where they’re like, “They have it over there. Let me go buy one over here and expand. That one looks good.” It’s got to be on-prem. It’s got to be highly secured. You have the compliance thing. There’s a mix but that one is how we started. It’s the one that pictures how we want it to work.

{{divider}}‍

In terms of running these applications on-premise, are you mainly targeting Kubernetes? Are there other deployment stories that you’ve got?

You name it, we got it. We have a Kubernetes operator. It’s interesting because it’s for applications. It’s one of the most more sophisticated Kubernetes operators out there because it’s bringing the prerequisites and orchestrate everything properly. We have a lot of kudos from our customers on it. It’ll be like a half-hour call, they jump on, and they got a few questions. Whatever we hear, we want to push back on the documentation but making it super easy to run, K compatible, Docker compatible, all those things. It’s part of having a great community and it’s part of being focused on our customers having empathy for them. That’s where we built our deployment.

{{divider}}‍

A few months ago, I didn’t know what a Kubernetes operator was. For the benefit of naive people like me who are reading, can you talk about what that is, why enterprises care about it and why it exists?

When you think about orchestration in general, there’s a saying, “Treat your infrastructure like cattle and less like pets.” If you’re thinking about individual nodes and putting them together, it’s a lot of configuration and there are runbooks and all these steps to go through. Different orchestration technologies, which Kubernetes is one, is like, “How do I automate all that and put intelligence in there? How do I deploy things as opposed to a node by node? How do I put things together in an orchestrated set of resources that can self-heal, manage, run upgrades and do all these things smoothly?” It’s almost like ops management in the large. I’m trying to figure out how to say it abstractly to folks who might not be as into that layer.

{{divider}}‍

I hadn’t seen this before. Someone was researching OpenShift and put an OpenShift cluster together. I saw that they had this app store. I had no idea it existed. This is like an enterprise app store and you can click a button and seven minutes later, you’ve got Mattermost installed. That’s the theory. They’re super successful. OpenShift is dominant in that market space. Operators are cool. It means that you can collapse what would have been months of installation, paying down into what they’re selling, which is almost one-click installs.

It’s making it easier. The whole world is going digital. The ops folks are in high demand. The easier you can make ops, the faster the whole world goes. Back in the day when PCs were difficult to use and you had Windows 95, which people remember how transformational that was and making things easy to use. They got Windows 10, which makes things even easier with apps and simple installs. Think of that analogy on the personal computer side. One of the dot bat files was to boot up your computer. Now it’s easy to click and go and you got 3D graphics and all of the things. Think of that same analogy on the infrastructure data center side. That’s one way to think about Kubernetes and the different virtualization pieces. I’m going to take a shot at that analogy.

{{divider}}‍

Do you find that it’s quite labor-intensive to keep those deployment methods humming and up to date? Are you quite judicious about, “We could support X but we’ve only had three people mention it and one of them might be moving off of it?” You can accumulate that quite quickly.

We do have this explosion of deployment options that have come from our community. We’re standing largely around the install guides that are on our documentation, whether it’s CentOS, Red Hat and different flavors of Linux. We’ve got the Docker install, the one-line previews. The Kubernetes piece is where we think the whole world is moving. This architecture is going to take a little time but that’s where we’re investing. When we use our cloud product, the Kubernetes operators integrate how we run our own systems. There’s a little bit of that natural building up with the systems through their own use. That’s one way to maintain it.

We think it’s either a head-tail or a power-law distribution where there’s going to be a couple of nodes where we try driving everyone towards in terms of install and there’s going to be a whole bunch of head-tail things. That’s an advantage we have as an open-source community because we have people who love maintaining, for example, the Puppet integration. They’re always updating every release we have. They’re lockstep. It’s great to have communities work with us to make the project more and more popular.

{{divider}}‍

It’s good to hear it because a lot of the people that I’ve been speaking to have said that the vast majority of the work that gets done on the project is done by employees of the organization. It’s rare to see 10,000 non-pull requests. It sounds like you guys have nailed that. Where do you see the future of messaging, especially in the context of federated platforms like Riot and Matrix? A few years ago, there were you guys and Slack. Now, there are Teams. There’s a bunch of other open-source projects as well. There’s a little bit of a coalescence that is coming around, putting those protocols back to the old-school where there was a standard SMTP. Hopefully, a better standard than SMTP. Do you guys all sit around a table once every six months and talk about that end goal?

I can share with you perspectives from two different sides. I can share a perspective when I was at Microsoft. I can share a respective when I’m part of this open-source community in the messaging space. Let me share on the Microsoft side. One of the reasons why Facebook is as large as it is now is because of Microsoft. When Facebook was small, it was “Invite your friends.” How do you invite your friends? You can’t email every single one. What Facebook was doing was hacking Hotmail address book. There were no public APIs for this. It would hack the Hotmail address book that gets people to log into Hotmail and pull their address books and send mass invites to Facebook from the Hotmail address books. This was the time when Gmail wasn’t that big. Hotmail was the social network of the world back in the day.

What Microsoft did is not a proper use of the APIs. A lot of people do this. All the social networks that found this hack was doing the same thing. What Hotmail did is it started negotiating bilateral agreements. Facebook had open certain APIs. Microsoft is trying to do a social network itself and all these different things and different agreements. Through that experience, what you understand is that you’ve got many different parties who have this corporate incentive to get as many people onto their platform as possible. That concept of “Let me use your address book” is a little antithetical to that.

What happens is companies like ADM or these other cross messaging platforms rise up. In Microsoft’s case, it’s all the time. People are trying to get to MSN Messenger, later Windows Live Messenger and have these connections. What would happen is they get to a certain scale and then the lawyers get involved. The lawyers say, “These are the terms and conditions.” When you’re small, you’re like, “I can connect everything. It’s amazing. I’m going to interrupt.” At one point, it triggers a certain legal conversation and it exposed the terms and conditions and you realize, “That’s not a thing.” Those large organizations that own those channel want to keep everyone on their network. If they’re going to open up theirs, they want to have bilateral agreements with the others. They don’t want some in the middle.

In addition to that, it’s not just because of that incentive but also the safety of those users. Is this consenting? What are the security implications of being able to plug in? What about impersonation? What about man the middle attacks? What’s the security posture? You’re saying, “I don’t know if the engineers are putting all this important stuff into the channel. Who’s the man in the middle reading everything as it crosses?” “There’s encryption.” “Why is there encryption?” “You said there was encryption.” “What?” It goes back to trust like, “Yes, there’s encryption.”

This one startup that got acquired, I won’t give any details, but they’re going through the checklist, “Do you encrypt and salt your passwords?” “Yes.” As they went to the security view, they encrypt and salt their passwords, but they also store the password in cleartext in case the end-user wants a reset. Who do you trust? If you approve of that federation, if you approve some of them in the middle, you have given all the trust of your company or your system to that person who’s in the middle. Whatever guarantees they make, those are your guarantees to your users. I love the concept. We want to see that happen. It is something that I’ve seen over and over again in the history of software. It gets to a tipping point and it doesn’t quite work out. Adium was a great product, it connected to all things. What happens next? How big does it get? Those are the questions. It’s not technical. You want to think of a good type of architecture, but it’s a question of what happens when it gets larger.

{{divider}}‍

People think of encryption as a checkbox. Especially around messaging, it’s way more complicated than that. It’s like, “Where are your keys? Is the metadata secure?” I have in my head that’s the open encrypted protocols. That one should be the one that everyone’s moving towards. Do you think it’s sufficient for an end state for that solution? Do you think it needs more?

It’s about the analogy. Let’s take it to analogies, which is rooms. Let’s say there are five buildings and there are five different rooms and call those whatever messaging networks. There are five buildings and five rooms. It sucks for me to go back and forth to every room. Instead, I’m going to hire someone and that person’s job is to represent what I say and what they hear in those other rooms. I’m going to stand here in this room. They’re going to go for me into all those different rooms. What happens is I’m trusting whatever that intermediate service is to represent me and to represent the other parties.

{{divider}}‍

I think about Adium, it was such a magical experience. You could throw away all the junk clients that you had and have this nice application. You didn’t even know what network you were talking on. It was your friend or whatever. There was a product that was doing what you were doing. The way it interacted with WhatsApp was by running a virtual Android device that could take your keys. I was thinking, “How did we get here?” We’ve got people running virtual Android phones. It’s a shame. I’ve got a Signal account and a Telegram account. When this WhatsApp announcement went out, people who I know, friends of mine, journalists, car industry analysts are joining Signal. It’s like, “Something’s happening here.” They’re doing that for a reason. They’re not doing it out of curiosity. That’s cool. That’s a great opportunity for that situation to get better. There’s still a hell of a lot of engineering and momentum that’s needed.

May I propose a different view, perhaps? This comes from Andy Rachleff who is one of my professors in grad school. He said, “The frame to look at the world is through economics.” Economics is how do human beings behave under incentive? The question is, what is the incentive of Signal, Telegram, WhatsApp? Why do they exist? What’s their mission? If you’re going to connect in the middle, what’s the mission of that organization? Are those interests aligned? If they are aligned, it will work. If it’s not aligned, you’re going to have competing forces. It’s not just the technology. It’s predicting based on the incentives of who controls the systems. When there is control, what’s going to happen?

{{divider}}‍

Email works.

The purpose of an email is to be that open communication layer that goes anywhere. It’s a standardized protocol. It’s evolved over time. That is its purpose. Messaging is closed almost by definition, versus email which is open by default.

{{divider}}‍

What’s in the future for Mattermost? What are your big goals now and in the future?

What we do is listen to our community. Our community has a lot of software builders and operators. They’ve got a lot of integrations and customizations in Mattermost largely around DevOps scenarios, SRE, security ops scenarios. They’re operating 24/7 services. We’re taking more and more of their use cases scenarios and putting it back to the product that’s a little bit more out of the box. Just like that contributor that wanted to give us 10,000 lines of code to translate in different languages, we want to take a lot of the customizations that people have built, for example, around incident response, incident collaboration. What happens with this outage? How do we bring everyone together? How do we do retrospectives? How do I analyze the productivity and put those back in the product? We’re going full circle from a games company and make a collaboration tool to saying, “Here are the additional use cases that we’ve heard from our community,” and making those more out of the box and offering those to the right audiences in the right markets.

{{divider}}‍

If you focus on a particular vertical, in your case, software engineers, you can be way more opinionated about those features in a way that a general use service can’t. The plug-ins can get them only so far. The ones on Slack, apart from the Giphy integration, would seem a little bit personal.

There are a couple of challenges there. Because it’s a closed platform, you have to influence either Slack, which is now part of Salesforce, or you have to influence the integrations vendor who might have done that project years ago and moved on. Innovation and progress are hard to do in a closed platform owned by a $200 billion company. When we think about the market, you got Slack and Salesforce, a $200 billion company. You have Teams in Microsoft, a trillion-dollar company. There’s a lot of room for the open-source version of messaging. For software builders and operators, it’s different needs.

Those three things that we’ve talked about a lot during this conversation, that developer-centricity we’ve talked about, developers are the harbingers of the collaboration products that are used in the future. They take a strong role in shaping those. The developers-centricity that opened this kept innovation upstream and downstream to have all the great things that we build in the customizations to be able to move into that primary project and come out for everybody. It’s not just the ivory tower that decides what everyone gets. It’s being able to participate in that platform. That’s huge. Every enterprise CIO wants a seat at the table and they know they’re not going to get it from the Microsofts and Salesforces of the world.

The last piece is what you talked about at the beginning, which is that trust and that architecture. Mattermost can run it in the cloud for you. I swipe a credit card and go ahead. You can run it completely on-prem and see every line of source code and know that this is something you can trust, tailor and invest in. There are options in between. Those three things, when you think about the developer-centricity, when you think about the openness, and when you think about the architecture that supports trust, that’s how we see the market evolving. That’s where we see the innovation happening.

{{divider}}‍

Have you got any people, contributors, GitHub accounts, URLs that you want to mention before we finish?

There’s so much out there. I encourage people to go to http://Mattermost.com to learn more about us. If you want to check out our forums, try http://Forum.Mattermost.org and see us there. Thank you so much for having me and having a little bit of time to share our story.

{{divider}}‍

It’s been great to have you. Thanks, Ian.