Autobahn: statement of direction



I've been asked (off-list) to provide a statement where the Autobahn libraries are heading, and what the future plans are.

In general, the Autobahn libraries are a community effort now with contributions from various sides.

However, we ( GmbH) have started these projects, provided massive development funding and in a way steer this - so I am feeling confident and certainly hope so that Autobahn contributors won't be upset about me making some statements about:

- Licensing
- Scope
- Status and future

Anyway, here you go: please see below. Any feedback on this would be highly appreciated.


1) Licensing

All AutobahnXXX libraries are licensed under permissive, non-copyleft licenses: MIT or Boost.

This is by design: Autobahn should be usable in both open-source (incl. GPL2-only) and commercial, closed-source, proprietory software.

I can assure everyone that this will NOT change.

And in this case, I can make a definite statement, since major portions of the code was written by us, and any license change would require our consent - and that won't happen.

The same policy appies to:

- txaio
- txaio-etcd

The former is a dependency for AutobahnPython.

The latter grew out of our own need for etcd3 in Fabric Center. And since we're open-source shop, we figured making txaio-etcd OSS would be just playing nice giving back to the community.

Please note that we reserve the rights to of the trademark "Autobahn" (as used in this context of networking, rather than real Autobahnen of course).

This is purely defensive: we want to avoid a situation where a big guy or fork comes around, free rides or modifies this stuff in a non-compatible way, and in the end, users are confused what's the "real Autobahn".

To give an example: if you fork Autobahn, and then make changes that render the WAMP implementation contained therein incompatible with the WAMP protocol spec., this is a problem, and we might then ask you to call it differently. But that's about it. Only about naming - code is OSS, do what you want.

2) Scope

The primary purpose of the Autobahn projects is to provide high quality WAMP client libraries for connecting to WAMP routers.

And WAMP routers means: any router compatible with the WAMP protocol.

In particular, Autobahn should not only work with, but any WAMP router, as long as the latter conforms to the WAMP protocol spec.

IOW: Autobahn has a non-discriminatory policy.

However, having WAMP router implementations within Autobahn is explicitly a non-goal. This is out of scope.

Two other important goals are:

- ease of use for app developers ("it just works", "feels natural")
- cross-language similarity

Rgd the latter: a developer that has used AutobahnJS should be able to transfer knowledge to use of AutobahnC++ - as much as that is possible. The idioms should be similar.

A secondary goal is to provide high quality WebSocket implementations - where it is not already in the run-time (browsers) or where no other WebSocket implementation fits the bill.


- provides state-of-the-art WebSocket client and server impl.


- browsers: already bring their own
- Node: we are using the "ws library"


- we are using websocketpp

AutobahnAndroid (but see below):

- provides own WebSocket client implementation

3) Status and future

AutobahnPython, AutobahnJS and AutobahnC++:

These are used in production applications and systems today and have already mostly reached the frontier of the scope described above.

The work still to do resolves around:

- fixing bugs
- filling gaps
- improving docs
- improving release process
- expanding test coverage


This has been unmaintained for some time, as the code base has major issues that essentially would require a complete rewrite:

- WAMP v1 only
- use of plain callbacks in user API
- no TLS (NIO sucks)

Note: Right now, for Java and WAMP, have a look at - this is WAMPv2 and based on RxJava. If you are using Akka, there is

_If_ we find time, we'd rather strive for a AutobahnJava that is:

- WAMP v2 (only)
- based on Java 8 CompletableFuture
- works on Android _and_ outside thereof


This is of strategic importance. Currently, there is no way of WAMP reaching _directly_ into embedded device targets like small microcontrollers. Think a 32 bit MCU with 64kB RAM and no MMU. Linux cannot go there. TCP already is a problem.

There has been some initial design discussions going into further detail on the issues here

Pulling this off will be non-trivial. But we love challenges;)


We do not have plans for other Autobahns.

WAMP has quite an ecosystem, with many other languages and run-times covered:

I've also be asked by WAMP client library implementors if they could bring their work under the "Autobahn" umbrella name.

In general, we'd be open to this, but the problem is: we provide commercial, professional support for all Autobahns as part of support for

And to do that, we need to understand the code base 100% and be able to fix issues quickly.

We cannot practically provide and guarantee that for a possibly open ended set of libraries.

So right now, the full set of Autobahns would be:

- AutobahnPython
- AutobahnJS
- AutobahnC++
- AutobahnC (future)
- AutobahnJava (future)