Good question - teams should do what’s best for them based on their resources and scope of feature flagging needs. Though open source libraries exist, they're per language (Ruby, Python). We offer support for all major languages + iOS. As well, we have environment support and access control levels to use feature flags effectively throughout development. You can read more here: http://blog.launchdarkly.com/enterprise-requirements-for-man...

Any hope for Android support?

Yes, we are planning on adding Android this summer. Are you interested in being a beta user? Write us at support at launchdarkly.com

Hi, I’m Edith Harbaugh, CEO & co-founder of LaunchDarkly. Feature flagging/toggling is a best practice of continuous delivery. Feature flagging is easy - you can do it with a config file or a database field. However, once you start feature flagging at scale, your feature flag config files can become a junk drawer & a form of technical debt.

LaunchDarkly is a feature flag management system that allows you to scale up. You get an intuitive UI that non-technical users can control feature flags with - for example, a Product Manager can turn on functionality. We also give you access level controls and audit logging - allowing you to control who can change which feature flag and get visibility on these changes. As well, we offer SDKs for multiple languages so you can use feature flags consistently, across mobile and web. When you’re ready to use feature flags at scale, we hope you’ll use LaunchDarkly.

Would love your feedback about how you’re using feature flags already, and what you’d expect to see from a feature flag management system.

So how exactly does launchdarkly help with feature flags becoming a junk drawer/tech debt? I can see how the intuitive ui would help in general, but what I was really expecting to see was:

* A way to manage dependent feature flags, because god knows once those non-technical(and technical) users have switches they can throw, they're going to ask for/build features that are dependent on each other in subtle ways

* A distinction between a true feature flag and what I call a "release" flag, ie, a feature that's not yet fully built, but that will not be optional once fully built and released, so its flag goes away at some point.

Also, btw, do you have an API for the flag creation itself, not its use, ie a addFlag()/removeFlag() API?

We do have some features to help manage the lifecycle of feature flags. For example, we can determine when a flag has been "flipped on" for everyone, and notify you that it's time to remove it. We can also determine that a flag has been removed from your codebase, and prompt you to remove it from LD (http://blog.launchdarkly.com/launched-flag-status-indicators...).

We have more coming, including an ability to mark "permanent" flags that should never be removed.

The product is built API-first-- everything in our UI is driven via our own REST API. Docs are here: http://apidocs.launchdarkly.com/

Thanks for the response. This is the confusing part for me: I've been talking in terms of Feature toggles as described by Martin Fowler: http://martinfowler.com/articles/feature-toggles.html, but it looks like LD is focusing on the AB testing piece primarily, with some parts of the base toggle functionality included by default.

Can there be a feature switch that is configured not based on users, but on owner/admin's choice alone?

More importantly, how do the LD SDKs help with the issues mentioned in the "Implementation Techniques" section of Fowler's essay - things like avoiding conditionals, DI, etc?

Our goal is to build a developer-focused platform that gives teams the ability to adopt feature flags as a core part of their dev cycle-- including pretty much all of the use cases described in Fowler's article (ops, permissioning, etc.). Many of our customers are not using us for A/B testing at all.

re: conditionals, DI: our SDKs focus on the base technique (flags based on conditionals), but it's possible to wrap that core with higher-level approaches like DI, etc. We're considering going down that path, but where it makes sense to do so, and not have to re-implement higher-level wrappers for every framework out there. So, e.g.-- in Ruby, I can see us providing higher-level APIs specific to Rails.

Dependent feature flags are also an interesting problem-- we don't have a solution to that yet, but we do spend a lot of time thinking about feature flags, and I hope we'll have something on that front soon :)

Yeah, this is exactly what my dev teams need right now. I reached out to you just now with my @agco email address on your "schedule a demo" button. Some advice - MAU is not connected to value delivered.

[edit] How much is premium support?

Thanks! Responded to your email.