Jummp’s Blog

No hace falta dar muchas vueltas para apreciar las consecuencias nefastas que provocaría estar sometidos a un entorno basado en patentes software. Si todas las ideas en el mundo del software fueran patentables, la innovación sufriría un tremendo varapalo, ya que gran parte de las empresas y grupos de desarrollo de software tendrían que hacer frente a un pago a los distintos propietarios de patentes para poder realizar su labor habitual. Independientemente del acuerdo al que se llegue habría que sumar a los costes normales de producción de software un importante complemento que se llevarían los propietarios de patentes. Esto sería tremendo en el mundo de las PYMES dedicadas al desarrollo de software que no podrían soportar esos costes y terminarían siendo extinguidas (la otra posibilidad es que ese sobrecoste terminase en el cliente, que tampoco podría soportarlo al menos en la misma proporción, es decir, los propietarios de patentes siempre se llevarían su parte, pero los desarrolladores de software verían mermado considerablemente su margen de maniobra).

Ante este panorama, ¿quién podría subsistir? Pues las empresas con suficiente nivel de negocio para poder afrontar el pago de multitud de patentes, las empresas que tengan un número de patentes que permita hacer un intercambio con las otras propietarias de patentes (ya sea un intercambio a pelo o por lo menos un intercambio que permita reducir el coste de uso de patentes) y las propias empresas de desarrollo de software propietarias de muchas patentes. Es decir, el mercado de proveedores se reduciría considerablemente, reduciendo el nivel de competencia, provocando un mayor nivel de cautividad en los proveedores y reduciendo el nivel de innovación, ya que cada paso que se de en este aspecto es como andar sobre arenas movedizas, ya que son tantas las patentes que existirían y algunas de ellas con una interpretación tan ambigua que difícilmente se sabría si en todo el proceso innovador se está utilizando una idea ya patentada o no. También dificulta el proceso innovador la existencia de empresas que son meras cobradoras, es decir, propietarias de patentes que lo único que tienen es un equipo de abogados y técnicos dispuestos a descubrir dónde se está utilizando una patente de su propiedad sin haber obtenido un ingreso a cambio. En resumidas cuentas, pura especulación, la innovación ya no consistiría en mejorar los productos software existentes o crear otros nuevos sino que se basaría en la búsqueda de nuevos métodos para sacar dinero a los demás.

Ni que decir tiene de las nefastas repercusiones que tendría sobre el software libre, ya que éste también se vería afectado por las patentes y al verse afectado por ellas el software sería menos libre, el problema no sería principalmente de dinero (que también) sino de libertad, las patentes sobre software restringen esa posibilidad de elegir, esa posibilidad de poder modificar el software con el fin que se considere pertinente.

