The Changelog: Software Development, Open Source - Open source threaded team chat?! (Interview)

Episode Date: September 5, 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 zulu. 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. Sentry is all about this notion of debuggability 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. I-O. 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. You 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. 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 as 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 Hackweek 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 nights and weekends in his spare time. And Dropbox also very generously gave the trademark for Zulip to Tim as well. So at this point, there's no relationship between Zulip 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 was it 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 I think originally they had thought that they might build their own chat app. I know you probably 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 team,

the Zulip 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. And all the history. That's like kind of unheard of, wouldn't you say? And then 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 um we actually still have some of zulip's like 2013 beta customers using zulip today continuously so they still have all their chat history that like 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 hip chat and irc were around at the time exactly hip chat campfire remember campfire yeah yeah yeah yeah those were. That was a competitive landscape at the time. Yeah, totally. What was Zulip's big idea then? Why did it begin to exist in the first place versus just using HipChat, for instance? Totally, yeah. So the big innovation in Zulip 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 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 goes across time. So 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 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, you know both both ways uh okay work

and what differentiates a channel from a topic is it merely the 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 and then inside there they're just chronological but then you can kind of like drill down in threads and stuff and I'm just trying to understand, are there actual data differences between a channel and a topic, or just where they exist inside of the hierarchy? The channel is very similar to channels

in other apps. 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, it's just kind of another level of structure.

And 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 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 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 kind of 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. I suppose if you really wanted just like a general chat reorganize things if things do end up in the wrong places like we 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 Yeah, you totally could absolutely, yeah. 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. Definitely. That's the biggest struggle.

Yeah, and the thinking is really that people are, I mean, 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 ingesting content and so if that process is really smooth and seamless and feels 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. Pretty accurate? Pretty accurate. Okay, cool. Because sometimes homepages get out of date, you know? They have a live demo there. 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 how 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. 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 model. Yeah, I mean, 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. People tell us, sometimes I have to go back to Slack to talk to my customers and it's just so chaotic and it's just so chaotic. And just having experienced the level of organization within Zulip, 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 yeah i'm not signed in so i can't see how like 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, organize topics, because you can, you know? 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

because kind of like 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 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- generally to my knowledge i mean i haven't been on a forum in 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 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 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 the sort of feel like oh i you know somebody sent a message i have to respond right now otherwise nobody's gonna like it's gonna be messy it's gonna be confusing i'm not gonna 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. It is. 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 uh 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 the Slack and then it's gone now. Yeah, I don't know. Do you know much about that, Alia? What the current state of Slack's... I imagine you're probably leveraging it in some way 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 was really, it was framed as kind of a positive,

but what we saw is a huge influx of folks, communities, who can't afford something like paying for a pro plan on Slack, leaving Slack and importing their data and moving to Zulub. 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 Zulub.

We really try to enable folks to benefit from our software. So we do sponsor free Zulip Cloud Standard plans for folks. We have, 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. And as much as we can, you know, 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 like 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. As if it is as ago. The 28th. Yeah. So as of this recording, 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. You know, we want our...

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 part of something i'm not but there's relationships and business there's partners were 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, you know? 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 like not 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. 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 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 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, et cetera. 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, their friend's business, when they go to ask them for a recommendation to Zulip, you know, their, their friends 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, because 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 it's a big advantage when it comes to getting people to use the tool as 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 saying, oh, I used it in, we asked 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 like 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 signups. 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 in GitHub. And we just have these like 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's 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 in 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 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 zulipip 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 Android and iOS apps and we're actually currently in the process of re-rating 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 Zulip 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... 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'd be like we 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 the 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. 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 wire guard, 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 prebuilt 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... 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.

Your employee's 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. 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 products that could 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 get folks to consider and evaluate our product and to take that time and attention away from so many other things that they need to be doing to really think about this choice in a very 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 don't

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 zolop name isn't as polished as maybe microsoft obviously you know that's that's the that's the hard part is that you kind of have to win them with showing up you know with the the open source-ness 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 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 entrance. 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 to 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. 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 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 like one person said used it at a different company liked it a lot it's like it's kind of like slack the higher-ups replaced it with teams as Zulip wasn't quote auditable so that was it 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. 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 know it's like I guess folks have their own priorities and I don't want to like second guess the management 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 so it's just where that perspective of like your team's efficiency and how happy they are with the software

