9 ms·

Show HN: Dorkly – Open source feature flags

203 points by drichelson 2y ago

Dorkly is a free open source Feature Flag backend for LaunchDarkly SDKs. It uses simple yaml files stored in GitHub as the source of truth. Full disclosure: made by a former LaunchDarkly employee + current fan.

drichelson 2y ago
Author here. I'm paying more attention to GitHub than the comments here so please feel free to chime in there or ask any questions: https://github.com/dorklyorg/dorkly/discussions/40 https://github.com/dorklyorg/dorkly/discussions/40
hiatus 2y ago
I like the idea of the flags being managed via normal change-management processes. In your experience, is it primarily developers in charge of enabling/disabling flags or have you seen responsibility diffused across departments (marketing, sales, etc)?
- drichelson 2y ago
  I have mostly seen developers in charge of changing flags, but there is also great value in empowering other roles to change flags (One example: sales people can unlock features as they sell them). Thankfully GitHub has an easy web-based Pull Request process. It's not as simple as a custom UI, but could be used by non-engineers to change flags.
  - vosper 2y ago
    It’s a trusting and non-siloed org that gives the sales team access to the repos
  - candiddevmike 2y ago
    > sales people can unlock features as they sell them That's a licensing thing, not a feature flag.
    - yjftsjthsd-h 2y ago
      What's the difference? Either way you're turning on and off code that's already in the application. The only difference I can immediately see is that some people do feature flags as being on or off for the entire application instance, but I'm pretty sure you can do A/B testing with them at arbitrarily fine granularity and still count as a feature flag.
    - yoz 2y ago
      Not always. The most common counter example is beta features which customers opt into, controlled by the product team. It's too early for that to be part of the license, especially because pricing often hasn't been decided yet. But there's also a surprisingly common situation with big customers who want to limit and control certain UI updates so they can ensure that employees are trained appropriately.
    - shagie 2y ago
      There are many different types of toggles of functionality. Not all of them are enabling code features. Well, they are but the why they are is what is at issue. But it's all the same code under the covers. The functionality of what is enabled encoded into a license key - that's the same type of functionality as "does this deployment allow people to sign up by email" or "has this deployment enabled the super secret power user test functionality?" But that's all under "if dataSource.toggle then {something}" https://martinfowler.com/articles/feature-toggles.html https://martinfowler.com/articles/feature-toggles.html
  - willsmith72 2y ago
    That's not a feature flag, that's a feature of the product. I would keep the 2 very distinct.
mikejulietbravo 2y ago
I'm kind of surprised they haven't already built this into the LD core
snapcaster 2y ago
If it's something controlled by the PR why is it even a feature flag? Seems like you lose a huge chunk of the benefit and might as well just change the code at that point. This to me seems like the wrong place to be controlling them, i certainly don't want to have to make a PR and merge it when a site issue is happening. Open to missing something though, curious what others experience has been
- alexchamberlain 2y ago
  I think the idea is that it's a separate flags repo?
  - snapcaster 2y ago
    Can you say more? I think i'm missing the point, in my mind that would make it even worse because you have all the problems I mentioned + merge conflicts being a possibility
    - Pet_Ant 2y ago
      Well I don't think you are doing active development on your flags repo. I think it's just using Git as a database for the what are your current feature flags.
    - irjustin 2y ago
      One repo is actual flags control-like-database. So instead of controlling flags from a website, you get the benefits of git merge, PR's, reviews, documentation etc without having to rebuild it. I like the concept since it brings accountability. But it's just a need that larger orgs have, but by that point have likely internally built a flag system and so transitioning is difficult.
      - Osyris 2y ago
        We do this at my company and another huge benefit is the ability to test config at a particular point in time. You can even git bisect to find which flag flip caused a regression.
rekoros 2y ago
If you’re looking for an open source feature flag option, also check out https://www.growthbook.io/ https://www.growthbook.io/
- peab 2y ago
  I introduced feature flags at my last company, and ended up choosing growthbook. I love how compute experiment buckets with local hashing, so you don't have to make roundtrip server calls to get flag values.
