Rasa Open Source in Maintenance Mode: What the 3.6.x Branch Still Does
💬 Open source machine learning framework to automate text- and voice-based conversations: NLU, dialogue management, connect to Slack, Facebook, and more - Create chatbots and voice assistants
At a glance
- What is it?
- Rasa Open Source is an Apache-2.0 Python framework for intent-based NLU and dialogue management, now in maintenance mode while Rasa points new work at Hello Rasa and CALM. Here is what the legacy branch actually gives you, and where it stops being the right tool.
- Who is it for?
- Adopt Rasa Open Source 3.6.x if you need an Apache-2.0, self-hosted, intent-based assistant with custom actions and voice or messaging channel connectors, and you accept that the branch is in maintenance mode. Do not adopt it if you want an LLM-driven agent with no NLU training step; the repository itself points that work at Hello Rasa and CALM.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 54 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Problem Rasa Solves, and the Version You Are Actually Choosing
Rasa targets a specific problem: a conversational assistant that holds context across many turns, runs on your own infrastructure, and connects to channels you already use. The README lists Facebook Messenger, Slack, Google Hangouts, Webex Teams, Microsoft Bot Framework, Rocket.Chat, Mattermost, Telegram, Twilio, and custom channels. The framework ships two halves in one Python package: NLU, which maps user text to intents and entities, and dialogue management, which decides the next action given conversation state. That combination is why teams pick it over a plain LLM wrapper. The classification step is trained on your labelled data, so a known intent lands in a known bucket instead of being re-inferred at request time.
The version question matters more than usual here. The default branch is 3.6.x, and the most recent releases listed are 3.6.21 (January 2025), 3.6.20 (April 2024) and 3.6.19 (March 2024). The README carries a maintenance-mode notice at the top, and the section describing installation and docs is explicitly labelled legacy. So the honest framing is not "should I use Rasa" but "should I start a new project on a branch the vendor has frozen while it promotes a different engine". For existing deployments that question is easy. For greenfield work it is the whole decision.
Intents, Stories and Custom Actions: the Legacy Mechanism
The classic Rasa pipeline is data-driven in two directions. On the NLU side you supply training examples per intent and entity annotations; the pipeline you configure in config.yml converts raw text into a structured message. On the dialogue side you supply stories (example conversations) and rules, and a policy model learns which action to take next given the dialogue state. Custom actions are Python code that runs outside the model, so database writes, API calls and business validation do not depend on the classifier being right.
That split is the design argument. A retrieval or generative approach decides both understanding and response in one step. Rasa decides understanding with a trained model and response with a policy plus your code, which means you can inspect and test each stage separately. The cost is that you own the training data. A new intent needs examples, and a new conversational path needs stories or rules before the policy can follow it.
The README does not describe the internals of the policy or the NLU pipeline beyond naming the framework, so treat any claim about model architecture as something to check in the docs rather than in the repository front page. What the README does establish is the scope: contextual assistants, layered conversations with lots of back-and-forth, text and voice input, and a set of named channel connectors.
Getting the Legacy Framework Running
The README gives two paths. For normal use it points to the installation docs at rasa.com/docs/rasa/installation/environment-set-up rather than listing pip commands on the front page, so the exact install command for your platform belongs to that page, not this article.
For building from source, the repository uses Poetry for packaging and dependency management. The documented sequence is to install Poetry from the official guide, then run:
make install
The README adds a macOS note: if compiler issues appear, run export SYSTEM_VERSION_COMPAT=1 before installation. That is a real constraint, not a footnote. Building Rasa from source pulls compiled dependencies, and the environment variable is the documented workaround on Apple hardware.
Tests have their own targets. Prepare the environment first, then run the suite:
make prepare-tests-ubuntu make prepare-tests-macos make test
The README does not print the contents of the Makefile, so what each target installs is only visible in the repository itself. If you are evaluating Rasa for a team, reading the Makefile and the Poetry lock file is the fastest way to see how heavy the dependency tree is before you commit to it.
Maintenance Mode Is the Constraint, Not a Footnote
The README states plainly that Rasa Open Source is in maintenance mode, and that the future of building AI agents with Rasa is Hello Rasa and CALM. The installation section is prefixed with a note that the instructions below it apply to the classic framework, and the heading itself reads "Rasa Open Source (Legacy)".
Read that as a support boundary. Maintenance mode does not mean the code stops working. It means the direction of new capability has moved. The release history supports a cautious reading: three patch releases between March 2024 and January 2025, all on the 3.6 line, with no new minor version in that window. Patch releases on a frozen minor line are consistent with fixes rather than feature work, though the repository front page does not enumerate what changed in each one.
There is a second, quieter cost. The README's most prominent content is now about Hello Rasa: a browser playground, templates for Banking, Telecom and Support, an inspector for watching decisions, and export to the Rasa Platform when you are ready to scale. A reader arriving at this repository is being routed toward a hosted product. If your reason for choosing Rasa was self-hosting and Apache-2.0 licensing, you are choosing the legacy branch, and you should plan for that branch to stay where it is.
Where the Intent Model Breaks Down
Intent classification assumes the set of things users can mean is enumerable and stable enough to label. That assumption fails in a specific and common way: a user phrases a request in a way your training examples never covered, the classifier assigns it to the nearest intent it does know, and the assistant confidently takes the wrong action. The failure is not a crash. It is a plausible response to the wrong question, which is harder to detect in logs and harder to explain to the person who received it.
The usual mitigation is more training examples, which is also the cost. Every new phrasing class is labelled data you maintain, and the maintenance burden grows with the surface area of the assistant rather than staying flat. For a narrow assistant with a fixed set of tasks this is a reasonable trade. For an open-ended assistant where users are expected to say anything, it is a poor fit, and that is precisely the gap the README says CALM is meant to close: the LLM handles dialogue understanding while you define the business flows.
There is also an operational limitation the README implies without stating. Custom actions run as separate code, so a production deployment has a model-serving component and an action server component to keep in sync. Version skew between them is a class of bug that does not exist in a single-process assistant. The README does not document the action server configuration, so verify that in the docs for your pinned version before you design the deployment.
Rasa 3.6.x Against a Plain LLM Agent Loop
The real alternative is not another chatbot framework. It is a single LLM call with tool definitions, where the model reads the user message, picks a function, and the result is returned as text. That approach has no training step, no intent taxonomy and no stories file. You add a capability by describing a tool, not by labelling two hundred example utterances.
The difference in behaviour is where the trade sits. A tool-calling loop handles phrasing you never anticipated, because understanding is done at request time by a general model. It also gives you less to inspect: the decision to call a function is generated, not classified, and reproducing a specific bad turn means reproducing a sampling process rather than reading a confidence score. Rasa's model gives you a trained classifier and a policy you can evaluate against held-out conversations, at the price of the labelling work above.
The README's own positioning is the clearest statement of this split. It describes CALM as combining "LLM flexibility with strict business logic", and says the project has "moved beyond intents", with flows describing logical steps rather than rigid dialogue trees. That is an argument that the intent model was the limiting factor. It is also an argument made by the same vendor about its own legacy branch, so weigh it accordingly. If your assistant has a bounded task list and you need offline, self-hosted inference, the legacy model is defensible. If the task list is open, the labelling cost never converges.
Licence, Upgrade Path and What to Pin
The repository is licensed under Apache License 2.0, copyright 2022 Rasa Technologies GmbH. That permits commercial use and modification under the terms of the licence itself. It is not legal advice, and the licence file is the authority, not this paragraph. The practical point for a team is that the open source branch and the hosted platform are separate offerings with separate terms, and the README's export-to-platform path crosses that line.
Upgrade cost is where the versioning policy becomes concrete. The README states that Rasa follows Semantic Versioning: major for incompatible API changes, minor for backward-compatible functionality, patch for backward-compatible bug fixes. It then points to a product release and maintenance policy for cadence and supported versions. Since the current line is 3.6.x and no 3.7 or 4.x appears in the release list, staying on 3.6 means staying on patches. Pinning an exact patch version is the safe move; a floating constraint will pull in whatever the branch produces next.
For a team already on 3.6, the upgrade question is not "when do we move to the next minor" but "do we stay on this branch or re-platform". The README answers that in one direction only, by naming Hello Rasa and CALM as the future. It does not describe a migration path from intents and stories to flows, so if you are considering that move, the migration surface is undocumented here and should be scoped from the docs directly.
Editorial conclusion
Adopt Rasa Open Source 3.6.x if you need an Apache-2.0, self-hosted, intent-based assistant with custom actions and voice or messaging channel connectors, and you accept that the branch is in maintenance mode. Do not adopt it if you want an LLM-driven agent with no NLU training step; the repository itself points that work at Hello Rasa and CALM. Before committing, verify three things in the docs for your target version: the Python version supported by the 3.6.x release you pin, the channel connector for your messaging platform, and whether the release cadence in Rasa's product release and maintenance policy still covers that minor line.
Community notes