tabbott

Slack and all its clones are based on the chat room model, which structurally has the problem described in this article (and many others for productivity, such as wasting attention). Fundamentally, the chatroom model pioneered by IRC is poor for asynchronous communication because you can't sustain temporally overlapping conversations in a channel.

However, you can't "just use email" -- Email's threading model is great for asynchronous work, but it is poor for synchronous communication and also doesn't support modern features that make it easier to communicate ideas efficiently (shared history, markdown formatting, image previews, emoji reactions, etc.). It's essential to be able to have (semi)synchronous written conversations with people you're working with, especially if you don't want to spend your days burning out on video calls.

This is why we created Zulip -- it's designed as a real-time communication tool with email's threading model and all the nice features of modern chat apps that email lacks. And the reading user experience is actually a lot better than email, because Zulip provides is designed with the goal of saving time when prioritizing, skimming, reading, and replying to conversations. It's also 100% open source software (not open core!).

Yeah, this was my reaction as well. The reason I found Caliphate interesting was not the details of Chaudhry's story, which I experienced as were portrayed as dubious and in need of verification throughout; I certainly finished the podcast feeling uncertain whether Chaudhry had actually done any of the things he claimed.

Instead, the reason I've recommended this podcast to friends is that it spends most of its time on a fascinating exploration of the journalistic process. How does reporter verify claims made by people about events in a war zone? The people you interview have a reason to lie to you, sneaking across borders doesn't generate passport stamps, and reliable records are hard to come by.

This latest news feels like an interesting addendum to all that; I'd have expected any other podcast publisher to do an additional episode or two covering the new evidence and grappling with what that changes about the conclusions one can draw (certainly Serial has done a number of updates on new evidence about its past stories).

That said, my sense is that the NYT is taking this extreme action in part because they in retrospect are unhappy with the fact-checking process for the podcast, and I could see that sort of concern motivating this type of retraction/disowning despite all the uncertainty the podcast itself presented.

Zulip's founder here. (I should write a blog post on this topic.)

The structural reason is that we're intentionally not taking VC funding, which does more or less inevitable lead to that outcome.

Less structural but just as important is that my personal priority is in creating great open source software for the world, not personal enrichment.

This thread may be useful: https://news.ycombinator.com/item?id=23105031.

Can you share what server this was (here or in chat.zulip.org)? Essentially every bit of feedback we get on performance is that Zulip is much snappier than Slack.

Given that you mention a big public server, it's likely caused by an issue specifically related to that server's scale/usage patterns, and I'd like to make sure we investigate it.

Zulip as a company is extremely different a massively-VC-funded-and-then-go-public company like Slack:

* 100% of the software we write is FOSS.

* We intentionally haven't taken VC funding despite plenty of opportunity to do so, to ensure we can remain an independent, values-focused company.

* Most features are built by our open source community, not fulltime employees.

* Zulip was a distributed company pre-pandemic (while we did have a SF coworking space walking distance from my home, I as the founder only went in about once every week or two, and essentially all collaboration was over Zulip or GitHub).

I don't think it's possible for this sort of individual, opt-in action to be material to the climate problem; problems at this scale can only be solved by government action. If Stripe raises $30M/year from this program, it'd be like 10000x too little to be significant to our carbon problem. (Maybe it could have some minor R&D acceleration impact for the carbon removal techniques they're looking at).

The root cause of our climate problem is the fossil fuel industry having successfully manipulated the government and public to prevent real action on climate change, for decades. The Drilled podcast is a good resource for primary source material on how oil companies systematically manufactured climate change denial.

I would prefer that Stripe allocate the funds to groups working to counter the fossil fuel industry's misinformation strategy. $30M/year would be a significant budget for that sort of work.

Right, lobbying is super valuable for a company whose business is in a legally questionable position on the boundary of the highly regulated banking industry.

This "apolitical" move would be a compelling choice if their only goal was optimizing shareholder value -- it's in their interest to maximize their ability to effectively lobby both American political parties to ensure any future cryptocurrency regulations benefit them.