Las patentes software (por su número (miles y miles) y sus características (en muchos casos conceptos difícilmente concretables) crean además una gran inseguridad jurídica, ya que para tener la seguridad de no incurrir en la utilización de una estrategia ya patentada habría que conocer todas las patentes (algo que es tremendamente complicado, por no decir imposible) y además saber interpretarlas correctamente (casi más difícil si cabe que lo anterior), por lo que al final cuando se desarrolla se tiene que ser consciente de que pasado mañana puede llegar la corporación X indicándote que has infringido las patentes Y y Z y que prepares la cartera. Cierto que si hay dudas puedes ir a juicio, pero ya sabemos qué equipo cuenta con mejores abogados, ¿verdad?.

Esta inseguridad jurídica sería una losa muy importante sobre las empresas dedicadas al desarrollo de software ya que siempre tendrían a las patentes como una sombra por detrás y que podrían afectar incluso a la misma supervivencia de la empresa (algunas recurrirían a provisionar fondos, otras a seguros, otras a ambas cosas) y como poco a sus balances económicos.

Hasta grandes corporaciones se han visto perjudicadas por sentencias controvertidas sobre el uso de patentes y si no que se lo digan a Microsoft con el famoso caso Eolas vs Microsoft, en el que la primera demandó a la segunda por infringir una patente sobre el acceso a plug-ins (por ejemplo el de flash) directamente a través de un navegador. Tal impacto tuvo este asunto que hasta la W3C se puso del lado de Microsoft al entender que se estaba atacando a una pieza importante dentro del funcionamiento de cualquier navegador. Al final tras años de litigio (en el que primero ganó Eolas, después se llego incluso a invalidar su patente para después volverla a considerar válida), ambas empresas llegaron a un acuerdo cuyos términos no han sido revelados. No obstante, hay que tener en cuenta que en primera instancia Eolas ganó el juicio (que después fue recurrido) en el que se indicaba que Microsoft debería pagar 521 millones de dolares.

Afortunadamente se puede considerar que tras la votación del Parlamento Europeo el 6 de julio de 2005 que las patentes software no son aplicables en el ámbito de la Unión Europea, no obstante el proceso para conseguir esto fue complejo (os recomiendo la lectura de la entrada dedicada a las patentes software en la Wikipedia para que se hagáis una idea de lo que costó que no se terminase de implantar la Directiva dedicada a las mismas y de las múltiples trabas que hubo en el camino. Este esfuerzo por defender la libertad y la innovación en el software debería servir de paradigma para que en un futuro y ante una circunstancia similar se actúe con la misma determinación que entonces) y duró varios años y pese a que últimamente se habla mucho menos de este asunto, es tan importante la no implantación de una política de patentes en el software que nunca hay que estar con la guardia baja, por un lado para evitar que se legisle a favor de las mismas y por otro para que la sociedad sea consciente de los serios problemas que traería consigo si se generalizase la aplicación de las patentes al mundo del software.

Dudo mucho que grandes corporaciones, poseedoras de miles de patentes software (el caso de la Unión Europea no es extensivo a otros países del mundo como por ejemplo los Estados Unidos donde sí están legalizadas las patentes software) o corporaciones más pequeñas, pero que viven casi exclusivamente del negocio de las patentes, renuncien sin más a un negocio tan lucrativo como es la aplicación de politica de patentes en un mercado tan amplio y tan rico como el de la Unión Europea.

Los programas de ordenador y productos derivados, tales como la documentación están protegidos por el copyright y quién lo desee puede utilizarlo para explotar el software como considere conveniente (el software libre hace también uso del copyright para asegurarse que el software, sus derivados y versiones puedan seguir siendo libres), por lo que quien desarrolle software y considere conveniente hacerlo propietario dispone ya de una garantía jurídica para hacerlo, por lo que las patentes software sobran y simplemente son un instrumento para ganar dinero por parte de los que tienen los derechos sobre las mismas.

El problema de las patentes software es que pretenden proteger no solo una determinada tecnología, sino lo que es peor, pretenden proteger ideas (conceptos), la mayoría de ellas lo suficientemente vagas o amplias que gran parte de los productos software que se desarrolle las infringirán. Hay otras ideas más simples que resultan igualmente dañinas, ya que se han llegado a patentar funciones y procesos computacionales triviales ampliamente extendidos en el desarrollo de cualquier software. Algunos ejemplitos de ideas patentadas lo tenemos con el doble click (concedida a Microsoft), el carrito de la compra (concedido a Amazon) o la navegación basada en pestañas (la empresa IP Innovation LLC demandó a Apple por este concepto, etc…).

¿Persistirá la información digital que actualmente se encuentra dispersa en infinidad de soportes?, en el caso de que persista, ¿se dispondrán de los medios adecuados para leer e interpretar dicha información?. Si no se hace nada al respecto, esta era (la actual) será una época oscura sobre la que no quedó rastro de lo que sucedió en la misma, si se intenta buscar información de la misma dentro de miles de años. Sobre esta base gira el documental “La oscura era digital” (del año 2003) que tuve la oportunidad de ver hace unos días.

Pese a que vi el documental desde una posición un tanto excéptica a sus plantemientos (ya que me pareció excesivamente alarmante, teniendo en cuenta de que gran parte de la información (y mucha de ella muy relevante) sigue (y seguirá teniendo aunque cada vez menos), su reflejo en medios físicos: libros, periódicos, etc…) y que tardé en abrir un poco la mente, al final me quedé con la moraleja de que es necesario de alguna manera buscar la persistencia de la información, pensando en ella no como un bien que necesito mantener en el presente, sino como un bien que se necesita consultar en un futuro (mirando este como algo a muy largo plazo), para ello no basta solo con almacenar los bits de información (que ya de por sí es algo costoso, no solo por su mantenimiento, sino por la sucesiva migración de los soportes que los contienen (la tecnología tiene eso, un avance continuo y progresivo que hace que cada cierto tiempo aparezca una nueva que desbanca a la anterior)), sino que además es necesario persistir la manera en que se interpreta ese conjunto de ceros y unos (sin esas interpretaciones no tenemos nada, simplemente ceros y unos sin sentido)).

