OpenFeature and Feature Flags: English Vocabulary for Progressive Delivery
Build the English vocabulary you need to discuss feature flags, progressive rollouts, and the OpenFeature CNCF standard in engineering team conversations.
Feature flags have transformed how engineering teams ship software. Instead of big-bang releases, teams roll out changes gradually, test with subsets of users, and kill problematic features instantly without a deploy. But to participate in these conversations — in planning meetings, code reviews, and postmortems — you need the right English vocabulary. This post covers it all, from the basic concept to the OpenFeature CNCF standard.
Core Feature Flag Terms
Feature flag (also: feature toggle) — a conditional check in code that enables or disables a feature at runtime, without deploying new code. The term “flag” comes from the binary on/off nature of the original concept.
“We ship the new checkout flow behind a feature flag so we can enable it for internal testers first before rolling it out to all users.”
Feature toggle — an older, interchangeable term for feature flag. Some teams prefer “toggle” because it better describes the on/off switching behavior. The two terms are used synonymously in most codebases.
“The PM asked us to turn on the dark mode toggle for beta users only — it’s already in the code, just gated by a toggle.”
Progressive rollout — a deployment strategy where a feature is gradually enabled for larger and larger percentages of users over time, allowing teams to monitor for issues before full release.
“We’re doing a progressive rollout: 1% of traffic today, 10% tomorrow, 50% by Friday if the error rate stays flat.”
Canary release — a type of progressive rollout where a small “canary” group of users receives a new version first. If no problems emerge, the release is widened. The name comes from the historical use of canaries in coal mines as early warning systems.
“The canary release showed a 3x increase in cart abandonment for that user segment — we pulled the flag immediately.”
Kill switch — a feature flag used specifically to disable a feature quickly in production without a code rollback. Every major feature should have one.
“We shipped the payment provider integration with a kill switch. When they had an outage on Tuesday, we flipped it off in 30 seconds.”
OpenFeature and Tooling Terms
OpenFeature — a CNCF (Cloud Native Computing Foundation) open standard that defines a vendor-neutral API for feature flagging. It lets teams switch between providers like LaunchDarkly, Flagsmith, or Unleash without rewriting their application code.
“We adopted OpenFeature so we’re not locked into LaunchDarkly — if we switch to Flagsmith next year, we only update the SDK provider, not the evaluation calls.”
Evaluation context — the data passed to a feature flag SDK when evaluating a flag. Typically includes user ID, region, plan tier, or other targeting attributes.
“Pass the user’s subscription tier in the evaluation context so the flag system can apply different rules for free vs. paid accounts.”
Targeting rule — a condition that determines which users or environments see a flag as enabled. Rules can target specific user IDs, percentage of traffic, regions, or custom attributes.
“Add a targeting rule that enables the feature for anyone with an email ending in @company.com — that’s our internal dog-food group.”
Flag lifecycle — the stages a feature flag goes through: creation, rollout, full release, and eventual removal. Stale flags that never get removed accumulate as technical debt.
“We have 40 flags in production that are permanently enabled and were never cleaned up. Flag lifecycle management is now on the Q3 roadmap.”
Trunk-based development with flags — a branching strategy where all developers commit to the main branch frequently, using feature flags to hide incomplete work instead of long-lived feature branches.
“We moved to trunk-based development last year. Feature flags replaced our two-week-long feature branches — merge conflicts dropped dramatically.”
Real IT Context Phrases
- “The flag is dark-launched but not yet enabled for any users.” — status update in a standup, meaning code is deployed but no one can see it yet
- “We need to clean up the flags from the Q1 migration — they’re all permanently true now.” — technical debt discussion in a sprint retrospective
- “Can you add a targeting rule to enable this for the QA team’s user IDs?” — request during a code review or deployment meeting
- “The flag evaluation is happening server-side, not client-side — there’s no UI flicker.” — architecture clarification in a design review
- “We’re at 25% rollout and p95 latency is unchanged — I’ll bump it to 50% after the morning peak.” — rollout status update in Slack
Key Collocations
| Collocation | Example |
|---|---|
| flip a flag | ”Flip the flag back to false — we’re seeing errors in the EU region.” |
| roll out a feature | ”We’ll roll out the feature to 10% of users starting Monday.” |
| enable for | ”Enable the new dashboard only for beta users initially.” |
| gate behind a flag | ”All new payment methods must be gated behind a flag at launch.” |
| stale flag | ”That stale flag has been true for eight months — time to remove the conditional.” |
| evaluate a flag | ”The SDK evaluates the flag on every request using the user’s context.” |
| percentage rollout | ”Start with a 5% percentage rollout and monitor the error rate.” |
Practice
Look at the last feature your team shipped. Write a short English paragraph (5–7 sentences) describing how you would have used a feature flag to release it progressively. Include: what the flag would gate, what your targeting rules would be, what percentage rollout schedule you would follow, and what metric would tell you it is safe to go to 100%. Use at least five vocabulary terms from this post. This kind of writing directly mirrors what you would put in a technical design document or a deployment runbook.