¿Pedir consejo / opinión sobre soft libre / opensource a vendedores de soft propietario?

Parece obvio, pero..pedirle consejo / opinión a un vendedor de soft propietario / pago sobre lo buenas / malas que pueden ser las soluciones basadas en software libre / opensource > ¿Qué creen que va a responder?

El negocio IT es un negocio, y los consultores / empresas de soft propietario hacen su negocio, lo que está totalmente bien.

Si Uds. fueran vendedores de soft propietario y en el marco de una posible oportunidad de negocios - vender software - alguien les preguntara por un software que Uds. no venden, que no pueden vender (por acuerdos y lealtad comercial con los fabricantes de soft propietario), del que no pueden vender soporte (razón, idem anterior), que se descarga gratis de Internet, etc... de vuelta  ¿Qué responderían Uds.?

Escribo esto porque hace poco, por enésima vez escuché de al menos un par de IT guys, y al menos dos empresas / organizaciones que les piden consejo sobre la calidad / fiabilidad / utilidad de software opensource / libre a vendedores de software propietario.  y ¿Cuál creen Uds. que pudo haber sido la respuesta?

"El tipo que sabe"
La fundamentación de por qué se pregunta a un vendedor de soft propietario sobre soluciones basadas en soft libre / opensource suele ser "Es un ingeniero / licenciado / tipo con mucha experiencia, trabajó mucho en X e Y especialidades, de mucho nivel técnico", etc. Además de eso, ahora está actuando como vendedor / empleado / socio de su empresa de IT que vende soft propietario. Cuando se le pregunta, se plantea un conflicto de intereses, que éticamente el vendedor / profesional, está habilitado de resolver a favor de su conveniencia comercial.

Así que, más allá de lo buen profesional que sea el vendedor, no se discute la cuestión técnica, sino el interés comercial. El vendedor, la mayoría o en todos los casos en que se le pregunte, va a terminar respondiendo que él - personalmente inclusive - implementaría una solución propietaria.

Conclusión
Como responsables de IT de organizaciones / empresas no solo es una responsabilidad conseguir las mejores respuestas, también hay que saber hacer las preguntas correctas y saber a quien/es preguntar sobre qué temas.

Correcciones, bienvenidas.

Aprendiendo a vender software barato con Elon Musk

Elon Musk 

http://es.wikipedia.org/wiki/Elon_Musk

Bajos precios, mucha venta.

[ Con bajos precios, para estas explicaciones, hay una implicación lógica de que el costo debe ser más bajo que el precio. No es como el caso de los "descuentos para ganar" que se suele hacer para intentar ganar en ventas (perdiendo plata, pero manteniendo a raya a la competencia) ]

Estaba leyendo sobre la industria aeroespacial y me dí cuenta que la situación de "optimizar-ventas-por-menores-costos-a-similar-provisión-de-calidad" es muy similar a la que encontramos en IT en el nordeste (NEA). No, no estoy hablando de outsourcing, sino de vender software en el NEA, solamente.

La cuestión del costo del software es tan prevalente, que las grandes empresas con software para vender (y sus distribuidores), hacen esfuerzos continuos denodados para mostrar que sus productos son "inherentemente" superiores, mejores, más avanzados, etc. que cualquier otro equivalente en la práctica, pero que es más barato.

Un caso de software barato compitiendo mano a mano lo conocemos en el software libre / opensource. Donde por un lado tenemos ofertas de costos (TCO real medido a mediano y largo plazo, no solo el costo de la licencia inicial para usarlo), de miles de doláres, versus soft libre de TCO real (a mediano/largo plazo en gral.), mucho más bajo.

Es el caso del soft de virtualización. Que tiene un alto costo de licenciamiento y ofrecen de base las mismas prestaciones que los productos de soft libre, solo diferenciandose en prestaciones poco utilizadas, que son - para la mayoría de los escenarios - fácilmente reemplazables.

