>
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.
>

Corporate citizenship is indeed important. But remember that supporting a product is quite different from innovating a product. IMO, the single best and most important thing MS can do for Fox developers is to make the transition, for those that either want to or must make the transition to .NET, as easy and painless as possible. I believe the loyalty VFP developers have shown has warranted some pay back.


>
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.
<

Not sure if this is correct or not. IE is a key part of the platform. MSDE is really a way of extending SQL Server. At the surface, they are "free". But in reality, they are enablers of technology that rings the MS register.

>
So this idea that the mighty dollar is the only factor relevant for the continued life of any specific product is really a fallacy.
<

I don't think this is true. Ken himself came up here and said the most important thing Fox developers can do is upgrade. That means the $'s are the key driver. There is a lot of talk about how Fox has the best profit ratio of any product at MS. I don't know how that is measured but I do know how it gets there. The product is kept on a very short leash. You have an aging code base that gets more difficult to improve upon. The more you tinker, the more likely you are to break something. What has been achieved so far is due to Calvin being a pretty smart and innovative guy. I wonder if anybody else besides Calvin is as up to speed on the code base as him? IAC, don't fool yourself into thinking that money is not the issue. The day VFP is not cost justifiable is the day it gets capped and goes into support mode. This goes for any product at MS and VFP is no different, nor should it be.

<
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.
>

Because IE is part of the platform, my guess is that this is internally funded stuff managed through various cost accounting procedures..

>
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.
<

How much would it cost to do this?
Could MS make the money back?
What other features would you have to give up to do this?

Keep these questions in mind when asking for stuff like this. I have been asking for COM debugging for a long time. I have long since given up. It is simply too complicated. And beside, COM is soon to become legacy technology anyway as far as MS is concerned...


>
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.
<

Remote Views bascially give you this now. All the SPT is shielded from you. Again, ask the 3 questions above.


>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.
>

Before you can address what MS can do, you have to address whether it wants to. I think it is patently clear that MS has no interest in pushing the product beyond the scope of people that already use the product. MS has to do very little in order to keep the masses happy. And quite frankley, it is not like the VFP folks are going to be able to go anywhere else. Check out the dbase 2000 community. If you think that is a love fest, I will bet folks that leave would be back in a few days.


>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.
>

Committment to a product is marked by the dollars allocated. Dollars warranted are driven by the market. Any way you look at it, it is thumbs down for VFP... I think you have answered your own question here...



>
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.
<

Considering VFP has nothing in common with .NET, other than XML support, it had no business being in the box...


>
In doing so the VFP Team said that the community would benefit from its being able to do things on its own schedule.
<

That is marketing spin Jim and the sooner you learn how to pick this stuff out, the better off you will be...

<
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.
<

Simply put, it would have killed the product.


>
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.
>

Not so much anymore since the decree was handed down by the court.


>
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.
>

Don't you think if MS wanted to do anything, it would have by now. When MS wants to do something, it does it. Do you realize that more probably gets spent on the XBox in one day than what gets spent on Fox in 6 months or a year????