The Changelog: Software Development, Open Source
Open source threaded team chat?! (Interview)
Thu, 05 Sep 2024
We're joined by Alya Abbott from Zulip, the open source, organized, threaded, team chat for distributed teams of all sizes. We talk about Zulip's origins, how it's open source, the way it's led, no VC funding, what makes it different/better, how you can self-host it or use their cloud, moving to Zulip, contributing and being a part of the community...all the things.
What's up, friends? This is The Change Log. We feature the hackers, the leaders, and those taking on Goliath. a.k.a. Slack and Teams. Yes, we're joined by Ali Abbott, one of the fine folks behind Zolip.com, the open source, organized team chat for distributed teams of all sizes.
And we're going through all the things, open source, its origins, what makes it different, why it might be better, how you can self-host it, how you can use their cloud, how you can contribute, how you can be part of their community, all the things in this show. A massive thank you to our friends and our partners over at Fly.io. That is the home of changelog.com.
Over 3 million apps have launched on Fly. We're one of them, and we love Fly, and you will love Fly too. Check them out at Fly.io. Okay, let's do it. Hey friends, I'm here with Dave Rosenthal, CTO of Sentry. So Dave, I know lots of developers know about Sentry, know about the platform, because hey, we use Sentry and we love Sentry. And I know tracing is one of the next big frontiers for Sentry.
Why add tracing to the platform? Why tracing and why now?
When we first launched the ability to collect tracing data, we were really emphasizing the performance aspect of that, the kind of application performance monitoring aspect, you know, because you have these things that are spans that measure how long something takes.
And so the natural thing is to try to graph their durations and think about their durations and, you know, warn somebody if the durations are getting too long. But what we've realized is that the performance stuff ends up being just a bunch of gauges to look at. And it's not super actionable, right?
Sentry is all about this notion of debug ability and actually making it easier to fix the problem, not just sort of giving you more gauges. A lot of what we're trying to do now is focus a little bit less on the sort of just the performance monitoring side of things and turn tracing into a tool that actually aids the debug ability of problems.
I love it. Okay, so they mean it when they say code breaks. Fix it faster with Sentry. More than 100,000 growing teams use Sentry to find problems fast, and you can too. Learn more at Sentry.io. That's S-E-N-T-R-Y.io. And use our code CHANGELOG. Get $100 off the team plan. That's almost four months free for you to try out Sentry. Once again, Sentry.io.
So we are joined today by Alia Abbott from Zulip. Welcome to the changelog.
Great to be here. Yeah.
Great to have you. Great to have an open source chat application out there and one with a storied history. Y'all have been around a long time. in and out of Dropbox even. I would love to hear a little bit about that story. Dropbox acquired and then open source out of that. Can you give us a little bit of the history? Really?
Yeah, yeah, yeah. Zilp has kind of an interesting history. So it was started back in 2012. So before things like Slack were out there. Yeah. That time it was not open source. It was just kind of your regular closed source startup out in Boston. And when it was still in private beta, the company was acquired at Dropbox.
At the time, Dropbox was exploring kind of different strategies with chat as kind of providing a suite of Office products alongside with the file storage. And then they went in a different direction and actually open sourced the entire Zulip code base along with the full history of the project.
So all that commit history, there was a hack week project to clean that up and make that something that can be publicly shared. And they very generously, I guess, once it was open sourced, Tim Abbott, who was one of the original co-founders and was working at Dropbox at the time, started running that open source project in his kind of nights and weekends in his spare time.
And Dropbox also very generously gave that trademark for Zulop to Tim as well. So at this point, there's no relationship between Zulop and Dropbox.
There's no relationship at all.
Yeah, yeah. But we're definitely very grateful that they decided that they would be happy to open source it, given that they were not using it themselves.
Why did they make that decision? Do you know why that decision was made?
I know Tim advocated for it, and that's really just they wanted to contribute to open source and just kind of a generous gesture for the community.
Well, that's pretty cool. So when they when they bought Zulip or yeah, I guess it was called Zulip from the beginning.
Yeah, the product was called Zulip at the time.
So when they bought Zulip and then Tim came inside of Dropbox was the original idea was to integrate and build that as part of their product. And they decided not to.
Yeah, originally, I don't know the details of their strategy, but probably I think originally they had thought that they might build their own chat app. As you know, I know you maybe have heard of Dropbox Paper, Mailbox. They kind of were at the time acquiring startups in a bunch of the office tools, in the office tool space more generally. And then kind of company priorities shifted.
The Zulu team ended up working on the core Dropbox product. And yeah, so they just kind of didn't end up going in that direction.
Very generous to open source it though. Yeah. Right. And all the history that's like kind of unheard of when you say, and then like be disconnected completely, like no back link or connection to it. Just like be free bird, go fly.
Yeah, and one thing that's pretty cool is that we actually still have some of Zulop's 2013 beta customers using Zulop today continuously. So they still have all their chat history. We've kept that running for them throughout the years, and they're still there.
So pre-Slack, like you said, definitely not pre-chat, though. I mean, IRC.
Yeah, so like HipChat and IRC were around at the time, exactly.
Yeah, HipChat, Campfire. Remember Campfire?
Yeah, yeah, yeah. Yeah, that was a competitive landscape at the time.
Yeah, totally. What was Zulip's big idea then? Like, why did it begin to exist in the first place versus just using HipChat, for instance?
Totally, yeah. So the big innovation in Zulop is how it organizes conversations. And the idea actually came from an older technology that was popular at MIT at the time for lots of students and folks were chatting there. But what's different about it is how conversations are organized. So in some of the tools folks may be familiar with, you probably have channels and within that channels,
A lot of discussion going on kind of like in that main channel feed. Maybe you have some threads on the side. Zulip is different in that when you start a conversation, you give that conversation a brief topic. So something similar to what you might do if you're sending an email and you write a quick subject line for your email.
And then when people respond to your messages, they respond within that topic. And so... it's a little bit of extra effort to start that conversation. You do need to give it a topic, but then it just makes a huge difference when you're reading your messages. So now instead of kind of everything being mixed up, you have these organized conversations labeled with our topic. And so it's,
You can come in and read your messages one conversation at a time. Rather than everything happening chronologically, you could say, okay, people are talking about this. Let me read about that. Okay, I'm done with that conversation. Let me move on to the next one. And so it doesn't matter if people are... And it's a busy channel. People are talking about 10 different things at once.
It's just not a problem. You can...
read everything in its own context and you can have a conversation that's goes across time so you know maybe people are working async or just busy with meetings and so somebody comes in a few hours later or a day later and wants to comment on something that was going on rather than getting kind of like lost in the noise you have all that context in the same place
So every Zulip instance has channels, which are like long lasting things. And then the channels have inside of them topics. Is that the, the architecture?
Yeah, exactly. Exactly. So, and then each topic is basically kind of a topic of conversation and that can be very ephemeral or it can be something that you come back to after a while and that, that, you know, both, both ways work.
And what differentiates a channel from a topic? Is it merely their position in that structure, or is there something about a topic that's different than a channel? Because a lot of chat apps just have channels.
Yeah.
Yeah.
I mean, the channel is very similar to channels in other apps. So, for example, it comes with some metadata like subscribers, privacy settings, those sorts of things. And then topics are just another level of organization within that channel. So, for example, for...
your subscriptions, you would be managing your subscriptions to channels, and then you would automatically see the topics that are in the channels that you're in. We do actually have ways to, within that, mute specific topics or follow specific topics, so you can kind of set your preferences there as well, but Yeah, just kind of another level of structure.
And that, you know, there's also ways to view, instead of viewing all your messages in a feed, you can also view the topics. So there's an inbox style view where you can see your unread topics. And then you can just jump into the places where you're, you know, you're like, oh, this is relevant for me. Let me take a look at that.
And there's also, there's another view that lets you see the recent conversations. So again, kind of gives you different ways to summarize what's going on and really dive into what's important for you and where you need to participate.
Does every message inside of a channel have to exist inside of a topic or is there also just like the, we're just messaging, we're not, we're not topicking.
Yeah, that's something that's configurable by the organization administrators. In general, there's not a lot of need for these. It depends. But in general, we recommend having at least the vast majority of the messages happen in topics. I mean, once you're replying to a conversation that's already ongoing, you kind of hardly notice this. It doesn't create any extra work.
You just click in and you're replied. It's not like you have to retype the topic or anything else. So it's really... not a lot of overhead. And once people get the idea, it's really pretty seamless. And we also give folks tools to reorganize everything if things do end up out of place. So you can move messages between topics as well as between channels.
So especially when an organization is just getting started and folks are getting used to the model, that really lets you reorganize things if things do end up in the wrong places to start with.
I suppose if you really wanted just like a general chat inside of a channel, you could just have a topic called general chat.
And then you're just like, you know, it becomes a junk drawer.
If nothing fits here, then it just fits in the junk drawer. And the junk drawer ends up being the only place people talk and then you're not using the tool right anymore. That's the biggest struggle.
Yeah. And the thinking is really that people are spending tons of time throughout the day on communication. Some surveys found that it's something like half of the time for a knowledge worker is spent on some communication of one kind or another. And so just making that more efficient can make a huge difference in terms of people's time.
And if you think about what you're actually doing when you do communicate and when you do chat, most of that time is really spent reading messages. So of course you're sending some messages, but there's more time spent kind of ingesting content.
And so if that process is really smooth and seamless and feels kind of structured and not chaotic, that's going to make a huge difference for people's experience the other day.
I'm looking at the screenshot on your homepage, which I assume is up to date. Is it up to date?
Yeah, it is.
Pretty accurate?
Pretty accurate.
Okay, cool.
But sometimes homepages get out of date, you know? They have a live demo. Their personal chat is chat.zulip.org, like their dev chat. And you can join that anonymously, Adam. And then you'd have like, you'd actually be using the software, which is pretty cool. If you wanted to like actually see how it, and you can go through channels and topics.
And so that's a, I found that to be a pretty good way of just seeing exactly how it works.
Yeah, where would I go to do that real quick? Because I was trying to open that conversation, like get into the actual UI.
Yeah, I don't know where the link is, but just go to chat.zulip.org, and then I think I'm currently in the design channel looking at the channels and topic illustrations topic. And it's very active and scrolly. I was just looking for the most recent conversation. So that's kind of cool. As you hop in, you can see all the recent conversations.
And yes, you can jump into those different topics and see what's going on there. It seems pretty well organized. I mean... We use Slack on the daily and we have slightly less organization.
We have channels and now there's threads, which is kind of a bolt-on, which kind of can act as a topic, but they're more like ad hoc, like, hey, maybe I'll reply in the thread or maybe I'll reply to the whole channel. And then it gets to be like, what's the idiom or what's the general, like what's the culture around threads? How do we use them? And people use them differently and it gets to be
hairy because of that. I think this, this little bit of extra structure, which really isn't very much, it's like one more level of structure, you know, it's like channel and topic might help organize your communications. And it seems like it is because you all still exist here 12 years later. Yes. 12 years later. And now you're a thriving business on top of an open source project.
So people must like this, this model.
Yeah, I mean, that's the, you know, we get lots of feedback from folks and that's really the biggest differentiator for people is that level of organization just makes a huge difference in people's experience using the product. Like people tell us, like, I can't, you know, it's hard to, you know, sometimes I have to go back to Slack to talk to my customers and it's just so chaotic.
And it's just having experienced the level of organization within Zulupe Other things feel, people start feeling like other things are messy and hard to follow.
Adam, have you clicked around enough now to formulate what you were going to ask before?
Yeah. Have you found messages from me yet?
I just, I do like it. So I'm going to paint a verbal picture of this visual I'm looking at. So channels on the left, topics to the right of me. Here I am. I'm just stuck in the middle with us. Stuck in the middle, you know. Nice. Well played. Great song, by the way.
I like when you click on a channel, you see these topics, and then if you click on show all topics, you obviously get into a channel view with all the topics in it that you can filter and scroll, and you can easily go back to channels. I'm not signed in, so I can't see how I start new ones, but it does seem pretty snappy in terms of just how easily you can map around.
I just wonder if it's overhead on anybody's part to organize messages online. organized topics because you can. That's what I was trying to figure out.
Well, for the most part, it's kind of self-organizing. So just when somebody is starting a new conversation, they'll start a new topic. I mean, in the Zulip community, we do have a lot of folks who are new contributors or somebody who's coming in who's kind of brand new to the product or just checking it out. So sometimes they might not be sure exactly how to name a topic well or where to post it.
And then Just when somebody sees that it was posted on place, they'll move it around to where it should be. So it's not like a big job. It's just you're reading your messages. You're like, oh, this belongs to another channel. Let me move that over there.
It's kind of like a real-time forum in a way. You know, like when I'm on chat.zulub.org, it's got the feels of a forum and the feels of a real-time chat kind of combined into one, which is kind of nice because there's, you know, in forums, you often are threaded conversations. They're obviously topic-based, but they're not real-time generally, to my knowledge. I mean, I haven't been on a forum...
and like active i suppose since the where's days of my life but you know i'm on forums here and there i think there's some obvious ones out there but it's not active in them i'm very active in slacks multiple slacks not just our own and really no discords at all for me so my only really experience is like older hip chat days obviously campfire And then obviously now modern application.
How about IRC? Did you ever get an IRC yet?
A little bit, you know, a little bit. Honestly, I just, it was like, I wasn't quite hacker then as much as I am now. So I didn't quite get into IRC. I tried. I was, but just not like steeped. Sure. Like real-time chat is. But this is kind of cool because it's kind of like a forum and a real-time chat all built into one. And it doesn't feel overwhelming.
Like you see this stream of content coming past you. I think... There's some psychological things that happen in real-time chat applications these days that you feel like you have to keep up or there's just a stream of data. It doesn't feel burdening thus far.
Yeah, and that's a really big thing we're trying to solve for as well, to sort of feel like, oh, somebody sent a message, I have to respond right now. Otherwise, it's going to be messy, it's going to be confusing, I'm not going to be able to reply.
How do I get back there?
Yeah, exactly. And then that disrupts people's focus time, even if they are online. You want to be able to just dive into your work and focus for a couple hours, and then when you need a break, maybe check in on your chat messages and follow up on stuff. Most of the messages people are sending are probably not so urgent that you need to interrupt your flow to jump in right away.
And so that's part of the design here is that to really make it possible to say, okay, I'm going to dive into the code. I'm going to dive into my project and then reemerge and follow up on all the chats where I need to respond and then go back to what I was doing.
The cool thing for us, Adam, if we did Zulip instead of Slack, is it's self-hostable. You can also use it in their cloud, so you can pay them money and they will host it for you. But if you were to... I haven't looked at the cloud offerings or the way that it breaks out pricing-wise. You can obviously catch us up with that, but... They can't hold our chat history hostage.
Our chat history is being held hostage inside of Slack. And sometimes I look at that as a plus, like, hey, who cares? Sometimes it's nice that things disappear. And other times you're like, no, I told you this 91 days ago. And 90 days is the maximum. And so it's gone. It's gone forever. And now we've lost that information.
Yeah, well, now they're going to actually start erasing it after a year, I think, right?
Oh, are they? Yeah, I don't know. I don't follow too closely along.
Well, I've gotten a couple of those emails and they are scary to see. I was actually a little nervous because I was trying to quickly as this topic came up in this conversation to find that message because I do recall them saying recently to us that there's some updates required by September or something like that. And like,
final notices for x and i'm like like you jared i who cares in a way but then i'm like maybe i do care you know maybe i might care right now like they don't care until you do care right you're like oh no it was in the slack and then it's gone now and you're like yeah Yeah, I don't know. Do you know much about that, Alia?
Like what the current state of Slack's... I imagine you're probably leveraging it in some way, shape, or form. If you're not leveraging it, you're getting the inbound of it, right?
Well, we did... I guess maybe you guys remember it was a couple of years ago, maybe now, that Slack switched from letting folks see 10,000 messages of history to just 90 days on a free plan. And that...
That was really, it was framed as kind of a positive, but what we saw is a huge influx of folks, communities who don't find, can't afford something like paying for a pro plan on Slack, leaving Slack and importing their data and moving to Zulop. And I mean, for us, we have a really robust sponsorship program for communities and open source projects, nonprofits,
education, kind of all kinds of non-business uses for Zulip. We really try to, you know, enable folks to benefit from our software. So we do sponsor free Zulip Cloud standard plans for folks. We have over, I think, over 1,500 sponsored organizations at this point. So it's a really robust program.
That's quite a few.
Yeah, and it's something that we really believe in Zulip as a way to help folks be more productive and really help them accomplish what they're trying to do. And so we don't want to wall that off as much as we can. Of course, we do need businesses and organizations that can afford it to pay for the product.
But otherwise, we really do want to share it as much as we can and enable folks to do awesome things with it.
Yeah, I found the email that was scary. This was sent on June 24th. It says free workspace content older than one year will be deleted. And then I won't read it all, of course, but it says this policy will begin taking effect. Get this, Jared. August 26th. Ooh. It is as ago. The 28th. Yeah. So as of this recording, we're recording on August 28th. They're deleting our stuff.
But it does say workspaces will be notified prior to the policy impacting that workspace. So we do have time. They haven't rolled it out yet. And it says your workspace is on a free Slack plan because... Alia, we are a community. We've been sort of hamstrung, I suppose, by Slack. We've always been dumbfounded that they would never have changed their tune towards communities.
And we have several communities in our sidebar that I'm a part of, and I'm sure, Jared, you're a part of some that I'm not. But there's relationships in business. There's partners who are in their channels or vice versa. And it always seemed like, what's the line from Goodfellas, Jared? Maybe it was one of the Godfather movies. I don't know. Which one? It was basically Pay Me. Oh, yeah.
You know what I'm getting at here. Yeah, yeah. It's a PG show here. That's how I've always felt about Slack. It's just not a great company. And I'm all for companies being ambitious and enterprise-focused and all that good stuff. I'm not at all against that. But I was always confused.
by their seemingly inability to see the goldmine of community that had leveraged Slack in its free tier to not find a way to make them pay in some way that wasn't thousands and thousands. It only seemed to be optimized for the large enterprises only, not for the smaller communities at all.
Yeah, well, and I guess our general philosophy on pricing is, look, if you're a business and you're paying somebody a salary, paying a small monthly fee for that user, a few dollars a month to have chat software that they use hours every day, and in our case, that can help them be more efficient with their time, that's just so worth it. And it's a very reasonable way to do things.
But if you're looking at an organization where the folks using chat are not your employees, so even if there's some kind of core employee corps, a few folks who are part of a business, but then you have a large community that's part of that organization, now the pricing doesn't make any sense at all. And so that's Folks can contact our sales team for their specific situation.
But in general, our approach is really businesses. It makes sense to pay that kind of level, but not for community members, even if there's a business involved.
Plus, if you're doing long-term thinking, the way you all are doing it builds value over the long run. Because the price of you all providing these standard plans for, at this point, 1,500 organizations, which are community-focused, nonprofits, open source, research, academia, etc. These are people who...
will use and love your product and it will help generate a network effect, you would hope, that would eventually bring their business to Zulip, you know, their friend's business when they go to ask them for a recommendation to Zulip, who becomes a paying customer. And that stuff doesn't...
pay off in the quarterly or sometimes even the yearly, cause you're actually losing money by giving this away to more people. But like on the, on the measuring 10 years, 15 years, 20 years down the road, that stuff compounds and becomes massive.
And it's something that Slack I think currently has to a certain extent is some network effects where it's like people already have a Slack app on their phone. And so it's easy to add another Slack. In fact, yet another Slack is kind of a fatigue at this point. Like, Oh, I have so many Slacks. I don't want to have another Slack, but yeah,
It's a big advantage when it comes to getting people to use the tool if they've already used it, if they already have it on their phone or on their laptop. And so what you're doing is you're getting Zulip out there for these people and you're doing good at the same time. So I applaud that strategy.
Yeah, absolutely. We definitely see folks say, oh, I used it. We ask folks who are creating new Zulip organizations how they learned about Zulip. And a lot of them say, I've used it in a Zulip organization before. And I think a lot of the time that will be an open source community somewhere.
And also, you know, another way that folks from these communities are really contributing is that we get a ton of user feedback. So as you saw, our development community is open and it's open sign up.
So folks will just come and come by and kind of share how they're using Zulip, what they think could work better, any kind of bugs they encounter, but also feature requests, as well as like just posting and proposing feature ideas on GitHub. And we just have these really open discussions with our users, and that's really valuable for just figuring out the ways that we can improve the product.
So when it comes to Slack, Adam, you and I have kind of have maybe two values that they hit on one of them. One of them is like high quality software and design. Like that's the thing that we both care about. And then the other one's like open source community ethos, which Slack does not have. And so they have kind of one of both. We like to have them both.
And high quality software and Slack, I think that's more questionable now than it used to be. I think they really did hit it out of the park in certain ways and were groundbreaking in certain ways. Recently, I've been less impressed after some redesigns, and I feel like it's kind of stagnated. Of course, they've arrived.
They are now part of Salesforce and a big company and all that, and they have other people in their minds that aren't us. But I'm curious about Zulip when it comes to the software and the way it all works, and does it fit into all the different places that you communicate with? Because more often I'm using Slack on my phone even, even though I stand at my desk for hours every day.
You communicate all day long and all night long. And so Zulip on the phones, Android iOS, Zulip on the web, Zulip apps. Do you have all that necessary surface area accounted for and how do you all manage that?
Yeah, absolutely. So Zulip, you can use it just in a browser tab. There's also a desktop app for all the major platforms. And then, yeah, Android and iOS apps. And we're actually currently in the process of rewriting our mobile apps from the ground up using a different framework. We're switching to Flutter-based apps. So our current apps are definitely functional, but not as...
sort of smooth and beautiful as we would like them to be. And so that next generation app is really going to get us all the way there. So we're very excited for it. And for sort of old school folks out there, there's also Terminal Client for Zillow if anybody wants to use it that way.
How about API? Is it programmable?
Yeah, there's an open API and actually our mobile and terminal apps use the API to communicate with the servers. So we're constantly kind of testing it ourselves and using it ourselves and relying on that documentation ourselves. So absolutely.
Is the desktop app an Electron app?
It is, yes.
Have you considered a Tori app?
My understanding is that the engineering team was thinking about it and was kind of waiting for it.
Because if you wanted to get the nerds excited, I think, if you came out and said, Zulip's desktop app is now no longer using Electron, then it would be like, we'd just throw slack right out the window, wouldn't we, Adam? All of us nerds would be like, ah, finally, something we can use here. Yeah, pretty much.
Okay, friends, I'm here in the breaks with Annie Sexton over at Fly. Annie, you know we use Fly here at Change. We love Fly. It is such an awesome platform and we love building on it. But for those who don't know much about Fly, what's special about building on Fly?
Fly gives you a lot of flexibility, like a lot of flexibility on multiple fronts. And on top of that, you get, so I've talked a lot about the networking and that's obviously one thing, but there's various data stores that we partner with that are really easy to use. Actually, one of my favorite partners is Tigris. I can't say enough good things about them.
When it comes to object storage, I've never in my life thought I would have so many opinions about object storage, but I do now. Tigris is a partner of Fly and it's S3 compatible object storage that basically seems like it's a CDN, but is not. It's basically object storage that's globally distributed without needing to actually set up a CDN at all.
It's like automatically distributed around the world. And it's also incredibly easy to use and set up, like creating a bucket is literally one command. So it's partners like that that I think are this sort of extra icing on top of Fly that really makes it sort of the platform that has everything that you need.
So we use Tigress here at ChangeLog. Are they built on top of Fly? Is this one of those examples of being able to build on Fly?
Yeah. So Tigris is built on top of Fly's infrastructure, and that's what allows it to be globally distributed. I do have a video on this, but basically the way it works is whenever, like, let's say a user uploads an asset to a particular bucket. Well, that gets uploaded directly to the region closest to the user. Whereas with a CDN, there's sort of like a centralized place where
assets need to get copied to. And then eventually they get sort of trickled out to all of the different global locations. Whereas with Tigris, the moment you upload something, it's available in that region instantly. And then it's eventually cached in all the other regions as well as it's requested. In fact, with Tigris, you don't even have to select which regions things are stored in.
You just get these regions for free. And then on top of that, it is so much easier to work with. I feel like the way they manage
permissions the way they handle bucket creation making things public or private is just so much simpler than other solutions um and the good news is that you don't actually need to change your code if you're already using s3 it's s3 compatible so like whatever sdk you're using is probably just fine and all you got to do is update the credentials so it's super easy
Very cool. Thanks, Annie. So, Fly has everything you need. Over 3 million applications, including ours here at ChangeLog, multiple applications, have launched on Fly. Boosted by global anti-cast load balancing, zero configuration private networking, hardware isolation, instant WireGuard VPN connections, push-button deployments that scale to thousands of instances. It's all there for you right now.
Deploy your app in five minutes. Go to fly.io. Again, fly.io. And by our friends over at Paragon, useparagon.com. Check them out. Ship every SaaS integration your users need. With more than 100-plus pre-built connectors, you can add dozens of integrations to your app quickly and reliably. with their embedded iPaaS for developers. And I'm here with co-founder and CEO, Brandon Fu.
So Brandon, talk to me about the friction developers feel with integrations, SSO, dealing with rate limits, retries, auth, all the things.
Yeah, so there's a lot here, and I think there's a lot of aspects to the different problems that you have to solve in the integration story in building these integrations and also providing them in a user-friendly way for your customers to self-serve and onboard and consume those integrations.
So part of what the Paragon SDK provides is that embedded user experience, again, what we call our Connect Portal. That's going to provide the authentication for your users to connect their accounts. That's going to be the initial onboarding. But in addition to that, your users may also want to configure different options or settings for their integrations.
A common example that we see for Salesforce or for CRM integrations in general is that your users may want to select some type of custom object mapping. Every CRM can be configured differently, so your users might want to map objects to some different type of record in their Salesforce or different fields in their Salesforce.
And typically that's what developers would have to build on their own, is this UI for your users to configure these different settings for every single integration. That's also going to be what's provided by the Paragon SDK.
It's not just that initial onboarding and authentication experience, but also the configuration end user UX for different settings like custom field mapping, selecting which types of features on your integration that your user might want to configure, And that's also going to be provided fully out of the box by Paragon SDK. With integrations, different APIs might have different rate limits.
They might have different policies that you have to conform with. And your developers typically have to learn these different nuances for every API and write code individually to conform to those different nuances.
With Paragon, because we build and maintain the connector with each of the integrations that we support in our catalog, we're automatically going to handle for things like retries, things like rate limits.
And so we look at this as sort of the backend or infrastructure layer of the integration problem that we have spent the last five years essentially building and optimizing the Paragon infrastructure to act as the integration infrastructure for your application.
Okay. Paragon is built for product management. It's built for engineering. It's built for everybody. Ship hundreds of native integrations into your SaaS application in days. Or build your own custom connector with any API. Learn more at useparagon.com slash changelog. Again, useparagon.com slash changelog. That's U-S-E-P-A-R-A-G-O-N dot com slash changelog.
What are some of the biggest challenges you all are facing?
Good question, I guess. I mean, one sort of thing that is complex for us is the competitive landscape, like Slack and Microsoft Teams being the sort of big gorillas in the room, and Teams effectively gives away their chat for free, oftentimes as part of their Microsoft Suite, and it's really hard to get folks kind of... At the same time that It's free. It's not free, right?
In the sense that people are spending their time and their energy and their attention in ways that aren't making them productive. You know, like they're wasting... Your employees' time is your most valuable resource. And so...
wasting that time and energy on an app that's frustrating or hard to use or is not organized in the ways that you'd want it to be is a major cost, but it's hard for companies to budget it that way and to really evaluate it that way. So I think one thing we're really trying to do is get better at telling that story and really communicating with folks and trying to explain this
make people really sort of feel in their guts this sort of, okay, this app might be free or it might be kind of an easy choice like Slack for most, a lot of folks are familiar with it. It's sort of like, nobody got fired for buying IBM, probably nobody got fired for picking Slack for their chat. And there's lots of things that are great about it compared to sort of
products that had come previously. But choosing a chat app is just so important to how folks are going to collaborate in your organization. And so that's really the message we're trying to get across. And that's, I think, kind of a big challenge for us is to really...
get people off of their kind of default mode or the easy decision there and really, really get folks to consider and evaluate our product and to take that time and attention away from, and there's so many other things that they need to be doing to really think about this choice in a very like intentional way.
It is hard to compete against free, especially when the Goliath is giving it away for free.
Yeah, I mean, Microsoft is facing anti-competitive lawsuits in Europe because of how they've set things up.
Yeah, it's unfortunate, especially you would think as a user, like you said, nobody got fired for buying IBM. I didn't make that up, but I don't disagree with it to some degree. Except for what if you're missing out on what is free and open source, but you can also pay for it. when the Zulip name isn't as polished as maybe Microsoft, obviously.
You know, that's the hard part is that you kind of have to win them with showing up, you know, with the open sourceness of what you're doing, the way you've been in the trenches with the communities, the way you've sponsored things, not just simply the larger brand name and the The literal freeness that you can get with Teams.
Now I know that at certain points organizations have to pay for Teams, but it's pretty much free for the entrants. And then you pay once you're literally locked in.
Yeah. And I think in the past, a couple of things that have held us back have been, one, the design of the app. That's really something that we've been focused on improving. That's been a major, major investment for us over the past year or two and continues to be. For the longest time, our users would tell us that
the user experience in Zulip is second to none, but the design could use some work. And that's not such a big problem necessarily for folks who have got kind of like, once you've gotten used to an app, you might kind of stop noticing some of these things. But in the initial evaluation, it makes a huge difference. If you open an app, you're like, oh, this doesn't look modern.
This doesn't look beautiful. And so we're really trying to get away from that and have folks have an immediate kind of like positive response to the app as well as enjoying the UI over the long term.
And then another thing we've been really focusing on is that the onboarding experience, because there is a little bit of a different mental model for Zulub compared to other apps folks might have seen. And we do want to have that be easy to understand and easy to onboard people, easy to get everybody in your organization, kind of have folks get started with that.
And also, I think almost any app, when you first encounter it, might feel a little overwhelming. If you've never seen Discord before and you open it up, there's a lot going on. But some of these apps that we're competing with, most folks have seen them before, and so now they have forgotten that first initial feeling of, oh, there's so much happening, it's different.
So we really want to help folks through that experience with Zulip, because... We do have a lot of users who are coming in who haven't interacted with it before to really get them across this threshold of like, oh, I get it. This is comfortable. This is not, you know, some things about it are different, but a lot of patterns I'm familiar with from other applications work here as well.
And it really is pretty intuitive once I kind of like have a handle on it.
Well, I asked in our Slack community just moments before hopping on if anybody's used Zulip and what they think about it. And one person said, used it at a different company, liked it a lot. It's kind of like Slack. The higher-ups replaced it with Teams as Zulip wasn't, quote, auditable. So that wasn't the free part. It was the auditable, which to me makes not 100% sense, but there you go.
Yeah, I'm not so sure because we do provide different ways to export your data, including like compliance exports, or you can just export it. I don't know. Okay, okay.
Yeah, he says it was infinitely better than Teams. So there you go.
All right, well. So that's cool. But that's an example of that kind of like, what might be a little bit, I don't know, it's like, I guess folks have their own priorities and I don't want to like second guess the management, but. That's just where that perspective of your team's efficiency and how happy they are with the software they have to use every day.
No.
Not directly. Indirectly? Like you were listening to them talk to their spouse or something? I don't know. I love teams.
Through the tea leaves or something.
Now, Discord, people seem to love. And I'm not really sure why, personally. I've signed in. I've joined some Discords. It seems like a hot mess to me. But... It's very big in gaming communities, musicians and crypto scam artists I know use it, other communities. And I'm not sure what it is about Discord. I know they have some cool audio features built in.
They kind of have a lot of different stuff because it came out of, I think, gamers would hang out and talk to each other initially. Yeah. So do you have a lot of, do you ever have to compete with Discord or do you ever have to explain Zulip in light of Discord and how you all differentiate from them?
So it depends. So Discord is not so much designed for business use or use within organizations that needs to be closed and have sort of, because it's a single account across all your organizations, it's sort of a different structure there. We do have folks who are Discord users who have definitely requested some features that Discord has.
I would say that, yeah, their kind of video and calling and the way they do that is quite nice. And that's something we've heard folks interested in.
Something that we're actually working towards is Discord has, maybe if you haven't administered organizations, you haven't explored that side of it, but they have really nice ways and flexible ways to manage permissions and groups within an organization. And so that's actually a big project that we have going on right now, like really, really flexible ways
permissions management where you can create an arbitrary group and then give that group kind of an arbitrary set of permissions within your organization. And I think that's going to be really, really nice for anyone administering a large organization.
That's one thing I really wish we had in our Slack, Jared, is that we have people come and they share things they should not, a.k.a. spam. Yes. And I would just like to be able to eventually boot them because... I delete the message and I look at them and I'm like, well, you're clearly not here for the reasons everyone else is here for. You violated the code of conduct intended for this place.
There's no way for us in our current state to enforce these kind of things aside from just deleting messages. Sure, we could probably log into Slack and delete their user, but that doesn't stop them from coming back. I'm not sure if any platform can really do that to prevent somebody from recreating a new account or whatever.
But I do wish we had some moderation tools where I'm sure even the community inside of our Slack would step up and say, you know what, I'll help you guys because it's 2 a.m. and you're sleeping and I'm not because I'm in a different country. And if I see a spam message, it doesn't have to sit there for eight hours until the morning or whatever time it is.
When we look at Slack again, it's like, well, hey, this thing has been sitting there with people piling on or looking at it or clicking it. And we can't do that stuff. So I wouldn't mind having some moderation tools.
Yeah, we have some tools. I guess if you deactivate a user, they won't be able to rejoin with the same email. And you can also disallow throwaway email domains if you want to prevent definitely is helpful for preventing spam. You can also, personally, you can mute a user.
So if you, as an individual, don't want to see somebody's content, we do let folks have the option of muting that person and that just hides all their stuff for you. So you never have to interact with it.
It would be cool if you could auto-block new users if they start a message with, dear sir slash madam. Auto-block, sorry.
Write a bot, I guess.
Yeah. Some sort of pattern match, I guess. Oh, yeah. Known. Yeah, I mean, it doesn't happen often. We get some spam here and there. And mostly, I get it. Go join a Slack or find a place to belong and share your messages. And you do that with enough numbers, you'll get people... I get it.
It's a numbers game, but it doesn't make any sense to me because you're not really getting the long-term benefit you actually want for a brand. And so it's such a nasty thing, really. And like I said, it doesn't happen too often, but often enough where I'm like, yeah, I wouldn't mind some tooling. What would a migration look like?
So for something like moving from Slack into Zulub?
Just for instance.
Yeah, sure. Just for instance. Yeah.
As a random example. Hypothetically speaking. Yeah, apropos of nothing.
Yeah, so we have instructions on our health center for how to go about it. So basically what you would want to do is, assuming you want to keep your message history, you can export that through Slack. It might be limited, I guess, now, depending on your situation.
And then if you're moving, say, to Zulip Cloud, so that's our managed SaaS offering, you would just send over that data to us, and we would import that into a new organization for you. And so you could preserve not just the messages, but also the user data. So you'd have a running start on that.
And then we also, I don't know if you guys have integrations, but also to make it easier to move over your integrations, if you have any, we have Slack-compatible webhooks. So basically you could... just kind of remap where your webhooks are sending in their data to be Zulip. And then on your own time later on, if you want to move over to more like Zulip native integrations, then you can do that.
But things would be working for you right away. So yeah, and you can tell folks where to log in or we can automatically send emails to all the users that you imported with their login information. So however you want to manage that.
And they would just get an email and they would maybe have like a password reset on the first sign up or like, obviously you're not going to import their passwords.
Yeah. And we have all the social auth as well. So if folks want to log in with their, you know, Google account and GitHub or anything like that, that's also on offer.
That's the, it's 90% of my anxiety. If we're hypothetically speaking about things. Yes, we are. Is I feel like I'm just, I've been like in this waiting pattern in my own brain. You know, I haven't taken any action. I've been like just thinking that maybe Slack would someday get it and somehow just recognize that there's so many communities that have, you know, built up their thing around them.
And that many of us in even developer land or just let's just say tech land have, you
numerous logos slash icons in our Slack sidebar so we bounce from one workspace to another and I like that I don't want to be in a world where I can't where I have to like still I guess keep Slack or I just like the unification of it and as a user I don't want to have to go to the Slack app and then the Zulip app and then the whatever app I would just like a unification if it was possible I'm sure it is I think there are some out there but there's diminishing returns
My point is that I've been just anxious about what it would take to literally migrate if ever we actually had to because we got 7,000-ish people in our main channel. Not all of them are obviously present and active every day. I'm sure some of them come and go. Maybe some of them lurk.
I have no idea because I don't really have any analytics to our usage in terms of just beyond messages I'm paying attention to. So, I just wonder if we moved to something else, how much would we lose? How hard would it be to get even our active people to stay involved?
Would they come with us and would they continue to hang out? Or would they be like, Zulip? What? Why?
I can't promise anything about your specific experience, but we have had folks tell us that when they moved to Zulip, they actually started getting much better at community engagement. Because it works quite nicely for folks who are not around all the time.
So, I mean, one kind of category of folks, as you were saying, is maybe people who are lurking or who are just kind of coming by once in a little while, once in a while to check in on something. And if you're coming to something like Slack, you know, it's hard to... you might see the latest messages.
It's going to be not really possible for you to kind of catch up on what you missed if you're checking out every couple of weeks or every month in an active organization. Whereas for Zulu, if you just want to sort of check in on things occasionally, folks will come in and they'll look at that recent conversations you maybe saw when you were exploring the app.
And instead of having to look at sort of individual messages and try to figure out what's going on, they'll just see that list of topics and they can be like, oh, this topic sounds interesting. Let me jump into that.
And so you don't even have to feel obliged to kind of make everything be marked as red or kind of manage your own reds necessarily if it's just something where you're not following every little detail. You really can kind of just skim that list of what's been going on and jump in to the ones that are of interest. And so...
Yeah, so we've had folks say that something like an open source project, that it can actually really be great for community engagement because people can select the parts that are interesting to them and just follow those and jump in on those. You can even configure notification.
There's a concept of following topics, so once you've seen something that's interesting, if it's a community you're not engaged with very regularly, you can follow that particular topic and, say, get email notifications when there's more messages just to that topic. And so... There's really ways to follow specific conversations and find things to engage with for occasional users in a community.
I do like how you can set your Zulip to public as well. Can you do that on like a per channel basis?
Yeah, exactly. So this is something that there's an overall organization setting for whether you want to have public channels as an option. So for example, some businesses might not want to share anything and they just want to turn that all the way off. And then, yeah, for any given channel, you just configure it.
You can configure it to be kind of public for logged in folks, private or public even without logging in. So, yeah, what you guys were seeing in the development community is a bunch of channels that we've marked as completely public. And then, yeah, you can just kind of come by and not have to log in and just view messages there.
And then, of course, if you want to participate, then you would create an account and log in and post.
Now, are those public channels, do they get indexed by search engines?
They don't. We do have a way to, a tool for exporting your Zulu data, and then you can get that indexed by search engines and like a kind of an archive of all the messages. But it's actually kind of a major technical, the reason is that it's a major technical project to make those searchable, indexable by search engines.
And we just haven't had a chance to prioritize that project yet, but that's definitely on the radar, but it just requires quite a bit of technical work to make that work.
Yeah. I mean, that'd be pretty cool for public ones because then it would double as an indexable forum. For sure. Because a lot of those conversations become kind of canonical resources, or they could be, but they are lost to the ether. But if they were actually indexed... Yeah.
One thing we do a lot is linking to conversations. So you can link either to a conversation or even to a particular message within that conversation. And so, for example, when we, say, file an issue for a Zulu feature... we'll generally link to a conversation where we had some initial brainstorming discussion of that feature.
And so when folks are working on it, they can get that extra content and context. And then also, if they have a follow-up question, they can just pose that question in the same conversation and continue from where it left off. So that linking does make some things easier to find.
So one thing you might not know all yet about Adam is that he is an avid home labber. And so what would a migration look like to the self-hosted if Adam were to become our system administrator and run our Zulip community out of his home lab?
Yeah.
What would that look like?
Yeah. So it's pretty similar, except for you would skip the part where you email us, and you would do that for yourself.
One last step. Even easier, Adam.
Exactly. Yeah, we have an installation guide that is pretty straightforward. We really do work hard to make it easy to self-host Zulupe and also make the installation process as easy as possible, really smooth upgrade process when the new version comes out. So it's definitely a priority for us. And there's detailed documentation on how you need to do everything.
So it should be very doable for you if that's something that you're enjoying. Yeah.
You have a Docker image?
Yes. Sorry, this is not the part that I personally work on nearly as much as some other things.
All good.
You hear that, Adam?
They got a Docker image. And what aspects of Zulip Cloud, the hosted version, are completely inaccessible to you as a self-hoster? Are there specific features that you will never be able to use in self-hosted or is it all there but you have to worry about backing it up and making sure it's up and all that kind of stuff?
It is all there. So Zulip is 100% open source. There's nothing that we're locking away from self-hosters. If you self-host, this is the one thing that... So we do offer paid plans for self-hosters. You don't have to sign up for one, but they're on offer. And the kind of two major things that we're providing with those paid plans. So one is mobile push notifications, right?
So the way that App Store policies work, both on Android and iOS, is that if you have a mobile app, which our apps are also 100% open source, but you probably want to use the app that we put in the Play Store or the App Store, rather than kind of rolling your own, which is a whole thing.
And so the way those app store policies work is that a single app can only get push notifications from a single server. It's kind of like an anti-spam security measure on their end. And so for your self-hosted server to send notifications to those little mobile apps, what you do is basically bounce that traffic through our server.
And so that's a service that a lot of folks who are self-hosting choose to pay for as part of our plans. And then the other piece is just support. So if you want any kind of support with running your Zoop server, there is community-based support in our development chat. So folks do come by and get some help there.
But if you need SLAs or if you need something more than just asking a question on chat and seeing if folks are around to reply, then we do have support offerings as well. So those are kind of the types of... plans for self-hosted organizations.
I did find a repo, and I know that you may not be able to go deep on this if you can, it's okay, is on your Zulip org on GitHub. It's docker-zulip. So I assume this is official. It's container configurations, images, etc. for all of it. There's a Docker-composed file there.
Yeah, so I guess the way it's described in our docs is it's an officially supported experimental Docker image.
Okay. Official yet experimental.
So, you know, tread softly, but officially. 102 lines in this compose file. I mean, that's a lot of lines. So you've got SSL certificates set up for folks. You can set up a custom CA certificate if you want to. You can point to a different Git repo. So you can point to the official or you can have your own fork, which I think is pretty cool.
And you're just a dark compose up away from running Zulu locally.
Sounds pretty awesome. There is also an architecture document on your docs, which I found to be pretty good at describing the way the whole thing works and the various parts. Postgres backend, they're using Redis and Memcached in certain areas. It's a Django web app for the back end.
And then there's a single page app, which is written in TypeScript, probably React, I'm not sure, for the web and browser experience. Obviously, the mobile clients you mentioned are getting rewritten into, did you say Flutter?
That's right.
Yeah, and so they're all using that same backend API. Now, if you're self-hosted and you want to connect your phone app to that, are you just basically saying like zulip.changelog.com?
Like, would we just create a... Yeah, just when you sign in, you put in the URL for your server and you're good.
Wham, bam. What do you think, Adam? Do you want to dockerize us? Yeah.
Well, see now, that's a great question, obviously. But now you have to be your own uptime for your own chat apps. That's the high price of self-hosted. That is the high price of self-hosted. I would want to compare Zulip Cloud and other ways first, but I'm not against the idea of self-hosting. I just think it takes a lot of responsibility to do so. Yeah.
I assume, how then, maybe you answered this already and I was reading docs or the doc compose file while you said it, and if I missed it, I'm sorry. No worries. But how does your iOS, Android app work with a self-hosted scenario? Do you point it at... Like a URL kind of thing? Yeah.
I asked that one. Yeah, exactly.
Asked and answered.
No worries, yeah. So when users log in, they'll just put in the URL for your server and then they're good to go.
You just CNAME a subdomain and you're good. Yeah.
So self-hosting, yeah, I mean, you would have to have, even if it was like literally self-hosting in a closet or self-hosting on DigitalOcean, Render, those are two that are mentioned in your docs. We obviously prefer Fly, fly.io. Not paid to say that, but just definitely very passionate. So I guess we can self-host on fly, right, Jared? Like we wouldn't have to self-host anywhere.
I just thought it'd be cool to run out of your closet. It would be cool. Except for, I think, I don't know if the uptime would be as good. I mean, the ping, the latency, Gerhard may have opinions about it. That's for sure.
It's just chat. You know, like worst case scenario is we can't send each other memes for a few hours.
I mean, we've had folks self-host Zulip air gaps, like on a ship.
Oh, really?
Where they weren't going to have connectivity with the wider internet, just as there's chat within that ship community. That's cool.
So if we ever decided to travel the world, maybe on a sailboat, like our friend Alex McCaw did, we could have Zulip on that sailboat with us. That would be cool.
Self-contained Zulip, and I guess local area network only, right? Yeah, yeah, yeah.
Might not be required if you have five people on your boat.
You could even go local machine only. You could unplug that machine from the whole internet and have Zulip just on that machine if you wanted to. Truth.
Truth.
Not very useful that way, but you could do it. Via the terminal. The terminal app even.
Yeah.
What's up, friends? I'm here with Kyle Carberry, CTO at Coder.com. So, Kyle, I've known Coder as the IDE in the cloud. And over time, you've iterated to become a fully open source cloud development environment, a CDE. How do you explain what Coder is and what it does?
Coder is a platform to provision you a development environment on any cloud infrastructure. That might be in a VM, that might be inside of a container. But Coder is kind of a developer's route to provision infrastructure for them to write software inside of. We started with the IDE, which is kind of like putting VS Code in the browser, which is what most people are certainly familiar with us for.
And we kind of funneled that into more of a platform where people provision the infrastructure. And a lot of people do use a web IDE with Coder. A lot of people use a local IDE and just connect in.
Okay, so what are teams coming to you for? Who's coming to you?
What people really come to us for, particularly this problem is really exacerbated if you're a large enterprise, is when you have like 500 engineers that are trying to update like a version of Python. And instead, we allow one engineer to go through that tedious work of updating some scripts or some Docker container.
And then you can actually just deploy that in one click to say like 500 engineers and make it really, really simple.
Let's laser focus in on the platform engineer. It is that team's job to provide the best infrastructure, the best platform for their given applications, for their teams. What are some signs or signals for platform engineers to think about when it might be time to consider a cloud development environment like Coder.com?
So as a platform engineer, developers might constantly be opening IT tickets that their computer isn't working properly. They might constantly want to update dependencies, but that's a big mess. You constantly have to email people across your team to say, hey, Adam, could we update from Java 17 to Java 18? Those are the kinds of problems that people typically have. That's the status quo.
You ship people more powerful laptops to improve the build times of your projects. You try to reduce the complexity of your products instead of simply leveraging better hardware. We believe that the future is leveraging the cloud for a lot of these things. You can get more powerful instances in GCP or AWS that can make the build times faster instantly.
You can let one developer create a standardized environment and then distribute it to a thousand so that when you're updating from Java 17 to 18, it's just a simple pull request. You can co-locate your servers right next to something like S3 or a database they're using in development so that you get immediate data transfers and it's not slow.
Many of our customers, which is a crazy thing to say, but they use absolutely massive monorepos and they get clones that go from like 10 minutes or 20 minutes or an hour to simply like a minute or 30 seconds. It's just a lot simpler when all of your engineers are standardized on one centralized piece of infrastructure and then one person can impact the lives of hundreds of engineers.
And with that, we don't believe that everything belongs in the cloud. We think that some workloads are really amazing for it and some are absolutely terrible. Coder should be a self-serve offering to your engineers. It should not be prescriptive where you migrate all pieces of software development into the cloud.
Only the things that really get a lot better by running them in this cloud native way do we really promote moving.
Well, it might be time to consider a cloud development environment. And open source is awesome, and Coder is fully open source. You can go to Coder.com, get a demo, or try it right now, or even start a 30-day trial of Coder Enterprise. Once again, Coder.com, that's C-O-D-E-R.com, Coder.com. Well, there's a terminal app. I haven't seen visuals of this yet. How cool is this terminal app?
Have you seen it, Jeremy? I'm excited for a terminal app. I think that's very hacker. I like that.
Yeah, if you go to zilv.com slash apps, you'll see a link to it.
There you go. Okay. Terminal beta. Cool. It's very TUI-like, Jared. Obviously.
It's an application. I do like TUIs. It's an official terminal client written in Python. Seems like Zulip is almost entirely written in Python, except for that Flutter part. And that web app, of course, has to be TypeScript. But you guys have Python roots, right?
Yeah, Zulp was one of the first major projects to be using MyPy static typing in Python. So our engineers were part of developing that.
Awesome. I'm just staring at your terminal UI now. Same. I've seen a squirrel, and I've become distracted. I forgot to continue talking to you.
What I'm seeing on the side, though, if I can talk through it a little bit and see if you're following me, Jared, is that it seems like you've got the channels, of course, and it seems like those are topics beneath it, potentially. Obviously, it's not as full-featured as an actual web UI or an application UI. Do you find that people actually use this terminal app a lot?
Is it one of the primary client set that you have in your stats? What do you think the usage might be?
I don't have a number handy for you. I mean, folks do use it. Definitely not as much as their other clients, but for sure. I guess sort of philosophically, I would say one piece of it is that we've talked about just how much time folks are spending in chat. And so having that chat experience feel pleasant and natural and sort of do what you want, I think is really, really important.
You don't want to be annoyed and frustrated by something in an app you're using every day. And so we do believe in giving folks flexibility and options and configurations and different ways to experience Zulip that sort of matches well with their workflows.
And I would say having a terminal app as part of that, just for some folks, that is really the natural way for them to engage with a piece of software, and it feels really smooth and kind of... how they want to experience it. And so I think that's really valuable just because people are different. We can't make an app that is just one way and works perfectly for everybody.
There has to be flexibility for folks to engage with it in different ways.
If we can use this GitHub repo as a proxy for usage, I would say there are people using this. It has over 600 stars, but most notably 871 merged pull requests and 165 open pull requests. So people are working on this. People are collaborating on this. And of course, people only work on and collaborate on software if it's useful and being used by folks. This is not an afterthought.
This is very much a officially supported thing with 77 contributors. So pretty cool.
Yeah, and we had multiple interns working on it this summer. So yeah, it's definitely interactive.
That's awesome. Tell us about the team. Tell us about the company and all the people involved.
Yeah, so we have a pretty small kind of core team of folks who are paid full-time to work on, or full-time or part-time, I guess, to work on Zulip. And we do think that's really important kind of as part of our model that there is... a team of really talented expert engineers and other folks for whom this is their day job.
It's really hard to run a project where it's kind of a side gig for everybody. So with this core team, we've also invested a lot into... making it really easy for folks to get started contributing to Zulop. So there's been a huge amount of investment into creating the space for a really active, really lively community around it as well.
And that comes in terms of like tons and tons of documentation I think you saw. some of our production documentation. There's also tons of contributor side documentation from, you know, as you mentioned, how systems work, but also just the contribution process, what a good pull request looks like for us, kind of everything about that process.
And that's really something that we put a lot of thought into, like what is that process of contributing and how do we make that a really excellent experience both for us in terms of kind of reviewing the work as well as for the contributors themselves and make that a really great experience positive experience, great learning experience for folks.
So for example, on the order of 15 paid team members, we had 124 people contribute to our last major release. So that's about a six-month cycle. So it's a lot of folks who are either doing, some of them are doing kind of a formal internship program with us. We've been participating in Google Summer of Code for the past for a number of years now.
I don't know if you're familiar with it, but basically Google funds internships for open source projects as well as kind of managing that overall structure of helping folks find projects to work on. So that's been amazing for us. Most years we have about 15 to 20 interns, most of them mentored by kind of alumni of the program or other community members.
And that's been another really great way for us to bring folks into the community. So yeah, but it's, you know, Zulp is open source, not just in the sense of like the code being open, but really just in our whole model of how we develop the product and how we engage with contributors, how we engage with our users. You know, one time, I guess one of our...
Folks who joined recently, he started out as an intern and then joined as a full-time team member. And he commented that he was surprised when he got added to kind of all our private company channels, just how little traffic there is in those channels.
Like he was thinking that, you know, when we were giving him feedback on things he was working on, maybe we're like somewhere off on the side discussing that amongst ourselves. And then like...
providing the summary version he was like oh wait no that's not how it works i was like no no no yeah we if we're talking about how the product should work we just talk about that in the open and you know that way everybody can kind of see understand the decisions can can contribute to the decisions like yeah we're very like non-hierarchical in terms of it's really about what your ideas are and how clearly you communicate them and explain to them not you know what
what your title is or how long you've been involved with Zulip or anything like that. It's really about kind of working together to come to the best decision we can about how something should work. Yeah, let me know if I didn't quite answer everything, all the parts of your question.
Has she answered your question, Tara? Yeah. Okay. What's stopping you from, or have you considered, raising funds? I know you had grants in the past, but I'm not sure... What your angle is, I mean, there's obviously this idea of commercial open source companies out there.
We're very anti rug pull, not cool here around these parts, which means don't change your license once you've gotten to critical mass because it's against your future business objectives. Hopefully I paraphrased that well enough for you, Jared. I think there's an opportunity. I'm just curious. Have you? Why haven't you? What's the status on that front?
Yeah, absolutely. So we have intentionally not raised VC money and do not plan to raise VC money. And in terms of the business model, what we want is just to build a sustainable company on top of this open source project. So we've discussed some paid plans we have on the cloud side, on the self-hosted side, services we can provide.
And so that's really our strategy to have our users pay for the software and then that funds the development of the project and the product. And kind of a key reason we don't want to go the VC route is that We feel that kind of misaligns the incentives. There's kind of an inherent misalignment of incentives. So for us, we're not going to take 100 swings at this.
We're not going to try to build 100 different products and see which ones land and abandon ones that don't. We really are building Zula because we think it's a better way to work. And we're really, really committed to making that around for our users for the long term. So as I mentioned, we still have users from 2013 who are on Zilp now, and we want that software to be around for the long run.
And so we want to just take that one single bet and make it work. Whereas VCs, their incentives are, you know, they're looking for like the next, you know, your next Facebook, your next like giant company that just explodes. And they're willing to take big risks in order to have that probability of a really remarkable, amazing return.
Whereas for us, we want to take very small risks and have a very high probability of kind of success without necessarily aiming for that like galactic outsized return, right?
We just, you know, our main priority is really to get to a point where the software, we have enough, you know, we're making enough money to really continue to develop the software and have the staffing and the team that we want. And it doesn't have to be, you know, stratospheric. And of course, we would like to reach as many people as we can.
And we think it can benefit lots and lots of different kinds of organizations. It's a huge market. There's definitely tons of opportunity. But just like the kinds of risks we're facing comfortable taking to get there are very different from the kinds of risks VCs would feel comfortable with taking to get there.
What if that's not true?
Which part?
All of it. What if there are venture capitalists that align with open source, which is becoming a thing? What if there are venture capitalists that see your idea as the way and they want to fund companies that have prived by cold at hands aspects to open source? Would your tune change?
Well, I think it's not just about open source. I think there are now starting to be VC firms that are focused on open source and really buy into that model. But it's also just kind of the structure of how you do that investment, right? So do you...
try to like hire up really quickly, spend tons of money, you know, in marketing, even if it's the return is not there, but just to, to get that growth curve, you know, like, what are you, what are you trying to do? Right. And like, what is your strategy to get there? I'm not going to tell you 100% never in the next 100 years we'll take VC money. We're a small company, right?
We do to some extent make decisions about things when we need to make them, not planning things for 50 years ahead. But just that has been our kind of strategy so far. And we have not been approached by a venture investor who we think would be completely different from all the other venture investors such that we would start thinking about it.
I think the reason why I come with those questions is less to challenge you by any means. It's like zero about challenging.
It's more like if Zulip is the best and it is open source and it is superior in so many ways, in so many models even, of how you can use the software, not just in your cloud or in the self-hosted version, the exporting, the non-fettered access to it to be able to move and all those things, if it's superior...
I would want to, if it were me, I would want to do all I could to ensure everyone could use it more. And the way you get there is generally the reason why people raise money is not because they literally just want money. It's because they can leverage that money as a resource to go faster to the roadmap. And we talked earlier about Flutter. We talked earlier about some different areas.
And maybe you're slow and steady, and that's okay. There's nothing wrong with that. I just wonder if a little funding that was in alignment with your morals, values, etc., towards open source, the way you run your company... if that money didn't challenge those values, if things would change.
Because if you truly are better, and we've seen even in our own Slack, a person say infinitely better than X, you know, so we hear that ourselves even, if that's truth, then I would want to do all I could to get that truth to many people.
Yeah, and we're definitely, so we're not currently raising money, but we definitely are. Currently exploring different strategies on the go-to-market side, and that's something that we're thinking very actively about. How do we increase that reach and grow faster in terms of finding different ways to introduce folks to Zulub and to reach more people?
So that's definitely a major priority for us right now.
Yeah, that has to be one of your biggest challenges, is nine out of ten people don't know who you are.
Yeah. Right. Yeah. Yeah. No, that's true. It's true. Yeah. It is a major challenge.
No offense, but I mean, even most things, nine out of 10 people don't know what it is.
For sure. Yeah. Yeah. Yeah.
I mean, there's tons of things we're trying and I like the, I like the free for open source education, et cetera, that you already discussed. What are some of your other ideas? What else? Some of the other things you're thinking of trying to get more people to know what Zulip is to make Zulip a household name.
I mean, some of them are kind of standard things. So like paid advertising, going to conferences and various kinds of events and sharing Zoom that way. One thing that another direction is kind of content. So we've had blog posts on various topics. We're starting to...
You know, one of the things that I talked to, you can see, probably see my excitement about is this kind of side of community management and getting folks engaged in an open source project. So, for example, like we're working on some, partnering with some organizations on blog posts around that kind of thing. And so, yeah. Just kind of getting the name out there in whatever way.
Because I think, you know, as you were saying, kind of the brand recognition and just kind of awareness matters so that when not everybody's all... People aren't like constantly in the market for a new team chat, but we want to be top of mind when they are starting to think about it and when it does come up. But yeah, I would say we don't necessarily have kind of like...
So something unique other than, you know, we do have this open source angle and so things engaging with community and like the open source community more broadly and sponsoring open source projects is definitely like one angle for us that we're investing in.
Well, it's one of the hardest nuts to crack. And everybody out there is trying to crack that same nut, aren't they? And so there's a lot of noise. There's a lot of competing voices. And you definitely have a lot going for you. I think leaning in on community and open and I think moderation, as Adam said earlier, as you guys continue to flesh out the product. Those are all good strategies.
If there was a magic carpet that you could go on, it would automatically get you to brand awareness. Of course, we'd all just hop on that magic carpet.
Exactly. But in general, our style is just try to be really like as clear and direct as we can. That's really our focus for all our kind of marketing and so on. Just we think the value is there for folks. And if we can communicate that clearly, we don't need to get super marketing, super salesy. Just tell folks what's there.
Very cool. Adam, anything else from you?
Just to add on to what you're saying here, Jared, I think probably without digging into the data, I will hypothesize that probably the biggest challenge first is awareness that you exist. And then obviously once they realize you exist, the opportunity for superior feature sets exists. Then I would say that the very next thing is like, okay, now what?
Which is our requests for information on hypothetically what it would take to move, what it would take to go from a Slack or a Discord. I feel like if you could do content
around that subject not just documentation like how to but like good stories of folks who've moved and their journey and to demystify the scares and concerns like my main scare is is that a proper adjective i don't know i'll allow it is that or i guess anxiety point is is will we lose the people that we have in our community will they will they bounce you know if you can showcase the what's on the other side of the of the wall rather than me assume
As somebody who is not happily but happily using Slack, given the things we've already said, still like Slack. It's still amazing. It's just they've got warts for people like us, communities like us. I feel like that's the content I would personally, I would look at the data, and I think that would be the hypothesis.
Get awareness, show off the amazing feature set that really captures 80% of who likes you most, and then show how easy it is to move. And almost make it like, you should be doing this. Like, it should happen today. We can help you.
And if there's money to invest, in quotes, money to invest, could be time, could be people, could be people hours, is to guide and assist certain organizations on that path.
Yeah, and some of what you described, we do have case studies on our site where a lot of folks talk about starting initially with something else and then moving over to Zulip and sort of that experience. But part of what you said, you're kind of reading off of the to-do list I was working on yesterday. Just yesterday? Okay, cool.
Literally just yesterday, yeah, I was thinking, you know, we have some content in our help center about that migration path, but... We definitely need more clarity on just kind of bring all those pieces of information together and coming from different kinds of tools. Here are the steps you take. And just, yeah, folks are busy. There's a lot going on here.
To the extent that we can make that easier for people, it can make a big difference.
If I had to divide my time up into fifths, I'd take two-fifths of that time and dedicate it to that kind of content, if not more. Because fourths is like whatever, you know, like 25%, 25%. I mean, that's pretty easy, like one-fourth. I feel like two-fifths sounds better to me. Two-fifths of my time would be focused on awareness and showing off the better world, the FOMO. You're missing out.
Yeah.
On freedom, control, access, enjoyment. Privacy. And then obviously your dev team and engineering teams can be focused on all the surface area, Flutter, that migration, finishing out those applications, polishing the peripherals.
Your dev team does a great job on... documentation compared to what I've seen in a lot of projects. We see a lot of open source projects. The documentation is really good. The readmes are very deep and detailed and organized, thoughtful. And so obviously you want your dev team to be devving. That's what they're there for.
But as much as they can write about what you're doing technically, decision making, architectural stuff, not just in documentation form, but in content form, I think that would pay off dividends as well and obviously can also double as documentation in a certain way. Cool. What's next? Yeah, exactly.
What is next for you, the listener? Are you going to go to Zulip.com? Got the dot com. It's a big deal. It is a dot com. It is a big deal. It's a five-letter dot com. Free, open source, cloud, or self-host, unfettered. Do it today.
And if you think we should switch to Zulip, hop in our Slack and tell us. I'd be happy to at least try that Docker image. I mean, I'm going to give Adam a to-do, you know? See if you can get it running on Docker on your home lab or fly and just toy around with it and see how it feels. Try it on for size, you know? Yeah.
I mean, or if you want to just try a Zulip, it literally takes less than two minutes to create an organization Zulip cloud and then you can just poke around and experience it for yourself.
It's almost too easy, Adam. It's almost too easy. Yeah, I feel like we should try Cloud out first. And if we like how it feels... Take the next step.
Yeah.
That's half the battle, right? Because sometimes that switching of the UI and everything, it can be jarring. The ideas and the features that may be there, but maybe it feels weird. I don't know.
And then give us feedback. That's the other thing. If there's anything that feels off or feels confusing, just come by the development community and tell us and we'll try to fix it.
Well, very cool. Well, thank you for this time. Thank you for going through all the details with us. It was awesome.
Thank you for the great set of questions.
In a world where open source is eating software faster than software is eating the world, there's Zulip, the open source chat that has the potential to unseat the giants, to at least unseat the giants based upon features that really matter to users. And the thing is, is that they have so much potential. What exactly is potential? Potential is kinetic energy stored waiting to be released.
And after this conversation, I'm so hopeful for the team at Zulip. But at the same time, I know it's kinetic stored energy potential not realized. Now, there are a lot of people who love Zulip and there are a lot of people who don't even use Zulip or even know about Zulip. But now you do. So what are you going to do?
Well, I say go to Zulup.com, check it out, try it out, self-host it, use their cloud, contribute, be a part of the community, all the things that open source provides. Now, I, for one, am very hopeful and very happy Zulup exists. But Microsoft, Slack, Salesforce, they're massive. And so they need us to step in, to use, to try, to contribute all the things. Well, make sure you check them out.
Zulip.com. And all it was inspired by this conversation to create a brand new guide called Moving to Zulip. And that'll be linked up in the show notes for you. Okay. Sponsors for today. Big thanks to Century. Century.io. Use our code CHANGELOG to get three months, almost four months of the team plan for free. Again, Century.io. And the code is CHANGELOG. And also to our friends at Fly.
We love Fly. Fly.io. It is a platform where you can do pretty much anything. And Tigris is one example of that. Check them out at TigrisData.com. We're using it, and we love it. And to our friends at Paragon, UseParagon.com. All these SaaS integrations you need for your B2B SaaS. Again, useparagon.com. And to our friends over at Coder, coder.com. Cloud development uncompromised.
They're the number one self-hosted cloud development environment out there. I checked it out. I think it's so awesome what Coder can do. Check them out, coder.com. And of course, the beat freak in residence, Break Master Cylinder. Bringing those beats every single week. Much love, BMC. Much love. Okay, so no bonus today, but I do want to mention, because, hey, why not?
changelog.com slash plus plus. It's better. It is better. Today, it's not better because there's no bonus, but hey, other week's Other shows, bonuses galore for our plus plus subscribers. That is where you go to get the ad free version of our show. The way to directly support us to get closer to that cool change law metal, get bonus content. Not this week, but hey, you know, next week.
And I know because we recorded next week's show today and we have a very lengthy, very awesome bonus content for you. You'll love it if you're a subscriber. Once again, changelog.com slash plus plus. Okay, that's it. This show's done. Thank you for tuning in and we will see you on Friday.