Remember that this is a press release, not independent journalism. This press release tries hard to position it as "people left because of the severance was really good" because that narrative is in Coinbase's interest. That may be true, but it's also possible most of 60 people quit through this program because they were upset about it.

In an ideal world a reporter could answer your question by talking to many of the people who quit and ask what motivated their decision, but the severance package almost certainly came with an NDA that would make doing so impossible.

So we'll likely never know. Probably one should assume that the answer doesn't look great for Coinbase's narrative; if they thought it would, they might have done a survey and published data from it.

I've been using the Altwork (https://altwork.com/) desk for this purpose since January, and I'd recommend it to anyone who wants this sort of thing. It was expensive (~$7K), but I needed it due to a medical condition that makes extended sitting difficult for me, and it's made a big difference in my ability to work despite this condition.

The workstation is awesome technology; it's really well built, nicely runs wires everywhere, etc. My only complaint is that the headrest is too hard to be lying down on it for hours at a time -- I fixed that by putting an old sweater between my head and the headrest, which made it perfectly comfortable for me. One thing that might not be obvious is that it takes up surprisingly little space -- something like 4' x 6'.

Talking to them about the delivery, a lot of their customers are other folks with medical reasons to want it, because I think that's what justifies the price point for people. But the price will come down with scale (there's already a $4K model: https://altwork.com/products/flex-altwork-station?variant=34...). And at that price point, the price is immaterial compared to software salaries, at least if you think about it as a capital item that will amortize over many years.

They have magnet stickers you attach to the back of any keyboard (or mouse) and it'll work. My keyboard is kinda heavy so it needed like 10 magnets attached to it, but it's completely stable.

That said, for lying down, you really want a trackball mouse (the alternative is to dock the mouse when not in use, which is OK if you mostly use the keyboard for everything).

I attended TJHSST from 1999-2003. TJ does have a serious diversity program, but I think it's important that readers understand just how special TJ was.

Because of TJ, I became a top participant in some America's most prestigious high school academic programs (USAMO, USACO, USAPHO, etc.). Through those programs, my family met incredibly successful students from all over the country. What shocked my parents was how parents of these other top students had to do a ton of work to get their child a challenging education -- usually a mix of homeschooling, driving them to classes at the local college, working the system, scouring the early Internet for resources/summer camps/etc. These other parents (and their kids) envied our experience, because they'd worked incredibly hard to get an education experience worse than what we'd gotten from our county's public education system. (And it wasn't just TJ -- the high school I'd have gone to were I not admitted to TJ was also one of the best in the country).

TJ's education was why I was able to test out of or otherwise skip more than 10 MIT classes -- more than a full year -- because I'd taken a version of those classes in high school. (Of course not every TJ student took differential equations and complex analysis in high school -- there were maybe 20 of us each year -- but where else is that possible?). AFAIK no other high school had (student organized!) after-school gatherings for 10 hours every single week to learn from each other solving interesting math/cs/physics problems, and still take the school bus home? Most importantly, it provided me with a community of intellectually curious students similar to what I found at MIT. When I think back on all my major successes in life, whether attending MIT, my published academic research, 3 startups... likely none of that would have happened without TJ and its student community.

The worst part about this is that TJ's diversity was severely damaged by legal challenges back in ~1998. What was missed in his discussion is that TJ didn't just have affirmation action -- there was also this great program called Visions [1], where TJ teachers would teach middle school students from under-represented backgrounds on the weekend, a key function of which was to provide the support and encouragement for strong students from those backgrounds who could get into TJ to apply.

I don't remember the precise numbers, but every year starting with my class of 2003 had something like 2-3x fewer Black students than the few classes before that. TJ admissions published statistics that made clear the school was doing affirmative action (100% of Black students who made the "top 800" test-based cut were admitted to the class of 400), so affirmative action was still in effect. But the end of the Visions program meant many fewer qualified Black students were applying.