Para poder persistir esa interpretación existen diversas posibilidades como por ejemplo almacenar el conjunto de programas y aplicaciones informáticos que permiten interpretarlos (sería algo así como tener un Arca de Noé de software), algo que es complejo debido a la gran cantidad de software que se genera y manteniente a lo que hay que sumar que también habría que almacenar en el arca los sistemas operativos sobre los que funcionaban y una emulación de cada uno de los sistemas físicos que lo soportaban (o disponer de un Arca de Noé del hardware). No obstante, la posibilidad más lógica es persistir la especificación de los formatos de los ficheros lógicos, para ello en primer lugar los formatos deben ser abiertos y por tanto conocidos (sin formatos abiertos esta posibilidad no existe para gran cantidad de información digital, de hecho, gran parte de la información almacenada en formato digital corre el riesgo de no ser interpretada en un futuro, al no ser abiertos sus formatos (lo que hace que o se tiene el software que lo interpretaba (Arca de Noé del software) o no hay nada que hacer (salvo intentar descifrarlo, algo que puede resultar bastante costoso)).

Tras la visión del documental, tengo más claro que nunca que debemos dirigirnos lo más rápido posible al uso de software que permita almacenar ficheros (audio, video, texto, imágenes, etc, etc, etc….) siguiendo especificaciones abiertas, de hecho a la mañana siguiente solicité una serie de modificaciones en el libro blanco de desarrollo de mi organización en lo que se refiere a la documentación de los proyectos (más adelante, no depende de mi, intentaré abordar un tema más complejo como es el de la información documental generada por los sistemas de información, ya que ésta también deberá seguir la filosofía de utilizar soluciones que tengan especificaciones abiertas).

Hay algo a lo que todavía no me he acostumbrado y es a lo desproporcionado que le parece a personal no relacionado con la informática el coste del desarrollo de proyectos informáticos.

Es una situación que no alcanzo a entender sobre todo cuando esas personas que se sorprenden incluso cuando comentas cantidades irrisorias se gastan muchísimos dinero en hacer otras actuaciones que sí que son realmente caras en relación al precio de los proyectos informáticos.

Esto provoca que en muchas ocasiones se subestime el coste de un proyecto informático con todos los problemas que esto supone, ya que como he comentado en otras ocasiones, los profesionales de la informática no tenemos una varita mágica que haga surgir un análisis y su codificación posterior de la nada, por lo que si el importe del proyecto es inferior a lo que cuesta realmente lo más probable es que el proyecto no vaya bien, por muy diligente que sea el responsable del proyecto y por muchas horas que dediquen los programadores.

Los profesionales de la informática tenemos que hacer sobre esto una labor didáctica, de manera que las personas con las que trabajamos y costean los proyectos entiendan que el desarrollo de software es una actividad tremendamente compleja y como tal tiene su coste.

Tanto si tienes externalizadas las tareas de programación, como si no o tu empresa se dedica al desarrollo de software, resulta esencial la existencia de un libro blanco de desarrollo que marque una línea tecnológica y de arquitectura para los sistemas de información.

De esta forma el desarrollo de los proyectos es homogéneo y facilita las tareas de mantenimiento. Además, supone un ahorro de costes, ya que el desarrollo bajo un paraguas común facilita la existencia de un framework y de una colección de componentes estable.

El libro blanco de desarrollo supone también una métrica cualitativa de medida de la calidad de los desarrollos en cuento a lo que a tecnología y arquitectura se refiere, algo que resulta fundamental.

El libro blanco de desarrollo debe centrarse en la selección de buenas prácticas, tecnologías, patrones y arquitecturas para el desarrollo de software para cada uno de los paradigmas de sistemas de información en los que se desarrolle. El libro blanco debe marcar un camino y digo camino y no línea, ya que es recomendable ser flexible para determinadas soluciones, dando la posibilidad de utilizar distintas alternativas. Además debe huir de soluciones “propietarias” (en el sentido de que sean soluciones particulares de una empresa en cuestión) a nivel de framework y adoptar componentes que resuelvan problemáticas funcionales recurrentes sean o no “propietarios” en el sentido indicado anteriormente.

Evidentemente si trabajas en una empresa de desarrollo de software debes desarrollar según las directrices tecnológicas que te marque el cliente, pero en el caso de desarrollos internos, desarrollos I+D o desarrollos para clientes que no te marquen una directriz tecnológica sí que resulta muy interesante el uso de un libro blanco de desarrollo.

Otros aspectos importantes que debe cubrir un libro blanco debe ser la organización del software y el procedimiento de entregas, es decir, qué sistema de control de versiones utilizar, cómo utilizarlo, cuál debe ser la política de etiquetado, qué solución utilizar para automatizar la realización de pruebas unitarias, despliegues, cuál es la política a seguir para el paso a pruebas y/o producción del sistema, etc…

Como se puede apreciar, un libro blanco de desarrollo bien hecho, no está al alcance de cualquiera, de hecho se escapa, en mi caso, varios millones de leguas de mi capacidad técnica. La persona o personas que lo realicen deben tener un gran conocimiento de arquitecturas y tecnologías software, estar muy al día de todas ellas y tener una gran experiencia en el desarrollo y gestión de proyectos de desarrollo de software.

Desde hace unos pocos años está muy de moda el concepto de producción industrializada de software, queriendo dar una semejanza entre los procesos industriales de fabricación de coches, lavadoras, ordenadores, etc… y el proceso de desarrollo de software.

El concepto de producción industrializada aplicada al software es relativamente reciente, aunque se viene aplicando en las empresas de desarrollo de software desde prácticamente los inicios de la programación y se ha visto reforzado en los últimos años con la aparición de potentes frameworks de desarrollo, potenciados por las distintas empresas para reducir los costes de desarrollo y la programación aplicando patrones de diseño y la reutilización de componentes de análisis, software y documentales.

Es decir, las empresas desarrolladoras de software siempre van a intentar reducir los tiempos de desarrollo, aplicando algunos conceptos de lo que es la producción industrial. No obstante, en el software hay que tener en cuenta que en la mayoría de los casos se trata de un desarrollo a medida, lo que provoca que soluciones software parecidas tengan un enfoque distinto en función del cliente que la ha encargado. Esto rompe el concepto de producción industrial y nos dirige a un proceso más realista como es el del desarrollo moderno de software basado en arquitecturas que utilizan patrones de diseño, un framework de base y un catálogo de componentes.

El aseguramiento de la calidad implica, entre otras cosas y a grandes rasgos, la necesidad de verificar si el software desarrollado cumple con los requerimientos funcionales y no funcionales, así como con las directrices tecnológicas y de arquitectura y si se ha realizado la entrega de la documentación solicitada utilizando, si existen, las plantillas definidas en la organización a tal efecto.

Esta característica ha abierto una línea de negocio a las empresas tecnológicas, consultoras y desarrollo de software como son las oficinas de calidad y la han aprovechado, ya que cada vez se contrata más este servicio tanto en organizaciones públicas y privadas.

Sin embargo hay que ser conscientes de varias cosas:

1) Si en una organización se implanta o se externaliza una Oficina de Calidad no se obtienen resultados satisfactorios al 100% desde el primer momento, sobre todo si la organización no tiene definida una estrategia tecnológica y de arquitectura (lo que se vienen a llamar libros blancos de desarrollo) y/o una estrategia metodológica. También hay que tener en cuenta otros factores, como tener en cuenta en el cronograma y plazo de los proyectos el período de pruebas y que los directores o jefes de proyecto crean en las funciones de la Oficina de Calidad. Todo esto provoca que el tiempo que pasa desde que la Oficina de Calidad empieza a trabajar hasta que realmente cumple la función ideal para la que se le ha contratado puede ser amplio.

