Les PInter on selling VFP apps (Post: Paalbalk Huissen)

From this thread:

Les Pinter has a nice strategy for selling VFP apps.
He first shows to his audience, most likely managers and budget-responsible people, the whole myriad of classes and possibilities of VB.Net of C# or whatever they can come up with.
He is driving them crazy with all the things you can do in .NET to a point where they ask him for a price to develop that must-have application XYZ.
He gives them the price and the time to deploy the app and tells them there is an alternative.... and then says, "nahhh, you probably won't be interested, it will cost you only 25% of the price I just mentioned but it won't be interesting of you". Well, those budget-responsible people ARE interested then, and then he shows them his "special framework, developed in C++, AKA VFP".

He drives their minds to a boiling point with another show-off from VFP and compares that with the things he just showed to his audience. And shows that it is indeed, remarkably quicker, and, what's more, cheaper!!

Poster disses YAG (Post: Spock of Vulcan)

From this thread:

Personally, I think it is a disservice to the Fox community that you are still around. Ever since you came to Microsoft, you have done nothing but try to kill the product and continuing your involvement will certainly ensure that happens. Please let someone with true interest in the product and community take over responsibility for Fox's future.

Win32 & the future (Posts: Mike Helland)

From this thread:

I recall Jim Alchin saying at a meeting "Nothing will happen to Win32."

If that's true, Microsoft ensures VFP being around and functional.

If that's not true, and Microsoft blatantly lied (or rather, failed to uphold Mr. Alchin's promise), then the computer industry will ensure the proper hardware and software technology exists to keep running Win32, and thus VFP keeps running for decades to come.

Anyone "worried" about the future of VFP can stop ragging on Microsoft, because someone is out there stockpiling Intel Pentiums and Windows 2000 licenses and if Microsoft does "kill" VFP, VFP will be around and our existing source code will be viable anyways.

---

Microsoft cannot kill VFP.

In order to do that they would have to kill Win32, which I doubt they would do.

And even if they do, the technology industry has invested in it to the point where Microsoft would be ordered by the courts to maintain Win32 (given the number of Win32 applications our government runs I find this somewhat likely) or by that time the industry will offer something like WINE2000, meaning we maintain Win32 itself.

It is true that "VFP is dead!" in the sense that we won't see exciting new versions.

But, I really can't think of any new features that would make or break VFP as a solution for a decade to come.

VFP with .NET (Post: Rick Strahl)

Link

If you use VFP with .Net you're diminishing that platform's performance and scalability significantly. Many of the benefits you gain by using .Net in the first place just go out of the window. Second, using VFP COM objects with .Net is painful if you do anything non-trivial because there's no direct connection to those objects. You have to use Reflection to get to lower level objects/properties etc. or VB and Option Strict off which also is not what I would call an option. Can you do it? Sure. Is it easy to do it? No, especially not in the face of native code.

I think COM interop with .Net is a nice stop gap choice, but not a permanent solution. If you want to go that route than classic ASP is actually a better choice IMHO.

A lesson from Lotus 1-2-3 (Post: Steven Black)

From 2003:

I spent several days with a guy with a PhD in Operations Reseach from Stanford, and a internationally recognized specialist in transportation modeling, who was putting together a proposal to write a scheduling system for Canada's entire railroad network. Using what, you may ask? Using Lotus 1-2-3 version 1.x for DOS.....

...Lotus, it turns out, is plenty powerful to do the job. A killer was several versions into the project, when both Lotus and Excel became so bloated on the Windows platform that they just couldn't grind the mega-models anymore. Who knew? I bet that, before you read this epilogue paragraph, you thought you knew what the failure modes were. It was bloat, Bob. Now replace "Lotus 1.x for DOS" with ".NET" and realize that you don't have any control whatsoever over your life going forward. That boat ride (bloat ride?) is a billion-dollar illusion by a bunch of hacks who peddle technology with little or no insight into applications. No more, no less...

...Today's cool deal is *always* tomorrow's legacy nightmare...

...I reckon 80% of all .NET developers are taking a product that they know fundamentally little about and creating applications based on snippets of code they find in books and on the web. All of which were written by near-rookies at best. Those chickens, your chickens, will someday come home to roost.

Rich or Thin? (Blog: ISV Blog)

Excerpt from "Tech Corner - Rich or Thin?"

Browser-based applications are not going away. Client/Server applications are not going away. The technology you choose for your product should be able to do BOTH and also be build on a platform that will be adaptable (in terms of platform and form-factor [e.g. mobile devices]) to handle it.

