A lo largo de mi carrera como estudiante universitario, y más tarde durante mi etapa como técnico de sistemas, me he encontrado a menudo con el tema de debate preferido por el personal técnico —y no tan técnico— de sistemas: Windows vs. Linux. Será que me estoy haciendo mayor para discutir, o que tengo otras preocupaciones, pero lo cierto es que actualmente no es una cuestión que me preocupe lo más mínimo; si quieren saber mi opinión, cada uno tiene sus ventajas y sus desventajas, y el resto es simple miopía (o ceguera, en los peores casos). De cualquier modo, hay veces que esta discusión muta y se convierte en una igual de estéril pero mucho más relacionada a mi parecer con la seguridad, que es de lo que he venido a hablar aquí: open source vs. closed source. Es decir, código abierto vs. código propietario (que me disculpen los puristas del lenguaje y de las licencias si la traducción de Open Source no es la mejor).
Y como por lo general los que más ruido arman son los defensores del open source, lo que vengo a criticar es que sus ventajas ni son tantas ni tan buenas como sus partidarios quieren hacer creer. Aun diría más: la etiqueta en cuestión no sólo no garantiza absolutamente nada en términos de seguridad y/o funcionalidad, sino que puede inducir a engaño y una falsa sensación de seguridad, sobre todo en aquellas personas más “creyentes” en la causa. Ya verán.
Nuestra historia comienza en el momento que alguien afirma que como el kernel de Linux es open source, pues es “obviamente” mejor que Windows, porque eso nos permite modificar su código y adaptarlo a nuestras necesidades, además de que nos aseguramos de que su código sea revisado y validado por miles de ojos, y por tanto esté libre de errores o vulnerabilidades. Francamente, no sé ustedes, pero yo no conozco muchas personas de las que utilizan Linux a diario que hayan echado nunca un vistazo al código fuente del S.O. con intención de hacer algo productivo, entre los que me incluyo; a todo lo que llegué fue a la soberana idiotez de compilar todo el sistema como se puede/podía hacer con Gentoo, pero ello sin mirar ni una puñetera línea de código (que por otra parte, hubiesen dejado en evidencia mis limitados conocimientos de C). En general, cualquier vistazo a los fuentes del kernel es motivado por problemas de compilación, que nunca son problema del código sino de una configuración errónea, conclusión a la que llega uno tras decidir que ya ha perdido bastante el tiempo. Resumiendo, que el código fuente del kernel de Linux está ahí, pero aparte de unos cuantos privilegiados, nadie le mete mano por su complejidad. Y a pesar de esos miles de ojos, periódicamente se publican vulnerabilidades del kernel que se supone que el hecho de que sea código abierto nos garantiza que no deberían estar ahí.
Este último aspecto es algo que me llama mucho la atención del código abierto. Dejando atrás el kernel, hay programas cuyos fuentes son públicos, y protocolos universalmente conocidos que un buen día, después de años sin mayores problemas, resulta que algún genio en estado de gracia demuestra que son vulnerables, si Marte se sitúa en el cuarto cuadrante de Sagitario y en ese momento tienes hambre. Así, sin más. ¿Cómo es que nadie se había dado cuenta hasta entonces? ¿Pero no había miles de ojos? Protocolos abiertos, conocidos, muchas veces implementados, estudiados y revisados… ¿cómo es posible que este tipo de cosas sigan pasando, año tras año? Lo más interesante de todo es: si hubiesen sido código propietario, ¿cuánto tiempo habríamos tardado en descubrir esa vulnerabilidad? ¿Más, o menos?
Hace ya cierto tiempo, fui a parar al caso de g-archiver. La utilidad de este software, que hasta hace un tiempo podían comprar/descargar desde su web aunque era totalmente desaconsejable, es/era facilitar la realización de copias de respaldo del contenido de una cuenta de Gmail. Por fortuna, Dustin Brooks descubrió que su autor, John Terry, no sólo había cometido la estupidez de hardcodear en el código el usuario y la clave de una cuenta de Gmail, sino que además enviaba a dicha cuenta de correo el usuario y contraseña de cualquier usuario que utilizase el programa. Es cierto que esto parece un argumento en toda regla a favor del código abierto, pero lo cierto es que al menos 1700 usuarios confiaron en el programa antes de que Dustin descubriese este problema, lo cual me hace pensar que la etiqueta open source no supone en realidad ningún tipo de garantía sino que además puede llevar a pensar a los defensores del código abierto que el programa está libre de malas prácticas o vulnerabilidades graves.
Es cierto que si dicho programa hubiese sido código propietario, el problema hubiese sido probablemente descubierto mucho más tarde. Claro que eso demuestra simplemente la poca sensatez del personal, y es una lección más de que no hay que confiar en cualquier programa que encuentre uno en Internet, independientemente de si el código está disponible o no. Me atrevo a afirmar que si el tal John hubiese sido un mejor desarrollador (asumiendo que el descuido fue malintencionado y no un trozo de código utilizado para testear que desafortunadamente acabó en la versión de producción), habría sido capaz de ocultar su usuario, su clave y el envío de las credenciales de los usuarios con técnicas de ofuscación, de modo que nadie se hubiese percatado de sus intenciones al revisar el código, más que con un análisis muy exhaustivo… cosa que no es demasiado habitual.
Seguramente saben lo que es el Javascript. La mayor parte de las páginas utilizan algo de javascript, y se utiliza prácticamente para todo (y cada vez más). Además, como es código que tiene que ser interpretado por el navegador del cliente, tiene que ir en claro; si quieres ocultar algo, mejor utiliza flash (o eso creo; francamente, de tecnologías web no sé más que lo justo). Eso parece apuntar a que cualquier desarrollo que hagamos puede ser “robado” por otros desarrolladores. Nada más lejos de la realidad; existen programas para comprimir y ofuscar el código, que lo hacen virtualmente ininteligible para cualquier persona, incluyendo a su autor. Por tanto, el hecho de que dispongamos del código de dichos desarrollos no supone ni una ventaja ni una desventaja; unas veces es una necesidad de tamaño (tamaño del código) y otras una necesidad de protección (propiedad del código).
Podría parecer, llegado este punto, que defiendo que el código propietario es más seguro que el código abierto. Pues tampoco. La muestra son no sólo las frecuentes vulnerabilidades del software propietario como el de Microsoft, Adobe y otros, sino la velocidad a la que dichas vulnerabilidades se descubren cuando alguien está realmente interesado en encontrarlas (véase cualquier código relacionado con DRM). Por tanto, la verdad es que por lo general da exactamente lo mismo; no se fíen ni de uno, ni de otro. Con lo cual llegamos a lo que les comentaba al principio: que la conversación es tan estéril como el del huevo y la gallina, y tampoco sirve para dar conversación a la vecina del sexto en el ascensor. Es más, seguro que te mira raro y piensa que eres un friki; mejor utiliza la previsión del tiempo.
Acabo. Si recuerdan, el principio denominado “Seguridad por oscuridad” (Security thru obscurity) consiste en ocultar los detalles de diseño e implementación —entre otros— de un programa o dispositivo, consiguiendo que el producto actúe como una caja negra y por tanto sus potenciales puntos débiles no puedan ser descubiertos. En principio, eso se considera una mala política, porque además de que la exposición pública incrementa la posibilidad de que sus vulnerabilidades sean descubiertas (algo que como hemos visto no exactamente cierto), siempre hay alguien que acaba descubriendo sus vulnerabilidades, explotándolas, y entonces es cuando decimos que una vulnerabilidad esta siendo explotada “in the wild”. Lo cierto es que eso pasa con código abierto y con código propietario, a pesar de lo que puedan pensar; las vulnerabilidades están ahí hasta que alguien las descubre públicamente, y mientras tanto, quién sabe.
El problema no es, en realidad, código abierto frente a código cerrado. El problema son empresas responsables frente a empresas irresponsables. No me hagan dar nombres, que me entra la risa.
Nada más. Tengan cuidado ahí fuera y pasen un buen fin de semana.
Me ha encantado, y en general estoy de acuerdo con la máxima no hay verdades absolutas.
Sólo discrepo, en el antepenúltimo párrafo, el que habla de la “Seguridad por oscuridad”. No creo que sea la mejor estrategia, ya que a la larga toda “caja” sea negra o transparente (siguiendo con el símil) se rompe. En ese caso la caja transparente tiene más ventajas. Por eso la considero una solución mejor.
De acuerdo con tu post, mis respetos, una excelente balance para tu redaccion, en especial porque revisaste detalles como g-archiver.
Saludos!
Estoy de acuerdo en que, la mayor parte de las veces, los debates entre ambos modelos de desarrollo (propietario y libre) son baldíos. Pero el enfoque que has adoptado en esta entrada la acerca a esa misma banalidad que pretendes criticar.
Es de destacar que, a lo largo del escrito, dejas clara tu falta de conocimiento de lenguajes de programación, lo que te honra y, además, nos sitúa en perspectiva: si no sabes programar, si no eres programador, es decir, siendo un usuario con conocimientos técnicos (supongo), ¿cómo es que puedes valorar el poder disponer del código fuente o no?
Porque es esa, precisamente, la diferencia entre un modelo de desarrollo y otro.
Yo, como programador, puedo ver que determinada aplicación o rutina no funcionan como se espera. Incluso puedo, en la mayoría de las ocasiones, dar con la solución. Siendo así, me cuesta muy poco enviar la corrección a la lista de recogida de errores, colocar el parche en mi empresa, pasárselo a mis amigos, conocidos, etc. Es algo que puedo hacer cuando tengo el código fuente y puedo modificarlo. Pero es algo imposible de realizar cuando no se dispone del mismo. Y esa es la gran diferencia entre un modelo de desarrollo y otro.
El resto son debates que no llevan a ningún lado, algo a lo que contribuye esta entrada que, además, mezcla el concepto de código abierto o libre con el de código ofuscado o cifrado: ¿dónde lo has visto? ¿alguna aplicación “Open Source” lo tiene? ¿cuál?
Y, para terminar, comentar que el disponer del código fuente y del privilegio de modificarlo no es ninguna vacuna que evite que éste tenga problemas (de seguridad u otros) sino que es la única forma de que, ante uno de esos problemas, la solución sea la más acertada (no la que se le ocurra a la empresa propietaria del código fuente) y rápida (basta con echar un vistazo comparativo a las correcciones de código libre y a las que realizan las empresas).
mariorg, el hecho de ser o no programador no implica que no pueda expresar una opinión fundada en relación con la disposición de código fuente o no en aspectos relacionados con la seguridad. De hecho, creo que es más bien irrelevante.
Es natural que disponer del código fuente te permita realizar modificaciones que en software propietario no es posible realizar. Sin embargo, la mayor parte de esas modificaciones están relacionadas con aspectos funcionales y no de seguridad, y apostaría a que sólo un porcentaje muy pequeño de los usuarios de las aplicaciones (por lo general, únicamente aquellos implicados en su desarrollo) realizan algún tipo de modificación sobre el código fuente que utilizan; no me dirás que revisas el código fuente de los programas que utilizas cuando alguno de ellos muestra un comportamiento extraño, ¿no?
Por otro lado, has confundido la referencia que hago a la ofuscación de código. No estoy diciendo que existan proyectos open source ofuscados, sino que el hecho de que un código esté a disposición del público no implica que esté libre de fallos de seguridad o malas prácticas intencionadas, debido a que existe la posibilidad de que dicho código haya sido ofuscado a propósito. Así que como ves, mezclar no mezclo nada. Simplemente advierto sobre la falsa sensación de seguridad que en ocasiones proporciona el código abierto.
Estoy de acuerdo en que el código abierto no es garantía de inmunidad frente a problemas de seguridad y/o funcionalidad, pero no en que la respuesta de los desarrolladores del código libre sea siempre la más acertada ni la más rápida.
Por un lado, no han sido pocas las ocasiones en las se ha demostrado días más tarde que un parche generado por un usuario en un proyecto open source no resuelve totalmente el problema, o que introduce otros, mientras que en el otro extremo, muchas empresas propietarias de código (que francamente, hay unas cuantas, y no sólo las grandes multinacionales) aplican y desarrollan parches sin mayores problemas. En la parte de la velocidad, quedarse en una comparativa de velocidad en la generación de parches entre Firefox y Microsoft reduce significativamente el campo de visión, ya que deja fuera muchas empresas desarrolladoras de software que responden rápidamente a las vulnerabilidades, y también muchos proyectos/productos de open source que son apenas mantenidos y cuyos parches no llegan en 24h.
En definitiva, no estoy a favor del codigo propietario, ni en contra del código abierto. Por supuesto que tiene sus ventajas, que son muchas, pero no tantas ni tan buenas en ocasiones como se quiere hacer creer. Dicho de otra forma, no es oro todo lo que reluce.
Lezer, confieso que no soy un fan del principio de Seguridad por oscuridad, y de hecho creo que no suele ser la mejor opción (ten en cuenta que la serie GOTO tiene en cierto modo una intención de hacer de abogado del diablo, aunque eso no signifique que los argumentos no tengan porqué no ser razonados).
Sería no obstante interesante estudiar, utilizando tu comparación, cuánto tarda en romperse una y otra, entendiendo como tal el descubrimiento de sus vulnerabilidades, independientemente de que sean hechas públicas o no.
Hola, Manuel: muchas gracias por responder.
Me parece que en ningún momento he dicho que no puedas opinar, seas o no programador. Lo que he intentado explicar es que la óptica desde la que ve una aplicación un usuario y la de un programador es distinta. Y que hablar del código, de sus errores y de sus correcciones, no siendo programador, queda a desmano.
Yo, como usuario de un conocido sistema operativo propietario, cuando el propio sistema o alguna de sus aplicaciones se comporta de manera errática (por decir algo), no puedo ni acercarme a las posibles causas. Así, no siendo posible estudiar el código fuente y mucho menos modificarlo, resulta imposible corregirlo: para hacerlo hay que esperar a que la empresa, propietaria del código fuente, libere un parche (binario, claro está); y, como sabemos, lo hará cuanto la venga bien, independientemente de la gravedad del error.
Por otra parte, como usuario de sistemas operativos y aplicaciones libres, no estudio el código fuente de las que utilizo ni de cada función del ‘kernel’. Sin embargo, cuando una de esas aplicaciones falla o lo hace el propio sistema, sí me gusta echar un vistazo al código fuente y, si veo el problema, corregirlo, probarlo y, si da resultado, publicarlo para ayudar a otros.
Me parece que ya he comentado antes que soy programador; no lo soy de ninguna aplicación libre sino propietaria (trabajo para terceros) y, por tanto, no estoy pendiente de los errores que aparezcan en ellas. Pero, en el software libre, al disponer del código fuente y de la posibilidad de modificarlo, se me proporciona la capacidad de corregirlo, mejorarlo y/o adaptarlo a mis necesidades o a las de otros.
En lo que respecta al código ofuscado que comentas, no me cabe duda de que existe ese código. Pero no suele estar en el “Open Source” (lo sé de buena tinta: hay más ofuscación en el código propietario). La ventaja (otra más) es que un usuario con cierto conocimiento del lenguaje puede ver ese código e incluso desentrañarlo: ¿se puede hacer lo mismo con un binario cerrado? ¿es una “leyenda urbana” la existencia de “puertas traseras” en el software privado? ¿cómo se puede introducir y mantener una “puerta trasera” en el “Open Source” cuando hay cientos o miles de ojos que pueden ver el código?
En cuanto a aquel que tenga alguna sensación de seguridad ante el código abierto se equivoca. Sin más. Confundir el acceso al código fuente con que éste esté exento de errores o fallos de seguridad es un error, probablemente motivado por desconocimiento.
Tienes razón en que el hecho de disponer del código fuente y de que puedan sacarse “parches” rápidamente (oficiales o no) puede dar lugar a que esos parches produzcan, como efecto colateral, errores más grandes (u otros) que los que pretendía solucionar.
Pero eso no es inherente al “Open Source” sino que cualquier cambio en el código (propietario o no) puede provocar más daños que soluciones: depende de lo afortunado que haya estado el equipo de desarrollo y, sobretodo, de su conocimiento y experiencia (por poner un ejemplo tonto: suelen ser más graves los fallos en Ubuntu que en Debian, estando ambos muy cercanos y la razón es más que evidente; dicho sea con todos mis respetos para con los programadores de Ubuntu).
En ese sentido, tanto en el software libre como en el software propietario hemos asistido al típico “parche sobre el parche anterior” debido, precisamente, a algún efecto colateral del primer parche.
En mi experiencia, suele ser más rápida la reacción en el software libre que en el propietario ante un problema de seguridad, especialmente si éste es grave. Pero eso no implica absolutamente nada excepto, quizá, que hay más gente trabajando en el software libre que en una empresa dedicada al software y que, por tanto, se dispone de más tiempo.
Por eso, no intentaba hacer comparativa alguna sobre la rapidez entre diversos modelos de negocio a la hora de corregir problemas. Lo que sí tengo claro es que, si dispongo del código fuente y puedo modificarlo, independientemente de que se saque o no un parche oficial, la solución la puedo tener en menos de 24 horas. Y no me es posible dar ninguna solución ante (la ausencia de) el código propietario, ni en 24 horas ni en un mes.
Pienso que si se van a comparar las ventajas del modelo “Open Source” frente a la del código propietario hay que valorar, en primer lugar y como punto de partida, el hecho de que en uno de esos modelos de negocio el usuario (sea o no programador) está a merced de lo que decida la empresa, propietaria del código. El otro modelo no tiene esa restricción.
Sigo las entradas de este sitio desde hace muchos meses y, hasta ahora, no había comentado nada, especialmente por mi falta de conocimiento sobre la mayor parte de los temas que tratáis y que me resultan altamente interesantes. Si he intervenido hoy es porque, según mi opinión, se ha argumentado en falso (el “software libre” no es sinónimo de seguridad sino de libertad), y se ha dado la perspectiva, no desde la óptica del programador (lo que parece un contrasentido, tratándose de código fuente), sino del usuario con pocos o nulos conocimientos de programación que, lógicamente, no se va a poner a leer el código fuente y mucho menos a modificarlo.
mariorg, vaya por delante que independientemente de que discrepemos en diversos puntos, agradezco que te hayas decidido a participar, y espero que lo sigas haciendo en el futuro. Dicho esto, vayamos por partes.
En relación con la posibilidad de echar un vistazo al código fuente, indudablemente tenerlo ahí para revisarlo cuando se produce un error es una ventaja, pero sigo manteniendo que excepto si es una aplicación que usas de manera intensiva o a la que estás estrechamente vinculado, mirar el código no es una opción, en cuanto éste adquiere cierta magnitud. Es decir, sí, existe la potencialidad, pero no es una ventaja real. No creo, francamente, que muchos desarrolladores miren habitualmente el código fuente del Firefox, por mucho que éste consuma a veces recursos de manera preocupante, ni creo que estén al tanto de las últimas modificaciones o parches de seguridad.
Respecto a lo que comentas de ofuscación de código y puertas traseras, sí, no me queda otro remedio que admitir que el código abierto es al menos en teoría menos propenso a ese tipo de malas prácticas. No obstante, el hecho de ser código propietario tampoco implica que, por lo general, tengamos que admitir que existen puertas traseras o funcionamientos malintencionados. No son pocas las aplicaciones que a partir de ingeniería inversa, o a través del análisis de tráfico “sospechoso”, se ha demostrado que no son nada limpias. Pero sí, las puertas traseras son más susceptibles de aparecer en el código propietario que en el abierto, y las leyendas urbanas siempre estarán ahí.
Respecto a la rapidez y corrección de los parches, creo que la discusión está tomando como base grandes grupos multinacionales de software (Microsoft, Adobe, Oracle, etc.) y grandes proyectos open source (Firefox, Linux, KDE/Gnome, etc.), que tanto unos como otros requieren prácticamente un trabajo a tiempo completo. Dejando de lado esos casos extremos, sería interesante analizar la comparación de otros proyectos open source de mucha menor relevancia y difusión, cuyos autores no disponen de demasiado tiempo para el mantenimiento de la aplicación, frente a pequeñas y medianas empresas de desarrollo de software.
La libertad. Por supuesto, el hecho de tener el código fuente te da una mayor libertad para corregir errores, pero no deja de ser una libertad ficticia, porque en muchos casos, y más si nos vamos a programación de aplicaciones de sistemas o comunicaciones, el programador tiene que conocer muy bien el código de la aplicación para poder arreglar algo, y al final no le queda otra que esperar a que los desarrolladores de dicha aplicación saquen una nueva versión… exactamente igual que con código propietario. Sendmail es un servidor de correo que tradicionalmente ha sido famoso no sólo por lo críptico de sus ficheros de configuración, sino también por los frecuentes problemas de seguridad que presentaba. Cuando salía un 0-day, ¿a alguien se le ocurría, sin conocer el código, meterle mano? Por supuesto que no. Lo que se hacía era esperar a la salida de un parche oficial, que podía tardar más o menos dependiendo de la disponibilidad de sus desarrolladores y la complejidad del código. Por lo tanto, daba igual que el código estuviese ahí o no, porque la opción no era otra que esperar al parche del autor.
Lo que quiero decir es que al final, esa libertad que comentas es más ficticia que otra cosa. La modificación de cualquier aplicación de unas cuantas miles de líneas, a no ser que el autor haya sido excepcionalmente cuidadoso comentándola y documentándola, sigue siendo poco factible en un periodo razonable de tiempo para cualquier persona que no esté realmente involucrada en el desarrollo, con lo que la solución de errores queda sujeta, como en el caso del software propietario, a la generación del parche por parte del autor, sea éste una empresa o una persona/grupo de personas. Por supuesto, cuanto más desarrolladores tenga un proyecto, antes habrá un parche, pero seguimos dependiendo de los autores.
No creo que la diferencia entre los dos modelos radique en que en uno el usuario está a merced de lo que decide la empresa propietaria y en otro no. En realidad, en ambos casos el usuario corriente y moliente está a merced de lo que decide el autor de la aplicación o sistema, sea una persona, una empresa, software propietario o libre. Las nuevas funcionalidades de Linux no son algo que se decida de manera arbitraria o por votación democrática; Linus y algunas personas más deciden, y al que no le guste, pues que se busque otro SO. Más de una persona ha abandonado el desarrollo de Linux por las imposiciones algo dictatoriales de su creador. Por supuesto, uno siempre tiene la libertad de hacer un “fork” de Linux, GIMP, Firefox o cualquier otro software, si no le gusta lo que ve y lo que se decide, pero eso es sólo una ilusión tranquilizante en la mayor parte de los casos porque hacer algo así lleva tiempo y recursos.
Por otro lado, me dices que eres programador. No obstante, igual que no es lo mismo la administración de Oracle, que la de PostgreSQL, que la de MySQL, no es lo mismo una librería gráfica de GIMP, que un módulo de gestión de memoria del kernel de Linux, que una aplicación de cálculo científico, que la implementación de SSL en Firefox. Lo que quiero decir es que ser programador no es, al final de la corrida, el argumento o el hecho que garantiza la existencia de esa pretendida libertad. Para ser libre de hacer algo hay que ser capaz de hacerlo, y aparte de que la inmensa mayoría de los desarrolladores no son capaces, por recursos, capacidad o dedicación, de “trastear” con software libre de cierta magnitud, cada uno está, como lo estamos todos, limitados por nuestro ámbito de aplicación profesional. Tampoco hay que olvidar que aunque uno pueda estar familiarizado con C, eso no le da automáticamente la capacidad de entender modificar el código de Linux.
Ya he dicho que no soy programador. Desde que acabé la carrera, todo lo que he programado han sido shell scripts, perl y alguna cosilla en C, y poco más si la memoria no me falla. El hecho de hablar sobre open source como usuario sería totalmente absurdo, y en efecto un contrasentido, si me pusiese a divagar sobre las bondades de éste o aquel paradigma o modelo de programación. No obstante, hacerlo desde la altura que yo lo he hecho no es tal contrasentido, sino una opinión que francamente, no creo que vaya nada desencaminada.
Hola.
Contesto, de nuevo, a Manuel, al que agradezco su tiempo.
Yo, en mis respuestas anteriores, me he referido a tu entrada y, en concreto, al punto de vista adoptado que, como decía, es el de un usuario.
Me resulta chocante que se pueda hablar sobre las ventajas y desventajas del software desde ese punto de vista cuando, en el fondo, de lo que se trata es de tener la posibilidad o no de acceder al código fuente. Y si éste no se entiende (porque no se es programador o porque no se tienen los conocimientos necesarios para ello o no se dispone de tiempo), es lógico que se llegue a la conclusión de que da la mismo uno u otro modelo. O que incluso es mejor el modelo propietario (no digo que lo sugieras sino que puede llegarse a esa conclusión si se tiene en cuenta al “departamento de calidad” de la empresa en cuestión).
Desde el punto de vista del usuario se está, siempre, a merced de los programadores que realicen, amplíen, corrijan, adapten o modifiquen la aplicación. Pero esto no es extraño ya que pasa en cualquier campo profesional: estaremos a merced del albañil cuando tengamos que hacer reformas en casa; o del mecánico, cuando del coche se trate.
Si embargo, en el software libre el usuario tiene varias posibilidades que no existen en el software propietario (y que, dicho sea de paso, se obvian en la entrada):
a) Si el usuario de software libre es un “usuario normal” (un usuario con pocos o nulos conocimientos de programación o que no desea dedicar su tiempo a corregir los problemas que surjan), el empleo que va a hacer del software es el mismo que el que tendría con el software propietario. Esperará a que, oficialmente, se corrijan los problemas y se apliquen las correcciones (probablemente, de manera automática). Así que, por ahí (punto de vista de tu entrada, Manuel) no parece haber ventaja alguna entre un modelo de desarrollo y otro (sí las hay, pero tratarlas sería entrar en matices que distraerían el tema).
b) Si el usuario de software libre dispone de tiempo y conocimientos es posible que pueda corregir los problemas que surjan con aplicaciones que utilice. Esto, como decía, no es posible realizarlo con software propietario porque, sencillamente, no se dispone del código fuente. Y es posible que, aún cuando exista esa posibilidad, no se haga con software libre. Pero basta con darse una vuelta por las páginas de recogida de errores en el software libre para comprobar que, efectivamente, se envían parches. Luego, alguien lo ha corregido, para su uso y, posteriormente, ha enviado la corrección a la lista, de donde cualquiera con conocimientos puede recoger el parche y aplicarlo (yo lo he hecho en más de una ocasión: aplicar los parches antes de que salgan oficialmente).
c) Si el usuario de software libre no tiene conocimientos o tiempo para corregir los fallos en el software existe la posibilidad de contratar los servicios de programadores independientes o empresas que se dediquen a corregir, ampliar y/o adaptar el software. También es algo que no puede hacerse con software propietario y también es algo que se da en en la realidad, esto es, no es una utopía (como ejemplo: yo, antes de estar en la empresa actual, de software propietario, adaptaba aplicaciones de software libre o hacía las mías, apoyándome en ellas y, en ocasiones, ampliándolas).
Entre esos tres puntos de vista, sólo el (a) pone en la misma o similar posición a ambos modelos de negocio, libre y propietario. He omitido, deliberadamente, la posibilidad que apuntas de realizar un ‘fork’ (que tampoco se puede dar en el software propietario) porque considero que está incluido en el punto (c).
Ciertamente tienes razón al afirmar que, en general, nadie va a meter mano en un software que no conozca, especialmente si éste no es trivial: miles o millones de líneas de código, varias bibliotecas, etc.
Dices: “No creo que la diferencia entre los dos modelos radique en que en uno el usuario está a merced de lo que decide la empresa propietaria y en otro no.”. Pues, desde mi punto de vista, esa es la diferencia fundamental. Y, además, no es una utopía porque yo lo he hecho: realizaba modificaciones al código fuente según solicitaba la empresa que me había contratado, no según los parches, correcciones y ampliaciones oficiales.
Podría decirse que mi trabajo actual es algo similar a eso. Dispongo del código fuente (no libre, como digo), que no he escrito, y que consiste en unos millones de líneas de nada que, cada dos por tres, he de modificar porque, cuando no aparece un problema por un lado, lo hace por el otro, lo que dice muy poco de su calidad: cosas del software propietario y de su forma de desarrollo.
Y es que, si una empresa me paga para hacer modificaciones, ampliaciones o adaptaciones de un determinado software, siempre que tenga acceso al código fuente (sea libre o sea propio de la empresa), acabaré conociendo esas miles o millones de líneas (en serio: lo digo con conocimiento de causa). Una vez domine la estructura del código me costará bien poco hacer cualquier cambio, corrección o adaptación del mismo: esa es la ventaja principal de disponer del código fuente… para un programador.
Chapó Manuel!
Alguna puntualización adicional: que un sistema operativo sea open source considero que no aporta una ventaja real por tener acceso al código, qué empresa tiene una necesidad real de adaptar el sistema operativo? open source “podría” aportar ventajas en el caso de aplicaciones especificas como pueda ser un software de gestión pero en ese sentido el software propietario también es permisivo como ejemplos tenemos Sap, Navision o incluso algunos mas pequeños como Nexus y un sinfín de aplicaciones que están poniendo las pilas para que el cliente pueda tocar código y adaptar la aplicación a sus necesidades. En cualquier caso, coincido contigo, es muy importante la empresa que hay detrás.