Rocket.Chat Interview | The Craft of Open Source

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

Ben: I am legitimately super interested in talking to Gabriel Engel, who is the CEO of Rocket.Chat an interesting market. From a commercial open source point of view, I'm interested in getting into the weeds on that. Gabriel, welcome. Do you want to introduce yourself and what you do?

Gabriel: My name is Gabriel Engel. Thanks, Ben, for having me here. It’s a pleasure to talk about something I’m passionate about. I'm the Founder and CEO of Rocket.Chat, an open-source workplace digital collaboration and a virtual help desk for customers. It's this mixture between Slack and maybe Zopping but chats for websites and integrating to everything else. It’s exciting to be here, talk to you, and tell a bit about our story.

Do you want to talk a little bit about the very first commit that got made to the projects and how it came into life?

The origin stories are always the best. The whole thing we started is I had a company. We were building a CRM and trying to create an open-source CRM eventually because we were not happy with SugarCRM. We wanted something more modern using Node.js and MobiDB, anything like a new web stack. Our initial customers keep asking for a way to talk to their customers on their website. My brother had a real estate agency there in Brazil. He was always asking, “I need my agents to talk to the people visiting my website.”

There were some open-source projects for that but none of them had a backend that looked like Slack. The experience for the agents wasn't something pleasant. We thought it was important because when you have a big team, you need to be talking to your customer as easily as talking to your colleague, manager or team. We were like, “Why do you need two tools to talk to?” At the end of the day, just talking or chatting but you have to jump into different tools depending on who you are chatting to. All this data that the company is creating, all those conversations, there are some insights and value in that conversation.

Having that data away in someone's cloud that is not accessible for you to be querying and running anything that would give you the right insights was not ideal. Can we build a Slack that allows you to communicate with your customers wherever you are? Using open-source, you can keep this database available for the organization or the company so they can do whatever they want with it. That was the beginning.

We created this chat module. We didn't have a name, and then comes the story about the naming. Some people ask me, “Why Rocket.Chat? What is the name Rocket.Chat?” We started to be Rocket.Chat using a framework called Meteor. There was this thing on the Meteor community to put space-related names for every Meteor project. We tried everything. We tried Chat Comets. It was always chat something, Chat Rocket, and then ended up calling it Chat Rocket.

I went, “I need to register to launch the project.” I went to GoDaddy, and GoDaddy was like, ChatRocket.com is taken. Maybe you need $10,000 to buy it. There were those stupendous fees. I was like, “I don't have that money to put on the side project.” I have to say thanks to the algorithms because that suggestion when you don't want to buy a domain, you say, “Rocket.Chat is going on sale tomorrow,” because the dot-chat domains were being launched, and they were going on the next day. We end up putting a bid for $50 to Rocket.Chat and then get the domain the next day. I have to change the name rather than Chat Rocket.

I'm looking at your second commit is changing the header of the Readme from Chat Rocket to Rocket.Chat. For those of you who haven't started looking through the source code like a weirdo, this was May 2015. Where was Slack at this point?

We were users of HipChat first. One of our developers said, “There is this new tool, Slack.” They were already getting rather popular, more so with the developers at that point. We started using Slack and then got a glimpse of what a good user experience can look like. You were like, “That's so good. You feel comfortable. Let's build something that it has this feeling.” Before HipChat, we were using something called Hall. It was the best chat I used. The HipChat, a class, acquire them and maybe do a revamp of HipChat.

We had high expectations that HipChat would become this cool thing. Some companies observe and then dilute the skills that they are acquiring to other areas. HipChat never evolved. Maybe years later, it was growing to become Stride. Stride was coming to do something. Maybe they were using a little bit of that knowledge but then they sold to Slack, and Stride never became a big thing. Slack was starting to get very popular with developers at that time.

I remember that the difference between HipChat and Slack back then. It was a 10X difference in terms of the products itself. Slack had a crazy free tier. At the time, it felt crazy. Way before all of this, we have the agency that Flagsmith came out of. We were running an IRC server for years and years, which was a pain. We were doing that back in the day. There weren't any integrations. If you weren't logged in, you didn't get to chat for free. The user experience was dire. In terms of pushing this open-source, did you have a theory and a philosophy around that? Did it feel like the right thing to do?