Otherwise, you may find yourself behind the technology curve and therefore vulnerable to other companies with similar offerings who are on the technology curve.

On the lack of alternatives (Blog: ISV Blog)

Entitled "Foxpro is dead: which 4GL is next?":

Microsoft recently announced that they will no longer develop new versions of Visual FoxPro, once one of the leading 4GL tools. Who's next? Oracle announced last year they will no longer develop new versions of Oracle Forms and also other 4GL vendors including Uniface, PowerBuilder, 4D, Omnis and Magic have not been really keeping up with the market in the past years.

What I find fascinating is that these vendors are not coming up with good alternatives for the products they are discontinuing or slowing down development on. I asked a couple of ISV's that have products in FoxPro what Microsoft is recommending them, I was guessing Microsoft would be suggesting (and helping!) them to move to .Net but guess what? Microsoft is recommending them to become a reseller of their confusing mix of Dynamics products.

Really! Microsoft essentially started to compete with ISV's when they started building up their Dynamics portfolio: it offers: CRM, ERP, Accounting, Warehousing and more. Exactly the products ISV's where building very successfully in FoxPro. Microsoft buys FoxPro, kills it and recommends you to rewrite your products as enhancements to their offerings. Sounds like a brilliant strategy! Perhaps it's time to switch to a tool-vendor that doesn't compete with your core business!

The Problem with "Legacy" (Blog: ISV Blog)

Part of Tech Corner - The Problem With "Legacy"

If you don't change, you stagnate. It's bad enough in the "real" world - and forget about the technology sector. There are new acronyms and new paradigms every other month. There are young, hungry companies with zero technology bias, starting from scratch, with nothing to lose, nothing to convert and zero installed base. In short, they have no legacy to support.

A lot of ISVs have a problem. The 4GL that they've based their entire system on is either hopelessly out of date (Delphi, Oracle Forms); not being supported anymore (FoxPro); have a proprietary, non-SQL database (FileMaker, Progress, Access, Alpha 5); and/or have no way to support modern, standards-based technologies (web services, XML, HTML, PDF, etc.).

There are only two ways to go if you find yourself in that position:

1. Do nothing and continue doing what you're doing
   
2. Completely re-write your application in another more modern tool/technology

Option 1 is attractive because it doesn't involve any change on your part or your customers. The danger is that a new competitor will emerge without the legacy and packed full of the technologies and standards that customers are demanding.

Option 2 is painful. It involves a learning curve, re-training customers, data conversion and much more. The payoff is that you re-vitalize your existing customer base, gain new market share, and continue to have the ability to provide value to your shareholders, employees and end customers.

It's a tough business decision, and by not deciding, you've already made your choice.

Interesting thought on future 32-bit compatibility (Post: Ken Murphy)

From Foxite:

Personally, I plan to continue to use VFP until something better comes along. VFP works VERY well when used in conjunction with backends like SQL, SQL Express Oracle, MySQL, etc. Indeed, because of VFP's speed, many developers (myself included) prefer to use VFP for the middle tier, even when using a dot Net front end. The only real worry is if MS decides to create an operating system that will not support 32 bit apps. The lesson they are learning with Vista should prevent this. (Vista sales are in the basement - there is really no business case for anyone to go and buy the "upgrade" from XP.) If MS creates an operating system that does not support 32 bit apps, it is unlikely that anyone will buy it. It would simply break too many mission critical apps.

VFP runs well in a Windows Server environment, so you will probably find that people will continue to use VFP for middleware. I do not see MS changing Windows Server to the point where it would not run a 32 bit app. Again, this would break too many mission critical apps. Their customers would flee.

---

On a personal note, if you are a young developer (or even if, like me, you can no longer be called young) you need to learn new languages.

The cost of a rewrite (Post: Ars Technica)

Plicker7 said:

It's not even about the database side of VFP, so much as the ease of use of the tool-set. We use VFP for the UI development and SQL for the back-end within our applications. We currently have users who have SQL 2000 and some that are using SQL 2005 with the same VFP developed UI.

In Jan07, we started rewriting the our primary product in C#. In 3 months, we have 7 dialogs built, only 257 more to go. I'm sure it will get faster as we've spent much of our time building the data-access layer, and working the CSLA framework into the design for the Business Object side. But it takes a ton of C# (or VB.NET) code to call a stored procedure, vice the one line of VFP with SQLEXEC() command.

To date, it has cost us 10K in components and tools to support the .NET product, plus the MSDN subscription, and 85K for a dedicated programmer for the .NET product.

The new application will look more modern and be built on a development platform that people know is being supported.

