[uylug-varios] K2B en AGESIC

Fernando Da Rosa fedaro at adinet.com.uy
Thu Aug 1 10:00:23 PDT 2013


Recuerdo la IMM de Rocha, cuando asumió el Chueco Barrios, tenían un
programa de gestión realizado en Clipper, del cual no había ni código
fuente ni documentación alguna. Un desastre.

Ahí cayo Daniel Alaniz, que supongo esta en esta lista, a hacerse cargo de
ese problema y sacar adelante el área de informática de la intendencia.

Vaya que me contó anécdotas Daniel, cuando se fue de Montevideo a vivir a
Rocha, y empezó con gran esfuerzo el trabajo de migrar la IMM a software
libre. Entre otras cosas me encajo a mi la responsabilidad de hablar sobre
el tema en unas jornadas realizadas hace años en La Paloma por la ASIAP.
Recuerdo la batalla que tuvimos que dar en esas jornadas.

También hubo experiencias en otras intendencias, y organismos públicos. Una
tarea que nos debemos es realizar una documentación de toda esa historia,
que hoy en día se encuentra muy fragmentada. Principalmente para aquilatar
la experiencia obtenida sobre migración en el Estado.

Otra cosa que se aprende a golpes, es que además de tener software libre,
el mismo debe estar bien documentado.

Saludos
Fernando



El 1 de agosto de 2013 13:32, Eduardo Trápani <etrapani at gmail.com> escribió:

> On 08/01/2013 12:37 PM, Carlos M. Martinez wrote:
> > Estaria bueno demostrar casos donde una aplicación OS efectivamente
> > evita que una institución quede atada, no a un proveedor capaz, pero si
> > a una empresa de soporte/consultoria.
>
> Uno queda atado cuando no puede salir. Si la empresa de
> consultoría/soporte es la única (o una de muy poquitas) que brinda
> soporte sobre un producto, o si esta empresa desarrolla cosas por arriba
> (incluso para solucionar problemas del proveedor), entonces quedar atado
> es muy simple.
>
> Se de alguien que trabajó en Dell como consultoría de software que
> proveía Oracle y vivía haciendo arreglos para evitar bugs en el soft de
> Oracle. Dependiendo de cómo estuvieran documentados, tanto el bug como
> el arreglo en la aplicación, el cliente podía quedar atado de por vida o
> bloqueado en versiones viejas sin posibilidad de mantener. Y uno de esos
> casos era un banco. Y ojalá pudiera entrar en detalles técnicos, algunas
> cosas eran de perogrullo.
>
> La gran ventaja del SL ahí es que, con la cantidad adecuada de esfuerzo
> y plata, uno puede llegar a zafar mucho más fácil. Con software
> privativo y ecosistemas de proveedor/consultoría reducidos, lo más
> probable es que solamente puedas cambiar a algo nuevo, teniendo en
> cuenta esta vez las licencias para ganar libertad. Y otra más, en
> general el formato de datos del SL está documentado o es, por lo menos,
> legible. Y eso hace que tus opciones a la hora de cambiar (que podés
> tener que hacer con SL también) sean mucho más amplias y que la
> información siga siendo tuya.
>
> Ojo, el SL te la posibilidad de hacerlo, con esfuerzo y plata, no quiere
> decir que te lo resuelva automáticamente.  En este mismísimo momento
> estoy viviendo esta situación con una consultora que entregó hace tres
> años un sistema hecho en PHP que usa "register_globals" que ya no
> existen en 5.4. El código está ahí, pero hay que entrarle. Sin embargo,
> además del código, tengo las bases de mysql y eso, ese "todo" que
> conforman el software+datos (donde con el correr del tiempo los datos se
> vuelven más y más importantes) es lo que hay que cuidar. Lo que te da
> una libertad además de las 4, la libertad de migrar o adaptar. Y eso no
> es poca cosa y para un Estado diría que esa libertad es simplemente
> innegociable, aún si se usa software privativo. *Tienen* que incluir la
> opción de hacerse de los datos de manera abierta para poder, por
> ejemplo, implementar funciones nuevas o existentes, con otras
> herramientas. Lo otro ... es estar atado.
>
> Eduardo.
> _______________________________________________
> Uylug-varios mailing list
> Uylug-varios at listas.uylug.org.uy
> http://listas.uylug.org.uy/listinfo.cgi/uylug-varios-uylug.org.uy
>



-- 
Fernando da Rosa
fernando.darosa at gmail.com
http://www.fedaro.info
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listas.uylug.org.uy/pipermail/uylug-varios-uylug.org.uy/attachments/20130801/d33b86c9/attachment-0002.htm>


More information about the Uylug-varios mailing list