Virginia needs to fix TJ's diversity, but thinking about "TJ admissions" as a problem in isolation is ineffective (and it has been tried many times before with TJ specifically, including admissions changes motivated by improving diversity that actually made the numbers worse). I'm not close enough to the facts around TJ today to make specific proposals, but I think any overall plan should feature programs like Visions intended to market TJ to students (and parents!) from underserved backgrounds who would thrive at TJ but aren't currently applying.

Folks who care about diversity at the high end of American education should consider donating to BEAM: (https://www.beammath.org/; [2] in an nytimes article on it). It's an exceptional program to help underserved students access an intellectual community of fellow mathematics lovers, with impressive results. (Disclosure: the founder is a friend from MIT, whose decision to devote his career to this cause inspires me).

[1] https://www.educationnext.org/stubborn-excellence-gap-despit...

[2] https://www.nytimes.com/2017/02/17/nyregion/new-york-math-ca...

I agree Django's migration system has a few unfortunate quirks (most notably the help-text-change-migrations), but it's also worked great for Zulip across over 300 database migrations, and I wouldn't recommend anyone do their own migration framework on raw SQL files by hand.

The issues mentioned here in this article are real (E.g. we have a lint rule blocking importing other code inside migration files), but the author is also ignoring the benefits of Django's system, namely that it's a well-documented system that does most of the work of managing migrations for you, and does a good enough job that the vast majority of developers working on a large software project (like Zulip, with 96 people who've contributed changes to database migrations) will do it correctly without special training just from the Django documentation.

And the downsides are certainly minor compared to the obvious downsides with rolling one's own system with raw SQL (E.g. the fact that nothing validates that the model definitions match the database schema in the author's proposal!). I wouldn't recommend anyone take the author's advice for what to do instead, but this article is helpful reading for anyone curious about what issues one will encounter after a few years working with Django.

> How many times have you worked on a project and, after 1-2 years of development, you have changed to a different database?

FWIW, Zulip was originally developed with MySQL, and then about a year into developed we switched to Postgres. It also had a phase where we ran SQLite in development environments. Building on Django made our life a lot easier doing this.

> Once the migrations have been applied to all your testing and production systems, and all your developers' databases, just remove them.

This is only true if you don't care about being able to use tools like `git bisect` where you might want to switch a development environment to older versions and back again (I do this often as part of).

> If you do it in a loop, it results in a "ripple load", meaning you'll run 50 queries, each one fetching one record, while you could have run a single query fetching 50 records, or just adding an extra JOIN to another query.

This is my biggest complaint about Django's ORM -- lazy fetching of foreign keys is great in a management shell but rarely desirable in production, and it results in inexperienced developers doing database queries in loops all the time. We address this with a bit of middleware that formats log lines like this e.g. `41ms (db: 10ms/2q)` (showing how much time was spend doing database queries and how many queries were done) -- which lets one easily identify problematic cases of this both in development and in production.

But if Django had a setting that just disables the lazy fetching of foreign keys feature (making accessing an unfetched foreign key an error), I'd turn it on for Zulip.

See also https://zulip.readthedocs.io/en/latest/subsystems/schema-mig....

We've been using semgrep for Zulip's python codebase for the last few months; here's our configuration:

https://github.com/zulip/zulip/blob/master/tools/semgrep.yml

I really appreciate the semantic checks. They're especially nice for security-sensitive lint rules, but really it removes the hacky regular expressions feel of adding lint rules to a codebase. It's also been useful for some codebase migrations (semgrep is more precise than e.g. `git grep -w` for finding "All the places we use code pattern X that we want to stop doing").

My main complaint about it is performance -- it's too slow per unit rule for us to replace the regular expression based system that we run on our whole codebase (so we can't happily convert our other ~100 regular expression-based lint rules to semgrep (https://github.com/zulip/zulip/blob/master/tools/linter_lib/...).

But performance has been improving a lot over time, and I think there's potential for it to be faster (E.g. mypy, the Python type-checker, has gotten way way faster in the last year or two). Because semgrep is getting active investment from a venture-funded company that I imagine will improve the performance, I expect semgrep to be a tool that most projects serious about code quality are using in a few years.

I should add that performance may also be less important to others than it is to us; we run all of our linters (currently 20 distinct linters, including eslint, prettier, pyflakes, isort, shellcheck, etc.) in parallel using https://github.com/zulip/zulint, with the goal of being able to lint the entire codebase in <30s or changed files in under 1s (obviously time depends on number of files changed).

I run an open source team chat product (Zulip) and I have no love for Slack (https://zulip.com/why-zulip/). But I also think Microsoft's behavior in the team chat market is definitely anticompetitive.

* Many businesses have purchasing rules that discourage buying 2 duplicate products -- so by bundling a bad team chat product with Office 365, they significantly reduce Slack's ability to get paying customers simply because of their monopoly position (not because of their product's quality).

* Microsoft is in a market position where they can effectively bribe potential customers with discounts on other services they sell (E.g. we'll add another $250K in Azure credits if you agree to go all Microsoft).

> You're going to get eaten, and there's not much you can do about it now.

This I agree with -- but the reason is that we're in a world of essentially unconstrained monopolistic tech giants, and it's basically impossible to stop a tech giant 100 times your size from taking your market if they really focus on doing so. And Microsoft is clearly very focused on the team chat market.

There are very few markets where it's possible to create a moat that can resist a monopolist copying your product (however badly) and then making the price of their copy zero (or negative!). I don't think we should accept a world where the only long-term outcomes for a fast-growing technology company are to be acquired or destroyed by a tech monopoly.

> Something any fifteen year old can write with web sockets

This is a common misconception. While you can make "chat" as a demo with any web framework, nobody would willingly use that tool. Creating a team chat user experience that isn't terrible requires a huge amount of work because there are hundreds of features that significantly improve important workflows for large classes of people (if you don't believe me that it's hundreds, read https://zulip.readthedocs.io/en/latest/overview/changelog.ht... and https://github.com/zulip/zulip/issues?q=is%3Aissue+is%3Aopen...).

We don't at present have an official policy on it, but we'd certainly be open to creating one. (And of course one can always self-host).

What is Slack's adjusted pricing in India/Asia? I don't see it advertised on their website.

FWIW we have been seeing a lot of larger communities that previously were deadset on Slack because "everyone knows it" importing their data from Slack in the last few months.

Part of the reason is that Zulip's topics make it a lot easier for a part-time participant to use their limited time well (E.g. skimming or reading the conversations in most relevant to them in batch a few times a week). The Slack/Discord/IRC/etc. data model limits how effectively one can participate and benefit from a high-traffic organization without constantly watching it (and being in the organization's dominant time zone!).

More on the inclusivity issues with synchronous chat here:

https://zulip.com/for/open-source/

Thanks for the kind words!

One of our goals as a project is to have a "teaching-quality" codebase, so this is no surprise. I think this is incredibly important and something every community open source project should strive for.

An analogy I like to use is to think about the experience of contributing to your open source project as a product, so you should:

* Do usability studies where you help a group of people try to get started with your product (I used to do this all the time at events like Python conference sprints pre-pandemic). The first few we did were eye-opening as nobody got anywhere without a lot of handholding, and I suspect that's common.

* Make the development environment tooling Just Work and have a good support experience.

* Write good documentation that thoughtfully explains the ideas one needs to understand to participate on your project. My strategy for this was to avoid explaining how things work to a contributor, and instead meet the need by spending a couple hours writing something like https://zulip.readthedocs.io/en/latest/subsystems/sending-me... and send it to them. That way, even if that contributor bounces (as the vast majority of new people who show up to any volunteer organization do), I still used my time well.

I'm planning a series of blog posts on building a successful open source community, since we've spent a lot of time thinking about how to make contributing to Zulip a great experience, and some ideas are subtle (E.g. the secret to being able to give high quality code reviews is equipping new contributors with the tooling and documentation to help them avoid problems before a reviewer even looks at it!), and I regret not having spent more time sharing that thinking.

A big benefit of the organization provided by every message being in a topic is that it makes finding this more efficient. E.g. if you remember that Steve made a joke about donuts in the conversation, you can search for messages sent by Steve mentioning donuts, find the topic, and from there find the actual conversation. I do this to find months-old or years-old conversations several times a week.

If you're curious to hear more, https://monadical.com/posts/how-to-make-remote-work-part-two... talks about this idea in more detail.

I also highly recommend making use of Zulip permalinks to conversations in issue trackers and other resources -- my anecdotal sense is most projects using Zulip do that a lot (the Zulip development team certainly does). Certainly the main feedback we've gotten on the zulip.com domain transition is "Will my permalinks keep working???". (Yes, they will).

Also, new in this release: BigBlueButton (another OSS video/call project).

This release removes Google Hangouts support (as Google killed it and rebranded it to Google Meet). Unfortunately, the Google Meet rebrand came with removing the API that was useful for third party tools like Zulip. I don't understand why they don't provide the brilliant API Jitsi has where you can just generate a URL containing a random meeting ID and everyone who clicks it gets the same meeting (which Google Hangouts did, at least if everyone was in the same G Suite team).

We also support Zoom (though note that Zulip Cloud is stuck in their marketplace approval process as it has been for months; supposedly it'll get approved any day now).

https://zulip.com/help/start-a-call

(And of course we're happy to integrate anything else that has a reasonable API)

I notice you mention a pixel phone; are you by any change using mobile Chrome? I think this is https://github.com/zulip/zulip/issues/14943, which sadly didn't get fixed for this release but is being worked on.

Generally Zulip's scrolling and view-switching is very smooth and a ton of work has gone into it (my view is that if an app that you use all day isn't snappy it's going to waste tons of your time).

The short answer for how to make good scrolling performance (like any other performance work, really) is to profile, make sure you understand what's happening, and fix it. It can be hard to predict what makes things slow without doing so. (Fun fact: seemingly reasonable ways to use an emoji spritesheet with CSS can wreck scrolling performance).

> yes, this is self-hosted. I can't check the version, but I think it was recently updated

Well, 3.0 comes out tomorrow (hopefully) so your administrators may want to upgrade once it does :).

> the "drafts" feature took me a year to discover. Sadly, messages were recomposed

Yes, we're planning to add an onboarding notice the first time a draft is saved to avoid this failure mode :).

> notification emails in non-html mode don't carry over the bold, not even in the form of asterisks, so it all blends in with multiple messages

Oh, interesting. Non-HTML emails are hard to do much good with; if you have specific ideas for what we could change to make that better, let us know: https://github.com/zulip/zulip/issues/new

- thanks for fixing the collapsing bug, I'll see how my opinion on the composing workflow changes

Happy to! We generally fix any easy bug as soon as it's reported as a general practice, since users can really tell how buggy a product is, so hopefully this will encourage you to report more :).

> Point in time backups isn't trivial either

Have you tried our built-in backups tool? See https://zulip.readthedocs.io/en/latest/production/export-and...

> How do I connect to existing databases?

It's straightforward in the inline configuration file, see https://github.com/zulip/zulip/blob/master/zproject/prod_set...

There's more detailed documentation available here:

https://zulip.readthedocs.io/en/latest/production/deployment...

We only store transient cache-type state in memcached/redis/rabbitmq, but they have similar configuration options.

> How do I store this in an existing configuration management system?

Our intent is that you configure /etc/zulip using your configuration management system and then use the Zulip installer to install the Zulip software (and it'll configure the services you've configured it to manage accordingly). Our puppet rules are intentionally written to allow only running the application frontend role on a system (as we do in our own production systems).

> You'd better run in on the recommended Ubuntu version, any deviations will cause the above procedure to explode into a ball of mud.

We support all Debian releases and Ubuntu LTS releases in production (which are the only ones worth supporting given that their-non LTS releases are only supported by Ubuntu itself for a few months and thus are structurally long-lived betas). And we're working on CentOS/RHEL support.

I'd love to collaborate on how we can improve Zulip's documentation around your use case. Would you be up for stopping by chat.zulip.org to discuss specific changes?

Our 3.0 release, coming out in a few days, has some major design improvements. Visual design continues to be a major focus area for us.

-Zulip lead developer

I'd be curious to hear more about these concerns, because they're largely not things others have reported. Would you be up for dropping by chat.zulip.org to provide more detail? A few initial thoughts:

* Notification emails for PMs don't include the sender in the body at all. Those that do have the sender bolded on a line by itself. So I am not sure what you're referring to here. Maybe you're using a self-hosted server running an old version? We did a total redesign of missed-message emails in 2019. * When closing the compose area, Zulip saves message content in the "drafts" feature, so one never loses partially composed work: https://zulipchat.com/help/view-and-edit-your-message-drafts. * I was able to reproduce the uncollapsing bug as https://github.com/zulip/zulip/issues/15808, and fixed it a couple minutes later. Thanks for the report! * The issues around CPU load, reloading and server issues are probably best discussed interactively, since I'd like to see browser profiles for your situation and understand if you're using a self-hosted server that might be underprovisioned, which seems a bit much to work out on a HN thread :)

-Zulip lead developer

As other folks have mentioned, Zulip has a number of cross-server integrations with both the Zulip protocol and other protocols like XMPP. There's a few we document here as well as Matterbridge:

* https://zulipchat.com/integrations/communication * https://github.com/42wim/matterbridge

We'll eventually add a more native way of connecting a stream between two Zulip servers; we just want to be sure we do that right; federation done sloppily is asking for a lot of spam/abuse problems down the line.

(I'm the Zulip lead developer)

The author did a really good job of articulating why I've spent the last several years working on Zulip despite there being a thousand Slack clones to choose from.

Asynchronous communication is essential to being able to focus, at least if you do enough communication that it matters how you communicate. And it's very inefficient to do asynchronous communication at scale in Slack or any of its copycats. This leads to the Slack cultural issues detailed in the post; they're the result of people working around the bad core workflow of a beautiful, masterfully marketed tool.

Consider "Everybody expects an immediate response" culture. In my view, that is people adapting to it being unpleasant to be a busy person waiting for a reply in a Slack channel. (Which is because it's miserable to make sure you don't miss things in busy slack channel, so everyone does, so anyone who wants to be sure of a response spams PMs and mentions and otherwise applies pressure to get a reply now now now so that they can mentally move on to their next task).

Zulip aims to make asynchronous communication so efficient that such adaptations are unnecessary. The core innovation is that all messages in channels are organized within "topics", which work exactly like the Subject field in email. This model works great for enabling asynchronous communication in email, and it works even better in Zulip (mainly because of topic editing and linking features).

The main goal of Zulip's interaction design is to make skimming hundreds or thousands of Zulip messages (and replying thoughtfully to the ones where you can add something!) pleasant. This enables a better way of working. Personally, I read and respond to 500-1000 Zulip messages sent by dozens of people across 50+ topics every single day, and I get compliments on how responsive I am, despite the fact that I do focus work in multi-hour blocks most days, Zulip's development community is all over the world, and I lose hours of productive time every day due to a chronic illness. This wouldn't be possible with Slack.

And this isn't just my experience; I've heard from so many people in organizations that switched to Zulip that they love how Zulip makes better use of the limited time they have (whether busy managers at companies or participants in part-time communities).

> "You'll lose your history"

This is the other major bundle of problems that Zulip's topics solve. Zulip can be a valuable knowledge store because of the organization provided by topics (combined with features like permanent links and topic-powered search workflows).

Zulip is 100% open source software (Not open core! We're intentionally not VC-backed so that we can prioritize our values; see https://news.ycombinator.com/item?id=23102430). And we sponsor free hosting on zulip.com for open source projects, academic research, and other non-commercial organizations.

> How much power do the VCs typically have?

I think it's less about the power relationship, exactly, and more about the way VC-funded companies are setup to be run. As part of raising a round, you prepare a business plan that involves aggressively spending the money over a couple years. You're committed both internally and to your board to execute that plan, and it's cognitively difficult to do something different as there's social pressure to do so (and one of your VC's greatest sources of power over you is they're the reference for your next fundraising round).

The result is that your company has planned to run out of money with potentially a multi-million dollar annual burn rate in two years. If as those two years are approaching, the company and/or market situation don't support raising more capital and the company isn't close to profitable, the momentum of that burn rate applies a great deal of pressure for a sale, destructive layoff, or total change in goals to "anything that improves the bottom line".

Also, the search for a story to help raise your next round can have a big effect on companies -- my view is most of Dropbox's problems when I was there (2012-2014) resulted from the search for a totally new business bigger than Dropbox Business that could justify a bigger valuation than $10B starving more obvious investments (Carousel, the now-dead photo sharing app, at one point had ~10x the engineering resources of Dropbox Business).

> Reading about Zulip - didn't you get bought by Dropbox before being open source? Is your current situation a lucky outcome - or was it a condition of the sale?

It's an extremely lucky outcome. There's a combination of factor that made this possible:

* Dropbox leadership prioritized doing the right thing by their users, and so we were able to get permission from both leadership and legal. I'm sure my personal position as a leader at the company who had a personal relationship with the people who had approve it made a difference (Though Luke Faraone made a big difference by asking legal if we could and inviting me to the meeting!). But I think Dropbox deserves a lot of credit, because they spend significant time from expensive resources (legal, etc.) making this happen, and I don't know of many companies that would ever do that. * Our users were big fans, enough so that 10 of them flew to Dropbox HQ for a week to help us do the technical work required to do an open source release with all 10,000 commits of history intact and with a scripted installation process. This was essential to Zulip being usable after that release.

https://zulipchat.com/history/ has a bit more background on the early history (though it's a bit out of date).

Losing their independence was from the beginning the most likely outcome of building something that's hard to monetize like Keybase on the VC funding model. FWIW, I doubt Keybase offering a paid plan would have raised revenue that's significant compared to their burn, so Chris was probably right to not spend resources figuring out a paid offering. For raising their next round, having $5K in revenue from a paid plan few people buy might well have been worse than having $0.

The VC funding model is terrible for most open source projects. With a few exceptions, you end up with an acquisition that ends or repurposes the project, or an Open Core project. And a VC-funded Open Core project will end up trying as hard as it can to have everyone need to buy the paid version, since that's clearly the way to optimize revenue and eventually the slippery slope will get you there. I don't blame folks for taking VC; it was easy to get, and there aren't a lot of alternative funding models that can pay the multiple fulltime staff that might be required to create what one wants to create.

I don't think VC funding as it currently exists is consistent with running an open source company according to my values, which is why we're not taking venture funding for Zulip. Obviously, being scrappy, applying for NSF grants, and spending my own money have very real downsides both personally and for our growth, especially when every competitor has VC funding, but it also means that I can ensure Zulip continues existing as a real open source project for the long run.

Just to be clear, Zulip is not Open Core. We are 100% open source software, in contrast with Mattermost, GitLab, and many (most?) other VC-funded applications marketed as "open source".

I think this is a really important distinction; the VC-funded open core business model has a fundamental incentive structure that pushes the company to makes its open source project an intentionally crippled demo product so that they don't miss any revenue they might have had as a proprietary product.

Disclosure: I run Zulip, a Mattermost competitor that has intentionally avoided taking venture funding in part because we don't want to be forced by investors to be Open Core.

Venture-funded Open Core software like Mattermost is an awkward place for the terminology. The free version is distributed under an open source license, as so there is a thing that is "open source", but the clear intent of Open Core licensing policies is primarily to achieve the goals of: (1) Being able to market the software as open source. (2) Maximizing the portion of users who buy the paid/proprietary version.

While in theory open core can be run responsibly, the incentive structure is to intentionally not include features important for typical use cases in the "open source" version of the software that any similar community-driven open source project would have considered an essential, early feature.

FOSS means different things to different people, but my personal perspective is that venture-funded open core software like Mattermost feels like FOSS to me about as much as proprietary software with a free plan like Slack or GitHub does.

For Mattermost in particular, this thread is a good reference: https://news.ycombinator.com/item?id=21820583. They made changes to the specific items mentioned there in response to the community pressure, but that doesn't change their fundamental business strategy.