Otro ejemplo actual y comercial - NO es soft libre - son los - creados por terceros - pequeños productos de gestión de nube e infraestructura virtual. Capaces de brindar capacidades de administración y gestión de infraestructuras virtuales, en gral. con capacidades muy por encima de lo que brindan las empresas/proyectos que crearon la plataforma (Vmware, Microsoft, Citrix, RedHat, etc.). Esas empresas compiten brindando muchas mejores capacidades - que lo mejor que se le puede comprar al creador de la plataforma - a mucho menor precio. 

Redundo, mucho menos precio, muchas más prestaciones.

http://www.toolsjournal.com/tools-world/item/183-15-of-best-cloud-management-tools

* Obviamente, las ofertas para comprarles la empresa (de los grandes productores de software), les llueven a estos muchachos. No las venden porque hacen mucha más plata por año que lo que ofrecen. Plus, para muchos no es solamente un negocio, es SU negocio, laburan ahí, la pasan bien, trasteando y desarrollando tecnología de punta (plus, el tema económico ya lo tienen solucionado luego de un par de millones).

Todo lo anterior está basado en unas ideas que tuve al leer una entrevista a Elon Musk.

La entrevista

Vamos al artículo de Elon Musk, en este caso vemos un ejemplo de competencia apoyandose en las debilidades coyunturales, y dado que los demás factores están prácticamente congelados, se compite principalmente en el precio.

* En la venta de software básicamente es lo mismo, los clientes típicos no evaluan realmente el TCO, o no quieren hacerlo, o no les importa, simplemente quieren pagar el menor precio posible hoy - ya - y obtener el software que necesitan para trabajar. Lo que deja los ganadores del lado del precio más bajo (siempre que ello pueda proveer con total certeza la prestación que se busca en el software).

Ejemplos: licitaciones públicas

El artículo:

"Elon Musk’s Mission to Mars"

http://www.wired.com/wiredscience/2012/10/ff-elon-musk-qa/

comienza así:

"Cuando un hombre te cuenta de la vez que estuvo planeando una huerta en Marte, te preocupás por su estado de salud mental. Pero si el mismo hombre ya ha hecho despegar varios cohetes que son de hecho capaces de llegar a Marte, al estilo Bond, desde una pequeña isla en el Pacífico, te hace falta encontrar otro diagnóstico.

"Todos los emprendedores tienen una aptitud para el riesgo, pero más importante que eso es su capacidad de auto-engañarse. De hecho, investigaciones sobre psicología encontraron que los emprendedores no son más tolerantes al riesgo que los no-emprendedores. Solamente tienen una habilidad extraordinaria para creer en sus propias visiones, tanto que piensan aquello en lo que se están embarcando no es en realidad tan riesgoso. Están equivocados por supuesto, pero sin la habilidad de estar tan equivocados, de propia voluntad ignorar a todos los pesimistas y a toda la evidencia al contrario de su visión, nadie podría poseer la audacia necesaria para empezar algo radicalmente nuevo."

La visión de Elon Musk para replantear la industria espacial se encontró con varios obstáculos, y a la vez varias potenciales ventajas. Ambas dadas y muy limitadas, no por las posibilidades y potencialidades máximas de la tecnología espacial disponible, sino por la coyuntura de esa industria, por el conjunto de condiciones sociales, económicas, culturales y organizacionales dentro de la industria espacial a nivel mundial.

Básicamente los cohetes y usarlos cuestan demasiado caro, la tecnología en uso en 2012 es la misma que la de los años 60'.

Entonces, traduzco una parte de la entrevista:

Nota: 

* http://en.wikipedia.org/wiki/Catch-22_(logic) quiere decir "..cuando solucionar un problema, crea otro"

...

Musk: Correcto, así que pensé, deberíamos ser capaces de construir un cohete mucho más barato dados esos costos de materiales. Deberían estar pasando cosas bastante tontas en el mercado..y estaban pasando!

Entrevistador: ¿Como qué?

