At a glance β how these 4 alternatives compare
Our read on each project's adoption, maintenance activity and commercial-use risk, derived from GitHub signals and SPDX license terms rather than star count alone. Sorted by stars. How we score.
| Project | Adoption | Maintenance | Commercial use |
|---|---|---|---|
| β
37,617 Β· Ruby | Flagship | Active | Low risk Embed in a proprietary product with no copyleft obligation. Split licence β this rates the core component; read the β text for the separately licensed parts |
| β
6,114 Β· Elixir MIT | Mainstream | Stale | Low risk Embed in a proprietary product with no copyleft obligation |
| β
5,986 Β· Ruby AGPL-3.0 | Mainstream | Active | High risk Even a hosted/modified deployment can trigger source release |
| β
4,096 Β· TypeScript | Established | Active | High risk Even a hosted/modified deployment can trigger source release. Split licence β this rates the core component; read the β text for the separately licensed parts |
β Licenses marked β were read from the repository's LICENSE file on 2026-09-05 (linked, pinned to the commit we read) because the GitHub API returned no SPDX id for them. Unmarked licenses are the GitHub API's SPDX classification.
The alternatives
Open-source live-chat, email support, omni-channel desk. An alternative to Intercom, Zendesk, Salesforce Service Cloud etc. π₯π¬
chatwoot/chatwoot Updated 2026-10-08 papercups
Open-source live customer chat
papercups-io/papercups Updated 2024-02-15 zammad
Zammad is a web based open source helpdesk/customer support system.
zammad/zammad Updated 2026-10-08 Experience Operating System (XOS) that unifies marketing, sales, operations, and support β run your core business seamlessly while replacing HubSpot, Zendesk, Linear, Wix and more.
erxes/erxes Updated 2026-10-08 Editor's take
Yusuke Morinaga Β· last revisited Β· star counts quoted in the text (β) are as of that date; the cards above are refreshed daily
Intercom is a support tool wearing a marketing tool's clothes β and the OSS world only rebuilt the support half.
Intercom is sold as one product but it does two jobs: reactive support (a shared inbox, live chat, a help center) and proactive lifecycle messaging (product tours, behaviour-triggered in-app messages, onboarding nudges). The open-source projects below have, almost without exception, rebuilt the support half and left the marketing half alone. So before you pick one, be honest about which half of your Intercom bill you were actually using β because if it was the product tours, none of these will satisfy you.
Chatwoot β the only mature, no-asterisk recommendation here
Chatwoot (β36.5kβ
, Ruby) is the clear leader and the
one I would deploy. Live chat widget, email support, social channels, a
proper agent inbox β it covers the reactive-support core of Intercom
genuinely well, and it is actively developed (see the last-push date on its card).
The one thing to verify yourself is the license: the GitHub API returns no
SPDX id because Chatwoot carves out enterprise features; the card shows what
we read in its LICENSE β MIT for the core, with the enterprise/ directory
under a separate licence. Read the current LICENSE before building a
commercial product on top of it and pulling in enterprise features; for
running it as your own support desk, it is fine.
Zammad β pick this if βsupportβ really meant βticketingβ
Zammad (β5.9kβ , Ruby, AGPL-3.0) is a different shape: it is a help-desk / ticketing system first, with email, phone, and chat folded into a ticket model, rather than a chat-first tool with tickets bolted on. If your Intercom usage was mostly the inbox and SLAs and less about the live-chat bubble, Zammad will feel more native. AGPL-3.0, which for self-hosting your own support desk does not trigger any obligations.
Two entries I would not lead with, and why
Papercups (β6.1kβ
, Elixir, MIT) shows a healthy star count, but its last
commit on the card is 2024-02-15 β over two years stale at the time of
this review. That is the single most important fact about it: a customer-
facing chat tool that has not shipped in two years is a maintenance risk you
are signing up to own or fork. MIT-licensed and pleasant, but I would not put
it in front of customers today without accepting that you may be the
maintainer now. erxes (β4.1kβ
, TypeScript, AGPL-3.0 core with ee/ plugins
separately licensed) is the opposite
problem β it is more than Intercom, an entire βexperience operating systemβ
spanning marketing, sales, and support. If you want a sprawling all-in-one
platform that is fine, but as a focused Intercom replacement it is a heavier,
broader thing than most teams leaving Intercom actually want.
The honest gap nobody fills
The part of Intercom you cannot get back from any of these is the proactive layer: product tours, behaviourally-triggered in-app messages, and especially Fin, the AI agent that resolves tickets from your help center. Chatwoot has added bot and automation pieces, but βrebuild my onboarding tour flowβ is not something any project here does out of the box. If that workflow was central, either keep a dedicated product-adoption tool alongside your OSS support desk, or accept that you are giving up the onboarding automation when you leave.
Comparison notes
Chatwoot is the most developed open-source choice, pairing live chat, email support, Twitter/Facebook channels, and a unified agent inbox on a self-hostable Rails backend; Zammad is the option to look at if your need is really helpdesk ticketing. Both handle support messaging well, but Intercom does more than support, and that's where the gaps appear. Its product tours and in-app onboarding messages have no open-source equivalent, nor does Fin, the AI chatbot that resolves tickets straight from your help center. Chatwoot also stops at support β it doesn't carry Intercom's marketing and lifecycle communication tooling.
Migration tips
- Export Intercom conversations via the Data Export tool β download conversation transcripts as JSON
- Export contact data (users, companies) via Intercom's CSV export or API for import into Chatwoot or your CRM
- Migrate your Intercom help articles to your OSS help center or wiki before pointing users to the new URLs
- Update your website's chat widget code from Intercom's snippet to Chatwoot's widget embed
- Notify active conversations of the support channel change β in-flight conversations should be resolved before migration
Which alternative should you pick?
Replacing Intercom isn't a single call β it's a trade between license terms, team size, and how much early-stage roughness you can absorb. The 4 projects above split along those lines:
- You want the project with the most GitHub stars in this list β chatwoot. 37,617β β the most of the 4 projects here. Stars measure attention, not quality or maintenance; check the last-push date and the Editor's take before reading more into it.
- You ship commercial software and need to ship modified code without releasing source β papercups. MIT licensed β modify and embed without copyleft obligations.
- You want a copyleft project whose modifications must be shared back β zammad. AGPL-3.0 licensed β distributing a modified version (and, under AGPL, offering it over a network) obliges releasing the source, which is what some teams explicitly want.
License & commercial-use notes
When replacing Intercom, the license usually decides more than the feature list β whether you can modify it, ship it inside a product, or host it as a service. The 4 projects here fall into:
- Permissive (chatwoot, papercups) β MIT / Apache / BSD / ISC β modify and embed inside a commercial product with no copyleft obligation. The safest bucket for shipping in a proprietary codebase.
- Network copyleft (zammad, erxes) β AGPL / SSPL β the copyleft trigger extends to offering the software over a network, so a hosted deployment of a modified version can oblige you to publish your changes. Read the exact terms before building a paid hosted product on these.
Split licences: chatwoot (MIT (core) + separate license for enterprise/); erxes (AGPL-3.0 (core; competing SaaS hosting not permitted) + separate license for ee/ plugins). These projects are grouped above by the core licence; the separately licensed directories (enterprise or EE parts) are not covered by that bucket β check which files you actually ship.
License fields come from the GitHub API's SPDX classification and can lag a relicense. Where the API returned no SPDX id, the license marked β was read from the repository's LICENSE file on 2026-09-05; the β links to the exact file and commit we read. The repository linked on each card is authoritative β confirm its LICENSE file before any license-sensitive deployment.
Maintenance health of these 4 projects
Of the 4 projects listed, 3 shipped at least one commit in the last 12 months. See how we rank for the full criteria and our self-hosting cost reality check, which apply across every comparison on this site.
Frequently asked questions
How do these 4 alternatives compare on maintenance health?
3 of 4 have shipped a commit in the last 12 months. At least one project here has 5,000+ GitHub stars. Always check the last-pushed date in the cards above and read the latest closed issues β those two signals are the fastest public check we know of.
How this page was compiled
- Repository facts (stars, license, language, last push) come straight from the GitHub public API and are linked on each card as the primary source. Where the API returned no SPDX id, the licence marked β was read from the repository's
LICENSEfile (linked, pinned to the commit we read, with the date checked). - Editorial analysis (the intro, comparison notes and migration tips) is Claude-drafted from Intercom's use case and the alternatives' repository metadata β in Claude Code sessions or scheduled routines run under the operator's account. Samples are spot-checked against the upstream repositories; entries are not individually reviewed unless they carry a signature. See what Claude drafts and what the operator writes.
- Editor's take is signed by Yusuke Morinaga. It was drafted in a Claude Code session the operator ran, then read and confirmed by Yusuke Morinaga before publication, and carries the date it was last revised. It is written from each project's README, LICENSE, release history and issue tracker β not from running the project in production; where that distinction matters, the take says so.
- Maintenance signal: 3 of 4 projects shipped a commit in the last 12 months as of the latest rebuild (most recent activity: ).
- Last editorial review: by Yusuke Morinaga.
- Spotted an error? Email [email protected] with the page URL (subject prefix
[correction]) β we ship corrections within 14 days.