Los músicos (los autores o creadores) tienen razón y hacen bien en defender su propiedad intelectual pero la evolución de la sociedad valora unos trabajos y deprecia otros. Un panadero del siglo XXI no gana lo que uno del siglo XIX. Lo mismo ocurre a un herrero, un soldador, un futbolista, etc. La sociedad cambia de criterio a la hora de atribuir mérito o valor a las cosas y lo que hoy genera ingresos, mañana puede estar completamente devaluado. Que se lo cuenten a los oficios que han desaparecido a día de hoy por los avances técnicos de nuestra sociedad. La tecnología tiene sus pros y sus contras. El empleo ni se crea ni se destruye, sólo se transforma. E igual que el esfuerzo y trabajo por elaborar y producir una nueva creación antes era un trabajo más artesanal y laborioso, no es lógico y razonable que se pretenda eternizar el precio cuando todos sabemos que los costes de producción han bajado y la complejidad de las actividades de producción se ha reducido (gracias al software por ejemplo).
Quizás la música vive un problema similar a la agricultura. El que sufre por crear o por plantar es quien tiene el mérito del trabajo y del sudor, pero el modelo productivo establecido hace que el dinero lo acaben ganando los intermediarios. Lo mismo que le ocurre a los agricultores con las distribuidoras y comercializadoras de sus productos les ocurre ahora a los músicos con las operadoras de servicios de telecomunicaciones. Quienes se benefician completamente del tráfico de información son los intermediarios, los que ponen las tuberías por las que circula su propiedad intelectual. Además al principio con cierto descaro usaban la descarga de estos contenidos como atractivo para lograr abonados a sus redes de interconexión.
Sin embargo, al leer su manifiesto me ha venido a la mente el relato de "El conde Lucanor" de Don Juan Manuel.
Había una vez dos hombre que eran muy ricos, pero por determinadas situaciones habían acabado los dos mucho mas pobres de lo que ellos nunca hubieran imaginado, estando uno buscando algo para comer, encontró una bolsa de altramuces empezó a comerlos y sintiéndose tan pobre comiendo esos altramuces tan amargos y tirando las cáscaras hacia atrás... empezó llorar, así dándose cuenta de que detrás de él había otro hombre todavía mas pobre que él porque el otro hombre estaba comiendo las cáscaras que él echaba.
Comprendo su situación pero cada gremio tiene sus problemas y el nuestro de la informática es otro de esos ignorados. Si la música es cultura y genera empleo, ¿qué es la informática para la sociedad de la información?
No me dedico al software aunque siempre me gustó resolver retos y problemas. Cuando estudiaba en la carrera algunos profesores comentaban que eramos los arquitectos del siglo XXI, que seríamos los cimientos de la "supuesta sociedad de la información". Sin embargo y paradójicamente en el máximo momento de desarrollo tecnológico parece que para la informática no cuentan las reglas de la responsabilidad atribuidas a comercializar productos en el mercado, no valen las regulaciones ni las normativas de fabricación, no valen los criterios de calidad ni de certificación de componentes. Es software y parece que no necesita garantías. (Se que esta afirmación no es cierta en todos los entornos, la aeronáutica, la medicina y otras áreas donde el software tiene un papel muy relevante para garantizar la vida de las personas no funciona bajo este paradigma de la no garantía y la no industrialización del software).
Sin embargo, me toca juzgar en mi trabajo la seguridad de la información y no deja de impactarme el ver como lo importante sigue siendo poner servicios o productos en marcha a cualquier precio, de cualquier forma, sea como sea aunque no sea seguro.
La siguiente parte del post utiliza reflexiones que ha volcado también Héctor Montenegro en su blog en contados textos. Creo que él mejor que yo puede hablar con más propiedad de la situación de la industria del software en España. Sus mejores post sobre este tema son:
El software cada vez tiene más importancia en nuestro día a día, cada vez es más responsable del buen funcionamiento de nuestros procesos de negocio, cada día es más relevante para lograr un bienestar en la sociedad de la información. Y en plena transición del papel a lo electrónico, empieza a ser necesario que las casas del software se construyan con planos, que los diagnósticos técnicos se realicen por parte de profesionales acreditados, que si cualquiera puede desarrollar y poner a disposición servicios basados en el software, también responda por ellos si estos han sido desarrollados con negligencia o con defectos en su fabricación. Porque la complejidad va en aumento y esto que estamos construyendo es un castillo de naipes. Cada pieza se apoya en otra y no tener garantías de cómo están los cimientos solo puede producir algo muy malo. Un día una pieza esencial caerá y todas las demás piezas irán detrás.
Por eso es posible hacer un manifiesto paralelo al elaborado por los músicos que también refleja la situación en la que se encuentra el software. Porque en el software también nos estamos acostumbrando al todo gratis y todo libre. Sin embargo, todas las aplicaciones no pueden entrar en este juego. Y además, las Administraciones Públicas están cometiendo un error muy grave cuando confunden "propiedad" con "oscuridad" o "acceso al código fuente" con "calidad del software".
Creo que para comparar el software con justicia no se puede atender únicamente al argumento del coste de licencia. Eso es una mira cortoplacista e ingenua. Me canso de oír en las Administraciones cuando se habla de las suites ofimáticas... hombre, ¡cómo vamos a pagar esa barbaridad por las licencias!
Y mi reflexión interna siempre es... es que vas a pagar una barbaridad más en productividad y rendimiento. No nos engañemos, muchos productos opensource y gratuitos imitan pero no inventan. Su única aspiración es hacer con código abierto lo que hace ya una aplicación comercial optimizada. Y por desgracia para ellos, los resultados no son los mismos. No trabaja igual el que imita que el que crea. El que tiene por objetivo mejorar en rendimiento que el que sólo aspira a tener una funcionalidad similar. Y detrás de todo eso hay un gran coste oculto que nadie mira o quiere mirar.
Claro que es uno de los sintomas que acechan a la productividad de nuestro país. Esta mañana estaba auditando un organismo que trabaja con Office2000. Un software de 10 años (que está plenamente operativo) pero que no incorpora muchas mejoras que hacen que a diario se pierdan varios segundos al día de cientos de funcionarios en hacer tareas que ahora en las nuevas versiones están a golpe de click (¿Es menor ese coste que lo que vale actualizar las licencias?)
El mercado debe juzgar a los productos por su mérito y por su productividad, no sólo por su forma de creación. Opensource no es sinónimo de calidad del software. Lo que es importante es que detrás de cada aplicación haya un responsable. Y aquel que confíe en un producto que le proporciona el acceso al código fuente, que también se haga responsable de lo que en esas líneas está escrito. Si funciona y es competitivo, chapó por el programador que haya decidido regalar su tiempo y aspirar a vivir de los servicios que genere ese producto. Pero si no funciona, que respondan por él aquellas personas que han decidido confiar en un profesional que pudo no estar capacitado para crear un producto con plenas garantías. Si somos valientes para ponerlo en producción y vendemos como garantía que el código se puede leer, seamos también valientes para responder por él. Si confiamos en las líneas de código de vete a saber quien en vete a saber donde, asumamos la responsabilidad que ello supone por tomar esa decisión dentro de nuestra organización. Para eso está la Comunidad, para dejar tranquilos a los responsables que confíen en ella y en su rigor a la hora de encontrar errores en ese código abierto. Y este baremo o criterio de exigencia, por supuesto, que se aplique también a los fabricantes comerciales del software. Todos deben trabajar con la misma profesionalidad y diligencia. Es necesario empezar a pensar en industrializar el proceso del software y dotarlo de los criterios de calidad, regulación y cumplimiento normativo que tiene cualquier otro elemento que forma parte de nuestra sociedad como bien de consumo.
Porque una sociedad del siglo XXI no se puede permitir basar su funcionamiento en elementos sin garantías. Es un contrasentido que tenga más fiabilidad una lavadora, un tostador o un cuchillo de cocina que se ven sometidos a normativas, a controles de calidad y a pruebas de fabricación que un desarrollo software que puede estar soportando servicios básicos de la sociedad del siglo XXI. Y tenemos un handicap en nuestra contra. La complejidad sigue aumentando y la interdependencia entre piezas sin garantías aumenta. Como digo, es un rascacielos construido con cimientos de barro que algún día tendrá problemas.
4 comentarios:
Totalmente de acuerdo en casi todo, Javier, pero déjame contradecirte en una cosa:
Como tú bien dices, confundir "open source" con software de calidad es un error garrafal (y demasiado común en el entorno que nos movemos, que es parecido), pero asumir que un software comercial garantiza algo también es otra falacia (y si no, no hay más que leer los "Disclaimer of Warranty" que hay en la mayoría de software, comercial o no).
Asumiendo eso, no es tampoco extraño que reponsables decidan confiar en el software abierto con la esperanza que de ante un problema puedan al menos "meter mano" al código o a los productos (léase ficheros, bbdd, etc.) generados por el mismo. (Lo cual, en el fondo, es otra falacia por que muy pocas organizaciones tienen recursos suficientes para ponerse a ello).
Al final y bajo mi punto de vista el problema reside en una valoración incorrecta a la hora de decidir una adquisión, que se basa más en criterios políticos, ideológicos o de otra índole en lugar de aspectos más razonables como la productividad que tú comentas. Lo cual lleva a otra pregunta: ¿por qué? (¿ignoracia/incapacidad? ¿presiones externas? ...)
Lo que debe cambiar es esa aberración es que la cláusula de "No responsabilidad". La legislación, para cualquier tipo de productos no permite una redacción del tipo "Este fabricante no se hace responsable de nada". En el software es una lacra que hay que eliminar ya o las cosas seguirán como hasta ahora. Como en el OpenSource uno de buena fe hace lo que considera, el responsable debe ser el que supuestamente bajo un criterio técnico elige el producto por considerarlo solvente. ¿Os imagináis a un arquitecto diciendo cosas como "es que yo pensaba que esta estructura iba a soportar la carga, no necesitaba hacer cálculos, me fiaba de mi intuición".
Estimado Javier, permíteme felicitarte por el blog y agradecerte personalmente tus útiles e interesantes aportaciones. Intervengo para disentir de lo que dices. Intentaré ser breve, pero -citándote- será difícil:
"Y mi reflexión interna siempre es... es que vas a pagar una barbaridad más en productividad y rendimiento. No nos engañemos, muchos productos opensource y gratuitos imitan pero no inventan. Su única aspiración es hacer con código abierto lo que hace ya una aplicación comercial optimizada. Y por desgracia para ellos, los resultados no son los mismos. No trabaja igual el que imita que el que crea. El que tiene por objetivo mejorar en rendimiento que el que sólo aspira a tener una funcionalidad similar. Y detrás de todo eso hay un gran coste oculto que nadie mira o quiere mirar."
Esta afirmación no es generalizable (aunque tú lo haces), ni los argumentos pueden probarse. Hay de todo, aplicaciones que imitan y mejoran, que imitan y no llegan, y finalmente que innovan y son éxitos o bluffs. Sabes que hay ejemplos en software privativo y libre para todos esos casos.
"Claro que es uno de los sintomas que acechan a la productividad de nuestro país. Esta mañana estaba auditando un organismo que trabaja con Office2000. Un software de 10 años (que está plenamente operativo) pero que no incorpora muchas mejoras que hacen que a diario se pierdan varios segundos al día de cientos de funcionarios en hacer tareas que ahora en las nuevas versiones están a golpe de click (¿Es menor ese coste que lo que vale actualizar las licencias?)"
Mi responsabilidad es la de decidir eso mismo por cientos de funcionarios; sobre la migración desde un Office97, por cierto. He hecho pruebas de rendimiento, pilotos, casos de uso, he recopilado datos, de todo y... sorpréndete: lo más eficiente en coste/beneficio que sale es (resumiendo) pasar al 50% al wordpad, al 25% a Office 2007-10 y al restante 25% a OpenOffice.org. No es una opinión, es un resultado cuantificado y lo más objetivo posible en la organización para la que trabajo. Si puede extrapolarse o generalizarse ya es otra cuestión, pero lo que tú das es sólo una opinión, según yo veo, que además mi experiencia me indica que no es un axioma.
"Es necesario empezar a pensar en industrializar el proceso del software y dotarlo de los criterios de calidad, regulación y cumplimiento normativo que tiene cualquier otro elemento que forma parte de nuestra sociedad como bien de consumo."
Pareces obviar (aunque luego lo mencionas) la complejidad del software. En mi opinión y experiencia, desarrollar es una actividad intelectual creativa y como tal, no es industrializable salvo para actuaciones de poco valor (tirar cruds, reports y tal). Si no es industrializable, es difícilmente normalizable. Hablemos de normalizar por ejemplo la composición de música orquestal. Pues bueno, se puede hacer, pero reconoce que podemos matar la creatividad, fuente de la innovación. Pues ahí voy: regularizar según y cómo y para qué, pero así en general, y para todo, no lo compro. Por no hablar ya del negocio de las certificaciones, casi siempre más fines en sí mismos, que medios para el fin de la seguridad o la calidad.
"Es un contrasentido que tenga más fiabilidad una lavadora, un tostador o un cuchillo de cocina que se ven sometidos a normativas, a controles de calidad y a pruebas de fabricación que un desarrollo software que puede estar soportando servicios básicos de la sociedad del siglo XXI."
Es un poco lo de antes, la comparación de una lavadora con -por ejemplo- un sistema de control de mercados bursátiles no es lógica. Es como compararla, en el hardware con el LHC (Gran colisionador de hadrones)...
Ea, un saludo; y Felices Pascuas :)
Respecto a tus dos primeras apreciaciones, son simples opiniones. Es cierto que hay software opensource que aportan cosas nuevas o enfoques diferentes y la generalización siempre es un error. También hay productos que empiezan siendo opensource y cuando ya consiguen una cuota, se transforman en productos comerciales. En seguridad ha pasado ya en más de un caso.
Lo de la productividad tiene que ver con dos factores: lo que el software ofrece y lo que el usuario conoce de eso. Tu planteamiento ante la decisión que debes tomar es el optimo, primero valorar, medir y luego decidir. En el tema de usuarios y la ofimática, es común de los errores es la escasa formación que se proporciona sobre las herramientas cotidianas.
Respecto a la industrialización, me refería más que a la tarea creativa de crear el código, a hacer que todo el proceso pase por unas fases metodológicas de ingeniería del software. Programar puede ser un arte, pero debe ceñirse a cumplir unos requisitos, debe superar ciertas pruebas y debe dejar un código fuente documentado que sea luego mantenible por otros desarrolladores. A eso es a lo que llamo industrializar. Si además, ese producto es verificado y homologado por un tercero, ya estaríamos en idénticas condiciones a las tostadoras o lavadoras. En el fondo, nos da igual cómo el código resuelva el problema, pero que cumpla con unos requisitos técnicos mínimos. Ese es el enfoque que se da con la certificación de seguridad ISO 15408 o Common Criteria de la que escribí varios post.
un saludo y gracias por los comentarios constructivos.
Publicar un comentario