I did because my theory felt like the right thing to do. My first experience with open source was back when I was at the university. I started a business with 2 of my colleagues when I was 18 or 19. We were doing some internet business development using PHP and MySQL on Linux servers to build internet from a large company called Taja, one of the biggest ISP in Latin countries. They needed an editor so they could edit the news and the articles inside the WYSIWYG editor. I created in-browser editor called Inteli Editor. We said, “This is so cool. We use so much open source. There’s MySQL and HP.” Everything we are building is an open-source stack. Maybe it is a good time to give back.

That was ‘18 and ‘19. It was published on Salesforce. There was no GitHub at the time. Soon, there were what sounds like little but tens of thousands of downloads in the ‘90s or whatever it was. Maybe early 2000 or 2001. It was the early years of university. Maybe it was 1999. At that time, having tens of thousands of downloads, they were like, “This is amazing. Where do people downloading and editing my software?” It was starting to translate to many languages.

What happened next left a mark on me because a company from Silicon Valley called us and said, “The work you guys are doing is amazing. We would love to hire you guys to customize this editor for a project that we have.” The founder of the company flew into Porto Alegre and spent ten days with us, explaining that he was trying to create an editor for legal contracts. Something was very ahead of its time. They don't work that well but it was too ahead of its time.

Now there are dozens of software doing that but the guy was a bit genius. I was like, “We are small.” Turbo startup wasn't even created yet. We are this small company in a little room in a city in the South of Brazil that develop and do a software that never spend a dollar on the advertisement. We published our work for the world to see. Suddenly, we are getting customers from Silicon Valley hiring us and paying us in US dollars.

That was amazing for an 18 or 19-year-old. I left the Macromedia. The open service is not necessarily a one-way street like a lot of people think about. You are not just giving away. Sometimes it might be longer-term but I believe that in many forms of value, it comes back to you and not just revenue, contributions, and awareness. That was my philosophy.

It's hilarious as well because open source in browsers, WYSIWYG editor has a large graveyard of projects, doesn't it? That's a hard problem.

Since Google created Google Docs or there's one I used to call the FCKeditor. That's the only one that's still going strong. That was one of my greatest inspirations for building it. We wanted it to be more customizable. It is a very large graveyard of updates. Most of them evolved and became only office or there are so many full-fledged office editors. That was the mark that was left on me. Open source was not a one-way street. It was not a donation to the world.

It was a different way to engage with potential customers and partners. When we are building Rocket.Chat, I felt like, “We work on this.” I get the first version with my team to work. Once we have the first version running on production, let's publish it on open source. That was the first commit that you see there. There's a funny story about that as well because we were planning to do it much earlier. The product went live maybe in January that year. We were able to put a customer on production and had thousands of visitors, about a thousand people using the server.

It was working. We had to overcome a lot of the hurdles technically to make it work. It was working and we said, “Let's make it open source.” Some people underestimate how complex it is. Sometimes you are going to put it out there. You are going to put branding and explanations about how to deploy. When you are a small software developer agency and all your projects are usually late, and under budget, there's always something else that you should be doing rather than spending free time.

We ended up postponing. I was like, “Let's put on this print next month and the next month.” Suddenly, I received an email from the Meteor forums. A guy called Tim was put a published, saying, “I did a Slack project on this hackathon. Here's the cold base. Who wants to help me make this work?” There were hundreds of people replying on the blog, saying, “I'm going to help you.” They start engaging. I was reading it. I was like, “What?”

I have the product ready. I spent not just a weekend. We spend four months developing it, fixing the problems, making it able to scale and everything. This guy on the weekend creates the project and the idea because he is a lot braver to expose a project. Sometimes we are ashamed of our project, so we keep postponing it. You are like, “It's not ready yet.” He was like, “I did this in a weekend. What do you guys think?” It galvanized this whole community around.

I was like, “This guy is going to eat our cake.” We have the product, the same platform working and running. I called him, “Tim, I have a product that is far more stable and mature. Let's get the project together. Let's get the people and work on the same thing.” He was like, “You can make a commit to my project with your code base, and then we will follow your project.” I thought, “If it was completely altruistic, maybe if I wanted to give the code away but I wanted to get some saying of what the project is. I want to build the thing.