"Retired!" (Article: Michael Desmond)

From MCP Magazine:

"There's another theme here that's consistent across VB6 and FoxPro and Visual Studio as well. It's not just the language, it's the application model that goes with it. The language is almost incidental at that point. What you're really betting on is the .NET Framework."

O'Kelly points out that Visual Basic 6, Visual FoxPro and to a lesser extent C++ are being replaced by tools tuned for the managed code environment of .NET. "It's not Microsoft picking on the VB6 and FoxPro guys, it's that the industry has really moved on for productivity and robustness reasons, and Microsoft isn't doing this alone," he says.

---

"It's become less about individual productivity and more about what platform are you producing on, and then standardizing on that platform," Allen says. "Ninety percent of the developers that I've known for the past 15 to 20 years, companies are hiring them to do something with data. We wanted something better, not something different and harder to work with.

"FoxPro got caught in the mix because it was kind of the dessert topping, floor cleaner product," Allen says. "It didn't clearly fit into the developer realm and it didn't clearly fit into the end-user realm.

Allen, at least, saw the writing on the wall. He switched over to coding in C# and VB.NET, though he continues to use FoxPro for certain projects and as a prototyping tool before casting code in .NET.

---

In the paper, Hammond urges development managers to "triage their applications" and then commit to migrating, rewriting or replacing each one, based on what the assessment finds.

Hammond breaks the process into a four-square box, which helps managers plot their decision making based on the relative business value and technical health of the affected code. As shown in Figure 1, business-critical code (in the upper two quadrants) must be updated, whether via migration or a wholesale rewrite. Commodity applications can often be replaced by packaged solutions or simply left in place, depending on the quality of the code.

According to the report, well-structured and designed applications lend themselves to an automated migration process, using tools like Fujitsu CoolCat and Infosys VB Migration Workbench. Many applications, however, require significant manual tuning or even a full rewrite.

In all cases, Hammond stresses a phased approach, where applications and application modules are assessed and re-assessed as the migration effort proceeds. A collection of code that earned a deferral in the early stages of the process might two months later be targeted for a rewrite. To avoid scope creep, he suggests stabilizing the code base first on .NET Framework 2.0, then extending functionality from that point.

The Future of Foxpro (Article: Chad Hower, April 2, 2007)

From CIO:

I vividly remember what it was like to be in that position and I understand many FoxPro devotees are understandably upset. But logically, not only did the end of life for FoxPro make sense, but everyone, including the FoxPro followers knew that this was coming, regardless of what Microsoft did or did not say. When I mentioned this fact to some colleagues, the near-universal response was "What?! You mean FoxPro was still around?"

---

In addition, many FoxPro to .NET conversion consultancies have been around for several years. Quite bluntly, the FoxPro developers who were surprised by this announcement have had their heads in the sand.

Microsoft has not only been moving away from native development (C++ aside) and focusing on managed code, but centralizing all development tools around Visual Studio. Gone are the days of maintaining and supporting dozens of separate specialized development environments.

To bring FoxPro into this fold would require FoxPro to be brought to .NET properly and for it to become part of Visual Studio. Either step would have drastically changed FoxPro in ways that would make the VB to VB.NET change look small in comparison. The end result may have shared a name with FoxPro, but it certainly would not be a FoxPro the FoxPro developers would recognize, and it certainly would not run existing FoxPro applications without massive changes.

While FoxPro certainly has some unique features, most of them are now or soon available in .NET. Projects like LINQ continue to reduce the unique advantages of FoxPro, and taken in conjunction with the advantages of .NET, a move to .NET is the natural evolution.

---

There is no reason to panic if you are a FoxPro developer or if you have FoxPro applications. I would strongly recommend against new applications in FoxPro for obvious reasons, but existing applications are not going to expire tomorrow.

---

Some may blame Microsoft for dropping yet another product, but in reality it was the market and evolution that passed FoxPro by. Microsoft only did what was obvious and everyone but the devoted could see was coming.

From the comments:

This is how I see it: I have been developing web databases with Visual FoxPro for over 10 years, and when PHP or .NET programmers occasionally want to show me how much better their stuff is, they are always SHOCKED when they realize how much WORSE it is.

They typically need 3 to 10 times the code, sometimes over 20 times the code, to get business applications done. By the time they have instantiated their objects, I am finished with the business logic and application.

Furthermore, FoxPRO's built-in database is highly optimized and runs typically 5-10 times faster than SQLServer or MySQL in Web applications, no result sets need to be communicated, no SQL strings need to be parsed.

