Proposal: Automatically self destruct after 24 hours when alpha features are enabled

[negz]

What problem are you facing?

https://docs.crossplane.io/latest/learn/feature-lifecycle/#alpha-features

Crossplane uses a feature lifecycle similar to upstream Kubernetes. When we first ship a feature, we mark it alpha. It's off by default, and we tell folks it's not recommended for production use.

We ship features as alpha to test them and learn whether:

• They appear to solve a real problem for folks
• We got the API and concepts right
• They're relatively stable and performant

Our contract around alpha features is that we can make breaking changes or even remove them at any time. The goal behind this contract is to lower the bar to get features in peoples' hands. To lower the bar to let folks experiment and give us real feedback. We never ship an alpha feature we already know isn't what we want, but knowing we don't have to support ¹ alpha implementations allows us to move a little faster and spend less time agonizing over the design phase. It removes the expectation that we'll get the feature right on the first go.

Once (and indeed if) an alpha feature reaches beta, we make a stronger commitment to avoid breaking folks.

Unfortunately, I believe the alpha lifecycle stage is hurting the project more than it helps it. I see a couple of related problems, that are all symptoms of the fact that folks don't wait until a feature is in beta to use it in production:

• Folks become dependent on how a feature works. Removing it or making breaking changes is disruptive, which upsets them and paints the project in a negative light.
• There's no pressure on feature contributors to prioritize maturing (or changing, or removing) a feature once it ships as alpha.

These problems compound. The more folks use the alpha features, the less pressure there is to mature them, the longer they exist at alpha, the more folks use them, etc. Ultimately this leads to situations where we can't make meaningful changes to alpha features without either disrupting a lot of folks, or spending time and effort to avoid disrupting them. Essentially, we end up having to treat alpha features as if they weren't alpha, thus defeating the point of having them in the first place.

How could Crossplane help solve your problem?

I think alpha features are a good idea in theory, but we need a way to remind users and contributors that shipping an alpha doesn't mean the feature is done. It's like shipping a design document - there's more work to do before folks should actually use it!

One way we could potentially enforce this way of thinking would be to make it harder to use alpha features for anything other than experiments and feedback. For example configure Crossplane to automatically shut down (and remove all of its resources?) after 24 hours. This is similar to GKE alpha clusters, which self destruct after 30 days.

Footnotes

1. Support in the sense of maintaining backward API compatibility, behavior compatibility, or even guaranteeing the feature will keep existing in anything like its alpha form. ↩