6 ms·

I know this is a peak HN comment, but I really fail to see the appeal of using a third-party solution for something so basic. In my applications, feature flags

by heipei 4y ago

I know this is a peak HN comment, but I really fail to see the appeal of using a third-party solution for something so basic. In my applications, feature flags are simply controlled via a "tags" field per user and per team. Additionally, each subscription plan has a "tags" field attached to it that is merged with the user and team tags. The logic of how the application behaves in each case is something you have to write yourself either way, so the only thing these third-party applications are doing are managing a list of flags on your behalf the way I see it. I don't see how someone would pay for that and also expose their user information to a third party for something so simple. Maybe I'm missing something?

andruby 4y ago
Having had to implement custom billing logic and working in a startup that is still figuring out how to best price & bundle its product, I can see the value of this. I think this enables non-engineers to define pricing rules and the associated features. I wonder if this could integrate well with getlago.com (we're looking at integrating that after years which feel partially wasted on implementing custom billing logic)
- nirga 4y ago
  We're currently working on metering and billing integration so I'm not sure if such integration makes sense.
  - andruby 4y ago
    Thank you for the reply. If anything, you can learn from the choices Lago made. It's not easy making a metering and billing system that works well enough for the majority of use-cases.
- jmacd 4y ago
  I'd love your feedback on https://priceops.org https://priceops.org We recently open sourced Tier http://github.com/tierrun/tier http://github.com/tierrun/tier which combines metering, entitlements, feature flags and a client side SDK to simplify things.
  - andruby 4y ago
    tier seems interesting when using Stripe. We don’t so I can’t really comment.
- trynewideas 4y ago
  100% LD is targeted at product managers, technical account managers, and any other non-developers who want to gate feature rollouts. The devs can just focus on implementing features, flag them, and then forget about it. That said, LD is an expensive daily pain in my ass, and anything better, or even a little worse but cheaper, than it catches my attention.
nirga 4y ago
I get it - that's why it's open-source. You can just run it on-prem. What you suggested gets complex once you want to start making changes to your subscription plans. Let's say you want to experiment with different configurations. You'd then need to remember which customers were signed up with the "old" package configuration and each of the arms of your experiment, for example.
TrickyRick 4y ago
Most companies are not in the business of building UIs for rule engines, A/B-testing, user segmentation, etc. The value of giving non-engineers the power to roll out features without code changes is worth quite a lot. (Where I work we recently went from a home-rolled feature flag system similar to what you described to using LaunchDarkly)
- gitgud 4y ago
  Agreed, dynamically serving features based on a database flag is just one part. There's A/B analytics, rolling out to specific user segments, recognizing stale flags etc... You could always build it all your self, but I guess you could build a lot of things your self...
  - VicVee 4y ago
    Beyond that, who's maintaining it? Are you going to be able to deploy these things across every single one of your systems? Your website? Your apps? In conjunction? I absolutely understand that you could just read somejson from a cdn and call it a day, but at some point someone is going to have to maintain it and become the defacto feature flag person lol
- tofuahdude 4y ago
  How is using LaunchDarkly home-rolling a feature flag system?
  - prh8 4y ago
    They are saying they started home-rolled and switched to LD
  - TrickyRick 4y ago
    Like the other person wrote we switched from a home-rolled system to LaunchDarkly.
dd82 4y ago
That works great for simple things. how do you tie a specific feature flag to a cross-engineering organization feature that's under rollout with input from multiple projects? django-waffle is an example of your approach, and worked pretty well in a monolithic environment. But it also exposed multiple issues in coordination in a service oriented environment, which is one reason why O'Reilly went to LaunchDarkly around 2018.

by heipei 4y ago

andruby 4y ago

Having had to implement custom billing logic and working in a startup that is still figuring out how to best price & bundle its product, I can see the value of this. I think this enables non-engineers to define pricing rules and the associated features. I wonder if this could integrate well with getlago.com (we're looking at integrating that after years which feel partially wasted on implementing custom billing logic)

nirga 4y ago
We're currently working on metering and billing integration so I'm not sure if such integration makes sense.
- andruby 4y ago
  Thank you for the reply. If anything, you can learn from the choices Lago made. It's not easy making a metering and billing system that works well enough for the majority of use-cases.
jmacd 4y ago
I'd love your feedback on https://priceops.org https://priceops.org We recently open sourced Tier http://github.com/tierrun/tier http://github.com/tierrun/tier which combines metering, entitlements, feature flags and a client side SDK to simplify things.
- andruby 4y ago
  tier seems interesting when using Stripe. We don’t so I can’t really comment.
trynewideas 4y ago
100% LD is targeted at product managers, technical account managers, and any other non-developers who want to gate feature rollouts. The devs can just focus on implementing features, flag them, and then forget about it. That said, LD is an expensive daily pain in my ass, and anything better, or even a little worse but cheaper, than it catches my attention.

nirga 4y ago

I get it - that's why it's open-source. You can just run it on-prem. What you suggested gets complex once you want to start making changes to your subscription plans. Let's say you want to experiment with different configurations. You'd then need to remember which customers were signed up with the "old" package configuration and each of the arms of your experiment, for example.

TrickyRick 4y ago

Most companies are not in the business of building UIs for rule engines, A/B-testing, user segmentation, etc. The value of giving non-engineers the power to roll out features without code changes is worth quite a lot. (Where I work we recently went from a home-rolled feature flag system similar to what you described to using LaunchDarkly)

gitgud 4y ago
Agreed, dynamically serving features based on a database flag is just one part. There's A/B analytics, rolling out to specific user segments, recognizing stale flags etc... You could always build it all your self, but I guess you could build a lot of things your self...
- VicVee 4y ago
  Beyond that, who's maintaining it? Are you going to be able to deploy these things across every single one of your systems? Your website? Your apps? In conjunction? I absolutely understand that you could just read somejson from a cdn and call it a day, but at some point someone is going to have to maintain it and become the defacto feature flag person lol
tofuahdude 4y ago
How is using LaunchDarkly home-rolling a feature flag system?
- prh8 4y ago
  They are saying they started home-rolled and switched to LD
- TrickyRick 4y ago
  Like the other person wrote we switched from a home-rolled system to LaunchDarkly.

dd82 4y ago

That works great for simple things. how do you tie a specific feature flag to a cross-engineering organization feature that's under rollout with input from multiple projects? django-waffle is an example of your approach, and worked pretty well in a monolithic environment. But it also exposed multiple issues in coordination in a service oriented environment, which is one reason why O'Reilly went to LaunchDarkly around 2018.