|
(Waded through some trash, and cleaned up some shit)
|
(→Why this Licensing Model? - Do we really need this?)
|
| Line 11: | |||
| ** Committers are tracked for 90 days. | ** Committers are tracked for 90 days. | ||
| - | = Why this Licensing Model? = | ||
| - | The goal of the AnthillPro pricing model is to scale from the little guy to the big guy, and achieve a price proportional to delivered value. The only way to accomplish this goal was to come up with one or more scaling variables that are used to calculate the price. That's where our search for scaling variables began. We looked at the number of servers or the number of agents as the scaling variables. At first glance it appeared that the number of agents would be a good scaling variable. But upon closer inspection, it turns out that because of support for network deployments, a large company with hundreds of project and hundreds of servers may not need any more agents than a 5-person shop working on two projects with a handful of servers. We then looked at the number of administrators defined within AnthillPro as the scaling variable. But here again we know of enterprises with one or two build masters supporting hundreds of projects and even the smallest team will still need at least one admin account. So this turned out to be a sub optimal scaling variable. The number of projects configured in AnthillPro is also not a very good scaling variable because it encourages poor development practices in the form of monolithic projects. We strongly believe in modular or component development and encourage users to have many individual projects with dependencies between them. It would not be fair for us to encourage a practice where the better you are at it, the more we charge you. What we eventually found is that the only appropriate scaling variable that accurately scales from the little guy to the big guy, and is proportional to the value delivered, is the number of developers. | ||
| = Upgrades From AnthillPro 2.x = | = Upgrades From AnthillPro 2.x = | ||
