📣 RFC: Close sourcing this API and providing an SDK

[jpmcb]

As OpenSauced's services and foundation grow, the @open-sauced/engineering team is considering close sourcing this API source code. This is a request for comment (RFC) since we'd like to engage with the community to help us get a better understanding of the impact!

Why are we considering close sourcing open-sauced/api?

1. The complexity of making open source contributions into this code base from the broader OpenSauced community has grown significantly. Today, in order to bootstrap and get started with running the API, you need an active and populated Timescale database for events, a postgres database for users/metadata, an OpenAI API key, Supabase, a Bing search API key, and more. This is a pretty heavy lift and we haven't seen any active contributions in some time. Further, much of the necessary infrastructure (like the database schema for Timescale) is closed source. This means that it's effectively impossible for a non-OpenSauced employee to run the API without a connection that TypeORM can validate against an accurate schema in Timescale. This decision would more or less be bringing things closer in line with the reality of running the API as an outside contributor.
2. Operationally, this API has reached a point in its maturity where the engineering team needs to consider fewer bespoke "open" solutions and more internal operational solutions for managing our infrastructure and code. Because this API integrates so deeply with our entire product stack, it's a bit awkward trying to manage an open source repository while, behind the scenes, we try to manage a deeply integrated stack that doesn't make sense to bring into the open. For reference, https://github.com/open-sauced/api/issues/722 highlights some of the difficulty in managing these two different (and often competing) worlds. This means that if we close sourced this codebase, OpenSauced would be able to integrate the API vertically with more services, execute on operational DevOps tasks not appropriate for the open source, lift and shift our internal operations solutions to more "infra-as-code", move faster, and ship more features to client consumers.
3. In order to protect the intellectual "brain-trust" of OpenSauced, we have considered moving the most sensitive bits of future OpenSauced platform architectures and implementations to separate micro-services, outside of this API. This has already happened in a few cases (like our data ingestion pipelines, a few AI micro-services, etc.). But, for our small engineering team, the current "monolithic" API works really well as a centralized "hub" where many service spokes can be integrated and still service clients. Splitting this API, with the current team bandwidth, into small micro-services in service of protecting the most sensitive intellectual ideas would be ok, but for ease of our operations, we'd likely want to go down the road of close sourcing the entire API codebase so we can continue to move fast on integrating services and implementing new features.

What does this mean for code consumers of the API?

If you are a "code consumer" of this codebase (i.e., you run the OpenSauced API somewhere, you utilize some of the source code in your project/product as a downstream consumer, you have built additional applications on-top of the OpenSauced source code, etc.) - we want to hear from you! Currently, we are unaware of any direct code consumers.

If we don't hear from anyone in the coming weeks / months, we will make a decision and proceed with close sourcing this codebase. Any commits, changes, or content will continue to be licensed under the MIT license up to the point of the close sourcing. Communications will happen in this issue.

What does this mean for clients of the API?

Nothing! The API service itself will continue to be public and used by the OpenSauced platform and any other clients that want to connect to it! We also plan to continue providing a public swagger doc: https://api.opensauced.pizza/ that can be used to explore the API's controllers and routes.

Envisioning the OpenSauced SDK

In the future, we plan to build an OpenSauced SDK: this would be a single TypeScript package / library that anyone could use to integrate with the OpenSauced public API. This, like many other SDKs, would be open sourced and would become the defacto place to build ontop of OpenSauced and use the API.