- socksy 2y ago
  In a similar vein there's also Unleash with a similar open core model https://github.com/Unleash/unleash https://github.com/Unleash/unleash
- hardwaresofton 2y ago
  There are... a bunch of them. I write a little blog (soon to be directory site) about open source and at this point I groan a little bit when I see another one (wonderful problem to have of course): https://awsmfoss.com/flagsmith https://awsmfoss.com/flagsmith https://awsmfoss.com/unleash https://awsmfoss.com/unleash https://awsmfoss.com/featbit https://awsmfoss.com/featbit https://awsmfoss.com/flagr https://awsmfoss.com/flagr
- valtlfelipe 2y ago
  There is also https://www.flipt.io/ https://www.flipt.io/ which is open source. I'm currently building https://flaggy.dev/ https://flaggy.dev/ to be simple and aiming the best user experience, but initially it will not be open source.
ripperdoc 2y ago
Not directly related to Dorkly, but we've implemented feature flags (with our own system) and found them not super-useful and was hoping for more - but we may be doing it wrong. I can certainly see feature flags working well for us when activating e.g. new mostly UI-related features, but when many services and APIs need to change in unison for new features it seems a lot harder to use feature flags in practice. Then it goes beyond just putting new feature code behind conditions, as you might need to load different dependencies, offer different version of server APIs, run on different database schemas, etc. But maybe we are missing something?
- cqqxo4zV46cp 2y ago
  You aren’t. This doesn’t mean that feature flags are useless or not worth it, but there’s no silver bullet. It is exactly as hard an engineering problem as it sounds.
- viraptor 2y ago
  You need to organise your features in a way that these are not a problem. Need different dependencies - load both. Need a different schema - write both versions, drop old later. Need new services/APIs - feature flip only the user-visible one. The flags are really useful for things like enabling just a fraction of traffic, or ensuring you can switch a feature off much quicker than a full deploy would take.
  - hinkley 2y ago
    Everyone laughs when I say this but pull up a thesaurus. When you change the semantics of a thing, you have to change names to have old+new live at the same time. Don’t trust your mastery of English (especially if it’s your second language). There’s a synonym out there that describes the new behavior as well or even better.
    - hinkley 2y ago
      Exhibit A.
- 2y ago
deleted 2y ago
[deleted]
theogravity 2y ago
Neat! I'll look into integrating this with my feature flag abstraction library: https://github.com/theogravity/feature-manager-wrapper https://github.com/theogravity/feature-manager-wrapper Edit: It looks like it's a backend replacement to LaunchDarkly, but you can still use the LD client from what I'm reading here, so there's nothing for me to integrate here.
- icansearch 2y ago
  Similar to https://openfeature.dev/ https://openfeature.dev/ ?
  - theogravity 2y ago
    Same space but I don't see any integrations listed at all on the site, just SDKs for someone to write their own integration.
    - zellyn 2y ago
      The "Providers", as they are known in OpenFeature, are typically provided by the vendors, or contributed by the community. For instance, here are is the repo for contributed Providers in Go: https://github.com/open-feature/go-sdk-contrib/tree/main/providers https://github.com/open-feature/go-sdk-contrib/tree/main/pro... And here is LaunchDarkly's official Java OpenFeature provider: https://github.com/launchdarkly/openfeature-java-server https://github.com/launchdarkly/openfeature-java-server
esafak 2y ago
I would expect an open source feature flag solution today to support https://openfeature.dev/ https://openfeature.dev/
- yoz 2y ago
  And it does, because it uses LaunchDarkly SDKs: https://docs.launchdarkly.com/sdk/openfeature https://docs.launchdarkly.com/sdk/openfeature ... though there are only three officially-supported OpenFeature adapters so far (Java, NodeJS, .NET)
  - zellyn 2y ago
    The contributed Go provider seems solid enough, although it's quite opinionated about the exact shape of your attribute map. I just recently documented it carefully in the README :-) https://github.com/open-feature/go-sdk-contrib/tree/main/providers/launchdarkly https://github.com/open-feature/go-sdk-contrib/tree/main/pro...
