Cuando digo que conozco un sistema de misión crítica, que soporta uno de los sitios con mayor tráfico en latinoamérica, que tranza mucho dinero, y que está soportado con Windows y SQL Server 2008, mucha gente, que se jura experta en tecnología, me mira extrañado. Claro, se supone que Microsoft produce puras porquerías que no sirven para nada, y nadie pone sistemas de misión crítica corriendo sobre Windows. Claro que esa es la mitad de la historia, porque ese mismo sitio tiene, como front end, un application server java, opensource, corriendo sobre RedHat Linux, y con Apache como plataforma base. Ahí la cara de sorpresa es mayor. Hay otros, más “expertos”, que se extrañan porque todo eso que describo no esté corriendo sobre un stack Oracle.
¿Cómo es posible que exista ese engendro, y que además funcione tan bien? Muy simple, porque hay gente que es pragmática, que no se enfrasca en discusiones cansinas sobre si es mejor el software libre, o el opensource, o los sistemas operativos “privativos” (con todas las connotaciones incorrectas, y mal intencionadas de esa palabra).
El software es como la música, sólo hay de dos clases, buena y mala. No me gusta el regguetón, pero hay reguetón bueno, así como hay rock clásico muy malo. Lo mismo con el software. Hay software opensource (o libre) muy malo, y software propietario (¡ya ok!), digo privativo, ¡muy bueno!
En software lo que importa es que, primero funcione, que sea robusto, y que de pocos dolores de cabeza. La licencia? la licencia es para tener tranquilo a los dementores auditores. Mucho gerente TI viejo te dirá que lo que importa es que haya alguien que responda, si es una compañía opensource, o más tradicional, no es relevante, lo que importa son las garantías que tienes cuando las cosas fallan. Tener un contrato de soporte, que asegura que una empresa seria te va a responder cuando las cosas se pongan feas, hace que los gerentes TI puedan dormir tranquilos. Antes se decía que a nadie despedían por contratar a IBM, u Oracle. Ahora hay más alternativas en el mundo opensource, a nadie despiden por contratar soporte con RedHat.
Después de todo, sin los miles de millones de dolares que se invierte en opensource, y sin el sueldo de 6 dígitos que cobra Linus Torvalds, no tendríamos los excelentes productos opensource como los que que hay ahora.
Las empresas requieren un seguro, el core de los departamentos TI, no es participar en comunidades de desarrollo de productos open source, esos desarrolladores están para dar soluciones, y mantener operando los servicios de sus empresas. Muy pocas corporaciones, pueden darse el lujo de que alguno de sus desarrolladores dedique horas a participar de un proyecto opensource, aunque tengan las capacidades. Simplemente no hay tiempo. Es más eficiente levantar el teléfono de soporte, o abrir un ticket, para que un ingeniero en alguna parte del mundo resuelva el problema.
¿Y el acceso al código fuente?
La verdad, ¿de qué sirve el código si probablemente no tienes las capacidades para corregir el bug?, o si las tienes, probablemente no cuentes con el tiempo para hacerlo, sobretodo con productos de plataforma, como los sistemas operativos, o los motores de base de datos, que son monstruos de millones de lineas de código, que requieren capacidades de programación superiores. Además, ¿para qué? ¡si estás contratado para otra cosa!
El código fuente es un seguro, nada más, también puedes contratar una póliza en la compañía que más te de confianza.
Lo importante es la gobernabilidad del software, eso es lo valioso.
[...] This post was mentioned on Twitter by Eduardo Díaz, Luis Fuentes Cerda. Luis Fuentes Cerda said: RT @lnds No es el código, estúpido! http://goo.gl/fb/qt2OF #lnds // Totalmente de acuerdo. [...]
Totalmente de acuerdo… la calidad del software no tiene relación con su modalidad de origen. Decir que porque es Microsoft o Opensource es malo, es ridículo. Si nadie usara MS para software de misión crítica, MS no tendría necesidad de proveer este tipe de soporte (http://tinyurl.com/34sog4b).
este articulo es una mezcla bien rara de conceptos… si dices que da lo mismo tener acceso al codigo entonces basicamente estas diciendo que aca deberiamos solo ser consumidores de tecnologia ya que “de que sirve el codigo si no tienes capacidades para corregir el bug”? descartas por completo la posibilidad que desde aca pudieramos tomar el ultimo kernel de Linux, integrarlo con algun dispositivo y luego venderlo al resto del mundo…
Ricardo, no entiendo de donde sacas esa conclusión.
1.. Si no tienes la capacidad para modificar y entender el código, no te sirve tener el acceso al código. Debes contratar a un tercero para que lo haga.
2. Por otro lado, si tienes la capacidad y el tiempo, puedes hacer lo que quieras con el código, puedes crear tu propio emprendimiento, crear una distro de linux, o crear tus propios productos basados en JBoss, o lo que quieras, pero eso no se discute en este artículo.
3. Si estás en el mundo corporativo, que es el escenario del que habla este artículo, no tiene sentido tener acceso al código, da lo mismo, porque en un ambiente corporativo estás para hacer otras cosas, no para mantener un proyecto de software libre, para eso tienes proveedores, que resuelven eso.
Así que no se donde está la mezcla de conceptos, y no entiendo de donde sacas que sólo tenemos que ser consumidores de tecnología, no veo como llegar a esa derivada, no creo estar tan loco.
Por ejemplo, la aplicación que describo al principio fue desarrollada integramente por desarrolladores chilenos, y mucha gente desarrolla buenos productos basado en opensource, o en código propietario, da lo mismo, lo importante es el código que tú puedes administrar como desarrollador, y que el producto base tenga buen soporte. Si es open source, no es relevante.
Pero no es lo mismo tener soporte de un único proveedor (mercado monopólico) a un muchos potenciales proveedores (libre mercado).
No es lo mismo un ambiente competitivo a uno de cooperación win-win (mercado colaborativo).
Entiendo por su trabajo que usted tenga un enfoque asociados a los satisfactores, pero en el mercado de las necesidades desde el enfoque de sus clientes el software libre es un satisfactor sinérgico de sus necesidades y el software privativo muchas veces es un satisfactor singular y hasta inhibidor.
Saludos
Referencia:
http://www.slideshare.net/jrovegno/community-scrum-manager2
Siempre a sido interesante leer su blog, aunque ahora en adelante evitaré dejarle comentarios.
Ojalá al menos me pueda responder alguna de estas preguntas ¿No se entienden mis comentarios? (Asumo que mi redacción no es de lo mejor) ¿No dan gana de responder? ¿Los encuentra tan offtopic que prefiere ignorarlos?
Saludos
No Javier, al contrario, me gustan tus comentarios. Lo que pasa es que no siempre tengo tiempo para responder todo. Vi recién tu comentario en el post anterior, se filtró entre medio de otros, el problema de contestarte en ese hilo es que se desviarìa mucha la conversación. Por cierto, no estoy de acuerdo con lo que planteas en tu respuesta, pero pienso que tu tienes una visión menos radical que los otros comentaristas de ese thread, así que no quise exacerbar màs los ánimos.
2 cosas, el problema con la connotación de la palabra privativo, que introduce un sesgo cognitivo, y la segunda que la competencia no es mala ni buena, como tampoco el cooperativismo. De hecho, hay que evitar las discusiones bizantinas, y las ideas como el win-win, o cooperar es bueno, competir es malo, porque son nuevamente sesgos cognitivos, y hay que evitarlos.
1. si no tienes acceso al codigo, tampoco podrias contratar a un tercero para que haga modificaciones… si no tienes acceso al codigo solo puedes acudir al proveedor que inevitablemente sera una empresa extranjera, llevandose tu dinero (o del estado) fuera Chile…
2. no basta con tener la capacidad y el tiempo si no tienes demanda, la cual no existiria si se cumple lo del punto anterior…
3. te saldran mas caros los proveedores del software cerrado, ya que ellos primero deben ser “partners” del proveedor original, lo cual no es mas que pagar una cuota anual, costo que finalmente asume el cliente.
llego a la conclusion de que solo tenemos que ser consumidores porque al decir que es irrelevante que el codigo sea open source es lo mismo que decir que es irrelevante que existan mas proveedores locales con las capacidades de arreglar bugs de software mas complejo… se entiende? al no haber demanda tampoco habra oferta, por lo que solo seremos consumidores de software que algun proveedor grande de afuera nos venda… frenando la posibilidad de que algun dia nosotros mismos seamos proveedores de ese tipo de software.
en el ejemplo que usas, seria raro que *no* existieran sistemas de mision critica usando tecnologia Microsoft con la cantidad de recursos que se gastan en esa plataforma…
1. ¿Quién está hablando del estado?
2. Por qué? Que tiene el opensource de bala mágica? no crees que existen empresas chilenas que desarrollan en un modelo en que no entregan el código fuente? hay muchas, y les va muy bien, sin entregar el código fuente de su producto.
3. Por qué dices eso? de hecho no es cierto, hay mucho soporte opensource que es tan o más caro que el producto cerrado, ahí rigen las leyes de mercado. ¿Cual es la base de tus opiniones?
La conclusión que llegas es errónea porque caes en lo que se conoce como “petición de principio” (petitio principii), tu premisa lleva implicita lo que quiere demostrar.
1. de todo lo que puse solo me respondiste acerca de una palabra que puse entre parentesis?
2. la “bala magica” es el codigo, si quiero hacer un motor de base de datos no parto desde cero por ejemplo. y lo puedo “vender” al precio que yo quiera…
3. podria haber soporte open source mas caro que de un producto cerrado, pero si hubiera mas demanda el precio podria bajar… no asi los del soporte cerrado que siempre deberan cobrar lo mismo porque deben ser “partners”.
si mi conclusion es erronea, entonces explicame a que se debe la tendencia a cada vez usar mas software open source en el “mundo corporativo”?
Ricardo, tu argumento no tiene que ver con lo expuesto en el artículo.
El opensource es superior, eso no lo discuto, de hecho te invito a leer esto: http://www.lnds.net/blog/2009/08/cuestion-de-evolucion.html
El tema de este post es otro, tien que ver sobre las garantías que requiere alguien que esté a cargo del desarrollo corporativo, lo que importa es el nivel de servicios que te den los proveedores, si el producto base para tu sistema de misión crítica es open o closed source no importa.
El título me sugiere mucho a KISS (Keep it Simple, Stupid!), y el tenor del artículo también, pero añadiendo “pragmáticamente simple”. Un sano nivel de pragmatismo hace que las cosas funcionen antes fuera del laboratorio, p. ej., en entornos de producción. Aunque las soluciones de compromiso casi siempre tienen una vida menor que una solución más lenta pero correcta.
Respecto al análisis de tener a quién culpar (perdón, recurrir) en caso de falla, hay que agregar algo que a veces se pasa por alto: qué pasa con las futuras versiones. Microsoft tiene un historial de romper su compatibilidad hacia atrás que cuando menos hace levantar las cejas al momento de escogerlo como candidato. Si un sistema de código abierto es ampliamente usado no es necesario que uno sea un gurú ya que es seguro que mucha gente se preocupará de mantenerlo funcionando. En lo personal, tiendo a confíar más en el código abierto para desarrollos de largo plazo (con la excepción de PHP).
Veo que comenzó la guerra santa!!!!
Saludos.
Creo que Alex tiene razón. Pero eso siempre pasa con las mentes religiosas, sólo buscan pelear.
Gracias por su respuesta, en el futuro voy a tratar de no ser tan offtopic, pero por mi esfuerzo de desarrollar un modelo de gestión de bienes alternativo al actual, se me hace muchas veces imposible no cambiar el enfoque de las conversaciones.
En efecto no soy un radical del software libre y ciertamente en los casos que usted plantea una solución no libre es la mejor opción para esos requerimientos, con la información disponible en ese momento específico que se tomó la decisión.
En la actualidad aún el software no libre en muchos casos es una mejor opción, porque la evalución depende de la evolución del mercado (las personas) y hoy en día en muchas áreas los usuarios o los desarrolladores aún no generan un ambiente propicio para el uso de software libre en ambientes de producción.
Eso no quita el hecho y pienso que concuerdo con usted que en muchos casos la opción de desarrollo y uso de software libre genera más beneficios, que el soft. no libre, pero eso será hará evidente en el largo plazo.
Con respecto a la connotación moral (bueno y malo), creo que se mal interpretó, mi argumento es de origen económico y cuando hablo de estrategias justas de mercado tiene relación con criterios económico, pero es verdad el enfoque de la “economía descalza” tiene elementos que no son considerados en la economía tradicional y eso puede llevar a confusión.
Saludo
PD: Igual leyendo mi comentario anterior sonó un poco troll solicitar respuesta a mis comentarios, pero el gusto que tengo por los blogs es la posibilidad de diálogo y a veces tiene un sabor amargo, dedicar tiempo a leer y comentar y no recibir respuesta, aunque entiendo perfectamente lo difícil de hacerse el tiempo para escribir el artículo y aún más para responder los comentarios.
[...] ingenuas, que gastan su tiempo alimentando estas ideas quiméricas de libertad. Pero, además, el código fuente no importa, porque ya no tiene valor, así que da lo mismo que se entregue, regale, reparta, do whatever you [...]