On May 13, 2007, at 10:38 AM, Norman Palardy wrote: > On 13-May-07, at 11:24 AM, Tim Jones wrote: > >> On May 13, 2007, at 9:50 AM, Bob Keeney wrote: >> >>> Geeze, and based on the comments from earlier, no one would want to >>> pay anything more than $29.95 for a full featured grid - whatever >>> the >>> definition of a grid is. >> >> No one's complained about paying for a plugin control that does what >> is needed, so where did you get that idea? > > The common refrain that is "REAL should provide this" is not too far > from "but I already paid for this why should I pay more for something > that does what I want"
I believe that this is aimed at the missing components of a basic RAD development tool more than enhancements. I personally believe all of the 2d and 3d gizmos and movie player stuff should be removed and made into add-in rather than built-in and RB's core components - based on the OS core-components - be made the focus. How about an Editfield that actually works as expected and doesn't leak (just one example)? >> While I personally find >> the MBS plugins to be the bargain of the century, I would pay much >> more for what Christian brings to the table with that set. > > MBS and Einhugur are priced very inexpensively for what they provide > >>> Keep in mind, that the controls Suite from Component One (that >>> has an >>> awesome grid for VB6) is nearly $1200 for a YEARLY subscription PER >>> developer. If I had 1000 users willing to commit to that size of >>> suite someone (maybe even me!) would do it. >> >> But, you also need to take into account the scale of return that RB >> developers face. While it is true that RB offers Windows >> compilation, their market share is miniscule (no offense, Geoff) >> compared to the other tools out there for Windows. If I'm developing >> an application that potentially has over 400 million buyers, I'm a >> bit more apt to pay more for my development tools than if I've got >> the much smaller potential that is Mac. > > Which is why you use RB pro so you can target Mac and Windows But, we can't come close to producing the type of apps in RB that can be produced in VB - the code just isn't strong enough. This is why I used the comparison. >> Additionally, outside of Pro >> Apps, Mac users expect to pay $69 for their Mac apps with $99 being >> the extreme limit for a REALLY important app. > > Consumer applications maybe Which is why I separate business-class apps below... >> We've done serious market research on this and the sweet spot for a >> Mac application >> aimed at the desktop is $69 MSRP with a $50 street price. Granted, >> the business side of Mac will pay more if you can get a relationship >> going, but that is an even smaller part of the Mac space. Don't >> believe that? Look at iLife, Pages and Keynote; even Apple >> recognizes that pricing is important in this space. > > Certainly it is. > If people perceive the value is there they will pay what you charge. But, after monitoring over 3K Mac users over 2 years in both the US and Europe, if the sticker price on the product is higher than $99, the average desktop user won't even pick up the package to get a perception of the product's value. My point was that If we're selling 500K copies, we can easily absorb a $999 price for a 3rd party add-in as Bob mentioned. However, selling 1K copies makes either absorption difficult or causes us to raise our prices for the product about that $99 pain point. Now, the cost of producing that tool moves from the development tools' price to the cost of marketing the product so that the customer perceives of that additional value. Which in turn causes the cost of development to increase, and so on. I also know that from what I see on the lists and in the forums, most users of RB are captive delopers - developing for a specific customer or for in-house projects. That can make the cost offset even more difficult as the potential user count has now dropped into the 10's of users. However, this can also hide the costs of development as they can either be consumed as a "business expense" since the development was paid for by the hourly wage paid the developer. Tim -- Tim Jones [EMAIL PROTECTED] _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives: <http://support.realsoftware.com/listarchives/lists.html>
