Microsoft should open-source FoxPro, at least some version of it, because as of 2026, it has no commercial viability (no ability for it to make the company money) compared to say SQL Server, Access and/or Visual Basic with the appropriate back-end database drivers. If Visual FoxPro V9 (2007) is too late because there are unexpired patents or other issues, then Microsoft should open-source an earlier version.
Even open-sourcing FoxPro 2.6a for DOS (the last DOS version, August 1994, > 30 years ago) would be better than open-sourcing no FoxPro version.
Fundamentally, FoxPro, at its core, is 4 things:
1) It's own low-level database engine
2) It's own SQL parser/interpreter/engine sitting on top of #1.
3) Simple (but very data-aware of the underlying data!) scripting language (based on dBase, referred to as "xBase" -- or more specifically the FoxPro dialect of xBase) sitting on top of #1 (except for the SQL commands, SELECT, INSERT, UPDATE, DELETE, etc., which sit on top of #2)
4) Form / GUI / Data-entry and Data-search Form Designers that exist on top of #1, #2 and #3. Basically a primitive (although very functional and elegantly simple) windowed App building environment.
Now, all of those 4 things could be replaced and/or outsourced to other open-source projects...
For example, to read/write/index/seek in FoxPro database files (the low-level database engine):
I'm not sure if CodeBase comes with its own SQL engine/parser -- but if not, SQLite has a pretty good one which could probably be used with some modifications. If not, ANTLR has various SQL grammars for it floating around on the net (here's a quick blog post of someone using ANTLR to create a query language: https://markandrewperry.medium.com/using-antlr-to-create-a-q...)
For the scripting language, any scripting language could potentially work, but special attention should be paid to the way FoxPro variables are aware of data in underlying open tables in the current work area (SCATTER and GATHER commands and how they work, etc.), which is one of the unique features of FoxPro. (Also, for command / line / expression evaluation, you'd probably want to use or at least know about Dijkstra's Shunting Yard Algorithm: https://en.wikipedia.org/wiki/Shunting_yard_algorithm)
For the GUI / Form designers, well, any data-aware form-designing graphical toolkit could work, but of course, FoxPro has/had its own nuanced "flavor" of these.
Generically speaking, FoxPro is/was a database engine, SQL engine, very-data-aware scripting language and form/gui/app designer -- all rolled into one package.
I'd love to see an app where all of these components are open source, where there are clear interfaces between those components (separate compilation options for codebases, depending on which components you want), where the original FoxPro/dBase/xBase scripting language is used (because it was great!) and where any underlying database engine and/or SQL engine could be "swapped out" for any other (i.e., SQLite, Postgres, etc.)
Anyway, FoxDevStudio looks interesting in this space!
Even open-sourcing FoxPro 2.6a for DOS (the last DOS version, August 1994, > 30 years ago) would be better than open-sourcing no FoxPro version.
Fundamentally, FoxPro, at its core, is 4 things:
1) It's own low-level database engine
2) It's own SQL parser/interpreter/engine sitting on top of #1.
3) Simple (but very data-aware of the underlying data!) scripting language (based on dBase, referred to as "xBase" -- or more specifically the FoxPro dialect of xBase) sitting on top of #1 (except for the SQL commands, SELECT, INSERT, UPDATE, DELETE, etc., which sit on top of #2)
4) Form / GUI / Data-entry and Data-search Form Designers that exist on top of #1, #2 and #3. Basically a primitive (although very functional and elegantly simple) windowed App building environment.
Now, all of those 4 things could be replaced and/or outsourced to other open-source projects...
For example, to read/write/index/seek in FoxPro database files (the low-level database engine):
https://github.com/MPSystemsServices/CodeBase-for-DBF
I'm not sure if CodeBase comes with its own SQL engine/parser -- but if not, SQLite has a pretty good one which could probably be used with some modifications. If not, ANTLR has various SQL grammars for it floating around on the net (here's a quick blog post of someone using ANTLR to create a query language: https://markandrewperry.medium.com/using-antlr-to-create-a-q...)
For the scripting language, any scripting language could potentially work, but special attention should be paid to the way FoxPro variables are aware of data in underlying open tables in the current work area (SCATTER and GATHER commands and how they work, etc.), which is one of the unique features of FoxPro. (Also, for command / line / expression evaluation, you'd probably want to use or at least know about Dijkstra's Shunting Yard Algorithm: https://en.wikipedia.org/wiki/Shunting_yard_algorithm)
For the GUI / Form designers, well, any data-aware form-designing graphical toolkit could work, but of course, FoxPro has/had its own nuanced "flavor" of these.
Generically speaking, FoxPro is/was a database engine, SQL engine, very-data-aware scripting language and form/gui/app designer -- all rolled into one package.
I'd love to see an app where all of these components are open source, where there are clear interfaces between those components (separate compilation options for codebases, depending on which components you want), where the original FoxPro/dBase/xBase scripting language is used (because it was great!) and where any underlying database engine and/or SQL engine could be "swapped out" for any other (i.e., SQLite, Postgres, etc.)
Anyway, FoxDevStudio looks interesting in this space!