Visual FoxPro lleva más de una década sin soporte oficial de Microsoft, pero todavía existen empresas que mantienen aplicaciones desarrolladas con esta plataforma para gestionar facturación, inventarios, pedidos, contabilidad o procesos internos. La situación resulta menos extraña cuando se repasa su historia: FoxPro fue una herramienta especialmente eficaz para construir aplicaciones empresariales alrededor de bases de datos locales y acumuló durante años algo mucho más difícil de migrar que sus archivos DBF: las reglas de funcionamiento de miles de negocios.
Las claves de FoxPro en 30 segundos
- Fox Software convirtió FoxBASE y posteriormente FoxPro en importantes competidores de dBASE durante los años ochenta y principios de los noventa.
- Rushmore aprovechaba los índices para acelerar determinadas consultas y ayudó a cimentar la reputación de rendimiento de FoxPro.
- Microsoft anunció la compra de Fox Software en marzo de 1992, en una operación valorada entonces en unos 173 millones de dólares.
- Visual FoxPro 9 fue la última versión mayor y su soporte extendido terminó en enero de 2015.
- Muchas aplicaciones sobrevivieron porque migrarlas implica reconstruir código, datos y décadas de reglas empresariales.
El caso también desmonta una explicación repetida durante años: Microsoft no compró FoxPro en 1992 y lo cerró inmediatamente. Después de la operación continuó desarrollándolo, llevó FoxPro a Windows y publicó varias generaciones de Visual FoxPro. El problema apareció mucho más tarde, cuando la estrategia de desarrollo de Microsoft empezó a concentrarse alrededor de .NET, Visual Studio y SQL Server.
Ahí comenzó una situación que muchos administradores conocen bien: un producto puede quedarse sin futuro comercial mucho antes de que las aplicaciones creadas con él dejen de ser útiles.
De competir con dBASE a convertirse en una herramienta para crear aplicaciones
Para entender FoxPro hay que regresar a una informática empresarial muy diferente de la actual.
Durante los años ochenta no era necesario disponer de un servidor SQL separado, una API, un backend y un frontend para construir una aplicación de gestión.
Una base de datos podía residir directamente en los archivos del PC o de una red local. Sobre ella, un desarrollador podía construir pantallas, informes y lógica empresarial.
dBASE se convirtió en uno de los grandes nombres de aquella generación.
Su importancia terminó superando al propio producto. Los comandos, archivos DBF y técnicas utilizadas por sus programadores crearon una familia de herramientas compatibles conocida generalmente como xBase.
Fox Software entró precisamente en ese mercado con FoxBASE.
La compañía, dirigida por Dave Fulton, apostó por mantener compatibilidad con aplicaciones y conocimientos procedentes del entorno dBASE mientras mejoraba especialmente el rendimiento.
La estrategia funcionaba porque reducía uno de los principales obstáculos de cualquier migración: empezar desde cero.
Un desarrollador podía conservar buena parte de lo aprendido y una organización podía continuar utilizando sus datos mientras adoptaba otra herramienta.
Fox Software terminó evolucionando FoxBASE hasta convertirlo en FoxPro.
Uno de sus avances más recordados fue Rushmore, una tecnología de optimización de consultas incorporada a FoxPro 2.0.
Su principio sigue resultando familiar para cualquier administrador de bases de datos actual: aprovechar los índices disponibles para evitar recorrer innecesariamente todos los registros de una tabla.
Si una aplicación tenía cientos de miles de facturas y necesitaba localizar las correspondientes a un determinado cliente, un índice adecuado podía reducir enormemente el trabajo necesario.
Rushmore no solucionaba automáticamente un mal diseño. Los índices seguían teniendo costes y una consulta tenía que poder aprovecharlos. Pero contribuyó a construir la reputación de FoxPro como una plataforma especialmente rápida trabajando con datos locales.
El crecimiento de Fox también desembocó en una importante batalla judicial.
Ashton-Tate demandó a Fox Software por infracción de copyright relacionada con dBASE. El caso terminó complicándose para la propia Ashton-Tate.
En 1990 un tribunal estadounidense determinó que la compañía había omitido información material ante la Oficina de Copyright sobre la relación entre dBASE y JPLDIS, software de dominio público desarrollado en el Jet Propulsion Laboratory. El tribunal declaró inválidos los copyrights de la línea dBASE implicados en el litigio y desestimó las reclamaciones correspondientes.
La resolución es importante porque la historia no puede resumirse simplemente como «Fox copió dBASE y ganó». El procedimiento examinaba cuestiones concretas sobre copyright, derivación y la información proporcionada durante su registro.
Microsoft pagó unos 173 millones de dólares y siguió desarrollando FoxPro
El siguiente giro llegó en 1992.
Microsoft y Fox Software anunciaron el 24 de marzo su intención de fusionarse. La prensa de la época valoró la operación en aproximadamente 173 millones de dólares en acciones.
Para Microsoft suponía ganar rápidamente una posición relevante en bases de datos para ordenadores personales. Para Fox significaba incorporarse a una compañía que estaba convirtiendo Windows en la plataforma dominante del PC.
La adquisición no terminó con FoxPro.
Microsoft continuó desarrollando el producto y en 1995 apareció Visual FoxPro 3.0, que adaptaba la plataforma al desarrollo gráfico sobre Windows.
Visual FoxPro resultaba atractivo porque reunía muchas piezas necesarias para crear una aplicación empresarial.
El desarrollador tenía lenguaje de programación, motor de datos, formularios, consultas, informes y herramientas de desarrollo dentro del mismo entorno.
Para pequeñas empresas y desarrolladores independientes aquello podía reducir considerablemente el número de componentes necesarios para entregar un programa terminado.
Una tienda podía utilizarlo para inventario y facturación. Un distribuidor podía construir su gestión de pedidos. Una pequeña industria podía registrar producción, proveedores y entregas.
El desarrollador podía además modificar el programa cuando aparecía una necesidad específica.
Precisamente esa flexibilidad explica parte del problema actual.
Una aplicación empresarial mantenida durante 15 o 20 años deja de ser simplemente un ejecutable conectado a unas tablas.
Empieza a acumular excepciones.
Un cliente recibe un descuento diferente. Determinado artículo permite vender sin stock. Un informe calcula una comisión mediante una fórmula histórica. Contabilidad necesita una exportación concreta porque otro proceso depende de ella.
Miles de pequeñas decisiones terminan almacenadas en el código.
La aplicación se convierte así en una especie de documentación ejecutable de la empresa, aunque nadie la diseñase con ese propósito.
Visual FoxPro terminó, pero sus aplicaciones no recibieron la misma orden
Durante los años 2000 el mercado estaba cambiando.
Las aplicaciones empresariales avanzaban hacia arquitecturas cliente-servidor, servicios web, navegadores y servidores de bases de datos centralizados.
Microsoft también estaba construyendo una estrategia diferente.
.NET ofrecía una plataforma común para diferentes lenguajes, Visual Studio se consolidaba como entorno de desarrollo y SQL Server ocupaba una posición cada vez mayor en la estrategia de datos empresarial.
Visual FoxPro podía conectarse a bases remotas y convivir con parte de estas tecnologías, pero seguía manteniendo su propio lenguaje, runtime, herramientas y comunidad.
Microsoft publicó Visual FoxPro 9 en diciembre de 2004. Sería la última versión mayor.
En 2007 la compañía confirmó que no desarrollaría Visual FoxPro 10. El proyecto Sedna incorporó posteriormente componentes destinados a mejorar la interoperabilidad con tecnologías más modernas, pero no representaba una nueva generación completa de Visual FoxPro.
El soporte principal de Visual FoxPro 9 terminó en enero de 2010 y el soporte extendido finalizó el 13/01/2015, según el ciclo de vida oficial de Microsoft.
Y entonces ocurrió algo muy habitual en sistemas heredados: prácticamente nada.
Las aplicaciones no dejaron de arrancar.
Los DBF no desaparecieron.
Los programas de facturación continuaron generando facturas.
La desaparición del soporte del fabricante y la desaparición operativa de una aplicación son acontecimientos completamente diferentes.
Una empresa puede mantener un sistema heredado mientras continúe funcionando sobre el Windows disponible, existan personas capaces de mantenerlo y las dependencias externas no cambien demasiado.
El riesgo aparece progresivamente.
Cada actualización del sistema operativo requiere nuevas pruebas. Cada integración moderna puede necesitar soluciones adicionales. Cada desarrollador especializado que abandona el mercado reduce el conocimiento disponible.
Y aparece el problema más difícil: migrar FoxPro normalmente significa mucho más que convertir una base DBF a SQL Server, PostgreSQL u otro motor moderno.
Hay que descubrir qué hace realmente la aplicación.
Eso incluye código, consultas, informes, permisos, cálculos y procesos que quizá nunca fueron documentados. También incluye comportamientos aprendidos por los usuarios durante años.
Por eso algunas organizaciones terminan manteniendo estas aplicaciones dentro de entornos controlados, mientras otras trasladan primero los datos a un servidor SQL y conservan temporalmente FoxPro como frontend. También existen proyectos que sustituyen módulos progresivamente en lugar de intentar una reescritura completa.
Ninguna estrategia sirve para todos los casos.
Una aplicación departamental pequeña puede resultar relativamente sencilla de sustituir. Un ERP desarrollado a medida durante 25 años puede contener millones de líneas y una cantidad desconocida de lógica empresarial.
Ahí reside la razón por la que FoxPro continúa apareciendo en empresas décadas después de su mejor momento.
No sobrevivió porque Microsoft siga desarrollándolo.
Sobrevive porque el coste de reemplazar una aplicación empresarial depende menos de la antigüedad de su lenguaje que de cuánto conocimiento del negocio terminó almacenado dentro de ella.
Microsoft no eliminó FoxPro inmediatamente después de comprar Fox Software. Lo desarrolló durante más de una década y posteriormente decidió orientar sus inversiones hacia otras plataformas.
El resultado es uno de los casos más interesantes de legacy software: una herramienta oficialmente terminada cuya vida real quedó determinada por las aplicaciones que sus desarrolladores construyeron.
Y mientras esas aplicaciones continúen resolviendo correctamente procesos que una empresa necesita cada mañana, alguna ventana de Visual FoxPro probablemente seguirá abriéndose en Windows mucho después de que desapareciera el producto que la creó.
Preguntas frecuentes
¿Microsoft compró FoxPro para eliminarlo?
La historia no respalda esa interpretación simplificada. Microsoft compró Fox Software en 1992 y continuó desarrollando FoxPro durante años, incluyendo varias versiones de Visual FoxPro.
¿Cuánto pagó Microsoft por Fox Software?
La prensa de 1992 valoró la adquisición en aproximadamente 173 millones de dólares en acciones. Microsoft anunció oficialmente su intención de fusionarse con Fox Software el 24/03/1992.
¿Cuál fue la última versión de Visual FoxPro?
Visual FoxPro 9 fue la última versión mayor. Microsoft no desarrolló Visual FoxPro 10 y el soporte extendido de la versión 9 terminó en enero de 2015.
¿Por qué siguen existiendo aplicaciones FoxPro?
Porque muchas contienen años o décadas de reglas empresariales, informes, procesos y personalizaciones. Sustituirlas puede requerir reconstruir no solo sus datos, sino también conocimiento operativo que en ocasiones únicamente existe dentro del código.
