About BabelQueue

BabelQueue is an open-source standard — plus the SDKs that implement it — for queue messages that any language can read. It is free software, developed in the open, and maintained by Muhammet Şafak.

What it is

A producer in one language writes a job to the broker you already run; a consumer in another language picks it up and handles it. That works because every SDK emits the same strict JSON envelope instead of a language-specific serialization format — no PHP serialize() on the wire, no bridge service, no schema registry to operate. Messages are identified by a URN rather than a class name, and a trace_id is carried unchanged across every hop.

The envelope is frozen at schema_version 1: no field is added, renamed, removed or retyped without a deliberate version decision, so a v1 producer stays readable by every v1 consumer indefinitely. That guarantee — not any single SDK — is the product.

There are six SDK cores today (PHP, Python, Go, Node.js, Java and .NET), each with framework adapters and per-broker transport modules, and all of them are locked to a shared cross-SDK conformance suite of golden envelopes. The wire contract is the normative reference; the SDKs follow it, never the other way round. The vocabulary those pages use is defined term by term in the glossary.

Who maintains it

BabelQueue was created and is maintained by Muhammet Şafak (@muhammetsafak), who also writes the specification, the SDKs and the articles on this site. Work happens in public in the BabelQueue organisation on GitHub, where each SDK, the shared conformance suite and this website live in their own repositories.

Licence

The standard and every SDK are released under the MIT licence. You can use BabelQueue commercially, fork it, and vendor it into a closed-source product; every SDK repository carries the licence text (© 2026 Muhammet Şafak).

Getting involved

Bug reports, questions and pull requests are welcome on the repository for the SDK you are using — open an issue in the GitHub organisation and it will land with the maintainer. Two things are worth knowing before you file:

• Anything that touches the wire format is a contract change, not a bug fix. It needs a recorded decision and a version choice, so expect that conversation to start in the spec rather than in a patch.
• Behaviour that differs between two SDKs is the highest-value report there is — parity is the whole promise. Include the envelope both sides produced.

New to the project? Start with the documentation, the FAQ, the glossary, or the blog.