One Company Replaced Slack, Notion, Linear, and HubSpot With a Single Open-Source Rust Codebase

Somewhere in the last seven days, a 15-person startup's internal tools repo picked up roughly 2,700 GitHub stars and landed on GitHub's trending page. That's not unusual on its own — trending pages are full of viral demos that evaporate in a month. What's unusual is what's actually in the repo: Macro is a full replacement for Slack, Notion, Linear, Superhuman, and a chunk of HubSpot — email, team chat, docs, tasks, a CRM, calls, file storage, and AI agents — shipped as one Rust and SolidJS codebase, under the GNU Affero General Public License v3.0.

Companies open-source developer tools all the time. Companies open-sourcing the entire internal operating system they use to run themselves — CRM, email client, and all — is a different and much rarer bet. It's worth asking why anyone would do that, whether the code backs up the claim, and what it actually costs a small team to give away software this comprehensive under a copyleft license instead of the open-core playbook almost everyone else uses.

What Macro actually is

The pitch, straight from the README: a team of about 15 people in NYC and Toronto built Macro because their previous startup fragmented across a dozen SaaS tools as it grew to ~20 employees, and "the company was not computable." Every team picked its own stack, context lived in Slack threads nobody could search, and the tools were stitched together with MCP and Zapier rather than actually integrated. They dogfooded Macro internally for two years before opening the repository publicly.

The product is organized into "blocks" — Email, Messages, Tasks, Docs, Canvas, Agents, Calls, File storage, Pull requests, and CRM — each purpose-built rather than assembled from one generic primitive (the anti-pattern a lot of "everything app" products fall into). What actually differentiates this from just bundling ten SaaS clones behind a single sign-on is the data layer underneath: every block shares one backend, and cross-references between a doc, a task, a channel message, and an email are stored natively as a bidirectional graph. @-mention a company record inside an engineering task and you get a link that resolves both directions — the task shows up on the company's timeline, and the company record is reachable from the task. Leave a channel and you lose access to everything shared inside it; join it and you get pulled in automatically. That's the actual engineering claim: not "one UI for ten tools," but one permissions and reference graph underneath all of them.

Concretely, this shows up in things like: creating a support ticket directly from an email thread with the originating message still linked; an "Agent" automation that scans team channels every morning to update a shared markdown doc, skipping updates if a human already made them; and a CRM where "notes" on a company record are literally the same threaded-messages primitive used everywhere else in the app, so a deal's negotiation history isn't disconnected from the Slack-style conversation that happened around it.

The CRM block is a useful test of whether the "one graph" claim is more than marketing. The README is candid that Macro "hasn't innovated on the core idea of CRM" — it's a kanban board with customizable stages, list/saved/shared views, the features you'd expect from Attio, HubSpot, or Salesforce. The differentiation is entirely about where the CRM sits relative to everything else: @mention a company from any message, task, or PR and you get a bidirectional link back to that record automatically, and every deal gets a dedicated channel pinned to it rather than living in a separate tab you have to remember to update. Whether that's meaningfully better than a well-configured HubSpot-plus-Slack-integration setup is a question only extended real-world use will answer — but it's a specific, falsifiable claim rather than a vague "AI-powered CRM" pitch.

The architecture behind the pitch

The tech stack is a genuine engineering artifact, not a wrapper around existing SaaS APIs. The repo layout, per the README, breaks down into:

• apps/web — the SolidJS client, shared across browser, a Tauri desktop build, and mobile
• services/ — 42 deployable services, workers, and Lambda handlers
• crates/ — 167 Rust libraries covering domain logic, models, and database clients
• packages/ — shared TypeScript for the collaboration layer, including a package called loro-mirror
• infra/ — Pulumi definitions
• nix/ — a pinned dev shell and build inputs

