My initial reaction was that this was bad. But after a lot of consideration, I don't think so any more. The free Starter Kit was always a fantastic idea - the principle that people could start to learn Metacard (Rev) and see how easy it was to do stuff in just 10 lines is great. And I really liked that the documentation would try to encourage people to think about the flexibility of the Metacard model by using frontscripts etc to get round the 10 line limitation. To me this was just a very inviting model, and was one of the endearing things about the product, and actually made me want to buy Rev long before I had any need to because of the 10-line limit.
However, the jump between Starter Kit and Full version was huge. The introduction of the Small Business version meant it was a no-brainer for me to buy it. Even if my attention has been drawn elsewhere technologically in 2003, I have no regrets about buying into Rev. However, I could not see myself upgrading to the full Professional license any time soon. What is new for the 'Enterprise' license, is the inclusion of the 10 support incidents. We need to know if this is telephone or email support, and if there is a time limitation. I suspect many people never even saw (or have forgotten) that support could be bought. Even for me this might have been/might be useful, as there were some fundamental problems with some of the ODBC drivers I used with Rev. If this meant I could get something like that fixed by them (the drives worked for all the other software I used with them), it would be worth the difference. To me, the policy on non-ODBC database drivers is a bizarre mish-mash, and would never have offered me any real benefit in upgrading from the SBE. I can't see that any of it adds much benefit, even to an Enterprise user (plenty of companies are using DB2, Interbase, SQL Server or Sybase, and a myriad of other data sources). And anyone who thinks that ODBC has to be slow should see how fast SQLite and Firebird are via the ODBC driver (connecting to Oracle is famously slow, hence the need for non-ODBC solutions). The 10-incident support might well offer me the inducement to upgrade my license (the 'carrot'), as would the desire for upgrades (the 'stick'). The pricing model is probably an improvement for Runrev and for most users. The model is a little more complex than before, but probably provides more flexibility in terms of encouraging people to move from the version of Rev that brings in less income, to a version of Rev that brings in more income (for both the developer and Runrev). They can't be blamed for this - we want Rev to continue its advancement, so any change in the pricing structure that improves their revenue stream whilst not discouraging the uptake of Rev is great. The only people being squeezed are the SBE users who want to target multiple platforms, or who want the year of free upgrades. But they are getting free access to the non-ODBC drivers, so they are not just losing out (I assume I am the only one who thinks the whole database drivers policy is mistaken in principle). In fact, as someone who has no use for these drivers, but who wishes to target multiple platforms, I fall squarely into the camp of the 'losers'. But on the whole, I still think the new pricing model is a good thing. They have drastically lowered the bar for new entrants interested in producing apps for a single OS. I suspect that the majority of the apps made with Rev and Metacard are aimed at Win32 and the Mac OSs. I know that Metacard has a unix heritage, but it doesn't look from the Rev list like many people are targetting unix. If someone really is targetting multiple platforms for 'religious' or commercial reasons, then I think they should be prepared to step up to pay twice as much as the single platform version. If a multi-platform version of your app is not going to bring in $150 more in value, it is probably not a good idea to be thinking about it (unless, like me, you would want to do it to ensure future-proofing). I still think that the unix support (or at least Linux support) has to be maintained. It is hard for us to imagine the potential growth of Linux. Whilst many Linux users might be averse to paying for software right now, that is going to change. Businesses that are using Linux expect to pay for stuff (companies like Oracle and IBM are not giving away the Linux ! versions of their software). Increasingly there will be end-users who also expect to pay for software too. There is one thing that Runrev should seriously reconsider though. As Curry has pointed out, the 'Nag' screen principle leaves a bad taste. Since small scale, multiplatform apps can be developed and built in the Starter Kit (Evaluation version), and that version brings in no revenue for Runrev, it is entirely reasonable that those apps should produce some kind of advertising for Runrev when the app runs or quits. But it is unacceptable that someone who has paid for a license to use a development platform, should also be forced to include advertising for that platform. I personally have introduced people to Revolution and they have subsequently bought the SBE. These were people who were really only interested in developing for one platform, and would have jumped even more quickly if the Express version had been available. But I think that knowing they are forced to pay twice as much to get the multiplatform version just to get rid of the Nag screen would put them off altogether. Runrev should rely on the merits of the product and their pricing structure. Runrev should set about producing a range of small, free, multi-platform apps built with the Starter Kit (and the nag screen). These apps should be distributed with no support via shareware/freeware sites, and the actual Transcript could be available on Runrev's site so that anyone who is interested in developing with Rev could then see how it was done, download the Starter Kit, and either become a paying customer or feed into the cycle of apps that advertise Rev. Rev is still the best multi-platform RAD solution, and they need to _demonstrate_ this as part of their marketing. We all need Runrev to thrive so that they have more internal developers and the product continues to be the best choice available. But Runrev need to take responsibility for marketing their own product. I have never seen any promotional material for it outside their own site. I stumbled upon Rev completely by accident (someone mentioned it in an entirely unrelated discussion group and I looked into it purely because it was cross-platform). Now we just need to hear about how this all relates to those who want to upgrade their existing licenses on the basis of this new licensing structure. Regards Bernard _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