- hinkley 2y ago
  Is that Comic Sans?
kageiit 2y ago
Feature flags are great for safely releasing features fast. As you add more of them though, they add tech debt and make the code harder to reason about. Developers are rarely motivated to clean them up after rollout.
- _corym 2y ago
  My team leverages feature flagging heavily. Developers want to clean them up but product doesn't prioritize the tickets, and it creates more burden for QA as well having to do a full regression test.
  - goosejuice 2y ago
    Sounds like a great reason to include cleanup as part of the initial work.
  - willsmith72 2y ago
    The issue is not about feature flags then. It's stakeholders not giving engineers necessary time for upkeep, probably caused by engineers lacking ownership, or failing to communicate
    - hinkley 2y ago
      It’s a system where engineers are signing off on work that isn’t actually complete. Which is a problem we had in Waterfall and mostly solved in Agile, except for feature toggles.
- millerm 2y ago
  Then that is simply a bad lead on the team. "Do your job." (Not you)
- wetpaws 2y ago
  [dead]
- triyambakam 2y ago
  In my experience engineers usually want to remove the outdated flags but product does not prioritize that work.
dangoodmanUT 2y ago
Naming
alienchow 2y ago
Nice, thanks for sharing. I've been looking for an alternative to CDPush (Google's internal version controlled config push). Unaudited, untracked web UI based feature flagging has been my peeve with the other solutions. I'm surprised all the feature flagging solutions out there don't have this as a default. The next step would be to use an artifact versioning repository to decouple from S3.
wheresmycraisin 2y ago
I have 25 years of coding experience, built two successful businesses, and I have no idea what this thing is supposed to do.
- vyrotek 2y ago
  Think of feature flags as remote-toggleable IF statements.
  - TheCapeGreek 2y ago
    ...which still begs the question - why does it need to be an entirely different service? Probably answering my own question, but the main reason I can think of would be if your app doesn't have some kind of business admin panel capability. I suppose my bias is also that in my sphere of web dev, we build these business panels pretty frequently, so feature flags and a UI for toggling them is something that makes sense to do within the app rather than add a third party service (and associated cost + potential latency) for it.
    - xmcqdpt2 2y ago
      You mean an admin panel on a server application, right? At my current job, I'm on a platform team that supports hundreds of applications. Each of them have their own admin panels. However, there are settings that apply to all of them in our library code. For those, we use feature flags, and they are loaded from a network service, environment variables, code and config files. The overriding logic is complicated for legacy reasons and prone to bugs, so we are moving to a centralized feature flag system.
      - TheCapeGreek 2y ago
        Fair, that makes sense. Not a very common use case I think unless you're talking more about heavy use of microservices that need a feature flag across the entire suite.
- drichelson 2y ago
jerrygoyal 2y ago
i don't think most businesses need third party solution for feature flags. Just create an api and send config.
byyll 2y ago
So feature flags without the UI?
- drichelson 2y ago
  Well GitHub has a pretty simple UI for editing files + submitting pull requests, so let's say it's a different UI.