Musk: Una es la increíble aversión al riesto dentro de las empresas aeroespaciales. Incluso con la mejor tecnología disponible, siguen usando componentes legacy, muchos de los cuales fueron desarrollados en los años 60'

Entrevistador: He escuchado que la actitud es esencialmente que no puedes hacer volar un componente que ya no haya volado antes.

Musk: Exacto, lo cual es obviamente un catch-22, correcto? Tendría que haber un chiste de Groucho Marx sobre eso. Así que sí, hay una tremenda tendencia contra el tomar riesgos. Todos están tratando de optimizar su cobertura de trasero(original: Everyone is trying to optimize their ass-covering.)

Entrevistador: Esa es una buena frase.

Musk: Los resultados son bastante locos. Uno de nuestros competidores, Orbital Sciences, tiene un contrato para reabastecer la Estación Espacial Internacional, y sus cohetes honestamente "suenan" como el remate de un chiste. Usan un motor de cohete ruso, que fue hecho en los años 60'. No digo que su diseño es de los 60', quiero decir que el motor literalmente fue fabricado en los años 60' y por ende, estuvo empacado en algun lugar de Siberia.

...

Entrevistador: Suena como que la propuesta de valor no es tener mejor rendimiento que la competencia, sino en cambio, competir en precio.

Musk: Mirá, la velocidad de un cohete siempre va a ser básicamente la misma. La conveniencia y confort va a ser la misma. La fiabilidad tiene que ser al menos tan buena como lo que se haya hecho antes, de otro modo la gente no va a usar tus cohetes para lanzar sus satélites de costo multi-millonario, pero, en todo eso no hay muchas mejoras que hacer. Así que realmente te queda solamente el parámetro clave contra el cual las mejoras tecnológicas deben ser juzgadas, y eso es el costo.

# --- Esto que sigue es un consejo sobre RR.HH. de Elon, gratis con la entrevista ---

Entrevistador: Así, como lo hacés? Cual es tu proceso?

Musk: Te tengo que decir algo ahora, y lo digo en el mejor y más inofensivo posible de los sentidos: No creo en el proceso. De hecho, cuando entrevisto a un potencial empleado y el o ella dice "Todo es acerca del proceso" lo veo como una mala señal.

Entrevistador: Oh no, estoy despedido.

Musk: El problema es que en muchas de las grandes empresas, los procesos se vuelven un substituto del pensar. Te alientan a que te comportes como una pequeña pieza en una máquina compleja. Francamente, eso te permite emplear mucha gente que no es muy inteligente, que no es muy creativa.

# --- Fin del consejo ---

Conclusión

Esto es tarea para la materia gris del lector.

¿Por qué se usa Linux - cada vez más - en organizaciones?

Más allá de las discusiones por sí o por no en el uso de software opensource, su uso se expande constantemente en las organizaciones.

IT Infrastructure Lifecycle

Básicamente, una organización tiene ciclos, en algun momento las previsiones de presupuesto se van al piso, no hay plata, ni un mango, ni un duro, etc. 

Es decir, la gente - de IT primero y luego los gerentes/dueños de la organización - se dan cuenta que con la plata que tienen prevista gastar en updates/upgrades de infraestructura (software Y hardware, que se hace cada 5 años más o menos), no les va a alcanzar para renovar las licencias de productos que ya son legacy (3-5 años en uso), y que van a necesitar actualizar a nuevas versiones para poder seguir usandolos en producción (y poder recibir updates de seguridad, lo que es muy crítico en plataformas Windows. / y poder recibir updates/hotfixes de performance/funcionalidad que es muy crítico en unix típicamente). 

Jump Point

Entonces arrancan con pruebas piloto para implementar servers Linux "donde se pueda", que termina siendo - más o menos - en correo, proxys, file-sharing, websites, monitoreo, etc. Al tiempo de ya tener armado un test-team Linux de gente con cierto training+expertise ya se animan a más.

