What made you write this post, Greg?


>Just a thought here....
>
>Back in the 1980's Ashton-Tate developed dBase. This became a widely used product. Then a professor started a company named Fox Software developed a competitive product named FoxBase. This product was compatible with the language of dBase and the file structure. As time progressed Aston-Tate developed more versions which added functionality and FoxBase had to catch-up. Then Fox Software developed FoxPro -- it was considerably faster and had more language commands/capability beyond dBase. Aston-Tate developed dBase+ -- it was a failure (had many bugs). For Fox Software, FoxPro was the first to deviate away from the base of dBase (which came be known as xBase language). Fox Software continued to improve FoxPro and was later bought by Microsoft and later became Visual FoxPro.
>
>The story above is well known and I my point of telling it is that if Fox Software had developed a product that was not completely compatible with the existing base of dBase under Ashton-Tate, it probably would not have been as successful. Developers had a vested interest in dBase -- code and data. To change this to a completely different platform has a lot of risk and cost. Being able to seamlessly move to FoxBase and to FoxPro made the migration easy. Once the move to FoxBase or FoxPro, Fox Software was able to keep them as a customer based on the performance and reliability of FoxPro.
>
>Now you are attempting to build a product as a successor to FoxPro. My advice if you want user to use it is that it is completely compatible with all the commands in the VFP language, as well as all reports, all forms, all classes. They should be able to take any form created/edited in VFP and open that same form in your environment, make any changes (except for language additions that are specific to you) and then save the form. Then they should be able to open it in VFP and see the changes and have it work flawlessly in VFP.
>
>Otherwise, you are asking people to migrate and I as a developer would ask "what makes yours better than any other platform"? Why not use java, perl, C# or any other platform. I know you plan on a migration path, but for a developer to commit there has to be a degree of confidence in the platform in terms of stability and life. We all know that VFP is no longer being developed by Microsoft; but it is a known stable platform and can deliver what is needed. Your development environment does not have this same pedigree and will have to be proven.
>
>Just some thoughts -- my hope is that you succeed. Others have started down this path and stopped (maybe not failed, but lost ambition to complete). Where is the point that you lose ambition to continue? What is the longevity of FreePro? You are placing into the public domain as open source, but what value if no other developers will "sign-on" to maintaining the code base? Most of the VFP developers is suspect (myself included) do not have the skills to maintain C/C++ code nor do I have the time to learn. As an open source what is the incentive for others to join in? Typically open source developers are there because of their interest or passion in that area -- what passions are there in the VFP community that have C/C++ skills that would also work with this?
>
>Open source succeeds when others have passion in that project too...