This is the ONLY problem I see: Although Visual FoxPRO is the most bugfree programming language around, it does not make Microsoft much money. It does NOT require SQL Server License fees, third-party components, additional language components, and typically much smaller developer teams.

FoxPRO was always the renegade product in the company, it's almost as if Microsoft was ALSO giving away MySQL to any potential SQLServer customer. "OBVIOUSLY that had to end".

BUT the XBASE community will not die because of the End-Of-Life notice, quite to the contrary. In the past FOXPRO was always the most powerful and best product in the XBASE community, and it was not profitable for anyone's XBASE to compete against Microsoft's product. With Microsoft leaving the competition, the XBASE competition will THRIVE, and companies like dBASE Inc, Recital, FlagShip, Harbor Project etc. will see a whole new reason for existence: hundreds of thousands of programmers coming.

The 25-year old dBASEII advertising "Boy Is This Costing You!" (referring to inefficient BASIC programming) is more true than ever before: XBASE code is perfect for web databases, because it deals directly with data instead of all these .NET and PHP memory variables, objects, procedure calls, etc. etc.

FoxPRO may see the End Of Life in another 10 years or so, but XBASE will continue to grow. I should probably do some actual code demonstrations that show how much better it works and plan to do so.

Everything Old is New Again (Newsletter: Dan Covill)

I found this in the San Diego VFP User Group's newsletter, dated April 2007. I thought it was well written:

   Reading the comments following YAG's announcement (half of which,
  interestingly enough, were in Spanish) brought Chicken Little to
  mind.  It was either, "Oh, my God!  We're all going to be out of
  work!" or, "I'm leaving Microsoft and rewriting all my applications
  in PYTHON/JAVA for Linux/OS-X".

  Come on, folks!  While this isn't exactly _good_ news, it's not
  like we haven't seen it coming for about ten years now.  And anyone
  who's "lost faith in Microsoft" over this has been asleep for a
  long, long time.

  Yes, we have a problem in future direction.  It's doubtful that we
  will be programming in VFP in the year 2025.  (Okay, I myself won't
  be programming in _anything_ by then, but you know what I mean.
  )  But there's no need to rush out and buy a copy of Python,
  either (actually, it's free).  Here's how I see it:

  1. This is not a surprise.  There is absolutely nothing in the
  announcement we haven't known about for six months to a year.

  2. VFP (with its unique data structure) is the ideal platform for
  building custom apps for small/medium businesses.  Microsoft not
  only isn't into small business, they don't know anything about it,
  which is why they never pushed VFP and are only too happy to end
  it.  But in spite of MS marketing efforts, there is a huge
  installed base of dBASE/FoxPro/VFP apps out there, all running and
  needing occasional repair or upgrade.  And most of the owners are
  NOT interested in paying you what it would cost to rewrite their
  apps in .NET.  It's taken 20 years to build all those apps, and
  they won't vanish overnight.  I'd guess you'll be able to find VFP
  work for another ten years at least, even if FoxPro finally stays
  dead.

  3. I think it's entirely possible that, with Microsoft having left
  the field, more alternatives may appear.  dBASE is still around,
  for example - their website talks about running under VISTA.  Ed
  Leafe and Paul McNett are still working on DABO (which is a VFP
  clone written in Python).

  4. You can't just translate a good VFP app to some other language,
  because the magic of VFP isn't in the syntax (not that different
  from BASIC, really), but in the conceptual framework.  There IS no
  other language that treats database fields as linguistic
  primitives, allowing us to write code that is truly data-centric.
  So you have to re-design the app with a new set of concepts, and
  then write it in the new language.  That won't be cheap.

  In January 2006 I ran an item reporting that Visual FoxPro was
  ranked 20th in the worldwide index of programming languages put out
  by TIOBE.com.  Well, guess what?  As of today, VFP has fallen all
  the way to 22nd!  It's selling like hotcakes in China and India.

  OK, enough.  Like Pogo Possum, I advocate creative inaction.  Don't
  panic.  Keep on taking good care of your employer/client's VFP
  systems.  You've literally got years before you HAVE to do
  anything, give it some time to see what pops up.  Remember, the
  first ones to jump ship have the farthest to swim.

Interesting remarks on legacy tech (Posting: Hal Kaplan)

From this thread:

When I was a newbie, I worked for a company that kept two RCA Spectra 70
systems around way past their useful life because the systems hosted two
applications: Billing and Payroll. The programs were written in COBOL.
But it wasn't just COBOL or Spectra 70s. It was the disk drives, and
the printers. This company made several deals with the devil to keep
these machines going. It just could not bring itself to cutting the
cord. The vendor (Sperry) FEs would spend hours each week scouring the
nation for spare parts. We had printer ribbons up the kazoo stockpiled
because they were generally unavailable. Oh yes, they kept the
programmers around too (sweet job, I guess). And they postponed the
demolition of the old corporate headquarters to avoid having to move the
Spectras.

So I guess times are changing, but why do they have to change?

If you have an application running on a computer configuration today and
that running application is producing a meaningful product or service
for your company, why do you need to switch? When did the "upgrade or
lose support" gene become part of our collective DNA? Support is an
issue for immature products. When was the last time you actually got
support from M$ that was of any value? Probably shortly after you
upgraded (or updated) your system and the recent change was not yet
ready for distro.

The real problem here is not M$ but Intel. M$ stuff will only work as
long as Intel (or AMD, I suppose) produces a product that will bootstrap
the way it does today. Yes, one minor circuit change and everything,
including Linux, will fail. And that failure will be a lot harder to
overcome than if M$ changed one line of code.

VFP & its EULA (Thread: Leafe.com)

From this thread:

My feeling is that if your app is working, there is no need to panic
and abandon all that good, solid code because they finally made official
what many of us have sensed for quite some time. Given the number of really
smart people who use Fox, I'll bet that even if Microsoft doesn't do it,
someone will figure out a way to make VFP run on future OSs. Remember, the
fast CPU fix didn't come from Microsoft, but it enabled old Fox 2.x apps to
run on hardware well past the lives of the products.

---

If you look in the VFP EULA:

"Section 4.
You may not:

* work around technical limitations in the software"

I think you must admit that this is the equivalent of disabling your
software i.e you can't use it legally, and it covers a number of other
scenarios.

All Microsoft have to do is to place a "technical limitation" on the
software - whatever that means to them at the time.

Yes, I admit that this would be unlikely (I hope) but it shows what you
agree to when you accept the EULA. Just what is a "Technical Limitation"?

---

UK law (which overrides the EULA :0 ) says that you can reverse
engineer any software to resolve a bug.

The killer is that you dont own the tools just licence them and they
have the right to cancel your licence at any time for any reason. This
is the same for nearly all business software (in volume terms very
little is released outside this licencing model yet).

In the UK you can challenge this as being punitive but I dont know of a
case going to court.

---

Have you got big enough pockets to take a test case to court?

I guess not and that is where M$ will always win out - unfortunately.

---

"It's great to see the brain-dead requirement of having to uninstall
previous versions has been removed. However, there are some really
bizarre new phrases added. Rush Strong points out the weirdest: "You
may not.. work around technical limitations in the software," Excuse
me? That's how I have made my living for the past fifteen years. VFP
doesn't include your inventory system, but that's a technical
limitation I can help you work around. Yes, it's true that DROP TAG
ALL will remove all relations, but I know of a product that works
around that technical limitation� VFP crashes when used with some HP
drivers, but there's a technical work-around on the Microsoft
KnowledgeBase that lets me work around this technical limitation."

"I find it hard to believe that such a silly requirement could be
enforced in court. On the one hand, OJ was found innocent and Sacco
and Vanzetti executed. On the other, Microsoft was found guilty,
guilty, guilty. I have neither the money nor the interest in finding
out what is and isn't enforceable in the EULA! But I think a lawyer at
Microsoft needs to be flogged for writing such nonsense."

---

Once MS started putting silly, meaningless phrases in their license,
it was obvious they were not interested in doing business with people
who wanted to use their product. Imagine your corporate attorney
asking you "Did you work around any technical limitations in the
software in the course of developing this application?"

Good advice for programmers re: languages (Posting: Larry Bradley)

Comes from this thread:

...If you can write apps in VFP, you can write apps in anything...Once you know HOW to write programs, learning a new language and applying it is easy.

VFP is actually a lousy programming language - it doesn't protect you from
yourself, like a lot of modern strongly-typed languages do. It is easy to
shoot yourself (and your client) in the foot, or other more tender parts.
If you are successful with VFP, you should have no problems with Python,
C#, Algol, ... (add language flavor of the month here).

The development environment is a lot more important than the language. ...

Don't get hung up on "I'm a VFP developer". You aren't. You are an
application developer. And you can develop apps in any language that meets
the client's needs. It might take you a while longer than if you did it in
VFP, which we all know like the back of our hands. There is going to be a
learning curve. But you can do it.

But if a client's needs might be best satisfied by using Delphi, why not?
You don't need to be a one-tool application developer. A carpenter would be
in deep doo-doo (sawdust?) if he only had one saw. Put several saws in your
toolbox, and get out there and build things.

