Uber open-sources tool to automatically clean up stale code

I wouldn't call it unusual although I hear FOSS more often.

To be fair, I am a native english speaker and this is the first time I've seen it used as a verb. "OSS" generally acts as a noun. In this instance I would have used "open source" as the verb of what you could do to your proprietary Software, after which it would become OSS.

I wouldn’t add that to your list of widely understood verbs based on a single HN comment. Any noun can be (mis)used as a verb in modern English, if speaking very informally, and often with a slight tongue-in-cheek humour about the clunky incorrectness of it. Some examples eventually become mainstream (to google something, to text someone, to roadmap it).

Other commenters saying it isn't used as a verb are wrong. They're correct that people never say "I open-source softwared my last project."

However you can definitely use "open-source" as a verb: "I open-sourced my last project." It's pretty common. And in this case "OSS" stands for "open-source", not "open-source software".

What's confusing you is that when we use the abbreviation "OSS" we're really intended people to read that as "open-source" even though the abbreviation technically means "open-source software". btw, you would never verbally spell out "OSS"—chiefly because it's the same number of syllables as "open-source".

Partitioning by instance works if you have enough instances to avoid big increases, but at that point you can just deploy known-good and new-feature builds. Runtime checking helps if it's a lot faster than rolling back to the known-good build, or if you're doing concurrent experiments (you may not have enough instances to try every possible combination).

Then rolling forwards and backwards is a whole deployment away, or mucking about with infrastructure, vs tweaking a percentage flag somewhere.

If you want to get fancy with changes (and I've seen it done) you have something else capable of controlling that percentage setting that is tied in to your monitoring. Start out low, say 1% of requests hitting the new path. Automatically ramp up over time to full 100%. If you see failures, automatically drop back to 0% until it can be ascertained that the failure didn't come from the new code.

You mean unit testing? You can add a way in your framework to force the flag on.

I think it might be less confusing to say, how do you verify the feature? As in: how do engineers and product managers and designers know that the flagged behavior is correct and how do you verify that in production if all you do is ramp up? How do you make sure the interested parties are always bucketed into the on experiment?

Yes, but you move the logic for deciding which branch to take to an underlying function. It pollutes the parent function less, but results in more overall functions for places to hide.

Also, if the logic gets more complicated than just an if statement (if Permision... and date < cutoffdate: etc) you don't further pollute the parent function.

Naah, but at least that would make the decision simple and clear (if condition return doA else return doB).

Better would be for whatever ThingFactory or getThingService instantiates the Thing to make the decision, and compute it up front.

If-else statements in application logic tangle the concepts of "what should be done and why?" with "let me do this Way 1" and "let me do this Way 2". Ideally a typical service (or model or similar) shouldn't be aware that "feature flags" as a concept exist, and this should be regarded as inimical to their encapsulation. It should just know that it delegates a decision to Way N.

I thought between Google, VLS, Tom Tom, and I can't imagine that I just coughed up a complete list, there'd be enough competition to just procure this function competitively. I assumed it was more the Not Invented Here syndrome of a VC funded company who (until recently) had little of a cap on their Engineering spend.