On 13-May-07, at 1:11 PM, Tim Jones wrote: > On May 13, 2007, at 11:06 AM, Norman Palardy wrote: > >> On 13-May-07, at 11:53 AM, Tim Jones wrote: >> >>>> 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. >> >> personal experience with various commercial product made in RB >> suggest this is not true >> >> Check out XSilva Systems RB made app > > Which furthers our discussion into the dependence of external items. > Nothing visible in that app (except possibly the Bevel buttons) is > native to the RB framework. Otherwise, all of us would make apps > that look like Lightspeed (and it IS a fantastic app). How much of > the product is the result of heavy 3rd party tool use, declares, or > very custom canvas work? They may have used RB for the compiler, but > my suspicion is that the loss of the 3rd party code or the developer- > hours invested in the custom look-and-feel would result in their not > being able to release that app. Also, is it cross platform > (rhetorical question)? David, are you still reading the NUG?
Its not xplatform as that is not the market XSilva is going after A lot of the UI is, from what I know, done with declares and plugins A loss of code would be a problem but not impossible to overcome from what I know >>> 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. >> >> Am I reading that correctly ? 500,000 copies would allow you >> incorporate a < 1000 plugin and cover it's cost ? >> Even at 1K the cost is $1 per copy > > No, you're not reading it correctly. The 500K number was used to > firmly contrast the potential Mac market against the potential > WIndows market. > > I didn't mention that this $999 control was one of 18 such licenses > that were potentially used (Now we're at $18K), nor that there could > be over 1400 developer-hours in the project ($60K), nor that there > could be $150K involved in the marketing of the project over 6 months > ($210K), or that the manufacturer would need to define a projected > 2500 support hours annually ($290K), and over 500 hours for > documentation ($310K), or the nearly $200K that would be spent on > patent and IP research and legal fees to file copyright and trademark > registration data ($510K). So this project could cost a company > $510K to bring to market - and that cost would apply to both Mac > development OR Windows development (where do you think you'd be most > likely to recoup the costs?). So yes, that one plugin rounds out to > less than 1 penny per copy (assuming 500K copies), but it's just a > small piece of the total development process cost. Does that make it > a bit more clear as to my real point? Unfortunately most single > person shops don't understand exactly what goes into the release of a > new product from the perspective of a larger company. What I'm seeing is that the cost of a single 999 plugin would be miniscule compared to all other costs. If a plugin saves you time and money to get development done why would you avoid it ? If your developer hours could be reduced by the addition of one plugin then you're way ahead. There are always ways to license things that reduce the risk of an abandoned component. >>> I also know that from what I see on the lists and in the forums, >>> most >>> users of RB are captive developers - 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. >> >> Having previously been an in-house developer we always spent what >> needed to be spent. >> That was true in the $25 billion co's I worked for and in the small 3 >> person start ups. >> If it helps us do business better, makes our product better, etc we >> bought it. > > Exactly my point - you as the developer were not exposed to the other > business expenses involved. Most companies tend to - as you say - > spend what needed to be spent when looking at captive development - > the ROI is directly related to the expected improvement in > productivity. This same model doesn't work for a development project > aimed at an external, customer driven revenue model. All the start ups were customer driven revenue based and they shared the same attitude >> Maybe I've lucked out and worked in companies that realized this is >> how they made money and would spend that to earn bigger revenue in >> the long run > > Again, an example of captive development mentality versus for revenue > development mentality - internal productivity versus external > customer revenue. These companies varied in their focus as well. One was internal systems for anyone ranging from engineers to the CEO. The other was a startup selling product to outsiders and our success depended on revenue. The startup was eventually purchased and the other was a $25 billion in assets utility. Both spent what was needed to make the product do what was needed to be successful. _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives: <http://support.realsoftware.com/listarchives/lists.html>