Why not use some of your spare time taking a small VFP app that you have
written, and convert it to some other language? Python/DABO? VB and mySQL?
Make it a web-based app, using PHP and Apache and mySQL? C# and SQL Lite?

No need to despair. There will always be more work out there than people to
do it.

A VFP Guru's advice for the future (Posting: Whil Hentzen)

Come from this thread:

There are two schools of thought here. The first is to be an expert in a
language, and when the call comes for help in that language, you hold up
your hand and yell, "Pick me! Pick me!"

The other is to be a domain expert (auto parts, insurance, factory
automation, pet store inventory...) and develop 'solutions' for that
domain. The tool(s) you use are (mostly) irrelevant.

I've always been a door #1 kind of guy, fortunate that I can pick up
specific domain knowledge quickly and effectively. I like it because
it's really interesting; on the factory floor with the Archie Bunkers
and Homer Simpsons one day, in the bank's currency exchange back office
with the vapid young pretties the next. Lot of variety.

_MY_ plan (as I've stated in public many a time, although a few
disgruntled folks have chosen to selectively edit what I've said to suit
their own means) is to maintain VFP for years, but not to invest in it.
Rather, spend spare R&D time in a _growing_ market opportunity.

LAMP is the way to go as far as I'm concerned. I see MSFT's attitude and
approach being a losing game. They're nasty and don't offer good value
(anyone out there feel that a Vista upgrade is money well-spent?) The
reason they're still making money is because people don't have much of a
choice.

LAMP offers opportunity and freedom... oh, enough of that soapbox.
What's really compelling about the 'AMP' part is that it's cross
platform. MySQL, PHP and Python (and Apache, actually) all run on
multiple platforms, which is nice, since suddenly your skills are
xferrable.

I'm certain I'll be selling VFP books and doing VFP maintenance in 2020,
but I don't see a big benefit in becoming a Sedna expert. Maintenance
means remembering ON KEY LABEL, not MSFT's du-jour incarnation of COM,
some obscure hook between VFP and something else.

Thoughts from a young programmer (Posting: Derek Kalweit)

From this thread:

...if...you're young like me(20's). I've used
many languages over the past 10 years and primarily code in VFP and
VC++; VFP being the one I spend the most time with. I work at an
employer with VFP, and I work on the side and develop applications for
sale.

Personally, I have to think about the next 30 years or so of my
career(retiring right before January 2038 at the latest), unlike most
people here. I have to think of what I can write applications in for
my side business, ignoring any marketing hype(consumers rarely care),
but I also have to keep a pulse on the job market for software
engineers in my area.

With this dual requirement, I've decided to pursue .NET. If I look at
the software engineer positions being advertised around here, they're
JAVA, .NET, and C/C++ predominantly. Most of the JAVA stuff is high
level enterprise stuff which I've had some experience with in the past
and hated. .NET is my choice to learn more of right now and start
coding new applications in, as I think it makes the most sense for me,
financially/career-wise, going forward.

As much as I might like open-source stuff such as DABO and so on,
there are almost no jobs available in my area for such. Even Ed
himself doesn't have any paying Dabo work-- if one of the creators
can't get any, why would I think I can?

Think it through and try to make the best decision you can going
forward. At our age, the worst thing we could do is hide our heads in
the sand and think we can trek through with VFP alone for the rest of
our careers.

The Effects of MS's Actions (Posting: Robert Jennings)

A posting from this thread succinctly details the repercussions of MS's actions regarding VFP:

It may be fine for a programmer who goes from company to company to pick up lots of languages and write software in them (Which is fine) but my problem is that I have applications that I have out in the Market, we have over a thousand sites/ships using our software.

Prior to 2000 the company had software written in Clipper running in DOS.
VFP was the natural progression to provide the software on the Windows Platform. (yes a rewrite was required from the ground up) Saying that, it took 2 years to Migrate 1 application from Clipper to VFP.

We have had 9 years since the first VFP code was written. We have 6 Products that have progressed immensely since 1998. We have libraries of functions that work providing the meat of data manipulation and the interface presenting the data to the user. Many of the systems have been modified to meet user requirements.

Suffice to say, that I don't think that there has been a month gone by when the software hasn't been worked on to provide a customer modification or upgrades. There are 3 full time developers working on this software. I would say that 21 Man Years are invested into our software in VFP.

