By orders of magnitude, my most popular open source release was a project to help people migrate from FoxPro to PostgreSQL: https://github.com/kstrauser/pgdbf
FoxPro was cool for desktop apps, but couldn’t make the leap to networked clients, where “networked” was more than “has access to the file share where the database files live”.
In the early 2000s I was hired to write a website that published reports from data stored in a Visual FoxPro database. A not-so-fun fact I learned: the VFP database libraries are single-threaded at the OS level. That is, you couldn’t run more than one query on the same machine at the same time, even in different processes. One would block until another finished. In a fit a panic and madness, I ended up writing an XMLRPC service (“which was the style at the time”) in Python, deploying it to multiple old Windows XP desktops we had laying around, and writing a database adapter for the web server that would send queries to those servers round-robin. Need more parallelism? Add another Windows XP box running my janky little service. It was awful, but it let us ship the project.
Later I wrote pgdbf so that we could run a cron job that would copy all our data out of FoxPro into PostgreSQL so that I could code against a real multi-user database that was vastly better in every way. By accident, I released it at a time when the world was wondering how they were going to migrate from FoxPro to something else. Turns out VFP was wildly popular in South America, and pgdbf turned out to be wildly popular there too, which let to me getting lots of email in Spanish and Portuguese and offers to come talk at user groups. I turned those down because what was I gonna say, “yeah, it was painful for me, too. Anyway, here you go and good luck!”?
VFP was crippled, like intentionally, by MS. Fox was absolutely superior to Access and SQL Server at the time (ie: as for build productive apps).
But the engine have so many quirks that affect their reliability (I still remember any fox app have the "rebuild indexes" and "fix corruption" in the menu of the app!)
This was purely a ploy, I think. Then Fox was killed and now millions of hours are wasted doing what fox allow in minutes.
FoxPro was cool for desktop apps, but couldn’t make the leap to networked clients, where “networked” was more than “has access to the file share where the database files live”.
In the early 2000s I was hired to write a website that published reports from data stored in a Visual FoxPro database. A not-so-fun fact I learned: the VFP database libraries are single-threaded at the OS level. That is, you couldn’t run more than one query on the same machine at the same time, even in different processes. One would block until another finished. In a fit a panic and madness, I ended up writing an XMLRPC service (“which was the style at the time”) in Python, deploying it to multiple old Windows XP desktops we had laying around, and writing a database adapter for the web server that would send queries to those servers round-robin. Need more parallelism? Add another Windows XP box running my janky little service. It was awful, but it let us ship the project.
Later I wrote pgdbf so that we could run a cron job that would copy all our data out of FoxPro into PostgreSQL so that I could code against a real multi-user database that was vastly better in every way. By accident, I released it at a time when the world was wondering how they were going to migrate from FoxPro to something else. Turns out VFP was wildly popular in South America, and pgdbf turned out to be wildly popular there too, which let to me getting lots of email in Spanish and Portuguese and offers to come talk at user groups. I turned those down because what was I gonna say, “yeah, it was painful for me, too. Anyway, here you go and good luck!”?