Al par de años la organización tiene sus unix "acorralados" en aplicaciones legacy o de misión crítica que corren sobre hardware dedicado (SPARC, Itanium, etc.), y los Windows igual, corriendo apps "legacy" y sosteniendose en infraestructura vía AD (Active Directory), desktop (para las PCs), Exchange subsiste por su integración fuerte con Outlook (de hecho al implementar AD, casi todos implementan Exchange), Sharepoint para gestión documental, SQL server como backend de todo en background.

Expansión

Sin embargo, es un viaje de ida, los Linux comerciales soportan ciclos largos, lifecycles de una década o más, y se puede migrar en cualquier momento a otra distribución, si tenemos el personal adecuado..

Aunque hablamos de admins aquí, nadie con skillsets menor a SSr. - 2 a 3 años de experiencia de campo - siquiera va a soñar con hacer(se responsable directo - pasible de sanciones - de) migraciones de distribuciones, ni de win2003 a win2008 en otra plataforma.

En el momento en que la organización tiene deployados varios Linux comerciales, inmediatamente empiezan a planear el siguiente salto, migrando apps internas comerciales a equivalentes que soporten correr bajo Linux. Inclusive más, debido al largo tiempo de lifecycle y baja carga de horas de proyecto en migraciones - cada 4 años en Windows Platform típicamente y pagando la consiguiente licencia por el upgrade - productos caros - carísimos - como Oracle por ej. se vuelven viables de adquirir dentro del - nuevo - TCO optimizado.

El motivo

Recordemos que a una organización además del presupuesto le interesa que todo funcione, y una plataforma que le pide migrar sus sistemas de misión crítica cada 4 años (para estar "al día"), no es precisamente lo mejor en muchos escenarios. Ese es un pivot de venta tremendo para Linux.

Igualmente la cuestión de fondo, en el 99.99% de las migraciones a Linux NO es "Linux es más barato que X", sino "si usamos Linux tenemos más plata libre para gastar en otra cosa", y típicamente la gastan en hardware.

Como sabemos, Linux puede costar más caro de implementar al principio, pero, luego de pasar todo por el tamiz del TCO a largo plazo, el salto se hace igual (el TCO mejora usando Linux vs. que no mejora no usandolo).

No usamos Linux acá

El "derecho a protesto" y el "Linux no es para nosotros" dura lo que dura la plata, si la organización tiene presupuesto ilimitado y lo tienen todos los años, van a pagar lo que les cueste su plataforma de preferencia, aunque sea cara y eleve el TCO. Sino, para todo el resto de los casos, usarán lo que usen, mientras tengan plata para pagarlo, luego van a tener que "apretarse" a otras disponibilidades presupuestarias.

En mi experiencia personal, les puedo decir que el "jump point" que mencioné, el tema presupuesto, va haciendo que lentamente muchas organizaciones por todo el mundo vayan migrando a Linux, cada vez más. Otras plataformas ocupan nichos específicos de mercado, que a medida que van apareciendo apps, se vuelven menos sostenibles.

Un ejemplo para "desktop" de "menos sostenible" es la constante adopción del browser como plataforma base de sistemas de misión crítica en las organizaciones, con ello ya no se depende del sistema operativo subyacente. 

Otro ejemplo, para "server", es la adopción masiva de Java para software enterprise, que suelo ver a menudo como una "precaución", que le permite a la organización saltar de sistema operativo transparentemente, sin preocuparse de lo que corra bajo el Java Application Server, http://en.wikipedia.org/wiki/Application_server

Contracara

La contracara de la falta de presupuesto es la expansión de infrastructura, cuando una organización pasa de 10 servers a 50, y de compartir carpetas a comprar gestión documental y sistemas enteprise (SAP, etc.), y disponen de un presupuesto importante para hacerlo, en gral. aquí los vendors y resellers de todo tipo convergen y la solución adoptada - en soft - termina siendo una basada en software propietario (y que, realmente les suele ofrecer un TCO mejor que usar opensource, pero acotado en el plazo de los siguientes 5 años). Volvemos al principio, en 5 años, vuelven al principio, meten la mano en el bolsillo, ven qué hay y lo piensan de vuelta por sí o por no para continuar por ese camino.

