PricingDocs

Announcing the source availability of the Capture SDK

Today we are extremely excited to announce the source availability of the Capture SDK. Read on for details about why we are doing this, a high level overview of the repositories now publicly available, and a discussion of the chosen licensing structure.

Announcing the source availability of the Capture SDK
bitdrift Capture’s goal is to fundamentally reimagine mobile observability: we couple on-device intelligence with a sophisticated control plane in order to send 1000x the telemetry at 0.01x the cost of traditional observability solutions. By the very nature of the system we have built, the code that runs on the client is very non-trivial. On one hand, it would make business sense to keep this substantial investment completely closed source; we have put the money of our investors and our own time and effort into development. Why share a portion of our special sauce with competitors? On the other hand, for years the industry has been moving away from accepting closed source SDKs being embedded in larger codebases. Organizations do not want to risk taking on black box code that they cannot inspect for security and functionality issues, nor can they actively debug in the field if something goes wrong. Organizations are also increasingly hesitant to depend on technologies that require explicit vendor lock-in. While we have inked private source availability agreements with large customers and could continue to do so, we felt it would be more beneficial to see if we could find a licensing scheme that would allow the code to be developed publicly on GitHub, inspected by anyone around the world that wishes to do so, and used for a multitude of purposes that do not conflict with our business interests.

What is now source available

Today we are releasing publicly three repositories that are now available on GitHub:
  1. capture-sdk:This is the primary mobile SDK repository which contains the Android and iOS SDKs, platform specific Kotlin and Swift code, and bindings to call into the common Rust core code.
  2. shared-core: The majority of our client code is written in Rust and shared across every platform that we deploy to (gratuitous foreshadowing). This repository contains a number of Rust crates that are used both within the mobile SDKs as well as our server-side infrastructure. The “bones” of our client SDK can be found here including the ring buffer, the core logger, and the workflow engine.
  3. api: Our client SDKs use a bidirectional gRPC streaming API to communicate with our control plane. The control plane sends instructions to clients, the clients execute those instructions, and return telemetry based on the result of on-device processing. This repository contains the protobuf and flatbuffer API definitions required to implement a control plane that can interoperate with our SDKs.

Source available vs. OSS

As is probably already obvious, we have chosen to license all of the released code using a source available vs. a true OSS license. Before getting into the specific details of the license we have chosen, let’s first describe the overall goals we had in mind for the licensing structure:
  1. We wanted all code to be publicly available on GitHub. We are proud of this code and we want to share with the world the technical details of what we have accomplished.
  2. We wanted the code to be usable for any purpose that does not compete with our business interests - this includes permission to write a private control plane and UI on top of our client SDKs.
That’s it. Fundamentally, we want to share the code, allow its use, but prevent competitors and large infra/observability providers from implementing a competing paid SaaS built on top of our SDKs and APIs. After investigating various options we found the PolyForm Shield license to be the best match for our intended goals. We were drawn to this license because:
  1. The PolyForm family of licenses were drafted by experts in the field of source available and OSS licensing. We had no interest in developing a custom one-off license.
  2. The license is easy to read and understand.
  3. The license allows permissive use of the code for any purpose, other than competing with the business interests of bitdrift.
Obviously what constitutes “competition” might seem complicated (see our licensing FAQ for more information on this), but we feel that overall the Shield license hits every note that we are looking for. Thank you to the PolyForm project for such a great resource!

The future of observability

We have an extremely exciting roadmap ahead for Capture. The possibilities are nearly endless when coupling a smart client with a sophisticated control plane. We are thrilled to be able to develop the client and APIs in the open moving forward and encourage any curious organizations to join us on this journey. If the lack of source code was keeping you away, now is the time to give us a try! Interested in learning more? Check out the sandbox to get a hands-on feel for what working with Capture is like and then get in touch with us for a demo. Please join us in Slack as well to ask questions and give feedback!

Stay in the know, sign up to the bitdrift newsletter.

Author