Wednesday, March 14, 2007

Microsoft's Announcement

In case you missed it, Microsoft announced yesterday that VFP 9 SP 2 will be the last version of VFP and that Sedna will be released as one or more shared source projects on CodePlex.

Several others, including David Stevenson, Craig Berntson, Alex Feldstein, and John Koziol, have blogged about this already. My thoughts about this echo theirs: not surprised but both sad and happy.

Not surprised because if you carefully read the VFP roadmap, you could see that there really was no plan for a VFP 10. The announcement really was a confirmation rather than anything new (well, the part about VFP 10 anyway; the Sedna announcement really is news).

Sad because the VFP team isn't exactly a team anymore. They're mostly working on adding VFP-like features to Visual Basic, with some effort on getting VFP 9 SP 2 done. After it ships, they'll be available from time-to-time to work on bug fixes for VFP (likely only major ones, which are unlikely given how long VFP has been shipping) but there really won't be a VFP team anymore.

Happy because Sedna will now be available for free to all VFP developers, plus since it's available with source code and the same license as VFPX, we'll be able to customize and adapt its components as we see fit.

Here are my thoughts on this announcement in no particular order.

The VFP core is almost done. The only thing left to do is finish up some Vista-related issues, and that'll be in SP2. I remember Ken Levy's response at various conferences when asked what was going to be in the next release of VFP: "what features do you want?" Invariably, the answer was "I don't know". I honestly can't think of any new feature I want in VFP that must be in the core (ie. VFP9.EXE). The things I want, like new UI components (such as the Office 2007 ribbon), can be created using VFP code, GDI+ calls, or ActiveX controls without touching the core. So what could the VFP team do that would prompt developers to buy a VFP 10 in sufficient quantities to pay for the development costs? Let's not talk about "fixing the 2 GB limit" since that's not even remotely reasonable (they'd have to examine nearly every single line of code that makes up VFP and the test load would be enormous) nor is it really important: if you have that much data, use SQL Server, Oracle, or something else as the data store.

Suppose the announcement was about Microsoft Word instead of VFP. Would that mean you have to switch to a different word processor? Of course not. I'd continue to use Word until it no longer worked on some future system. After all, what new features in Word would I need added? I hardly use the full feature set now. So, if they stopped new development of Word and put it into maintenance mode, I'd be fine. It's the same thing with VFP; as long as it continues to work on any future operating system Microsoft chooses to release (and there isn't anything special in VFP that would prevent that from happening any more than there is in hundreds of thousands of other applications), I'm fine. I can continue to develop VFP applications for at least the next 10 to 15 years, at which point I'll be ready for retirement. In other words, if I choose to do so, I could use VFP for the rest of my career.

I've heard a few snide comments from other MVPs here at the MVP Summit that VFP is now dead or discontinued. That's not true at all. I can continue to purchase VFP licenses for new development staff for several more years and I can continue to receive support from Microsoft until 2015 (I've never actually contacted MS support, not one single time, but it's nice to know it's there just in case). That's not definition of dead. To me, dead means I can't buy any more licenses so no new staff could legally use it and there'd be no support available for it. I'm willing to bet that, like me, you've never or rarely contacted MS for VFP support, because the support available from the VFP community is so much better, faster, and cheaper than what you can get from MS.

The future of VFP is on CodePlex, in the VFPX and other VFP-related projects. We as a community can continue to enhance VFP through shared source projects. Just look at the extremely cool projects available there now. Add to that the entire set of components in Sedna and all the other things people can create and you'll see that there isn't much limit to what we can continue to do with VFP.

I'm not an MS apologist, I'm not naive, and I don't have my head in the sand. I realize that the product we all love has a limited shelf life. However, I've known that for years, and it didn't stop me from making buckets of money using this tool. I'll continue to use VFP while also using other technologies where it makes sense (for example, we use several C# components in Stonefield Query because those components enable us to, for example, access ACT 2007 data that we can't get at natively using VFP).

It comes down to using the right tool for the right job and making decisions that make sense for your business and your customers. VFP continues to make sense for me, so I'll continue to use it for a long time to come. I'll continue to write articles, continue to answer questions on various VFP forums, and continue to attend and speak at conferences.

1 comment:

Anonymous said...


With regards to your blog about VFP. The concern I have is MSFT is not providing a suitable upgrade path for the small and medium size business customers. .NET and SQL Server is overkill with a much increased cost of ownerhsip and access is not flexible enough.

It is not so much about changing the core to add new features (more built in control over process threads would be nice) but allowing VFP to coexist with future version of Microsoft software and operating systems.

It is almost a given at some point there are going to be changes to the API that VFP simply will not be able work with. We been through this with Microsoft when VFP did not support ISIMPLEFRAME and hindered it's activex suppport.

Furthermore SQL Server is a great backend for FoxPro. There are no gaurantees VFP will be able use future SQL data types and it will fall behind in it's SQL implementation and to the best of my knowledge SEDNA will not be able to address any of these issues as these types of changes are made at the core level of VFP.

I really do not forsee performing any new future development in FoxPro because for the above stated issues.

Best Regards,
Mark Gordon