Como bien decís, con este lenguaje tengo un cariño tremendo y como a todos, me dió mucha pena que tanta potencia diseñada con tan buen gusto y simplicidad se haya dejado así.
El motivo por el que hice FoxBin2Prg fue la necesidad:
En el equipo de desarrollo veníamos usando por muchos años SourceSafe con el programa que trae VFP (scctext.prg) y del que hubo una versión mejorada en VFPx (scctextX.prg) en el que tuve la suerte de poder colaborar con algunas optimizaciones y de paso interiorizarme un poco de cómo funcionaba.
La necesidad se presentó cuando íbamos a cambiar la herramienta de control de código por Plastic, que luego de un par de presentaciones que nos hicieron me impresionó tanto y tan bien que pensé que si no aprovechábamos esa potencia en el manejo de los merges y nos quedábamos solamente con poder comparar, íbamos a quedarnos demasiado atrás en cuanto a prácticas de manejo de software, y aunque existía otra herramienta que permitía cierta posibilidad muy limitada de merge (TwoFox) trabajaba en formato XML, lo que introducía una nueva complejidad en las ya complejas mezclas de código (merges). Por todo esto, y sacando las mejores ideas de lo que conocía de ambas herramientas, es que me motivó a hacer FoxBin2Prg como proyecto Open Source en mi tiempo libre, sabiendo que hay mucho software por ahí hecho en VFP y que podía ser útil para bastante gente.
Y no me equivoqué: desde el comienzo tuvo muy buena aceptación y el ser Open Source permitió que muchos desarrolladores pudieran colaborar aportando ideas de mejoras, testing y reporte de bugs, lo que fue una experiencia inolvidable y muy buena, también me permitió conocer mejor a varias personas de las que participaron --incluso de este foro :)-- y eso es genial.
Cuando pueda voy a intentar colaborar en otros proyectos Open Source, pero antes tengo que conseguir el nivel técnico requerido en los lenguajes en los que están hechos, lo que requiere mucha práctica. Para eso viene muy bien los cursos gratuitos que se encuentran en edX, Coursera, MiriadaX y varios otros sitios
El futuro lo veo algo complejo, al menos en el mercado de las grandes y medianas empresas (las chicas son harina de otro costal), ya que en general todas las que tienen tecnologías antiguas o sin soporte como VFP y otras --muy importante en esos niveles--, están migrando a tecnologías más actuales, multiplataforma y más versátiles respecto de la posibilidad de conectividad, movilidad, IoT, etc., como Java, Javascript+HTML+CSS y otros lenguajes.
La diversificación de lenguajes disponibles también hace más difícil la elección, ya que en algunos casos se suman otros lenguajes poco conocidos (al menos para mí) o nuevos, como R, GO, Swift y más.
Creo yo que las empresas chicas --dependiendo del mercado en el que se muevan-- que puedan funcionar con software más o menos estándar (facturación, stock, etc, lo típico que hace falta) son las que menos les afecta el cambio tecnológico y tienen más fácil incluso hacer dichos cambios de a poco, sin apuro. Pero en empresas más grandes o multinacionales, las necesidades cambian y en muchos casos las tecnologías están condicionadas a la usada en otros países, donde además el soporte requerido es de un volumen que solo otra empresa dedicada a ello puede ofrecer. Hablo de soporte directamente de Microsoft , RedHat, IBM y ese tipo.
En estos casos, a veces los acuerdos con algunas de esas empresas llevan a incorporar ciertos productos muy potentes y no muy conocidos fuera de ellas, que además son caros, como soluciones de software basadas en HP-Exstream, o IBM Message Queue (MQ) y otros.
Quienes trabajan en alguna de estas empresas además se están encontrando con que los departamentos de software --que en general forman parte de las mismas-- se están externalizando, aprovechando leyes creadas para favorecer esa externalización, y donde en algunos casos la gente es no solo cambiada de empresa, sino también cambiada de provincia o de país.
Este modelo del que hablo, está mejor explicado en estos dos artículos (muy largo el primero):
Quienes estén en los demás segmentos del mercado --con clientes particulares, dando servicio personal, trabajando en nichos específicos, etc, como muchos en este foro-- por suerte difícilmente vayan a pasar por estos nuevos procesos de externalización y deslocalización que están haciendo varias empresas grandes.
Respecto del software, creo
que
--quitando excepciones o nichos específicos-- para poder pensar a largo plazo se debe poder manejar una gama de lenguajes que como mínimo debe incluir Javascript+HTML+CSS, y ya luego depende de cada uno, por ejemplo NodeJS, Python, algunas bases de datos SQL y No-SQL, etc.
Realmente lo importante --para mí-- es al menos conocer algunas tecnologías multiplataforma (porque no alcanza la vida para conocerlas todas), para qué sirven y dónde es mejor utilizarlas, ya que a veces es necesario vincular varias tecnologías, y ayuda mucho conocer algunos estándares y usarlos, sobre todo para la conectividad entre aplicaciones y sistemas, por eso el auge de XML y JSon.
Se nota que es domingo, se me fué un poco de amplitud el tema, pero es que es un tema muy amplio.
Espero que hayan sobrevivido hasta el final :D