AsyncAPI Initiative

You'll be helping AsyncAPI's maintainers manage a project used by thousands of developers around the world.

The funds are intended to be used to support full-time maintainers vs. just a small group of volunteers. More funding would also allow us to grow the tooling support, which we think is crucial for adoption.

We're on a mission to standardize message-based communication and increase interoperability of the different types of messaging systems available.

The messaging world is full of schema formats and protocols. Some of us prefer to use a combination of Google's protobuf with AMQP, or Avro with Kafka, or Avro with MQTT, or protobuf with MQTT, ... you guess it.

In production systems, it's common to find REST APIs, GraphQL APIs, and message-driven APIs working together. All of them serving as different interaction layers for the same data/operations. REST is usually defined using the OpenAPI specification, GraphQL has its own built-in schema language, and message-driven APIs now have AsyncAPI.

AsyncAPI is a common language for all the different protocols and schema formats, but we need to make it easy for developers to create new message-driven systems, in their programming language of choice. A quick calculation takes us to 120 possible combinations, assuming we create tooling for 6 programming languages (e.g., Java, Node.js, Go, Python, PHP, and Ruby), 4 schema formats (OpenAPI schemas, JSON Schema, Protobuf, and Avro), and 5 protocols (AMQP 0-9-1, AMQP 1.0, MQTT, Kafka, and WebSockets). We know it's a huge challenge, but we accept it 💪

REST APIs have OpenAPI. Messaging has AsyncAPI.