I was like, “I was thinking that you guys should join us.” He was like, “No, you guys should join us.” It came to be like, “Who is going to join us?” it was like a piece of the contest. I felt weird but we are supposed to be open source and working together. On the same day, we are trying to build something. I don't know if there's a bit of an ego. I'm still trying to understand my feelings. At the end of the day, it was like, “If you are not going to join us, let's have a competition.” He was like, “Let's have a competition. May the best open source project win.” I was like, “Fair enough. We have six months’ head start.”

I got a lot of Red Bulls and pizza and told my guys, “We are not leaving this room until we publish the project.” We started to remove every token and password from the code because we only deployed to one customer. There were a lot of things on the code base that was still hard-coded for that customer and CRM. We spent the next 24 to 30 hours removing, cleaning up, writing, making the website and the page, and then published. That was the first commit.

When I realized that I couldn't get the domain, we had to change the name of the project. The competition went on for maybe six months. I also learned something interesting. We made a product. When we published it, it was something that was production-ready so people could use it. We organized our community on our open server. Everybody wanted to join the project. You need to join our server. People would join the server. It was like eating your own dog food. They were still like, “This button is bad.” We say like, “You can fix it. Here’s the source code. Make up yours and fix it.”

The community started to fix the things that they would find annoying about collaborating with the community itself using Rocket.Chat. It was this cool virtual circle that made us have this urge to fix the product because we are the users of the product every day. In the other project, their product wasn't able to handle more than maybe five users at a time. He didn't fix the hurdles of scalability and stuff. They had a Slack channel to develop this Slack-like product. They had one of those, “Click here,” to auto sign-in to Slack and get joined to this Slack channel.

Some people would join the Slack channel. I joined it because I wanted to see what was going on there. I was participating in both projects. Some people joined in and said, “This looks like Slack.” You never know if you were taking the piece like, “This is Slack.” They would be, “Why? Is not the open-source project about Slack?” “No. The open-source project is a busy realm, but only five people at the time can be aligned.” They were never able to make this transition of using their own product. They’ve given up after six months.

The guy made an announcement like, “We made a competition with Rocket.Chat. You guys can join Rocket.Chat.” He told me that because I was going to a webinar and a Meteor comp. He said, “You can make an announcement that our project is shutting down. Everyone that wants a Rocket.Chat. Slack and Meteor should join Rocket.Chat.” That was our early days of trying to get the commit together.

It's interesting as well because Meteor was like the Red Hat framework back then. It was Red Hat but it had scaling problems. It was tricky to scale. Is that right or not?

Everything has a caveat. There were some Meteor projects that scaled. We made it scale. It's not own unscalable. In Meteor, it's so easy to build a project. When something is so easy, there are some things that the framework is doing for you. It's trying to make it easier in a generalized way. Those generalizations can work pretty well. Sometimes if you have an educator, if you are trying to maximize for one type of data or streaming of data, it can get that overgeneralization and oversimplification of how the data is streamed from one site to another. It can get in your way and be hard.

We still use it. More and more, we started to build our own versions of some of the Meteor components that were optimized for our use case. We still think that eventually, we will soon set all the Meteor dependencies and maybe not depend on Meteor anymore. We are on that route. We have a list of things that we keep writing our own version, and then we will eventually de-meteorize. People say, “Do you regret starting on Meteor project?” Absolutely not.

In the beginning, you want to try things fast and do your MVP, and Meteor is amazing for it. It doesn't get in your way. They are getting better and better. A lot of the framework now can choose the parts that you want rather than trying to be all in one encompass thing. We feel that Meteor is going that way as well. In the beginning, if you were using Meteor, you had to use Blaze, a version of Handlebars. After a while, when React appears, they are like, “We are going to allow you to choose if you want to use React or View.“ They start to become more flexible about the components that you should use. They added the capability to use NPM packages as well.

They had their own package manager.

That was very restrictive in the beginning. They made way for you to rack the NPM packages into their own package but it's still cumbersome. You have to keep updating and stuff. They removed a lot of those hurdles and frictions about creating an open project. They are going on that path. You can see their philosophy. I like the way they are going. If I were to maybe to start a new startup, a new project, I wanted to build something fast and get an MVP out the door, I will still choose Meteor to start. It’s the best way to start a project quickly.

You've won the competition. At this point, your community is growing. The contributions are growing to the open-source product. What's your mindset at this point? Have you got a five-year plan that you are going to commit to or are you still waiting to see where things take you?

