NServiceBus: a commercial .NET messaging platform with a reciprocal license and a build that has moved

Reciprocal, not permissive, and that distinction decides your architecture

The Licensing section at the bottom of the README is short and specific. NServiceBus is licensed under RPL 1.5, with details in a LICENSE.md file in the tree. GitHub's own license field for the repository reads NOASSERTION rather than naming the license, so the metadata does not tell you anything; the README does.

The Reciprocal Public License is a source-available license with one real obligation. You can use NServiceBus in commercial software, deploy it, modify it, and sell what you build with it without paying anyone. What you cannot do is distribute a modified version of NServiceBus itself without publishing your modifications under the same terms. In practice almost nobody modifies the message abstraction layer, so the obligation rarely bites, and for most commercial use RPL 1.5 behaves like a permissive license.

That is the point at which the repository description becomes worth reading twice. It calls NServiceBus the gold standard for async .NET microservices, which is a marketing claim in a field where MassTransit, Rebus and Wolverine all compete hard. It is not a license contradiction, but it is a reminder that this is a vendor project rather than a foundation one, and the same README lists 24x7 professional support from dedicated engineers as one of the things NServiceBus includes.

The third-party sections are handled more carefully than the main license. net-object-deep-copy and FastExpressionCompiler are both named as MIT, with links to their upstream licenses, and their sources are described as compiled into the NServiceBus distribution as allowed under those terms. A THIRD-PARTY-NOTICES.txt file in the tree is where the full accounting lives.

The README tells you to open a solution file that is not in the tree

The Building section says to open `NServiceBus.sln` in Visual Studio and build the solution, then adds that you will find the built assemblies in `/binaries`. It even troubleshoots a failure mode for you, warning that long path names greater than 248 characters will break MSBuild.

None of that can work against this repository as it stands. The tree contains no solution file. What is there is `src/`, `docs/`, `global.json`, `nuget.config`, `.reposync.yml`, `AGENTS.md`, `CONTRIBUTING.md`, `SECURITY.md`, `Package-README.md` and the usual GitHub metadata. There is no `binaries` directory either, and the word MSBuild appears nowhere else on the page.

The presence of `global.json` and `nuget.config` is the tell. Both are files the dotnet command line tool reads to pin the SDK version and configure package sources. A Visual Studio solution and an MSBuild output directory belong to the older build model. The README is describing how the project used to be built, while the repository has moved to the SDK-style tooling, and the troubleshooting advice about 248 character paths still applies to the dotnet CLI, which uses the same underlying build engine.

So there are two facts and they point in opposite directions. Either the solution file is generated by a repository sync step, which is what `.reposync.yml` suggests, in which case the README is incomplete rather than wrong; or the build moved to `dotnet build` and the README was never updated. Either way, if you want to build the source, follow CONTRIBUTING.md rather than the README, and do not expect a `/binaries` folder.

Nine storage backends and five transports behind one abstraction

The NServiceBus feature list is where the product's actual scope appears. Storage runs on Microsoft SQL Server, MySQL, PostgreSQL, Oracle, Azure Cosmos DB, Azure Table Storage, Amazon DynamoDB, MongoDB and RavenDB. Queues are supported on Azure Service Bus, Azure Storage Queues, Amazon SQS and SNS, RabbitMQ, and Microsoft SQL Server.

That is the value proposition in one sentence. You write a handler against a message abstraction, and the transport and persistence choices become configuration. Migrating an endpoint from SQL Server to RabbitMQ, or from SQL Server persistence to Cosmos DB, is a configuration change rather than a rewrite. Few open source .NET messaging libraries cover both axes at that breadth.

The other capability listed is sagas, described as the way to orchestrate long-running business processes. A saga is the piece that handles a workflow which spans multiple messages and takes time, where you need to persist progress and know what to compensate if a later step fails. That is the part of the framework that is genuinely hard to build correctly and the part most worth evaluating.

Two smaller claims are worth reading. The product says it runs on-premises, in the cloud, in containers, or serverless, which is a hosting claim rather than a feature. And it says you can observe system performance using Open Telemetry integration, though the README spells it as Open Telemetry with the capital T, which is not how the project writes its own name.

Patch releases with one to three commits, and a ClamAV scan pasted into each one

The three most recent releases are 10.2.7 on 2026-06-26, 10.2.8 on 2026-08-05 and 10.2.9 on 2026-09-03, and each one states up front how many commits it contains and how many issues that closed. 10.2.9 has three commits and two issues closed. 10.2.8 has three commits and one issue. 10.2.7 had a single commit.

The bugs themselves are the useful part, because they describe the sharp edges of a messaging platform. Version 10.2.7 fixed endpoint-keyed root services failing to resolve without a FromKeyedServices attribute when multi-hosting, which is the kind of DI container behaviour that only surfaces in unusual deployment topologies. Version 10.2.8 fixed receive properties being lost on delayed retries, which is a message-handling correctness bug. Version 10.2.9 has two: saga correlation id loading falling back to expression compilation instead of the source-generated accessor, and endpoint shutdown throwing FileNotFoundException when a rolling log file is deleted concurrently.

Every one of those release bodies then includes a ClamAV scan summary inside a collapsed details block, complete with engine version, scan date, known virus count and a scan duration. The 10.2.9 release scanned seven files and 27 MiB in about 40 seconds. It is an unusual amount of ceremony for a three-commit patch release, and it is the clearest signal in the repository that this is run as a commercial distribution rather than a community project.

All three releases point to NuGet for the actual download, under the ParticularSoftware profile. The repository is not archived and was pushed on 2026-09-28.

A README that is mostly four links

It is worth being plain about what this repository is for, because the star count of 2171 invites the opposite assumption. The README has no architecture section, no configuration examples, no code samples and no API documentation. The Getting started section is four links: a quick start tutorial, a step-by-step tutorial, the ParticularTemplates NuGet package, and links to the tutorials and samples indexes. The Packages section is one sentence pointing at a documentation page listing every NuGet package. The Support section is a documentation link, a community forum and a contact page for support requirements.

There is also a link for help with a proof-of-concept. That is the clearest signal that the repository is the public face of a vendor business rather than the product documentation.

What the repository does contain is worth noting for anyone assessing it. Alongside the README and LICENSE.md there is a `SECURITY.md`, a `CONTRIBUTING.md`, a `THIRD-PARTY-NOTICES.txt`, a `Package-README.md` that presumably feeds the NuGet package listing, and an `AGENTS.md`. The last of those is the notable one: an agent instruction file committed at the root of a large .NET codebase is a deliberate signal to automated tooling, and it means the project expects contributions from AI coding assistants as a matter of course.

The scale numbers reinforce the reading. 2171 stars with 645 forks is a fork ratio close to thirty percent, and 292 open issues on a codebase this size is a healthy queue rather than a neglected one. The activity is real. It is just happening elsewhere.

Editorial conclusion

NServiceBus is a mature commercial product with an open source core, and the two halves have different terms. The RPL 1.5 lets you use, modify and deploy it freely including commercially, and asks only that you publish modifications to NServiceBus itself. That is a meaningfully different thing from MIT, and it is the first thing to settle before adopting a platform this central. The transport and persistence list is the genuine strength, with nine storage options and five queue technologies behind one abstraction, plus sagas for long-running processes and OpenTelemetry integration. What the repository does not serve you is the product itself: the README is a pointer to docs.particular.net, the supported build path is no longer the one it describes, and paid support is a line item in the feature list rather than an afterthought. Read the license, then read the quick start on the documentation site.

Frequently asked questions

Official sources

1. Issues
2. Particular/NServiceBus on GitHub
3. Project website
4. README
5. Releases