Conclusiones

Es decir, desde la visión del mercado global de software de infraestructura (que abarca sistemas operativos, aplicaciones + hardware y ultimamente clouds privadas), 

- como mínimo, podemos decir que el soft opensource en gral. y Linux en particular, va muy bien y en crecimiento constante; 

- como máximo, podemos decir que casi todo el mundo "con cabeza", va planeando su salida de otras plataformas hacia Linux, a mediano o largo plazo como máximo.

En 10 años veremos que sale, estas nociones que conté son una "foto" de la situación actual, no una profecía de "Linux en todo", de acá en más hay que hacer números y ver para donde apunta la veleta en el hoy.

Razones por las cuales el estado debe usar software libre

Hay mucha tela para cortar, tal vez se vea esto en el Congreso, puedo traerles - cortesía de horas de lectura de foros y correos durante años - un breve (en realidad no es tan breve :-), resumen de las fundamentaciones que se vieron durante años de discusiones previas a buscar la sanción de una ley de software libre para el estado.


Intereses
Desde la primera vez que leí sobre ideas para proponer una ley de software libre, años atrás, creo que en comentarios o posteos en Solar y un par de asociaciones pro software libre, lo primero que pensé fue:


"el lobby de software propietario y la coyuntura social-política deben ser tremendas, por eso buscan la salida de la obligatoriedad"


Es decir, los grupos de interés que pugnan por impulsar el uso de soft propietario por intereses particulares, lo hacen en gral. aún a sabiendas de que usar soft propietario no es la mejor solución para el estado en algunos (muchos probablemente), casos, igualmente le tuercen el brazo a la situación.


Vendors de software libre
Los vendors de software libre normalmente son inexistentes, generalmente no hay un reseller local (en Corrientes por ejemplo), que brinde soporte para Postgresql (instalación, configuración, mantenimiento, packaging garantizado para la distribución en producción en la organización por X cantidad de años, no más de 24 hs. de tiempo de espera para disponer de paquetes actualizados de la suscripción, etc. etc.); casi lo mismo se puede decir de MySQL, Apache, Squid, Samba, etc.


El soporte de soft libre en AR en gral. está en pañales, por ejemplo pocos se comprometen a hacer un seguimiento día a día del desarrollo de un paquete de software (Postgresql por ejemplo), e ir preparándose para por ejemplo, backportear y mantener código de la última versión en desarrollo que arregla una regresión que ralentiza el uso normal de la DB en 15% (que no suele ser taaan difícil tampoco). Obviamente, un backport de código no oficial se debería proveer con un procedimiento de regreso ordenado a la versión estándar, por si ocurriera algun incidente, exactamente igual a lo que se hace con los parches y fixes "out of band" - no oficialmente liberados por el vendor, que proveen muchos vendors comerciales cuando se pide soporte).


Lo que está disponible en cambio, son suscripciones a distribuciones industrial-level, RHEL y SLES (las únicas comerciales que tienen real "llegada" en la industria IT), y a veces, a veces, alguna empresa - perdida en la multitud en Cap.Fed. - compra algun paquete de soporte de Ubuntu Server (directamente a Canonical, vía Internet y tarjeta de crédito).


Es decir, el soft libre no tiene quien pelee el lobby propietario hoy, siquiera con una presentación aburrida de 10 minutos, desmintiendo, corrigiendo tergiversaciones y medias verdades presentadas como hechos veraces, cosa ocurren, todo el tiempo, obviamente, y desde las "mejores fuentes" - el artículo es un ejemplo - muy a pesar de los intereses del cliente puntual (para el que podría o no ser lo mejor usar soft propietario), y para su desmedro económico (TCO, etc.).