gedw99 2y ago
https://github.com/thomaspoignant/go-feature-flag https://github.com/thomaspoignant/go-feature-flag also can use GitHub
zellyn 2y ago
Assuming their (also open source) Relay Proxy[1] can connect to this successfully, the disclaimers about lack of HA might not be too concerning. We already run a giant pool of relays for our apps to connect to, both to save ingress/egress costs, and to provide a backup if LD blips out for a while. [Edit: yep, it actually uses the Relay Proxy, in offline mode. See https://github.com/dorklyorg/dorkly/wiki/5.-Architecture https://github.com/dorklyorg/dorkly/wiki/5.-Architecture] [1] https://github.com/launchdarkly/ld-relay https://github.com/launchdarkly/ld-relay
- zellyn 2y ago
  LD actually releases a crazy amount of stuff as open source. In addition to the Relay, the server SDKs are all open source too. In fact, their entire API for flag manipulation and definition (essentially all the operations you can do with their UI, but programmatically) is open too: https://app.launchdarkly.com/api/v2/openapi.json https://app.launchdarkly.com/api/v2/openapi.json One could imagine running an OpenAPI → Go/Java/Rust/Python/etc. code generator on their OpenAPI spec, and then gradually implementing their entire API as open source. Not sure how they would feel about that… although I suspect more usage of an LD-compatible API would only be good for them. Of course, it makes sense for all those things to be open. The majority of smaller startups they're competing against will have settled on OpenFeature. DataDog too releases some equivalently surprising things as open source: eg. https://vector.dev/ https://vector.dev/
- drichelson 2y ago
  It's worth noting that there is no architectural limitation preventing an HA topology: multiple Dorkly servers can be deployed behind one or more load balancers for HA + lower latency where it matters (ie web and mobile apps). If this is a limitation for anyone I'm happy to work with you on modifying the terraform module to support HA.
  - zellyn 2y ago
    Random question while you're paying attention here. In the example repo, I was unable to find a file that _didn't_ say "This file is managed by terraform. Do not edit manually." Which yaml files is one supposed to edit to actually modify the flags?
seattle_spring 2y ago
Please choose a different name. It could be the most useful product in the world, but no way am I ever advocating something called "dorkly" at work.
- zellyn 2y ago
  Ah, I've missed the CockroachDB name debate threads…
- hbn 2y ago
  I was confused at first because I immediately recognized Dorkly as a YouTube channel that was very popular on YouTube around 2010, they produced comedy animations based on video games though I'm sure the humor isn't as funny as I thought it was when I was 13. Checking now they have about 4 million subscribers. Probably not gonna be great for SEO longterm.
- drichelson 2y ago
  Fair point. I’m open to suggestions for a new name :)
  - zellyn 2y ago
    I may or may not have grabbed the "LaunchOpenly" github organization name a while back. But I was intending to use it if anyone wanted to write an API-compatible Open Source clone of LD's APIs and flag-editing UI.
Lukas1994 2y ago
Does this generate type-safe code? We ended up using https://www.hypertune.com/ https://www.hypertune.com/ to solve that problem.

203 points by drichelson 2y ago

drichelson 2y ago

Author here. I'm paying more attention to GitHub than the comments here so please feel free to chime in there or ask any questions: https://github.com/dorklyorg/dorkly/discussions/40 https://github.com/dorklyorg/dorkly/discussions/40

hiatus 2y ago

I like the idea of the flags being managed via normal change-management processes. In your experience, is it primarily developers in charge of enabling/disabling flags or have you seen responsibility diffused across departments (marketing, sales, etc)?

drichelson 2y ago
I have mostly seen developers in charge of changing flags, but there is also great value in empowering other roles to change flags (One example: sales people can unlock features as they sell them). Thankfully GitHub has an easy web-based Pull Request process. It's not as simple as a custom UI, but could be used by non-engineers to change flags.
- vosper 2y ago
  It’s a trusting and non-siloed org that gives the sales team access to the repos
- candiddevmike 2y ago
  > sales people can unlock features as they sell them That's a licensing thing, not a feature flag.
  - yjftsjthsd-h 2y ago
    What's the difference? Either way you're turning on and off code that's already in the application. The only difference I can immediately see is that some people do feature flags as being on or off for the entire application instance, but I'm pretty sure you can do A/B testing with them at arbitrarily fine granularity and still count as a feature flag.
  - yoz 2y ago
    Not always. The most common counter example is beta features which customers opt into, controlled by the product team. It's too early for that to be part of the license, especially because pricing often hasn't been decided yet. But there's also a surprisingly common situation with big customers who want to limit and control certain UI updates so they can ensure that employees are trained appropriately.
  - shagie 2y ago
    There are many different types of toggles of functionality. Not all of them are enabling code features. Well, they are but the why they are is what is at issue. But it's all the same code under the covers. The functionality of what is enabled encoded into a license key - that's the same type of functionality as "does this deployment allow people to sign up by email" or "has this deployment enabled the super secret power user test functionality?" But that's all under "if dataSource.toggle then {something}" https://martinfowler.com/articles/feature-toggles.html https://martinfowler.com/articles/feature-toggles.html
