Policy on development against non-supported protocols, like Ably native protocol

[mattheworiordan]

A few customers have, in the absence of an SDK for their platform, opted to build their own libraries that connect to Ably's realtime endpoints, and communicate with Ably using the native Ably protocol. More recently PTFarm have done this.

This is problematic for a number of reasons:

1. We cannot support them if they have issues. We have a very detailed and well tested client library specification that has been battle-test in production, and we know that if client libraries adhere to that spec, then the public APIs provided by those SDKs have predictable behaviours and thus we can support widely across our teams. If a customer implements code that uses the native protocol, we have a) no visibility into which parts of the protocol they support, b) which parts of the client lib spec they adhere to, c) their implementation logic (closed source).

2. If we help customers by answering any questions they have in regards to the custom protocol implementation, this is time consuming and won't scale as the business grows. We have invested heavily in SDKs and documented protocols we support so that we can scale the business with more customers. Each time an issue is encountered with a customer, we fix this in our docs, underlying SDKs, or service. Every time we answer a question for a customer who implements an unsupported protocol, this is a time sync from the most experienced engineers in the company (who have a deep protocol understanding), and worse more tightly couples these customers to a protocol we won't continue to support.

3. The implementations are likely to be very brittle for the customer. If we make changes to our protocol, knowing that all SDKs are unaffected by these changes, we will be unable to be confident these changes won't break custom implementations by customers who use the native protocol in ways we cannot imagine.

Actions

1. Document in our support articles why we don't support customers who opt to implement our native Ably protocol, unless:
   1. They open source their work in a way that other developers could reuse their community Ably SDKs
   2. They follow the Ably client library specification, and we help with their implementation of the specification. In this way, we're not supporting custom implementation, but instead helping people build Ably SDKs that can be supported.
   3. They wrap an existing SDK and open source that, and we too will provide support.
2. Document what we do support, namely:
   1. Ably SDKs (realtime & REST)
   2. Adapter protocols, MQTT, SSE, PubNub (subset) and Pusher (subset)
   3. Direct REST API (although we advise against that anyway given we have Ably SDKs for REST)

┆Issue is synchronized with this Jira Task by Unito

[paddybyers]

sgtm