Hagamos una ley y listo
Así que veo que lo quedó fue impulsar directamente una ley de software, con obligatoriedad incluída, lo que no es justamente una garantía de tener un mejor TCO.


Sí es muy probable IMHO, que si se fuerza a las empresas proveedoras del estado a crear una industria local proveedora de software libre, los revenues, las ganancias, muy probablemente sean mucho mayores que los "cuts" que sacan por revender licencias de soft propietario.


Hay sí una realidad tecnológica, muy presente para los que estamos metidos hasta los huesos en el opensource: cualquier solución comercial puede ser completamente reeemplazada por una solución opensource igualmente viable desde lo tecnologico. No, realmente no hay un "límite", CUALQUIER software propietario puede ser reemplazado por un software opensource;


Límites
Sí es verdad que hay casos en que el software opensource no va a brindar de inmediato similares topes de características: por ejemplo, mientras X OS Server propietario soportaba 50 TB de memoria máxima ya en su versión 2003 (y en ese año también), X OS Enterprise Server Linux, soportaba un tope de 16 TB de memoria máxima.


Hay otros ejemplos de topes de características, pero en todos los casos, va a llegar un punto en que se va a tener que considerar los beneficios devenidos de considerar el TCO. Donde un software tiene un costo de licenciamiento 1 millón de pesos en un ciclo de vida de 10 años totales, es probable que la organización debiera considerar contratar un experto o entrenarlo inclusive, para administrar un software opensource con similares características, pero de costo de licencia cero.


TCO
En ese punto hay que considerar muchísimos costos asociados, pero se tiene un (1) millon de pesos de límite para ver qué es lo que sale más barato al final. Luego de considerar usar el software opensource por 10 años, si ya se tiene un experto o dos, o un team, la siguiente iteración del TCO sería ahorrarse otro millón de pesos en costo de licenciamiento en los próximos 10 años.


Es bastante remoto que contratar y entrenar desde cero hasta nivel experto a un especialista le cueste a una organización un (1) millón de pesos, o inclusive a dos, o a tres (consideremos que no se contrata a los mejores, sino Jr. que se entrenan). Hay un gasto inicial grande, en la implementación, este gasto es el que suele igualar o superar inclusive a lo que costaría implementar software opensource (sí, es así), por lo que un TCO real podría implicar que incluso no pagando costos de licencias, aún así se superara el millón de pesos en los primeros 10 años.


Pero luego llega el siguiente ciclo de 10 años, y aquí es donde se podrá ver los beneficios y el ahorro a largo plazo que muchísimos expertos y casos de uso alrededor del mundo ya vieron.


Qué dirían si les digo que hay ejemplos que en vez de tener 2 ciclos de 10 años tienen dos ciclos 1 o 2 años, luego de los cuales ya van a empezar a ver cuantiosos ahorros ($$$), sería algo interesante para probar verdad?


Pero...hablamos de plata solamente, TCO?


El TCO no es el único argumento
No, de todos modos, el TCO no es la preocupación principal del estado, no importa (de vuelta, no importa), si el software opensource es más caro, mucho más caro o muchísimo más caro. En los fundamentos de las distintas ideas para proponer una ley de software, el costo - gratuito, ahorro a largo plazo - no es ni siquiera un argumento de importancia secundaria para impulsar la ley, al contrario, siempre lo presentan como un "costo importante", un inconveniente inicial, necesario, y temporal para la implementación de la idea detrás de la ley.


Un par de fundamentos de la ley
Los dos fundamentos más importantes de las distintas ideas de leyes de software fueron:


- Que el estado utilice soft libre por todos los beneficios no económicos que acarrea. Un mínimo, muy escaso ejemplo, es que se puede garantizar mayormente la ausencia de backdoors en los softwares que manejan información crítica (digamos, dentro de un datacenter del ejército con 700 TB críticos y secretos mayormente), si tienen dudas de que eso sea necesario, solamente busquen información sobre Stuxnet, Duqu y Flame y fijénse cuales son - exactamente - los pivots de ataque.


