>Interesting points about making a buck and capitalism. This gets to one of my chief concerns about VFP. On one hand, VFP makes money. On the other hand, its costs have to be kept to an extreme minimum to achieve profitability. To make a profit one of three things needs to occur:
>
>1. Increase Revenues
>2. Decrease Costs
>3. Combination of 1 and 2
>
>I see nothing to indicate option 1 is feasible. This immediately knocks out option 3. As Ken stated several months ago, there is only one thing the community can do to ensure the survival of the product: purchase upgrades. From my perspective, that means things like plaques, airplane banners, conference attendance, magazine subscriptions, etc, don't have a direct impact on the viability of the product. In order to take this discussion to a more "elevated" level, perhaps Mr. Black would like to address the question of whether the VFP market is growing at a rate that allows MS to realize increased revenue on the Fox product.

My apologies for not reading beyond here, John, but the above is what I want to comment on. . .

Firstly, lets keep in mind that the mighty dollar is not the only factor at play here - corporate citizenship demands that MS continue to support any product in significant current use and to at least perform additional development to allow the product to continue to operate successfully as MS changes the base components under which it operates. Either that or provide a good and proper tool to allow for a painless 'conversion' to some other language that is supported and growing.

Secondly, let me point out that there are several discreet components with large MS development staffs that MS continues to support and enhance that have no price tag on them. Things like IE and MSDE come to mind and I am sure that there are more.
So this idea that the mighty dollar is the only factor relevant for the continued life of any specific product is really a fallacy. If $ only was the case then the IE support folks would be far more productive for the corporation if they were put into the VFP team instead of costing all that money doing IE development and support.

Thirdly, there are ways for the VFP product team to make additional revenue. The one that comes clearly to my mind is a reasonably priced optional component that allows VFP to run as a true server for user-chosen databases and free tables. I have such a request sitting in the Toledo wish list for well over a year now.
Many others have asked for a feature of VFP that internally 'converts' commands as needed to correctly retrieve/update data under SQL Server control. They essentially want to be able to continue to use VFP native commands while taking advantage of SQL Server.
There are also other things that smart MS people can come up with to generate more revenue from VFP while all the while complimenting other MS initiatives! One obvious one is to take on your Powerbuilder or Delphi, integrating their best features into VFP and then marketing to those crowds.

The VFP Team at MS is very small. While this is really a blessing in the technical sense (because it is well known that smaller teams of highly competent people consistently out-deliver and out-quality huge teams, especially on complex products), it is also a curse because the standard measure of any company's "committment" to a product is the size of its development team. Those of us who have been watching closely are satisfied that we are getting full value plus out of the VFP Team but any outside 'information service' (industry watcher types) will consistently conclude otherwise because they don't look at the product and its evolution but simply look at things like staff counts.

The VFP Team essentially had to move VFP out of Visual Studio's .NET offering, further adding to industry watchers' concern for the future of VFP. It also added to many of our (the VFP community) concerns too for its future.
In doing so the VFP Team said that the community would benefit from its being able to do things on its own schedule. More than one statement about this has also alluded to the extreme overhead implied in being within VS.NET, not the least because .NET is being fully integrated into Windows OSs. The onerous testing requirements and documentation standards and other overhead inherent in being within .NET would not only take away from wanted features development but it also would greatly limit maintenance and version release schedules.
Now VFP is much akin to Powerbuilder or Delphi. Its developers are faced with identical constraints, though the VFP Team does have the advantage of being "on the inside" and so being privy to information, and possible assistance through internals, that are unavailable to the other product developers.

Finally, I think that it is reasonable for MS to permit VFP to continue to grow in features (especially those that are aimed at future exploitation of MS cash cows like SQL Server and Office) while the .NET initiative continues to evolve. While MS has the bucks to market the hell out of .NET, that alone will not gaurantee the success of .NET. My best guess on the matter (basically uninformed but intuitively based) is that .NET will "succeed" but most likely in a far smaller and more specialized way than MS originally and currently envisions. My take is that, in the end, it will more or less mirror MS' success with SQL Server and be nothing like the success MS had with Windows itself.

Now I'll set about reading the rest of your long message.

Jim


SNIP