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)
A few options:
- Minute - Existing solution, least flexible. Can be confusing when considering additional machine types (More CPU's, Mac, Windows.)
- 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.)
Current preference: Credits
Competition
GitHub's current pricing for now::
- Linux: 1x
- Windows: 2x
- OS X: 10x