- Que el estado promueva la creación de un ecosistema de producción industrial de software, no hablamos de la industria actual - masiva, nacional - de provisión de refactoría de software, sino de la creación de verdaderos productos de software. Por ejemplo, donde 3 empresas tienen que proponer la mejor solución opensource para un website de un ministerio provincial, una empresa puede ofrecer un LAMP estándar basado en Ubuntu, otra puede ofrecer Nginx, una empresa va a ofrecer un cluster web hiperescalable vía - digamos - GlusterFS, otra va a ofrecer algo menos escalable, pero más barato, etc. etc.


Una licitación de ejemplo
En una licitación legalmente llevada, el máximo nivel de provisión de servicios por el mínimo precio queda fijado al momento de la presentación de ofertas, así que el "yo también te puedo ofrecer GlusterFS" debería quedar limitado a opcionales, y acá llegamos al quid de la cuestion..


...como el software que las 3 empresas del ejemplo pueden ofrecer es básicamente el mismo, y asimismo se da con el máximo nivel de prestaciones que puedan proveer en el software, el factor diferenciador va a estar dado por el soporte que las empresas le puedan dar al software.


Si tenés una empresa con 10 empleados y ganás una licitación por 10 años con un costo anual de 1 millón de pesos de soporte para el software (opensource), contrato de un estado provincial, con pago - garantizado por contrato - anual, vas a poder contratar tranquilamente un experto, inclusive, podrías tener un helpdesk durante cierto tiempo (un mínimo de dos años y ello detallado por escrito en la oferta presentada en la licitación), y luego el experto - ya pasada la tormenta de helpdesk inicial + implementación inicial - se podría hacer cargo de las calls de soporte.


Es decir, la ley de software libre básicamente serviría para promover la replicación del modelo de venta y soporte de software que hoy se realiza vía software propietario, pero dejando todos los beneficios económicos y no económicos puertas adentro del país.




Faceta económica y no económica
Por el lado económico, es fácil, habrá menores costos a futuro, pero en principio el costo mucho mayor de implementaciones opensource va a beneficiar - tremendamente - a los pioneros que se "metan" en el asunto, permitiendoles crear - con ese cash masivo inicial - infraestructura empresarial (sedes, empleados, training, expertise, productos, etc.). El mercado debería hacer lo suyo y bajar los precios en unos años, para ese entonces, ya habría una vasta base de empresas bien afianzadas (algun oligopolio tal vez?), etc. etc.


Por el lado no económico, hoy esas empresas (y el oligopolio), no existen, no hay industria fuerte de producción de software, no hay helpdesk atendiendo 5 clientes por tickets de Postgresql, etc. No hay laburos. El expertise se vende acá y se cobra afuera (y la plata sale del país), los expertos en el expertise propietario - inocentemente en gral. - promueven el uso de software que impulsa la salida de inversiones y beneficios fuera del país, por ejemplo, cuando 200 empresas de AR compran licencias de X DB propietaria, tal vez, el vendor extranjero sume 2 helpdesk a tiempo completo, que cobran (y gastan) sus sueldos fuera del país.


etc.


Es largo de discutir como ven pero básicamente en principio se muestra el gran issue de que el costo lo correrían las empresas pero, de vuelta, no es tan así, y el costo no es el único ni el más importante factor a considerar para el caso de venta de software al estado. Más allá de que el alto costo inicial de implementar software libre en el estado también haya sido considerado, y de hecho sea uno de los principales pivotes de apoyo a la ley.


Si al final de toda la discusión macro y micro económica se aprueba la ley y no funciona (los costos no bajan, no hay oferente alguno en alguna licitación, etc.), un par de amparos bien fundamentados van a dar por traste la aplicación de la ley (licitación por licitación, pcia. por pcia.), y eventualmente darían lugar a una - merecidad y justa - derogación.


