Ayudar o no ayudar
Bien es sabido que los amantes del software libre y de la libertad de circulación de la información nos encanta ayudar y compartir nuestros conocimientos con los que recién se incorporan al mundillo de la computación y la telemática. Sin embargo, surgen cuestiones ideológicas fundamentales en este ámbito. No me refiero desde luego al nivel en que debamos prestar ayudar, pues esto queda a la discreción de cada uno, sino a prestar ayuda a aquellos que no apoyan el software libre ni la libertad de información. Desde luego, cada uno es libre de hacer lo que quiera, pero ¿es ideológicamente aceptable esta actitud?
Como todas las cuestiones ideológicas, ésta está sujeta a una opinión e interpretación personal de dichos conceptos. Mi opinión personal es que hay que ayudar a quién lo necesite, independientemente de sus creencias personales, pero que dicha ayuda debe estar encaminada a enseñarle a ayudarse a sí mismo. No vale con decirle "haz esto y esto otro", sino intentar explicarle el funcionamiento que se esconde detrás de esta frase. Si estas personas comienzan a entender parcialmente el funcionamiento interno de los sistemas cerrados que usan, muchos de ellos posiblemente querrán entenderlos más a fondo y se toparán con las limitaciones del sistema cerrado, y seguramente entenderán las ventajas de los sistemas abiertos. Y es que generalmente aquellos que no se sienten interesados por el software libre suele ser por cuestión de ignorancia o falta de interés sobre los aspectos legales (siempre aburridos) de las patentes de software. Este fue mi caso personal, que al ir profundizando en el funcionamiento interno del software, me fui dando cuenta de la injusticia que supone ponerle limitaciones al usuario, y por supuesto de la grandeza humana y moral que esconde el software libre y su filosofía de libre intercambio de información.
Siempre me he quejado del poco carácter científico de la "ingeniería" del software, que más que ingeniería debería llamarse la "economía" del software, porque sus objetivos generalmente están exclusivamente dirigidos hacia el sector empresarial, cuando lo principal de la ingeniería debería ser la eficiencia tanto tecnológica como económica. Desgraciadamente, la llamada ingeniería del software se ocupa muy poco de la eficiencia de la lógica (aunque sí da pautas de cómo preparar un "ambiente" de buena generación lógica) y se centra demasiado en la eficiencia empresarial, lo que le resta rigurosidad científica. Este hecho, unido con el carácter secretivo del software cerrado, hace que la calidad final del software deje mucho que desear y, sobre todo, que se ajuste más a las exigencias del fabricante que a las del usuario, que finalmente será el que use el sistema. Definitivamente poquísima flexibilidad.
El sistema de generación de software anteriormente descrito es lo que Eric S. Raymond denominó la Catedral en su famoso ensayo "La Catedral y el Bazar". Queda claro que el software cuyo funcionamiento interno está escondido a los ojos de los usuarios será opaco y poco flexible, aparte de ser corregido tan sólo por un grupo limitado de personas, lo que implica que muchos errores (bugs) se les escaparán. Sin embargo, el model del Bazar implica que el código siempre esté abierto, incluso durante el desarrollo de las nuevas versiones, dando lugar a la participación de millones de voluntarios que implican un aporte de ideas y una detección de errores muchísimo mayor que la cualquier empresa puede generar. Jamás una empresa privada podrá permitirse tener una plantilla como la Comunidad, y encima generalmente voluntaria. Este hecho es similar al de la comunidad científica internacional, donde lo que prima es el prestigio y el reconomiento de otros colegas que el beneficio capitalista inmediato, ya que el prestigio suele ir asociado al beneficio monetario tarde o temprano.
Todo esto para aclarar que el desarrollo del software con un modelo de código abierto es el que permitirá que la mal denominada ingeniería del software pase realmente a ser esto, una ingeniería, y que permitirá una nueva concepción del software y de los modelos lógicos que lo componen. La experiencia es fundamental en el método científico y desde luego el código abierto ofrece más posibilidades de generar esta experiencia al tener muchísimos más individuos activamente creándola. Cuantos más introudzcamos en la Comunidad, mucho mejor, ya que amenazaremos el modelo obsoleto del software cerrado. Y esto no se consigue manteniendo a los usuarios en la ignorancia. Por algo es el objetivo fundamental del software cerrado. No debe serlo para la Comunidad. Ayudar al prójimo no es tan sólo un mandato cristiano, sino también un deber de la Comunidad. Sólo hay que saber cómo ayudar y esto a veces no es sencillo. Pero con esfuerzo y unidad todo puede consegurise. Y es que "el pueblo unido, jamás será vencido".
Como todas las cuestiones ideológicas, ésta está sujeta a una opinión e interpretación personal de dichos conceptos. Mi opinión personal es que hay que ayudar a quién lo necesite, independientemente de sus creencias personales, pero que dicha ayuda debe estar encaminada a enseñarle a ayudarse a sí mismo. No vale con decirle "haz esto y esto otro", sino intentar explicarle el funcionamiento que se esconde detrás de esta frase. Si estas personas comienzan a entender parcialmente el funcionamiento interno de los sistemas cerrados que usan, muchos de ellos posiblemente querrán entenderlos más a fondo y se toparán con las limitaciones del sistema cerrado, y seguramente entenderán las ventajas de los sistemas abiertos. Y es que generalmente aquellos que no se sienten interesados por el software libre suele ser por cuestión de ignorancia o falta de interés sobre los aspectos legales (siempre aburridos) de las patentes de software. Este fue mi caso personal, que al ir profundizando en el funcionamiento interno del software, me fui dando cuenta de la injusticia que supone ponerle limitaciones al usuario, y por supuesto de la grandeza humana y moral que esconde el software libre y su filosofía de libre intercambio de información.
Siempre me he quejado del poco carácter científico de la "ingeniería" del software, que más que ingeniería debería llamarse la "economía" del software, porque sus objetivos generalmente están exclusivamente dirigidos hacia el sector empresarial, cuando lo principal de la ingeniería debería ser la eficiencia tanto tecnológica como económica. Desgraciadamente, la llamada ingeniería del software se ocupa muy poco de la eficiencia de la lógica (aunque sí da pautas de cómo preparar un "ambiente" de buena generación lógica) y se centra demasiado en la eficiencia empresarial, lo que le resta rigurosidad científica. Este hecho, unido con el carácter secretivo del software cerrado, hace que la calidad final del software deje mucho que desear y, sobre todo, que se ajuste más a las exigencias del fabricante que a las del usuario, que finalmente será el que use el sistema. Definitivamente poquísima flexibilidad.
El sistema de generación de software anteriormente descrito es lo que Eric S. Raymond denominó la Catedral en su famoso ensayo "La Catedral y el Bazar". Queda claro que el software cuyo funcionamiento interno está escondido a los ojos de los usuarios será opaco y poco flexible, aparte de ser corregido tan sólo por un grupo limitado de personas, lo que implica que muchos errores (bugs) se les escaparán. Sin embargo, el model del Bazar implica que el código siempre esté abierto, incluso durante el desarrollo de las nuevas versiones, dando lugar a la participación de millones de voluntarios que implican un aporte de ideas y una detección de errores muchísimo mayor que la cualquier empresa puede generar. Jamás una empresa privada podrá permitirse tener una plantilla como la Comunidad, y encima generalmente voluntaria. Este hecho es similar al de la comunidad científica internacional, donde lo que prima es el prestigio y el reconomiento de otros colegas que el beneficio capitalista inmediato, ya que el prestigio suele ir asociado al beneficio monetario tarde o temprano.
Todo esto para aclarar que el desarrollo del software con un modelo de código abierto es el que permitirá que la mal denominada ingeniería del software pase realmente a ser esto, una ingeniería, y que permitirá una nueva concepción del software y de los modelos lógicos que lo componen. La experiencia es fundamental en el método científico y desde luego el código abierto ofrece más posibilidades de generar esta experiencia al tener muchísimos más individuos activamente creándola. Cuantos más introudzcamos en la Comunidad, mucho mejor, ya que amenazaremos el modelo obsoleto del software cerrado. Y esto no se consigue manteniendo a los usuarios en la ignorancia. Por algo es el objetivo fundamental del software cerrado. No debe serlo para la Comunidad. Ayudar al prójimo no es tan sólo un mandato cristiano, sino también un deber de la Comunidad. Sólo hay que saber cómo ayudar y esto a veces no es sencillo. Pero con esfuerzo y unidad todo puede consegurise. Y es que "el pueblo unido, jamás será vencido".
Comments
Post a Comment
Comment, motherf*cker