It's a mix of both. I like to have plans but they are sometimes high-level plans because the future has a way of a reality to punch your plans in the face, and sometimes, all your plans just disappear. If you don't have at least a target where you want to go, then you might be running in circles. We do have a plan that is still part of our initial vision, which is having a platform for communication that is not a single-use case platform. It is to chat like I can email my friend, my mom, my partners, my suppliers, my customers, and my bank.

I can email anybody and don't need to know if they are on Gmail, Hotmail or Outlook. They all are using the email provider, and there are so many different email tools to consume email. We do believe that chat shouldn't be the silos that we have now. On the consumer side, we have maybe Telegram, WhatsApp, Facebook Messenger or Apple iMessage. On the business, you then have to jump to another app like Slack or Teams. You have all these different apps but you have only one email client, then you talk to anybody.

On chat, we have ten chat clients on your phone and desktop. That's not a good thing for the world. People were getting fed up with that. We are trying to make a product that could be core to bridging all those systems. That's where the open source felt right about it. If you want to build bridges to all those systems, make a Slack bridge, a Teams bridge, and a bridge into WhatsApp and Telegram. You need a community around them.

You need tens of thousands of people testing, helping to fix bugs and look at every case. In terms of Teams, we have one team doing all that. Our vision is still building all those bridges and investing in the federation protocol to get all the Rocket.Chat servers to talk to each other. There is a Federation protocol that you might know called Matrix that we implemented as a core part of Rocket.Chat. Rocket.Chat in the Matrix universe is called a home server, which is its own server. That's our plan. We are putting a whole team and even working with them as Matrix engineers to turn Rocket.Chat into a home server.

People might have forgotten this or didn't even realize it. Back in the day, Slack had an IRC interface originally. You could connect your IRC plan.

Google and Facebook had an XMPP port. In the beginning, there were some engineers that thought about the cool things and had the right mindset and the good of humanity at heart. Sooner or later, maybe corporate interest spoke louder and created this world garden.

Those are probably the most closed and highest wall gardens there are.

Did you see the European union pass the Digital Markets Act in May 2022? They have an act that is still debatable how fast it's going to be implemented or enforced. It is pretty much targeted at those tech giants. There's a whole character dedicated to chat and messaging saying, “If you are a supplier with more than 100 million users or X million users, and have more of X million dollars or billion-dollar evaluation, your system needs to build APIs for interoperability with other chat systems.”

The European Union is looking to mandate that Slack, Teams, WhatsApp, and Facebook are all going to have to open a set of APIs for interoperability with other chat systems. It's part of this Digital Marketplace Act. There are people pushing in the other direction. You can do some work around. It’s not ideal to work around using bots on both platforms on Teams and Slack to make those bridges.

WhatsApp offers where we use the business API. We allow customers to use Rocket.Chat to have their corporate profile on WhatsApp that native customers can talk to and then have Instagram, Facebook, and then WeChat and Apple Business Chat. I like where their opinion is headed and saying, “If you are going to build the system, you need to allow them a way to speak outside your world garden, and they are apparently going to go for it.”

I wasn't aware of that. I do remember reading briefly about it. I'm in London.

Your guys are not in the European Union anyway.

We left the European Union, which was a total tragedy. The interesting thing about, for example, GDPR and the whole point of the European Union is so big now that they become de facto global standards like, “If you want to trade here, you need to do that.”

I lived in the UK for almost ten years. I lived in Melbourne for almost ten years and enjoyed my time there. I learned a lot about Europeans. We have an interesting meeting with the Swedish government already in 2022, and we are starting an engagement. The Swedish government published a report where they explained why they were moving away from Microsoft. For the government, they were moving away from Microsoft Office 360 and Excel. They thought it was not very aligned with data sovereignty, a country being in charge of their own data. They said, “We are going to move the government to open source.”

They started creating a report about what products on the open source they are willing to use. They made a short list of what products for office collaboration and also max cloud for documents’ storage and sharing. It’s the whole list of open search tools that they recommend after doing their study. For collaboration, they got the list down to Rocket.Chat, Element and Mattermost are the three main open-source collaborations. They scheduled a meeting with the three of us and the next cloud guys as well, all the collaboration tools together in one single meeting.