- willsmith72 2y ago
  That's not a feature flag, that's a feature of the product. I would keep the 2 very distinct.

mikejulietbravo 2y ago

I'm kind of surprised they haven't already built this into the LD core

snapcaster 2y ago

If it's something controlled by the PR why is it even a feature flag? Seems like you lose a huge chunk of the benefit and might as well just change the code at that point. This to me seems like the wrong place to be controlling them, i certainly don't want to have to make a PR and merge it when a site issue is happening. Open to missing something though, curious what others experience has been

alexchamberlain 2y ago
I think the idea is that it's a separate flags repo?
- snapcaster 2y ago
  Can you say more? I think i'm missing the point, in my mind that would make it even worse because you have all the problems I mentioned + merge conflicts being a possibility
  - Pet_Ant 2y ago
    Well I don't think you are doing active development on your flags repo. I think it's just using Git as a database for the what are your current feature flags.
  - irjustin 2y ago
    One repo is actual flags control-like-database. So instead of controlling flags from a website, you get the benefits of git merge, PR's, reviews, documentation etc without having to rebuild it. I like the concept since it brings accountability. But it's just a need that larger orgs have, but by that point have likely internally built a flag system and so transitioning is difficult.
    - Osyris 2y ago
      We do this at my company and another huge benefit is the ability to test config at a particular point in time. You can even git bisect to find which flag flip caused a regression.

rekoros 2y ago

If you’re looking for an open source feature flag option, also check out https://www.growthbook.io/ https://www.growthbook.io/

peab 2y ago
I introduced feature flags at my last company, and ended up choosing growthbook. I love how compute experiment buckets with local hashing, so you don't have to make roundtrip server calls to get flag values.
socksy 2y ago
In a similar vein there's also Unleash with a similar open core model https://github.com/Unleash/unleash https://github.com/Unleash/unleash
hardwaresofton 2y ago
There are... a bunch of them. I write a little blog (soon to be directory site) about open source and at this point I groan a little bit when I see another one (wonderful problem to have of course): https://awsmfoss.com/flagsmith https://awsmfoss.com/flagsmith https://awsmfoss.com/unleash https://awsmfoss.com/unleash https://awsmfoss.com/featbit https://awsmfoss.com/featbit https://awsmfoss.com/flagr https://awsmfoss.com/flagr
valtlfelipe 2y ago
There is also https://www.flipt.io/ https://www.flipt.io/ which is open source. I'm currently building https://flaggy.dev/ https://flaggy.dev/ to be simple and aiming the best user experience, but initially it will not be open source.

ripperdoc 2y ago

Not directly related to Dorkly, but we've implemented feature flags (with our own system) and found them not super-useful and was hoping for more - but we may be doing it wrong. I can certainly see feature flags working well for us when activating e.g. new mostly UI-related features, but when many services and APIs need to change in unison for new features it seems a lot harder to use feature flags in practice. Then it goes beyond just putting new feature code behind conditions, as you might need to load different dependencies, offer different version of server APIs, run on different database schemas, etc. But maybe we are missing something?

cqqxo4zV46cp 2y ago
You aren’t. This doesn’t mean that feature flags are useless or not worth it, but there’s no silver bullet. It is exactly as hard an engineering problem as it sounds.
viraptor 2y ago
You need to organise your features in a way that these are not a problem. Need different dependencies - load both. Need a different schema - write both versions, drop old later. Need new services/APIs - feature flip only the user-visible one. The flags are really useful for things like enabling just a fraction of traffic, or ensuring you can switch a feature off much quicker than a full deploy would take.
- hinkley 2y ago
  Everyone laughs when I say this but pull up a thesaurus. When you change the semantics of a thing, you have to change names to have old+new live at the same time. Don’t trust your mastery of English (especially if it’s your second language). There’s a synonym out there that describes the new behavior as well or even better.
  - hinkley 2y ago
    Exhibit A.
