I think we can't blame Microsoft (or Ken) for their approach to market VFP and the "secrecy" of their plans. We are VFP developers, know it and like it (a lot); that's all we care and we think such a product deserves more attention from Microsoft.

But just put on Microsoft shoes and the picture changes. You have this cute fox that does not fit on any of your great product lines. It's not for the end user, and this place is reserved to Access (like it or not is better for uneducated users). This means you cannot integrate it in Office, "the" key product (business productivity tools).

We agree is a product for developers, and VFP keeps increasing it's focus on them. So it should be on Visual Studio. They tried it, but it did not work; VFP should suffer a BIG transformation in order to fit nicely in .NET technologies. The syntax, the approach, ..., the object model, ... too much of a change, and you risk to loose all the loyal developers that love how VFP is right now. To be true, it's not a .NET product, and most of VFP developers don't want it to be.

On top of that, you have Access and VB-SQL which are used a lot for database applications. If you were Microsoft would you push hard a 3rd product to compete in this arena? You can say that VFP is better, but Access and VB are part of the core line products of Microsoft: Office and Visual Studio. Would you promote another product heavily, even if it was better? It would be a nonsense.

So, looking the whole Microsoft picture as it is now, where do you put the fox? Do you have an easy answer? One of the answers is what they are doing now. Keep improving it and let it kind of market itself.

At this point is where a lot of people come and say that is not going to survive next month. I don't know and don't care, but think that Microsoft has many good reasons to keep it alive the way they have until now: it's a good product with nice technologies that benefit other departments, they can test on VFP new approaches and technologies faster and with less risk (as it is not a key product), VFP has a very-very loyal developer base wich make nice PR labor, more and more VFP developers are using SQL as the backend and this greatly benefits Microsoft (including the income side), Excel-Word automation and VFP make a good couple and tie customers to Office (the real cash cow), it detracts developers to migrate to Delphi or CA or ..., it keeps other database products out (who is going to spend a lot of effort in developing a dBase style product with VFP on the market), ...

Developer tools like VFP have many other "side effects" that increase their strategic value, one of them being that they help to tie customers to other Microsoft line of products (like Office and Windows). If some genius would come up tomorrow with a Linux product that would allow you to develop a whole database application in only 20% the time you spend now with VFP, or VB, or ... then Microsoft would have to worry, because they were going to loose a lot of Windows licenses because of a developer product (not a OS).

It's only my guess about what could happen inside MS. There is no easy way to market and position VFP without hurting other key products.

Just my .02

>>>With all due respect Ken, Denis is not making an assumption. Just asking a question. If its not the numbers then what does drive the decision making process iro VFP at MS? It's not really an unfair question, especially when asked by dedicated VFP developers who have bought and supported the product for a long time.
>>
>>I agree that it is not an unfair question to ask. You are just reasking what he did in a different way, and my answer remains the same for this.
>
>Ken, your answer is to the question of how one can help promote the sale and usage of VFP. And your answer is clear and concise. The question Denis and others are asking is if MS do not use "the numbers" for making decisions concerning VFP then what does it base its decisions on? Its fundamentally a different question.