They are like, “What? What do you want to announce?” They got all those vendors together in one call. The guys were like, “What are going to ask you? It might be naive of us. You might not and think that it is silly for a vendor to be asking that. I want to know what is the possibility of you guys playing nice together and making all your software talk to each other?” We want to move all the Swedish government to open source but we don't want to mandate a single tool. We have to give the freedom for each department to use a different tool but we want all those departments to talk to each other. They email each other. We want them to be able to chat with each other and stuff.”

They were using Skype for Business which allows a lot of this to work. It's like, “We want to have the Skype for Business open-source like an open-source federated version of chat but using modern UI as you guys provide. That’s what our users like. Can you guys be friends and work together?” That's why we are already thinking about this for the longest time with the Matrix guys. We are willing to go the route. It's best for humanity if we make our systems to talk to each other.

That was the whole goal of Matrix.

It is but getting the adoption of other open-source projects or other large systems. I like to call him a friend, Matt from Matrix. I met him a few times in person to talk. I'm totally aligned with his vision. That's why we started Rocket.Chat as well. The Matrix protocol that he’s built is very efficient. We build our own federation protocol. When we looked at the solution for those problems, we end up getting similar solutions. At one point, it was like, “What is the point of us trying to compete again for different protocols? It’s going to make everything harder. Let's adopt their protocols.” We are adopting their protocol as our internal engine for the federation. I do believe that's the way forward.

You talk about the five-year plan. Being a part of the major consideration is one. Embedding on the whole system, a lot more APIs for language, and NGL for building bots and apps is the next big thing in collaboration as well. It’s being able to build and integrating your own apps, especially if you are going to be able to be a cross-company, cross-organization, chats collaborations, then maybe having those apps that we can build services. Cross organizations will be the next big step.

The cross Slack connector, from a lock-in point of view, is a work of genius. It's a slightly evil genius. If you were able to do that but have a Discord connector or a Rocket.Chat connector is how it should be.

That's why us adopting the Matrix protocol. You can get a channel on any of the platforms on Rocket.Chat, on Discord or Element, and you can connect to any other service and have the same features and have the same basic conversation and features. That's the best way forward. It's like an email thread. I can add people to Gmail, Outlook, and Proton Mail. They are all on the same email thread, on a channel. Ideally, it would be the same. You add people and joining the group or the conversation.

It's bundling and unbundling like the circle of life. I'm curious. At some point, fairly soon after you win your competition or probably before, you are getting a steady trickle of emails from VCs at this point, is that right?

That's correct. Even before we won the friendly competition, our product on GitHub started to get a lot more stars and engagement from the community. People invited me to go and give talks in San Francisco about Rocket.Chat. I made a personal mission to be the spokesperson for the project. When the guys from Meteor invited me to come to San Francisco and give a talk, I was like, “How do I get to San Francisco? You got to give me pay for my flights, accommodation, and stuff.” They were like, “We give you eighteen minutes on the stage for you to talk about your project. You need to come here on your own.”

I was bootstrapping both companies at that point but I was like, “What do I do? How many times do have I had the chance to do that? You might have to grab me by both hands and then see where it goes. I'm going to San Francisco but then I'm going to call everybody on every open search project that I admire and ask them to have some coffee with me so they can hear me out. They can give me advice.” I called them MobiDB guys. I called Automaticc. I called everybody that I could. Some of them said, “I'm too busy,” but most of them said, “Come on for coffee.”

I went to the MobiDB office. I went to the GitHub office. They introduced me to everybody. The founder of MobiDB and all the engineers were there to help us to understand how we were using MobiDB and optimize our usage of MobiDB. It’s one of the free best consultation we have ever had for the system. They were giving us hints on how to monetize the project. The MobiDB guys were explaining how they were building MobiDB Atlas and all those external things for the enterprise. I ended up staying there for almost a week.

My wife was crazy because we just had a baby. He was five months old. It was still hard times. She was like, “You are running away. You are getting a ten-day holiday in San Francisco.” I told her, “I'm going to go and visit all those people and try to spread the word about Rocket.Chat.” She was like, “Isn't your talk for 1 day for 18 minutes? What are you doing there for almost ten days?” “Believe me, it's going to be useful.”

At the end of the day, I showed my idea to the MobiDB guys. They got impressed. They put on a press release. The press release then circled the VC world because it’s among MobiDB press release. We started getting all those offers. Some of them were insane. Some people were saying, “I'm going to send you a check for $200,000, and then you can write me back.” We didn't have the company yet. I was going to do a spinoff.