2y ago

deleted 2y ago

[deleted]

theogravity 2y ago

Neat! I'll look into integrating this with my feature flag abstraction library: https://github.com/theogravity/feature-manager-wrapper https://github.com/theogravity/feature-manager-wrapper Edit: It looks like it's a backend replacement to LaunchDarkly, but you can still use the LD client from what I'm reading here, so there's nothing for me to integrate here.

icansearch 2y ago
Similar to https://openfeature.dev/ https://openfeature.dev/ ?
- theogravity 2y ago
  Same space but I don't see any integrations listed at all on the site, just SDKs for someone to write their own integration.
  - zellyn 2y ago
    The "Providers", as they are known in OpenFeature, are typically provided by the vendors, or contributed by the community. For instance, here are is the repo for contributed Providers in Go: https://github.com/open-feature/go-sdk-contrib/tree/main/providers https://github.com/open-feature/go-sdk-contrib/tree/main/pro... And here is LaunchDarkly's official Java OpenFeature provider: https://github.com/launchdarkly/openfeature-java-server https://github.com/launchdarkly/openfeature-java-server

esafak 2y ago

I would expect an open source feature flag solution today to support https://openfeature.dev/ https://openfeature.dev/

yoz 2y ago
And it does, because it uses LaunchDarkly SDKs: https://docs.launchdarkly.com/sdk/openfeature https://docs.launchdarkly.com/sdk/openfeature ... though there are only three officially-supported OpenFeature adapters so far (Java, NodeJS, .NET)
- zellyn 2y ago
  The contributed Go provider seems solid enough, although it's quite opinionated about the exact shape of your attribute map. I just recently documented it carefully in the README :-) https://github.com/open-feature/go-sdk-contrib/tree/main/providers/launchdarkly https://github.com/open-feature/go-sdk-contrib/tree/main/pro...
hinkley 2y ago
Is that Comic Sans?

kageiit 2y ago

Feature flags are great for safely releasing features fast. As you add more of them though, they add tech debt and make the code harder to reason about. Developers are rarely motivated to clean them up after rollout.

_corym 2y ago
My team leverages feature flagging heavily. Developers want to clean them up but product doesn't prioritize the tickets, and it creates more burden for QA as well having to do a full regression test.
- goosejuice 2y ago
  Sounds like a great reason to include cleanup as part of the initial work.
- willsmith72 2y ago
  The issue is not about feature flags then. It's stakeholders not giving engineers necessary time for upkeep, probably caused by engineers lacking ownership, or failing to communicate
  - hinkley 2y ago
    It’s a system where engineers are signing off on work that isn’t actually complete. Which is a problem we had in Waterfall and mostly solved in Agile, except for feature toggles.
millerm 2y ago
Then that is simply a bad lead on the team. "Do your job." (Not you)
wetpaws 2y ago
[dead]
triyambakam 2y ago
In my experience engineers usually want to remove the outdated flags but product does not prioritize that work.

dangoodmanUT 2y ago

Naming

alienchow 2y ago

Nice, thanks for sharing. I've been looking for an alternative to CDPush (Google's internal version controlled config push). Unaudited, untracked web UI based feature flagging has been my peeve with the other solutions. I'm surprised all the feature flagging solutions out there don't have this as a default. The next step would be to use an artifact versioning repository to decouple from S3.

wheresmycraisin 2y ago

I have 25 years of coding experience, built two successful businesses, and I have no idea what this thing is supposed to do.