Services follow a hexagonal architecture — inbound adapters, a domain core with defined ports, outbound adapters — which is the kind of decision a team makes when it expects to run this for years, not when it's optimizing for a demo. Real-time collaboration runs on Cloudflare Durable Objects combined with CRDTs (the loro-mirror package name points to Loro, a Rust-based CRDT engine used for exactly this kind of local-first, conflict-free collaborative editing). The README's specific claim is that edits "come in ~instantly instead of ka-chunking like Google Docs" — a jab at the debounced, request-response sync most collaborative editors still use versus a proper CRDT sync loop.

The more interesting design decision is how agents plug into that same CRDT layer. Rather than exposing a separate "AI write" API that patches a document from the outside, Macro's agents edit through the same real-time collaboration protocol as human users — operating as peers in the CRDT session, not as a privileged batch process. The README links out to a longer engineering write-up on this by one of the contributors (Wolf's post on agents attacking the document) if you want the deeper mechanics. Practically, it means multiple agents and multiple humans can be mutating the same doc simultaneously and have the CRDT's conflict resolution handle it, the same way it handles two humans typing in the same paragraph — instead of the agent needing its own locking or diff-and-patch logic layered on top.

On the AI-agent-integration side specifically, Macro exposes an MCP server (mcp-server.macro.com) that any MCP client — Claude Code, Codex, or otherwise — can point at, described as having "near 100% coverage" of what you can do in the UI and, notably, no rate limits on that surface. Team-level memory is synthesized nightly via a cron job that pulls from channels, DMs, sent/received email, and completed tasks into one consolidated markdown memory file per team, which is itself exportable and model-agnostic — you can point any LLM at it through Macro's model picker, not just the ones the company has a deal with.

The license is the actual headline

Here's the part that should make you pause before scrolling past this as "another AI productivity tool." Macro isn't open-core. The README is explicit about this: "fully open source — not 'open core' — under the GNU Affero General Public License v3.0." Every block — CRM included — is in the same AGPL-licensed repository, with no separate paid module bolted on top that's kept closed.

That's a genuinely different bet from how most infrastructure and SaaS companies do open source. GitLab, Supabase, and Grafana all run some flavor of open-core: a functional open-source base with enterprise features (SSO, audit logs, advanced permissions, certain integrations) locked behind a commercial license, which is how those companies fund development without giving competitors a free ride on their differentiators. Macro is choosing the AGPL instead — a copyleft license that lets anyone read, fork, and self-host the entire product, but requires that anyone who modifies it and offers it as a network service (the classic AGPL "SaaS loophole" closer) release their modifications too. If you want to build a commercial product on top of Macro under different terms, the README points you to a separate licensing contact — so there's a commercial off-ramp, but the default is copyleft, not a feature-gated free tier.

Why would a team do this instead of the safer open-core path? A few plausible reasons, though the README doesn't spell out the business rationale explicitly:

• Trust as the product. For something asking to hold your company's entire email, CRM, and internal comms, "the code is fully inspectable and you can run it yourself" is a stronger pitch than "trust our SOC 2 badge," especially against closed incumbents like Notion and HubSpot that offer zero code transparency.
• AGPL as a moat, not a giveaway. Because AGPL triggers on network use, not just distribution, a well-funded competitor can't quietly take Macro's code, run it as a hosted product, and keep their changes proprietary — they'd have to open-source their fork too. That's a meaningfully stronger defense against "Amazon strip-mines your open-source project" than a permissive license, even if it's weaker than closed source.
• Self-hosting is genuinely part of the pitch, not a compliance checkbox — the README ships a docker/ compose stack and a documented "Running locally" path, and the FAQ (per the README's own pointer) covers self-hosting mechanics directly.

What this changes versus the incumbents

The comparison that actually matters isn't feature-for-feature against any single competitor — it's the shape of the bet. Notion, Slack, and Linear each dominate one category and integrate with the others through APIs and Zapier-style glue, which is exactly the fragmentation the Macro README describes as the problem. Open-core infrastructure projects like GitLab prove that a comprehensive open product can sustain a real company, but they do it by keeping something back. Macro is testing whether "everything open, self-hostable, and copyleft-protected" can work for a category — the internal company OS — that's historically been sold as ten separate rent-seeking SaaS subscriptions.

Why this should actually matter to developers

Setting aside the "cool, another AI wrapper" reflex, there are a few concrete reasons this is worth a developer's attention beyond curiosity:

Data ownership for once isn't hypothetical. If you self-host Macro, your email metadata, CRM notes, and internal chat history live in infrastructure you control, not in a vendor's multi-tenant database subject to a future pricing change, acquisition, or breach disclosure on someone else's timeline. That's a real, auditable property most SaaS product decisions in this space simply don't offer.

The MCP-first design is a genuine DX difference, not marketing. A lot of "AI-native" tools bolt a chat sidebar onto an existing product and call it agentic. Exposing near-total UI parity through MCP with no rate limiting, plus a memory layer that's plain markdown you can export, means an agent working against Macro isn't fighting an artificially constrained surface — which is exactly the complaint developers have about agent integrations with Slack, Notion, and similar tools that throttle or partially expose their APIs.

AGPL has real, practical implications you should understand before adopting it, not just legally but organizationally. If your company is AGPL-averse for compliance reasons (a lot of enterprises are, rightly or not, cautious about copyleft touching anything customer-facing), self-hosting Macro and modifying it to serve your own customers as a hosted product would trigger the same obligations that make some legal teams nervous about AGPL dependencies generally. That's a real adoption friction point worth knowing going in, separate from whether the product itself is good.

Hexagonal architecture and CRDT-based agent editing are patterns worth studying even if you never deploy Macro. The "agents as peers in a CRDT session" approach to the multiplayer-editing-with-AI problem is a cleaner abstraction than the patch-and-diff approach most AI writing tools use, and it's genuinely instructive to read through, even just as a reference implementation, if you're building anything with concurrent human/agent editing.

The contributor experience signals long-term intent, not a weekend project dumped on GitHub for attention. A pinned Nix dev shell, a documented docker/ Compose stack for local runs, a docs/STYLE_GUIDE.md, and a CONTRIBUTING.md covering the PR process are the unglamorous infrastructure of a project expecting outside contributors to actually land changes across 167 Rust crates and 42 services — the kind of thing that's easy to skip and hard to bolt on retroactively once a codebase this size exists without it.

Where it's actually useful

The README's own dogfooding example is a good illustration of the intended use case: an internal automation runs daily, scans team channels for mentions of a shared "Pool Games" tracking doc, and updates it — deferring if a human already made the edit, with the CRDT layer handling any conflicts natively. That's a small example, but it's the kind of low-stakes automation that becomes tedious glue code (a cron job, a Slack webhook, a doc API call, conflict handling you write yourself) in a fragmented stack, and is close to trivial when chat, docs, and agents share one permission and event model.

The more consequential version of the same pattern: a customer email lands in the unified inbox, gets turned into a task with one keystroke (linked back to the source email), assigned to an engineer, worked in a linked pull request, and the whole chain — "why are we doing this" → task → agent → PR — stays traceable in one graph instead of scattered across a mail client, an issue tracker, and a GitHub PR description that nobody bothers to fill in properly. For a small, technical team that's already frustrated by Zapier gluing five tools together, that's a genuinely compelling pitch, and it's the same problem statement Linear made when it said (as the README itself cites) that traditional issue tracking is "dead" because it drifts out of date from where the actual conversation happens.

What the README doesn't quite say

None of this means the pitch is complete, and a few gaps are worth naming plainly:

• This is a very young public project wearing two years of private dogfooding as a track record. Internal use by a 15-person team that built the tool for itself is a different bar than surviving contact with unrelated companies' messier workflows, larger headcounts, and edge cases the founders never hit themselves.
• No funding information is disclosed in the repo. A fully open-source, AGPL, self-hostable product still needs a revenue engine to keep 15 engineers paid — the README points to commercial licensing and managed-hosting contacts, but doesn't say how sustainable that pipeline currently is. That matters for anyone deciding whether to build a business-critical workflow on top of it.
• Doc version history is explicitly called "still v1" in the README, with the team saying they may add real git-style compatibility eventually — worth knowing if version control on your docs is a hard requirement today, not a someday.
• The mobile story is asymmetric: an iOS app exists; Android is listed as "coming soon."
• Consolidating ten SaaS categories into one vendor is a different risk profile than diversifying across ten, even when the code is open. If Macro the company folds, self-hosters keep working software and can fork; hosted-plan customers face the same migration cliff they'd face with any single SaaS failing — except now it's your email, CRM, docs, and chat history all leaving at once instead of one tool at a time.
• Security claims (SOC 2 Type II, ISO 27001) are self-reported in the README via badge images; that's standard practice, but worth independently verifying via the certifying body before trusting it with sensitive company data, the same diligence you'd apply to any vendor claim.
• AGPL cuts both ways for adopters. It protects the commons from being strip-mined, but it also means any internal modification you deploy as a network service to people outside your organization needs to be released — a real constraint if you were hoping to fork Macro, customize it heavily, and resell access without engaging the separate commercial license.
• "No rate limits on MCP" is a claim worth pressure-testing at scale, not just taking at face value. It's a genuinely attractive promise compared to the throttled agent APIs common elsewhere, but the README doesn't describe what happens under heavy concurrent agent load on a self-hosted instance versus the managed one — that's exactly the kind of limit that tends to surface only once real usage arrives.

My read

The interesting thing about Macro isn't the AI angle — "agents with memory" is table stakes marketing copy at this point, and every one of the ten product categories it touches has an AI-native challenger already. What's actually differentiated is the combination of an unusually complete product surface, a real distributed-systems architecture underneath it (hexagonal services, CRDTs, a genuine bidirectional graph, not a UI skin over Zapier), and a licensing decision that puts skin in the game: giving away the whole thing, CRM included, under a license that structurally prevents a well-funded competitor from forking it and out-marketing the originators without giving back.

The execution risk is real and worth being honest about — building one thing exceptionally well is hard; building ten things (email client, chat, issue tracker, docs, CRM, calls, file storage, agents) to a standard that beats each category's dedicated incumbent, simultaneously, with 15 people, is a much larger claim than the star count alone can verify. The architecture reads as serious engineering rather than a demo, which buys real credibility, but a trending repo a week old hasn't yet been tested by the thing that actually validates an "everything app": whether teams outside the founders' own workflow adopt it, keep using it past the novelty phase, and don't quietly drift back to point solutions for at least one of the ten categories it's trying to replace.

Should you try it?

Try it if you're a small, technically comfortable team frustrated by tool sprawl and Zapier glue, willing to self-host or take on early-adopter risk on the hosted plan, and you specifically want your AI agents to have full, unthrottled access to your company's operational data through MCP.

Wait if you need mature version history on documents, an Android app, or independently verified enterprise security posture before trusting it with production company data — the README is candid that several of these are still in progress.

Ignore it for now if your organization has a hard AGPL policy, if you need the negotiating leverage of easily swapping any single tool in your stack (an all-in-one platform is, by definition, harder to partially migrate away from than a point solution), or if you're evaluating this purely as "another AI chat wrapper" — that's not actually what's being offered here, and judging it on that axis will miss the part that's genuinely worth your attention: the data model and the licensing bet.

What's your experience with "everything app" workspaces that try to replace your whole SaaS stack at once — has consolidating chat, docs, tasks, and CRM into one system ever actually stuck for your team, or does it always drift back into point tools for at least one category?

Sources:

• Macro GitHub repository
• GitHub Trending — weekly
• Macro README — architecture, license, and feature details
• Wolf — Agents Attack the Document (CRDT agent-editing write-up)
• Loro — CRDT engine
• Model Context Protocol
• GNU Affero General Public License v3.0
• Twenty — open-source CRM