Some people are saying, “I will write you a check. When you create a company, you can write me by the hand saying that you are got to give me 2%.” I was like, “This is crazy.” Eventually, the guys from NEA reached out, came, and did a nice offer, “We will give you a check, $5 million. Create a business, and then you transfer the money.” That's the offer that we end up going.

Who won the copyright to the code at this point?

All the initial work was done by my developers on my other company. We ended up then selling the copyright of the code when we did the spinoff. My other company then sold the copyright to the code, the Rocket.Chat. It’s one of the things we paid large amounts of money for lawyers to get it all.

They sound simple on the surface, and then five digits of money later, they finally become real.

It was good. What surprised me was the experience of Harry from NEA because he was one of the early investors in Elasticsearch, MuleSoft, and MobiDB. He had experience in creating big things out of open source projects. I was like, “That's the partner that I need.”

It was not as common and not the juggernaut it is now. It's funny you mentioned some of those companies that have floated on the stock market or had massive exits and things like that. There may be exceptions many years ago but there weren't as many. This is what I'm interested in.

One thing that inspired me a lot was looking at the GitLab. I was also always doing that until it was a few steps ahead of us. We became very close. They tried to make an offer to acquire Rocket.Chat at one point. They were competing with Atlassian in many respects. Atlassian had HipChat. They wanted to have a chat thing inside a GitLab. The reason why we ended up turning down the offer and parting away is their vision for chat was the Atlassian’s vision for HipChat.

I always thought that was reductionist of what the platform could do if you are thinking as a component of a framework for developers. I was like, “Slack is not a part of something bigger. Slack is something bigger. I would want Rocket.Chat to be the something bigger where we wouldn't integrate things because you could serve a much broader audience in the world if you are this chat platform rather than a component.”

I always admire the remote work company be distributed and so on. We built a lot of things on our company. We were inspired by Sid Sij and what he did with GitLab. He introduced me to some of his investors at that point. I got a feel for what investors are starting to look at the market and understand that communities were making brands. The open innovation was the way forward.

That’s when the guy from NEA who invested in us, Harry, passed away immediately after, which was a tragedy. He was a genius in many sense. For instance, one thing that was already impressible. Forbes had a Midas List, the Midas Touch. Every year, Forbes would look to the DC investment world. Who are the guys who made the best 100 investments that year? The list was 10 or 9 years old when he passed away. He was on the nine editions.

He was in the top 100 best investments in the world. Some of those close were open-source deals that he managed. Even after he passed away, he would still be on the list. There were so many deals that he made that would become some of the top 100 that he didn't go like the MuleSoft. He did invest MuleSoft as well. There were a few of those that were big multibillion-dollar exits that he started.

He had the decision. He was the guy who came for us and said, “Digital collaboration is going to be a mandate. Every company is going to have its own tool. A lot of companies are going to want to customize and have total ownership of their data. There is going to be a massive market for open-source dish collaboration. You guys are doing an amazing job, so I want to put money on you.” He made the best offer and the best pitch about our startup for ourselves. That's why he own the deal.

How did you go about figuring out the parts to revenue? You've talked there about data sovereignty, data ownership, and things on premise. Was that immediately obvious or did it take a while to figure out? It took us quite a while to figure that out.

It took us a while to figure it out. We didn't monetize almost anything for the first year and a half, almost two years. We tried to create the obvious roots like, “Should we sell supports?” We can sell support, and have a support contract for a few companies but that doesn't necessarily scale. We start playing out to sell a SaaS version of our product which also start to get some traction. We immediately understood that we were competing too much directly with Slack or others that offer this free version and so on.

It wasn't a game-changer. It was the only one we created the license for the enterprise. I started to remember what the guys on MobiDB were talking about on selling, auditing tools, reporting tools, scalability, and package. We start to create our microservice APIs, put those things on the enterprise, and offer those on the enterprise package. We started to see the traction but that was already 2019 by that point.

We only got the funding in 2017. From 2015 when he had the first commit until it started to get traction, I was bootstrapping and trying to fund everything out of my pockets and my friends and family’s pockets. By the end of 2016, when I talked to the guys in NEA, they made an investment on the third of the year 2017. I started building a company. He passed away. I didn't get his influence and knowledge about how to move things faster and playing faster with finding a business model that works and playing with the monetization correctly.

