Pricing for Windows Shared Runners

Costs for Windows, and in particular Mac, is higher than Linux. For example, GitHub bills Windows at 2x, and Mac at 10x, that of Linux.

Let's use this discussion to align around a solution for how to charge differently for different types of runners. This could form the basis for offering different machine types of Linux, which could be helpful for some workloads that require more RAM.

Pricing during alpha/beta phase

During alpha/experimental release, we will keep the pricing the same as Linux, but ensure we are clear that eventually there will likely be increased costs.

Pricing for general availability

There are a few facets on how to price:

Whether it should be recurring in some way? Subscription of x/month? Automatically renewing prepaid? Current model of manual renewing prepaid?

What is the entity that one buys (credits? minutes? actual currency?)

Payment model (Subscription / Automatic pre-pay)

This is a larger discussion, but one that should be had when we are thinking through changes to our pricing model.

Our current model lets you buy a chunk of minutes. This is probably the least helpful model, since it requires manual intervention to buy more, which is not user friendly.

We can explore two alternative payment models:

Subscription price of X unit for Y dollars per month

This is recurring revenue which is beneficial and easy for GitLab and customers to budget for

This however puts the onus on customers to predict what their usage will be, to ensure they don't buy more than they need

Further, we would need to consider what happens during overage scenarios

Automatically renewing pre-paid of X unit for Y dollars

This is an iteration on the current model, where once the available number of units reaches a threshold, it will automatically buy more on the current payment method.

This lessens the burden on customers to estimate needs, but they will still need to do so for cost estimation

For larger customers with higher utilization, the increments can be unnecessarily small and lead to lots of small payments

Volume discounts would require additional thinking

Current preference: Subscription pricing with on-demand pricing on coverages.

Unit (Credit / Dollar / Minute)

Currency (e.g. a dollars/cents) - Not as compatible with subscription pricing ($X in Runners / month?), or volume discounts

Credits - Most abstracted. Compatible with volume discounts, subscriptions, and other types of services we may want to add in the future. (Managed backups for self-managed instances? Increased project storage limits? etc.)