Las ventajas potenciales luego de sancionada la ley
La idea de fondo es que el mercado va a hacer bien su trabajo y los empresarios ávidos de ganancias van a saltar al vagón de hacer cuantiosas cantidades de dinero básandose en ventajas como las de:


- Que el estado use soft libre obligatoriamente (se puede "esquivar" por vía legal si no hay oferentes), lo que se constituye en la disponibilidad de un - nuevo - mercado, garantizado y casi libre de competencia (quien vende soporte de soft libre en AR hoy? y lo hace para 700 clientes? puede dar soporte en 10 pcias.? etc.)
- Que el soft a vender sea libre y de costo de licencia cero (el vendor local se queda con todo lo que cobra)
- Que el código fuente se pueda modificar y crear productos de software nacional - opensource y aptos para vender al estado - de alta calidad, competitivos y con bajo costo de producción (gracias a reutilizar código fuente), con potencial de venta a nivel internacional (no nos olvidemos que existe Internet).
- Los primeros que salten al "vagón" del soft libre para el estado, se van a llevar los precios premium ($$$), altísimos y pagados obligatoriamente por el estado, se van a constituir en la base de la industria, con un mercado garantizado (revenue stream garantizado), y con el potencial de vender también su producto/servicio localmente con la tremenda ventaja competitiva de cobrar costos en pesos y disponer de una infraestructura local importante (visitas onsite de un ingeniero, trabajar con un laboratorio local para resolver un issue vía escribir código vs. abrir un ticket en un sitio de un vendor internacional y esperar - lo mejor - y que "aparezca" el hotfix.


...Ni hablar de que la competencia agregada al mercado interno local va a disparar - tal vez luego de un par de años- action paths de negocios de vendors internacionales que probablemente terminen abriendo subsidiarias y múltiples sedes en el interior (para competir con la oferta de soporte onsite), y/o incrementando los beneficios para los resellers locales (para que no se les "vuelen" puntos de venta), trayendo más empleos y mejorando muchísimo la provisión de software propietario a nivel local.


Conclusiones
Para finalizar, obviamente la ley de software libre no la están impulsando solamente un par de "loquitos de linux", sino que hay fuertes intereses económicos nacionales preparándose para llenarse de plata al minuto - las empresas se hacen para eso justamente, no es ningun "pecado" - que se sancione la ley (quien sabe cuantos abogados ya tendrán preparándose para dentro de unos meses presentarse en 5 pcias. diferentes en todo tipo de licitaciones).


Para ser más claro aún, el lobby a favor del software propietario (razonablemente), busca "dibujar" una situación de "empresas IT argentinas" vs. "loquitos de linux", cuando en realidad hay suficientes empresas IT nacionales respaldando con mayor o menor publicidad la ley de software libre. La fortaleza de la argumentación a favor no es un accidente ni mis dotes de escriba desplegadas, simplemente estoy reescribiendo los argumentos tuneados durante años vía discusiones y vía más de 4 o 5 revisiones de abogados/estudios caros pagados con dinero de empresas IT de AR.


La idea de fondo es más o menos la misma que la que se usó - exitosamente - para promover el ensamble de notebooks en el territorio (vs. importarlas a todas), con la consiguiente aparición de buenos $$$ de ganancia para empresarios, un par de miles de empleos (que antes no existían), y el consiguiente par de miles de sueldos que se termina - felizmente - gastando en ropa, comida, cosméticos, juguetes, medicamentos, etc.


Me tenté de usar esta frase, es grosa pero me parece apropiada para el tema tratado, así que con todo respeto > El que quiera ver, que vea.


Bueno, ahora me voy a dormir, y espero poder ver la discusión en el congreso, ciertamente estaría buenísimo escuchar la argumentación de cualquiera que le encuentre un punto flaco a la argumentación general pro-software-libre-en-el-estado y diga por qué no sería bueno una ley de software libre.