vyrotek 2y ago
Think of feature flags as remote-toggleable IF statements.
- TheCapeGreek 2y ago
  ...which still begs the question - why does it need to be an entirely different service? Probably answering my own question, but the main reason I can think of would be if your app doesn't have some kind of business admin panel capability. I suppose my bias is also that in my sphere of web dev, we build these business panels pretty frequently, so feature flags and a UI for toggling them is something that makes sense to do within the app rather than add a third party service (and associated cost + potential latency) for it.
  - xmcqdpt2 2y ago
    You mean an admin panel on a server application, right? At my current job, I'm on a platform team that supports hundreds of applications. Each of them have their own admin panels. However, there are settings that apply to all of them in our library code. For those, we use feature flags, and they are loaded from a network service, environment variables, code and config files. The overriding logic is complicated for legacy reasons and prone to bugs, so we are moving to a centralized feature flag system.
    - TheCapeGreek 2y ago
      Fair, that makes sense. Not a very common use case I think unless you're talking more about heavy use of microservices that need a feature flag across the entire suite.
drichelson 2y ago

jerrygoyal 2y ago

i don't think most businesses need third party solution for feature flags. Just create an api and send config.

byyll 2y ago

So feature flags without the UI?

drichelson 2y ago
Well GitHub has a pretty simple UI for editing files + submitting pull requests, so let's say it's a different UI.

gedw99 2y ago

https://github.com/thomaspoignant/go-feature-flag https://github.com/thomaspoignant/go-feature-flag also can use GitHub

zellyn 2y ago

Assuming their (also open source) Relay Proxy[1] can connect to this successfully, the disclaimers about lack of HA might not be too concerning. We already run a giant pool of relays for our apps to connect to, both to save ingress/egress costs, and to provide a backup if LD blips out for a while. [Edit: yep, it actually uses the Relay Proxy, in offline mode. See https://github.com/dorklyorg/dorkly/wiki/5.-Architecture https://github.com/dorklyorg/dorkly/wiki/5.-Architecture] [1] https://github.com/launchdarkly/ld-relay https://github.com/launchdarkly/ld-relay

zellyn 2y ago
LD actually releases a crazy amount of stuff as open source. In addition to the Relay, the server SDKs are all open source too. In fact, their entire API for flag manipulation and definition (essentially all the operations you can do with their UI, but programmatically) is open too: https://app.launchdarkly.com/api/v2/openapi.json https://app.launchdarkly.com/api/v2/openapi.json One could imagine running an OpenAPI → Go/Java/Rust/Python/etc. code generator on their OpenAPI spec, and then gradually implementing their entire API as open source. Not sure how they would feel about that… although I suspect more usage of an LD-compatible API would only be good for them. Of course, it makes sense for all those things to be open. The majority of smaller startups they're competing against will have settled on OpenFeature. DataDog too releases some equivalently surprising things as open source: eg. https://vector.dev/ https://vector.dev/
drichelson 2y ago
It's worth noting that there is no architectural limitation preventing an HA topology: multiple Dorkly servers can be deployed behind one or more load balancers for HA + lower latency where it matters (ie web and mobile apps). If this is a limitation for anyone I'm happy to work with you on modifying the terraform module to support HA.
- zellyn 2y ago
  Random question while you're paying attention here. In the example repo, I was unable to find a file that _didn't_ say "This file is managed by terraform. Do not edit manually." Which yaml files is one supposed to edit to actually modify the flags?

seattle_spring 2y ago

Please choose a different name. It could be the most useful product in the world, but no way am I ever advocating something called "dorkly" at work.

zellyn 2y ago
Ah, I've missed the CockroachDB name debate threads…
hbn 2y ago
I was confused at first because I immediately recognized Dorkly as a YouTube channel that was very popular on YouTube around 2010, they produced comedy animations based on video games though I'm sure the humor isn't as funny as I thought it was when I was 13. Checking now they have about 4 million subscribers. Probably not gonna be great for SEO longterm.
drichelson 2y ago
Fair point. I’m open to suggestions for a new name :)
- zellyn 2y ago
  I may or may not have grabbed the "LaunchOpenly" github organization name a while back. But I was intending to use it if anyone wanted to write an API-compatible Open Source clone of LD's APIs and flag-editing UI.

Lukas1994 2y ago

Does this generate type-safe code? We ended up using https://www.hypertune.com/ https://www.hypertune.com/ to solve that problem.