they have to use you know every day like I don't know anybody who likes Teams I know lots of people that use it

I'm not a Microsoft hater anymore I used to be when I was a younger man but I will say that I don't know anybody who says, like, Microsoft Teams? That's good software right there. We love it. No one says that.

Has anyone ever said that to you, Adam? 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 i've signed in i've joined some discords it seems like a hot mess to me but it's very big in like 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. Do you have a lot of, do you ever have to compete with Discord? Do you ever have to explain Zulip in light of Discord and how you all differentiate from them?

So it depends. 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 their 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 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 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 that, 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 kinds 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. 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 it's helpful for preventing spam. Yeah. 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 meeting that person and that just hides hides all their stuff um for you um so you never have to like interact with it it would be cool if you could auto block new users if they start a message with dear sir slash madam you know auto block sorry right right about i guess yeah some Autoblock, sorry. Right of 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. 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 Slack into Zulub? Just for instance. Yeah sure. Just for instance. As a random example.

Hypothetically speaking. Yeah yeah 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 all your,

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 Zulip-native integrations, then you can do that, but things would be working for you right away. So yeah, and you and you can 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 Google account or GitHub or anything like that, that's also on offer.

It's 90% of my anxiety, if we're hypothetically speaking about things. Yes, we are. I feel like I've been in this waiting pattern in my own brain. I haven't taken any action. 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 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 ever moved to something else, how much would we lose? How hard would it be to get even our active people to stay involved? Right, like would they come with us and would they continue to hang out? Or they'd be like, Zulip? What? Why? Yeah, I mean, 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 community engagement because it works quite nicely for folks

who are not around all the time. So, I mean, in the one kind of category, folks, as you were saying, is there 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 catch up on what you missed

if you're checking in every couple of weeks or every month in an active organization. Whereas for Zulub, if you just want to 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 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 make everything be marked as red or manage your own reds necessarily if it's just something where you're not following every little detail. You really can just skim that list of what's been going on and jump into the ones that are of interest.

And so, yeah, so we've had folks say that, you know, 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 um there's an overall organization setting for whether you will you want to have public channels as an option so for example you know many 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 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 archive of all the messages. But it's actually kind of a major technical the reason is 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 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 would be pretty cool for public ones, because then it would double as an indexable forum. Because a lot of those conversations become kind of canonical resources, or they could be,

but they are lost to the ether. 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, let's 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, you know, 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, Alia, 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 do that for yourself. One less 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 Zulup 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 how you need to do everything um so should be very doable for you if that's something that that you enjoy yeah you just have a docker image yes uh sorry this is not the part that i personally work on nearly as much as some other things um all good. But yes.

You hear that, Adam? They got a Docker image. Okay. 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 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 there's nothing that we're like locking away from from self-hosters if you self-host this is the one thing that so we do offer paid plans for self-hosters um you don't have to sign up for one but they're an offer and um the kind of two two things that two major things that we're providing with those paid plans so one is mobile push notifications so the way that app store policies work both on android and ios is that if you have a mobile app which are apps are 100 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 the Zulub mobile apps,

what you do is basically balance 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 Zulub 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. It's on your Zulip org on GitHub. It's docker-zulip. So I assume this is official. It's container configurations,zulip. So I assume this is official. It's container configurations, images, etc. for all of it. There's a Docker Compose 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. And you're just a Docker Compose up away from running Zulip 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 backend. 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 that URL for your server and you're good. Wham, bam. What do you think, Adam? You want to Dockerize us? 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, 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, but how does like your iOS Android app work with a self-hosted scenario? Do you point it at like a URL kind of thing like if I was yeah exactly asked and answered 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 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? 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.

