VFP.NET or VFP.Not?

January, 2003

Most VFP developers who have an opinion on the subject (that includes most of the ones I know) are unhappy with the marketing of FoxPro and have been for some time. It's not unusual to hear terms like "red-headed step-child" when discussing VFP's position at Microsoft.

There's been some improvement over the last couple of years. It's not as common as it once was to see lists of developer products from Microsoft that exclude VFP. Lately, FoxPro has even been mentioned in several of Microsoft's email newsletters.

Nonetheless, there's no doubt that if you or I were in charge, we'd be trying to tell the whole world what a wonderful product VFP is to bring a lot more developers into the VFP community.

Given this situation, it's not surprising that marketing discussions come up all the time in the VFP online venues. A couple of subjects seem to come up over and over again. One is making VFP a .NET language; the other is giving VFP a new name. I think they're both bad ideas.

Why not .NET?

Let's start with the technical question, why VFP shouldn't become a .NET language. What does it mean to be a .NET language? Fundamentally, .NET languages can be compiled to an intermediate language, which can then be executed using the Common Language Runtime (CLR). That means that .NET languages are restricted to those operations supported by the CLR, and therein lies the rub.

What's the fundamental thing that makes VFP different than its Microsoft brethren? Data handling, of course. FoxPro has a built-in data manipulation language that's fast and powerful. The CLR, on the other hand, doesn't include database support. (.NET languages use ADO .NET to work with data.) So, to become a .NET language, VFP would have to give up the key functionality that distinguishes it from other languages. (There are some other technical issues involved in moving VFP to the CLR, but I suspect that most of those issues could be overcome in one way or another.)

What benefits would FoxPro developers get from VFP being a .NET language? VFP 7 and 8 can already work quite capably with .NET: VFP can both create and consume web services; with some effort, VFP can talk to .NET objects and vice versa.

If that's the case, what's the upside here? Easier interoperability is an obvious answer. But the most common answer is increased credibility. In other words, many of those who want VFP to become a .NET language want it not for technical reasons, but for marketing reasons. They believe they'll be able to sell VFP solutions more easily if the product is VFP .NET. (In fact, I recently saw a recommendation to adopt that name without making VFP compile to the CLR.)

Is that a realistic expectation? For some people, no doubt it is. There are plenty of decision makers out there who have little technical expertise and are simply familiar with the latest buzzwords. For them, the name VFP .NET may be enough.

But the reality is that VFP was a member of Visual Studio for several years, and we didn't see a decrease in concern about the future of the language. Apparently, the packaging doesn't matter that much.

No new name

That brings me to the second suggestion. Fairly regularly, I hear people suggest that, in order to be taken seriously in the business world, Visual FoxPro needs a new name. The "fox" in FoxPro makes people look askance, says this argument, plus a new name would eliminate all the history of "FoxPro is dead" rumors. The suggestions for new names range from "VFP" (without the "Visual FoxPro" full name, a la KFC) to "F#" to totally unrelated names.

If Microsoft had changed the basic product name in the move from FoxPro 2.6 to Visual FoxPro 3.0, it might have worked out well. But we're four versions and seven years beyond that now, and the Visual FoxPro and VFP names are well-established.

A newly-named product would fight the uphill battle of appearing to be a 1.0 version. Without a significant marketing effort to tell people that F# (or whatever the product would be called) was Visual FoxPro 9.0 (or whatever), many current VFP users would be lost. On the other hand, such a marketing effort would defeat one of the main purposes of renaming the product-dissociating the product from the perception that "FoxPro is dead."

What can we do?

If making VFP a .NET language and renaming it aren't the answer, what is?

First, we need to make sure that Microsoft knows that we're still out here using this product. That means upgrading to the latest version. (I promise you, they do count heads, or to be more accurate, revenue.) With VFP 8 due any minute, that's an easy call anyway. Along the same lines, let Microsoft know what you want in the product. The official wish list for VFP is located at www.universalthread.com. Choose VFP Zone, then Visual FoxPro Wish List. The better the product is, the easier a sell it is.

Let the world know you're using VFP. Build public perception one user at a time. You can do this by including the phrase "Powered by Microsoft Visual FoxPro" somewhere that your users will see it, such as in your application's splash screen. If people run into enough applications "powered by Microsoft Visual FoxPro," they'll begin to wonder what it is. Make sure to include the name "Microsoft" in there; one of the issues is that people (including some Microsoft employees) don't realize VFP is a Microsoft product.

Write case studies. It's important that people who visit the VFP website find information about a collection of strong VFP applications to reassure them that VFP can do the job. A case study template is available here. Contact Ken Levy for more information.

Neither eviscerating the product nor renaming it will do as much for the public perception of VFP as a concerted campaign by VFP developers to let the world know what FoxPro can do.