Rating: +0
Aditya,
There is so much in a name, and semantics about words. For example, bug fixes and "new" features are something that is "expected" to be provided on a regularly scheduled basis - if not, customer goes to a new product that is keeping up and regularly adding new features. So new functionality can be difficult to charge existing customers for; new features within existing products should strategically hook the customer and increase wallet share across a broader spectrum of products – because by virtue of using this widget it just make sense that you should use this other widget that I have, and so on – now pricing gets fun and engineering is leveraged, so the costs line go down while revenue line goes up. Now that said, the same "feature" called a "module" or an "add-on" to the base product can safely be charged a license fee for, because its no longer a feature – it’s a “module” or “add-on” – the consumer perceives these differently – although they may be nothing more than “features” by another name. For the later, the “feature” needs to be of some significance. Let’s take an example using a Word Processor, if you add a feature to apply 'bold' to the text, that is difficult to charge for; or call a module; however if you add a mail merge "feature" that in-fact may be an add-on or module that you can charge for. Here is the base rule; if 100% of the end user population uses the feature (i.e. BOLD) its part of the base product and difficult to charge for; if the features falls outside of the 100% rule, then it's an add-on or module that you can start to extract additional license revenue for; Estimating and pricing rules are highly dependent on the type of pricing used; rental; perpetual; per click, etc. but at a minimum you have to use tangible data points to start (number of customers, geography, etc.); The trickier part of the overall question [imo] is not "how" to charge but whether or not you should charge.
Good Luck,
Peter
February 2009