The ping, the latency, Gerhard may have opinions about it, that's for sure. It's just chat. 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-gapped on a ship 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? Yeah. 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. 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. not very useful that way but you can 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 like 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-n 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, Jared? 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 2E-like, Jared. Obviously. It's an application. I do like Tuili's. 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? Yeah, Zoop is one of the first kind of major projects to be using MyPy static typing in Python. So we're engineers, we're 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.

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, 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 an 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 Zulub. 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 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 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 positive experience, great learning experience for folks. So for example, with a team of

on the order of like 15 paid team members, we had 124 people contribute to our last major release. So that's like around 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 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. We have generally 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. But Zulip is open source, not just in the sense of 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. 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. He was thinking that when we were giving him feedback on things he was working on, maybe we're somewhere off on the side discussing that amongst ourselves

and then providing the summary version. He was like, oh, wait, no, that's not how it works. I was like, no, no, no, yeah. If we're talking about how the product should work, we just talk about that in the open. That way everybody can understand the decisions, can contribute to the decisions. We're not hierarchical in terms of

it's really about what your ideas are and how clearly you communicate them and explain to them, not what your title is or how long you've been involved with Zulip or anything like that. It's really about working together to come to the best decision we can about how something

should work. Let me know if I didn't quite answer everything, all the parts of your question. Has she answered your question, Jared? 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. Yeah. 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 a misalignment, kind of an inherent misalignment of incentives. So for us, we're

not going to take a hundred swings at this. We're not going to try to build a hundred 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 you know, as I mentioned, like we still have users from 2013 who are on Zulu 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, of success without necessarily aiming for that like galactic outsize return.

Right. We just, you know, their main priority is really to get to a point where the software, we have enough, you know, we're making 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 are we're 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 would your tune change well i think it's not just about open source like i i think there are now starting to be vc firms that are focused on open source and and really buy into that model but it's also just kind of the the structure of how and 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 uh the return on 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 you know i'm not'm not, like, I'm not going to tell you 100% never in the next 100 years we'll take VC money. Whatever. We're a small company, right? Like we do to some extent, like kind of like make decisions about things when we need to make them,

not, you know, planning things for 50 years ahead. But just that has been our kind of strategy so far. And from, we have not seen, 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. And 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 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 to the 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, the sort of how do we increase that reach and grow faster in terms of finding different ways to introduce folks to Zulop and to reach more people. So it's definitely a major priority for us right now.

Yeah, that has to be one of your biggest challenges is like nine out of 10 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. I like the free for open source education, et cetera, that you already discussed. What are some of your other ideas? What are some of the 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 that way. Another direction is content. We've had blog posts on various topics. One of the things that I talked to you, you can probably see my excitement about is this side of community management

and getting folks engaged in an open source project so uh for example like we're working on some partnering with some organizations on blog posts around that kind of thing and so just kind of getting the name out there in whatever way um because i think you know the as you were saying kind of the brand recognition and just kind of awareness matters. People aren't 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. I would say we don't necessarily have

something unique other than we do have this open source angle and things engaging with the community and the open source community we do have this open source angle and so things engage in the 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, that 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. Yeah.

Yeah, tell folks what's there. Very cool. Adam, anything else from you? Just to add on to what you're saying here, 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 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 bounce? If you can showcase what's on the other side 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 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 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 bring all those pieces of information together and like coming from different kinds of tools here

here are the steps you take and just yeah like folks have a lot folks are busy there's a lot going on here you know the extent that we can make that easier for for people like 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. Uh-huh. If not more. Uh-huh. Because fourths is like whatever, you know, like 25%, 25%. I mean, that's pretty easy.

Like one-fourth? Yeah. 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,'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. What's next? Yeah, exactly. What is next for you, exactly. What is next?

What's next? For you, the listener, are you going to go to Zulip.com? Got the.com. It's a big deal. It is a.com. Yeah.

It is a big deal. It's a five-letter.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. We'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 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. 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. 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 Zolot, 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 Zulip.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. 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 Zulip 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 CHANGELOCK to get three months, almost four months of the team plan for free. Again, Sentry.io and the code is CHANGELOG. And also to our friends at Fly.

We love Fly. Fly.io It is the 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, cause 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 weeks, 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 Outro Music