By the time we figured out monetization, it was already 2019. Selling on-prem license for people who were looking for high degrees of customization but also the sovereignty of data ownership and security. We start having customers like the US Navy, the Air Force, Credit Suisse, and Deutsche Bank. We start to have a lot of different large corporations willing to spend 6 to 7 figures on security, privacy, and customization.

Has that environment got stronger as time's gone on? We found that an enterprise sales motion is a guy’s own challenges. It's difficult to know exactly what's the price on, how to price it, and what the dimensions of pricing are. How did you tackle that?

There is a whole learning experience that is hard because there's no one size fits all. We learned that it is a lot harder than anticipating. Our initial generation of cash took us longer. We even had an extension of a new seed round because we were not ready for series A and did not need the targets. We had to go back to some of the investors and do a new round before the series A because it was so complex to get the enterprise sales. In hiring the right people, sometimes you need more senior sales agents and account managers that know how to maneuver around the politics of larger enterprise, deal with their sales cycles, and what they need to find stakeholders.

It was tough. There was a lot of learning curve, who to hire, understanding the longer cycles for the sales and what they value, which is a lot about security, privacy, and control of their systems and management. Once you start learning what features we need to build for them and what they were willing to pay, things start to get into shape.

To be honest, that's not a solved problem. We still sometimes lose deals to our community edition. We are still sometimes struggling to prove the value of the enterprise edition and putting more and more developing on the enterprise. I don't feel it's a nut that we have cracked completely. We are still working on it. There is still a lot of work to do.

What's your record length of the sales process?

We have companies that have started talking to us. By the time we close the deal, sometimes two years have passed.

Our record is thirteen months at the moment.

It’s mainly because they were already using the community edition. That's the thing. You have the last compelling events for the deal to close. It's not like, “By this day, you are going to have to turn and have a solution in place.” You are like, “We are okay using the free version.” We think we can get this advantage but you have to prove the value and then go. Sometimes it took us almost two years to prove the value of the enterprise. It took a few releases, almost building stuff that we thought that they would want until they saw something at the enterprise. “Now you guys have something that is worth for us moving to the enterprise.” It happens sometimes.

Where are you at as a business? Do you have a fully remote team at GitLab?

We have a fully remote team. We do have an office in Brazil where it all started but mainly because I like the feeling of having something to call home. We have 175 people because we are onboarding people every week. It's hard to keep track but it's close to 180 people but distributed into 40 countries. It's pretty distributed. We have people in almost every time zone if you think about that. We have people from New Zealand, Asia, Africa, Europe, South America, and more in the US, and it's fairly distributed.

We have an office in Brazil that maybe would feed 40 people if everybody came at the same time. It's more like a meeting place. We have our internal Airbnb. We have a bedroom, so people can come and stay. It's almost like a place where teams can come and have their own get-together or have an office and spend some time brainstorming and working things together.

We try to simulate that to happen, inspired by GitLab and Automaticc. We do some annual summits. We try to get everybody together every year somewhere to spend a week getting to know each other and being inspired by each other. Those always have a profound and stronger impact than most people would anticipate.

In terms of the fully remote, are there any other companies, people or ideas that have been good sources of inspiration for how to manage that? There is a bunch of problems that you would never be considered.

That was something funny about the beginning of the pandemic when a lot of companies moved remote, and then they were like, “This is amazing. Let's close down the office. It's so cool.” It was positive about working remote. I read an article comparing the remote work to the new Coke when Coca-Cola changed its tastes. I was like, “What? What is the comparison?” The article told this story and tried to make it short. It was like, “Pepsi made an advertisement.” Maybe it was the ‘80s.

“We are getting people in the street to do a blind test of Coke and Pepsi.” People tried them both and then, “I like this one,” and it was Pepsi. They would always prefer Pepsi after having a sip. Coca-Cola got worried about it. It's like, “People are preferring Pepsi. You need to do something about it. They changed the taste to taste more like Pepsi.” There was a huge opera. People are complaining and even taking the streets against the change in Coca-Cola taste. Coca-Cola had to be reintroduced as Coca Classic.

