This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: Release Cycles and Pricing
Feed Title: Cincom Smalltalk Blog - Smalltalk with Rants
Feed URL: http://www.cincomsmalltalk.com/rssBlog/rssBlogView.xml
Feed Description: James Robertson comments on Cincom Smalltalk, the Smalltalk development community, and IT trends and issues in general.
In response to this post, I got a question about release cycles and their relationship to product pricing. That's a great question, and it allows me to expand on something that confuses a lot of people - the pricing model we use for Cincom Smalltalk. Let me talk about our pricing model first, and - in the process of doing that - I think I'll be able to address the release cycle/pricing thing
First off, I'm going to say something that a lot of you are going to question at first:
We don't sell development tools
That's right campers, we don't sell development tools. We sell a platform on which you can develop and deploy applications. Think about it - you develop and deploy on the same system - it's a platform (like J2EE or .NET) as opposed to a development tool (like Eclipse or VisualStudio).
Now, with that small bit of explanation out of the way, let me switch gears to pricing. We have a small number of pricing plans:
End user based (for internal, client/server applications)
Server based
VAR (for resellers)
We offer these on an annual subscription basis. In most cases, the number of developers are unlimited - which goes along with the idea that we aren't selling development tools - we don't price on the basis of developers, we price on the basis of platform usage. Now, how does any of that relate back to the release cycle? Well, if we are going to sell on an annual subscription basis, there had darn well better be some value. That's a large part of why we have short release cycles - it's a way of demonstrating value for the annual subscription. We not only give full support, but - during the span of a subscription, our customers get each and every release we put out. That's value back to them in a few ways:
New features on a regular basis
Incremental, hopefully easier to update to releases
Concrete evidence of progress
That last one is perhaps the most important one for many people - they want (and need) assurance that their investment in our product is safe. With any commercial venture, the proof is in the pudding - all the words in the world from me (or anyone else) are just that - words. Steady, ongoing releases, on the other hand - that's everyday proof of stability and commitment.
Previous Topic