2) Las oficinas de calidad en muchos casos se implantan para la revisión final de la entrega software (aunque previamente hayan revisado si se van realizando las entregas documentales y estan cumplen con las especificaciones de la organización) y esto puede ser demasiado tarde. La situación ideal es que a través de las entregas documentales ya puedan ir detectando fallos en el proceso de desarrollo. Sin embargo, esta situación ideal es más cara, ya que requiere más recursos de la oficina de calidad y con un perfil más alto y además requiere que los directores y jefes de proyecto acepten “la interferencia” de un agente externo desde las fases iniciales del proceso de desarrollo de software.

3) Si se externaliza la oficina de calidad, yo recomiendo el establecimiento de un acuerdo de nivel de servicio. En principio con una serie de indicadores mínimos a medir y después ir ajustándolos y completándolos conforme vaya avanzando el servicio.

En mi opinión las oficinas de calidad son una opción interesante, no traen debajo del brazo la solución al aseguramiento de la calidad en el proceso de desarrollo de software, pero sí pueden conseguir tras un tiempo, mejorar notablemente la calidad del mismo y de forma indirecta hacer que dentro del Departamento de informática de la organización se tomen una serie de decisiones orientadas a la normalización del proceso de desarrollo de software.

Ya he hablado muchas veces de los frameworks de desarrollo, desde lo que son las piezas base del mismo, hasta llegar al nivel de componentes reutilizables (de alto y bajo nivel en función del proyecto), pasando por la selección de una arquitectura óptima para el proceso de desarrollo.

Todo lo anterior ahorra costes de desarrollo y si el framework es estable, pues también asegura un número de errores mínimo provocado por los mismos, por lo que también supone una buena base para la calidad de la entrega.

En este post, hablo de ir a más, de crear componentes software a nivel de aplicación, diseñado de tal forma que con una parametrización de la misma pueda ser implantada en diferentes organizaciones. Lo de la parametrización es lo óptimo, sé que no siempre se puede llegar a ese punto, pero por lo menos se debe lograr que esas piezas completas de software se puedan adaptar a una organización aplicando los menores cambios posibles sobre su código.

Diseñar software así no es sencillo, pero tener un catálogo de productos software disponibles para su instalación y parametrización supone unos beneficios en cada venta muy considerables, además de situarte frente a tus competidores en una situación privilegiada.

…Por ese motivo no trates de buscar la perfección, es una pérdida de tiempo y por consiguiente de dinero.

Busca la calidad, que es una cosa bien distinta.

La mejora del sistema es un proceso evolutivo, de iteraciones, asegura la calidad en cada iteración, no trates de conseguir Plutón, sin antes haber alcanzado siquiera Marte.