At some point, they change the whole thing and bring the taste back. They never understood what or how it happened. People prefer the other taste, and when you give it to them, they complained about it. What happened? It took years until a guy from Harvard apparently did a study. What he realized sounds almost silly in hindsight is that people prefer Pepsi at the first sip because Pepsi is slightly sweeter. After having a whole can, you prefer Coke.

He was saying when all those companies went remote and were like, “It's amazing. It works. Let's close all the offices.” That's the whole new Coke all over again. They have the first sip of remote work. Wait until they have the whole can after a year or two and it's like, “We are in the same room in my house with my kids running around for a whole year. I haven't had a happy hour or meeting getting off the office.” That is what he was saying. For me, remote work can work if it's a hybrid and you understand that a lot of things have no replacement for. It’s about meeting your coworkers every once in a while and building the connection.

We are human beings. We were built to have things that we need to make this connection. We need the physical world. We need to get a meal and a drink together. We need to factor that in when you are creating a remote company. You are going to have to make those investments in trying to create those situations. Getting people to do random meetings online or every once in a while, maybe getting them to travel together for something, then it can work.

For us having this place to call home when people can come and meet, made a difference. We didn't close down the office because we wanted to have a place to call home and have a meeting place where people can go. It also created incentives where people can pay for a co-working space if they sometimes want to get out of the house and be in a working environment. You need to factor in this other stuff. It can work and has been working for us since the beginning because we have been a remote-first company since 2016 when the project started. We started hiring other people but you need to plan for it.

There's a book from Automattic, The Year Without Pants, that talks about this. GitLab published its handbook, and it has a lot of information around it. There's a book called Rework. That was one of the early books that I read on the topic that inspired me. It's an effort, and it's not for everybody. There are a lot of people who miss having their workmates and leaving home to get into the work mindset.

For me, the hybrid is what would work. When I was in the UK working for Vodafone, I experienced this hybrid for the first time because a Vodafone you might know has the big headquarters in Newbury. They had a hard time attracting talent and taking them to work in Newbury. They decided to open on a big office in Paddington, London. I was hired to work in Paddington. They asked people, “You can go to Paddington sometimes to work. If you need to talk to your technical counterparts, you must go to Newbury. It’s because you have to do all these travels, sometimes you don’t want to come to the office. It's fine.”

They bought an office in Paddington. There was enough for maybe less than half of the employees. They built this office which was a big co-working. They didn't have a fixed desk. Even the bosses didn't have their own office room. They had a preferred usage of meeting rooms. They could get a meeting room for themselves for a day but they didn't have their own office. It was just a massive co-working space.

It did work. People would come. We would organize days that you want to work with your colleague. You could come to the office three times a week. That was the mandate. After a while, some people were coming to the office once or twice a week. That was a balanced way of getting to see your colleagues or not. A lot of companies are going to that balance where people can meet frequently or in some frequency but can do some concentrated work at home when they need to.

Gabriel, this has been interesting talking to you. Before we finish up, is there anyone or any members of the community that you want to give a shout to?

There are journeys as well. It changes over time. It is more engaged, and sometimes, they end up doing other things in life. If I single out any one person, it would be unfair because we have thousands of people in the community. A lot of these students from the Google Summer of Code are participating with us. We are in our sixth year since the beginning. We are getting fourteen members in June 2022.

We hired people from the Google Summer of Code before. It's an amazing event like initiative. I want to say thanks to everybody in the community. I used to finish all my talks and presentations with a big picture of them like the whole family finger-pointing, “I want you,” because I wanted people to participate. I truly feel that we are building a whole federation thing, trying to integrate everything and break the barriers. It's something good for us as a business but much more for the world to have this thing.

You can stand behind that for sure.

Lastly, we get other open-source projects. We are following in the Matrix code but getting other open-source projects, maybe the Mattermost and all the other open-source guys, to join. Let's get together on the protocol that we can rely on and make interpretability a good thing. We are now going to get there. The shout-out is for everybody that is helping us to build this and that have not jumped on the bandwagon. Come on. Join in. We need to make it easier for people to collaborate and distribute teams than it is now.

That's great to know. Thanks again so much for your time. Let's zip through fast. I'm curious to see where you guys go in the next few years. It seems like you've got an interesting few years ahead.

The fun is just starting. It’s going to get cooler and more exciting. I will keep you posted. Maybe we can come here with some updates at some point.

I would love that. I will hit you up in a year.

Thanks much for having me.

Have a good day.

It’s a pleasure.