Granted, the software does need overhauling, made to be more oop, separate the Interface from the Data and make it work with a SQL server (any flavour) (we are still using VFP Tables!) Rewriting in VFP would be much faster as a lot of code can be copied over. We could have created the separate layers and we would have gone to version 2 of our software without a problem (well, I'm sure there would have been a couple but not too big!)

Now lets look at what Microsoft have done.
Driven the nail in the Coffin of VFP. They will not sell it, the will not Open Source it. The language, DBMS et al will go. At some point and they can't confirm when, their operating systems will not support the VFP runtime. Yes granted, it may be 2020 before that happens, but I'm astounded that there is not an upgrade path. If they rolled VFP into .NET then fantastic, I should imagine that we could have ported our applications.

Now lets look what I face.
Move all my applications over to another Language e.g. Dabo, .NET (any flavour), Python etc etc etc.
This is going to mean that I have to stop the Modifications and Upgrades to my applications while I (and the rest of the team) re-write the applications (6 of them) from the ground up. This is going to cost my company at least £200,000 ($400,000) for every Year it takes to re-write (Wages / Lost potential earnings in Modifications & Upgrades). I think it will take 3 of us at least 3 years to re-write all 6 modules. 9 MAN YEARS if we are flying.

The new software will not have all the modifications for clients who will one day have to move over to the New application, then there is going to be a backlash from them as I'm going to have to charge them to modify the software to do exactly what they want.

We are a small company, because of Microsoft actions our profitability is going to take a big hit. Our customers are going to see a slowdown in our reaction times (which at the moment is lightning) and they will face a bill to upgrade once we have re-coded. Companies are going to have less confidence in our products because they know that Microsoft is stopping support for VFP in 2015. If we had a rough date by which time VFP will no longer work on the VFP platform at least we could reassure customers slightly.

If we go over to .NET will Microsoft Kill that at some point?

Can Microsoft be more specific when they will pull the Plug on VFP running on Windows Operating Systems?

On Announcement (Thread: MSDN Forum)

Highlights from this thread:

They have invested a lot of money in VFP over the past 15 years and a lot of VFP technologies are used in other Microsoft tools - especially RushMore optimization and, I believe, also parts of the VFP ISAM and its CURSOR engine. So even if MS do not want to develop VFP any further, it is unlikely they would release it to a potential competitor.

As I said elsewhere:

Viewed objectively this is no surprise at all. About the only thing that would make any sense for a new "VFP 10" version would be a complete re-write from the ground up to make it a full 64-bit application. Given the revenue model for VFP (i.e. ZERO!!!), and the fact that Microsoft's preferred strategy is to sell SQL Server Licenses, that would make no financial sense whatsoever, and there really isn't (from Microsoft's perspective) a business case for a desktop database. Remember, Microsoft is NOT a software company, it is a primarily a Marketing company in the business of making money!

And before we start the "Sky is falling" chorus, just consider how many people are still using VFP 6.0 (never mind 7.0 or 8.0) - a version that was released 8 years ago and is no longer even supported. Now add in those who still use FP DOS, and FP 2.6W (products that died 12 years ago) and explain to me why this actually matters?

Just because Microsoft say they won't release a Version 10 doesn't mean any of the following:

• that VFP is going to stop working
• that its data handling and integration capabilities have gone away
• that the reasons that you chose VFP as your development tool to begin with have changed
• that you can no longer create and distribute royalty free EXE data-based applications
• that the capabilities and extensibility that make VFP the most powerful desktop database have changed
  

I have always tried to use the best tool for the job at hand. I will continue to do so, and as long as the best tool is VFP then that is what I will use!

---

...The sky is not falling, the sky is changing ... just that. And us as developers must adapt to the change. Now is a new ocassion to see what is out there, to think in new possibilities, to see the world from a new perspective. Since two days, now I'm considering cross platform products (Win, *nix and Mac OSX) thing I never planned before ... so this can be a good opportunity to see that live is out there.

VFP will still be the best desktop database development environment. People will still develop in a good product like VFP. We will have time for see alternatives to Fox.

But now things are changing.

---

Access is not the answer. It is morphing into some kind of Sharepoint database.

FoxPro type queries are already coming in .Net. Look carefully at LINQ. It does VFP type queries and more.

Also, keep a close watch on the next two or three versions of VB.Net. You'll be very surprised by how much it looks like VFP.

---

If microsoft are going to desert there long serving user base then I for one will be deserting Microsoft and will look at a non microsoft replacement.

---

That's a very unprofessional response. Many years ago, Ford discontinued producing the Escort, even though at the time, it was the best selling car in the world. Did that mean people should stop buying Ford?

You should use the current tool that is best for your customers.

---

I don't disagree that you should use the current tool that is best for your customers, but your customers are also sometimes other businesses with IT departments or someone on staff who will say "We don't want any FoxPro apps from a dead language" From the standpoint of being as marketable as possible FoxPro does me little good. It's actually a hinderance in some cases since so many people who really know little about FoxPro cringe when they here it's name mentioned. Whether I like it or not in order to continue my career as a programmer it's either .NET or Java.

---

You Guys are just wrong….

You do NOT use the best language for your client! You use the best language for your business. That entails the ability to resell and extend any code you write for YEARS to come. Foxpro was no longer that language as soon a MS announced it would never go 64 bit.

I cannot and will not build my business in such a way that I can only support my current clients and can’t take on new ones. I must plan for the future. By the time 2015 comes around Foxpro 32 bit will be what Foxpro 16 bit is to day.

Good luck selling a new client on any DOS app today, Good luck selling any client on a 32 App in 10 years, regardless if they heard of FoxPro or not.

Its time to move on……. In fact we’re VERY late.

Ps : Sedna is joke….. It’s just a scam to get FoxPro programmers to learn .NET.

---

That's why alot of VFP developers are now considering Open Source. It just doesn't seem right that a company can pull strings with a development language like VFP. Such a thing could not be done with PHP, Perl, Ruby-On-Rails,etc. because no one company controls them. Gee, it would be nice if VFP were like this too.

And what if MS decides VB.Net is not "strategic" in 3 years and it would be sooo nice if they only had 1 language, C#?

---

We cant stop times...

VFP it'snt the language of future...

I know only vfp, but now i MUST learn not only another developer language but "how" developer...

The future is programs that run in a browser but are quick as a stand-alone procedure. Programs that run on all platforms (OS and DB) and integrated with most distributed software... (Print in pdf format and in RTF, export in excel/openoffice, send email with mapi method and with HTML Mail)

VFP is sufficient now for this, but the future needs another structure.

VFP & Linux (Blog: Ted Roche)

Link

Highlight:

With the recent VFP9 EULA (I still haven’t seen it online), someone asked if that meant that VFP is dead on Linux. Frankly, I’ve always thought of it as more of a parlor trick than a viable platform for development. I mean, if the vendor really doesn’t want to run on the many other operating systems out there, that is their choice, even if they are cutting off their nose to spite their face. The other answer is one that Paul points out in the white paper on his site: you don’t need to run VFP 9 or 8 or even 7 to get most of the benefits of VFP. If you are running (or at least distributing) VFP 6 level applications, the EULA had no noxious requirements about the operating system. As always, you should consult a lawyer about this, but it looks good to me…

On Announcement (Blog: Ted Roche)

Link

Highlights:

Unlike the Open Source world, when a vendor choses to discontinue a product, developers have little choice but to move along. While many folks point out the upside that the product will likely run for years to come, and a lack of Microsoft official support doesn’t instantly obsolete a product (DOS apps can still be found, after all), there is an immediate slowdown in the custom software market, and a longer-term turning away from the product by customers. Large-scale vertical products have to be operating with 5- and 10-year plans for reinvestment and changes in direction, to ensure they can fund “The Next Big Thing” while continuing to deliver good value to their customers today and tomorrow.

This is not a death knell for the product. The writing has been on the wall for years. But developers with large applications have to be looking around for a new platform.

VFP as a threat to SQL Server (Quote: Les Pinter)

Link
He quoted a senior Microsoft official [who claimed to be quoting Bill Gates] as saying that "every VFP license sold represents a loss of about $10,000 in SQL Server license fees"

Discussion

Hi Jim (and others on this thread). Please do not believe everything you
read as-is without any validation. I don't know who Les Pinter talked to
here, it probably wasn't an executive and without names, the quote is
really meaningless. I've never heard a quote or anything like this from
anyone at Microsoft at any level. -- Ken Levy

---

Actually, chances are that for every license of VFP, hundreds of SQL Server licenses may be sold!

---

The way I heard it, the "unnamed source" WAS another high level m$
executive...not from Redmond...

On Announcement (Blog: ISV)

Link

Highlight:

Microsoft buys FoxPro, kills it and recommends you to rewrite your products as enhancements to their offerings. Sounds like a brilliant strategy! Perhaps it's time to switch to a tool-vendor that doesn't compete with your core business!

VFP & GoogleAPI (Blog: Kevin Ragsdale)

This guy is doing some really neat work.

Story of VFP9 SP2 DLL Hell (Blog: Kevin Ragsdale)

Link