Visual FoxPro: Where Does the Roadmap Lead?

I'm on the road between VFP conferences at the moment, having just left Advisor DevCon in Las Vegas, and headed next for the DevTeach conference in Montreal.  The major buzz at DevCon centered around the keynote, where Ken Levy reviewed the official VFP Roadmap that Microsoft posted on June 1.

Ken didn't really elaborate, because the roadmap is intentionally vague, giving the Fox team a lot of leeway in what will be included in Sedna.  Nothing has been ruled out, including the possibility that Sedna could evolve into VFP 10.  That possibility is quite remote, especially in view of the fact that it costs a lot more marketing dollars to do the branding, packaging, and everything else that goes into a new full version.  While I don't remember it being said directly anywhere, a VFP 10 version might logically extend the support window for VFP, which is currently through 2014.

If the Sedna effort simply consists of downloadable add-ons to VFP 9.0, VFP developers will get more new features than if the development budget was cut by the amount it would take to create a full-blown new version. 

In the meantime, the official roadmap allows Microsoft to keep all their options open.  After all, the Sedna effort is directly related to Microsoft technologies like Whidbey, Yukon, Indigo, Avalon, and Orcas, none of which will be released anytime soon, and some of which are quite a ways off.  No one knows how those products will finally be implemented, so there's no way to tell right now what Sedna will include for VFP compatibility and leverage.

What's the bottom line?  While I can't possibly predict what will happen to VFP over the next couple of years, a few things are evident:

1. VFP is not dead yet.  Heck, even FoxPro 2.6 isn't dead – you undoubtedly either know of 2.6 apps that are still running and being maintained or are working on one of them so yourself.
2. The core VFP product is not going to be enhanced (see the roadmap) to add more features.
3. The bulk of the Sedna effort is to ensure that our apps that run in VFP 9.0 will continue to run into the Longhorn era, and that they can be as .NET-"compatible" as is reasonably possible.
4. VFP is not a strategic tool in the Microsoft suite of software.  Does that surprise you?  It shouldn't, given what Microsoft has been saying ever since .NET was announced.  As I read in an online magazine article last week, '...Microsoft has spent more money developing and marketing on .NET than NASA did to put a man on the moon...'  It makes no difference that VFP is the awesome tool that no one else cares much about.
5. VFP developers love their VFP, and the VFP community is as passionate as ever

I think it's important to keep in mind that Microsoft is not compelled to keep the Fox team working on VFP at all.  There was some speculation after the release of VFP 8 that is would be the last release.  After all, it was, in my opinion, the single most feature-laden release since VFP 3.  I remember Ken Levy asking folks at conferences after VFP 8 was released, "What more can we possibly do with the VFP core product?"  VFP 9 is a killer product that answers that question well.  The fact that the Fox team is committed to work on "whatever comes next" over the next 2 years is by far the best news a die-hard VFP developer could hope for.  At a minimum, the roadmap ensures that the VFP apps that you and I are developing right now will continue to run on the Microsoft platform for many, many years to come.

Comments

[Jeff Johnson]

Drew: I am not surprised that your first blog "looks and feels" like one of the most professional blogs I have ever seen. You are a true master. It looks good and the content is what we have grown to expect from you. Great job and keep up the good work!

Jeff

[Braxton Perry]

I live and die by Foxpro. I know they have to be careful with compatability but I hope they can make good use of multicore in future editions of Foxpro.

I know Fox won't be 64 bit but I would like to see Fox use the additional registers when available because good use of registers speeds up code considerably. That is basic electrical engineering.

I wish it shipped with Visual Studio in a seperate folder.