Speaking as an open-source feature flag 'vendor' (https://github.com/flipt-io/flipt), the OpenFeature organization has been a joy to work with. They are very welcoming of new contributors (e.g., implementing a provider SDK in a new language).
We've been thinking a lot recently about supporting 'edge' k/v stores like vercel/cloudflare and having the client side evaluation SDKs pull from there, which wouldn't require a server at all. This seems very similar just with using GitHub. We could even use GitHub Container Registry as the store as its OCI compliant.
Also S3 (+ azure and GCP) would be a good 'edge' k/v store.
Someone could start with Github in a simple project, migrate to S3 to handle more requests and then migrate later to a full server solution... All of this keeping the same client codebase
We already support S3, Azure and GCS, as well as OCI (any compatible registry) as a source in the open-source server-side evaluator. So if you pop a deploy step to any of these sources from your Git repo, you can use them via the Flipt server process as a source of truth in production. Our server-side and client-side SDKs can source from Flipt in these scenarios.
But, we are keen to both explore skipping the Flipt server middle-man for client-SDKs, as well as make the publish step to these locations a simple configuration process in our UI. To avoid having to write things like GH actions to achieve the end to end result.
Approvals are coming next btw. With the ability to lock down envs like production and optionally require all state changes to go through a proposal/approval process
I tried to answer your first question below, hope I did!
Re: GitHub outage, each org gets their own instance in our cluster and maintains a checkout of the git state, so you can still write/read from your environments, they just wont be synched to GitHub until they recover.
We're also thinking about adding other 'sinks' like S3/object stores and OCI as backup sinks.
This! 100% All the same benefits of config as code, infra as code. And with feature flags if something goes wrong its a simple `git revert` to get back into the previous state.
Another benefit is you can easily replicate the current (or previous) state of production/staging/etc flags locally just by doing a `git clone` and then run our self-hosted version locally. Its a single binary, can be installed with curl or homebrew and can read the flag state from your local filesytem.
This allows you to test your code locally or in CI with the same state in production
Yeah the context only supports a map/JSON object of k/v string values for evaluation at the moment.
We could definitely look into supporting other types and making this simpler. The constraints that are matched can be of several types, which we try to parse at evaluation time https://docs.flipt.io/concepts#constraint-types.
Also thank you for the feedback about not being able to change the organization name. Currently we use the 'slug' of the organization (based on the name) when we setup the routes for your environment, so it was just simpler to make it a one time thing.
But I think we could support renaming your org, it would just make the previous URLs invalid, or we could maybe handle redirects on our end too.
If you're interested in this space I'd recommend lurking in their CNCF Slack Channel https://cloud-native.slack.com/archives/C0344AANLA1 or joining the bi-weekly community calls https://community.cncf.io/openfeature/.