Why did TeamCity choose a pricing model based on committers?

While build credits help us account for costs associated with running build agents, it does not account for costs associated with the TeamCity server costs and operation. While we did explore using Build Credits to charge for each individual piece of data processed in TeamCity Cloud, this type of model would make our pricing unpredictable and complicated

We’ve chosen to use an approximation for calculating the costs of the server. One of the best ways to estimate the server load is by counting the number of users who make the commits. TeamCity is a CI/CD tool, thus nearly every feature is related to these commits in one way or another. The more commits you make, the more builds you produce, the more logs are transferred to the server, the more tests are tracked, investigations assigned, notifications produced, and so on.

Ultimately, we choose a Committers mechanism as a method for determining costs, and providing a starting point for how many subscription-based build resources you have access to in your TeamCity instance.

We believe this model offers several advantages. 

• Unlimited parallel builds when using JetBrains-hosted agents:
  No more waiting for a build agent to become available, or watching an ever increasing build queue 
• Scale up with additional build resources as needed:
  Build credits, storage, data transfer and self-hosted build agents can all be purchased individually and quickly
• Unlimited web-users:
  While we do count committers, web users are unlimited in TeamCity Cloud. Open up your CI environment to developers, testers, and anyone else who needs access to TeamCity without worrying about user licenses or seats available.
  
  

We understand no licensing mechanism is perfect, and would welcome any feedback you’d like to share.