📣 Proposal: MassTransit v9+ Licensing and Elsa Integration Strategy

[sfmskywalker]

Hey everyone 👋

As many of you may have heard, MassTransit has moved to a commercial license starting with version 9. This change impacts how Elsa Workflows can continue to support MassTransit while preserving its MIT-licensed foundation.

🧩 Current Context

• Elsa Workflows remains 100% MIT licensed.
• The current integration module (Elsa.MassTransit) references MassTransit and is used by many to integrate workflow messaging patterns.
• MassTransit versions up to 8.x are still MIT licensed.
• Starting with version 9, MassTransit requires a commercial license and is no longer open-source.

✅ Proposed Path Forward

To support both OSS and commercial MassTransit users, we propose to split the integration into two separate packages:

Module	Targets	Notes
Elsa.Integrations.MassTransit.V8	MassTransit 8.x (MIT)	Fully open-source compatible
Elsa.Integrations.MassTransit.V9	MassTransit 9+	Users must obtain their own MT license

Each integration will:

• Live in the elsa-extensions repository.
• Contain a clear notice in the README.md about the licensing status of the referenced MassTransit version.
• Be maintained independently — no multi-targeting or version juggling.

📬 We'd Love Your Feedback

• Does this direction make sense to you?
• Are you or your organization planning to use MassTransit v9+ with Elsa?
• Would you use one or both of these packages?

Looking forward to hearing your thoughts! 🙏

[mohdali]

I think there will be few challenges to address:

• Mass Transit 8 targets .NET 9, it may quickly become obsolete and introduce compatibility issues with newer versions of .NET (10+) or when other packages have conflicting requirements
• Distributed Workflow runtime https://docs.elsaworkflows.io/hosting/distributed-hosting suggests using MassTransit for Distributed Cache, alternative solution may be required
• Whether V9 packages will be published in Nuget or will be only available in private feeds to paying customers (at this moment I cannot see any V9 packages in Nuget). this might even limit the ability to provide a solution for V9 (the Q&A suggests it will be available https://masstransit.io/introduction/v9-announcement#will-the-v9-code-be-open-source)

[sfmskywalker]

@mohdali makes some very good points.

• With regards to MT 8 becoming obsolete, I agree. As long as it's still used, I tink it's OK to also offer an Elsa integration. If MT8 is eventually no longer being used, so too can we sunset its Elsa integration.
• Yes, we definitely need to provide different implementations for the workflow dispatcher and distributed cache signaler.
• Good point, I hadn't considered that they might be doing this from a private feed. In that case, it would be tricky to have an open source project targeting a private package without getting a license for it. I do think it will be available publicly, but let's see how they will go about this.

Thanks for the input!

[dwoldo]

A few thoughts on maintaining support for both:

1. Splitting into V8/V9 creates friction and long-term maintenance challenges, especially as APIs diverge and require duplicated effort to maintain feature parity.
2. Elsa likely doesn't use most of MassTransit's advanced features, making the dependency heavier and more complex than necessary.
3. A custom messaging solution would simplify adoption, eliminate licensing concerns, and give Elsa full control while preserving its MIT license.

Questions:

1. What functionality of MassTransit would be needed by Elsa?
2. What were the reasons to move away from Rebus?

[jwillmer]

I'm also looking into a path forward for our apps and since we also use elsa it would be interesting how elsa deals with this. Any updates on the plan?

[sfmskywalker]

Yes, I'm considering replacing the out-of-box MassTransit implementations for services like IWorkflowDispatcher and similar abstractions with direct implementations of Azure Service Bus, Rabbit MQ and possibly others. Unless we find an MIT compatible project that takes care of abstracting away the underlying providers, like Rebus. We use Rebus in Elsa 2, but I never really got the "hang" of it. I might give it another try for Elsa 3 when we get to phasing out MassTrasit. Two others on my list to investigate are:

• Wolverine
• Brighter

[sfmskywalker]

The currently maintained Elsa extensions source still uses MassTransit 8.x: central package management pins MassTransit, MassTransit.Azure.ServiceBus.Core, and MassTransit.RabbitMQ to 8.5.7. The integration is currently provided under the Elsa.ServiceBus.MassTransit* and Elsa.Caching.Distributed.MassTransit modules; I could not find a separate V9 package or a published implementation plan in the active repositories.

So the accurate status is: MassTransit support remains present for the current 8.x-based integration, but I do not have a committed Elsa V9 package, publication model, or delivery timeline to share. If V9 support is important for your deployment, please open or link a focused issue with the transport and the Elsa features you rely on (workflow dispatching, distributed cache signalling, etc.) so it can be evaluated without turning this thread into a roadmap commitment.

Evidence: elsa-extensions/Directory.Packages.props (MassTransit 8.5.7) and the src/modules/servicebus/Elsa.ServiceBus.MassTransit* plus src/modules/caching/Elsa.Caching.Distributed.MassTransit projects.