PDF de programación - Valoración de productos de Software Libre y de Fuentes Abiertas

Valoración de productos de Software 
Libre y de Fuentes Abiertas 

Borrador de trabajo. v0.2 

Francisco Palm (​[email protected]​), Mariángela Petrizzo (​[email protected]​) 

 

 

 

 

Introducción 
Existe una preocupación en el mundo empresarial­corporativo con respecto a la producción de
 
software porque no les ha sido posible controlar su desarrollo del mismo modo en que se
 
controla y se garantiza la calidad en la industria de manufactura, de servicios o de construcción.
 
Está claro que paradigma neoliberal de la industrialización, por sí solo bastante cuestionable
 
 
por la evidente depredación del medio ambiente y la enajenación de lo que hace humano al ser
humano bajo el modelo económico imperante en la actualidad, busca con la mayor prioridad
 
esquemas productivos de economía de escala, predecibles y ajustables a conveniencia. 

 
   
 

   
 
 

   
 

 
 
 

 
 

 
 

 
 

 
 

 
 

 
 

 
 

 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 
 

 
 

En este contexto, a lo largo del tiempo el desarrollo de software ha mostrado ser una actividad
 
 
con un enorme potencial
lucrativo, pero poco susceptible a ser normado y controlado. Los
 
 
ejecutivos, actualmente CEOs, del ámbito de las tecnologías de información prefieren asumir
 
que los programadores son meros obreros de la informática , pero el problema es que incluso
 
 
un desarrollo simple en tecnologías de la información requiere un nivel de conocimiento y de
experticia relativamente alto, de modo que no es difícil encontrar situaciones en las cuales un
 
 
programador “junior” tiene un mejor conocimiento del negocio que un alto directivo. 

   
 

 
 
 
 

 
 
 

 
 
 

 
 

 
 

 
 

 
 

 
 

 
 

 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1

 

 

 

 

 

 

 

 

 

 

 
 

Esta lucha por poder y reconocimiento entre ejecutivos y desarrolladores se acentúa cuando
 
encontramos programadores de gran talento que no tienen interés en abandonar su trabajo
 
 
para ocupar exclusivamente cargos ejecutivos , y además superan con creces a los directivos
en el ejercicio de sus propias funciones. Este fue un factor clave del boom del Silicon Valley, el
 
surgimiento de empresas como Google y Amazon, y mantiene una enorme relación con el
 
movimiento hacker de las décadas de los 60s, 70s y 80s, indudable origen de los movimientos
 
de software libre y de fuentes abiertas. No es muy descabellado pensar que el mundo
 

 
 
   
 

 
 
 
 

 
 
2

 
 

 
 

 
 

 
 

 
 

 
 

 
 

 
 

 
 

 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 
 

 
 

1 ​Vale la pena insistir que ya es un problema en cualquier ámbito reducir a un ser humano a la
   
 
condición de obrero, porque quizás es apenas una forma de legitimar la asignación de bajos
salarios. 
2 ​Equivalente a que un obrero aún teniendo la oportunidad de no hacerlo, insista en seguir
 
pegando bloques. 
 

   
 

 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 
 

 

corporativo del software privativo sigue sin dar muestras para entender, o incluso intentar
 
 
entender al software libre. 

 

 

 

 

 

 

 

 

 

 

 

 

 

El modelo de Capacidad y Madurez 
Con la finalidad de evaluar desde una perspectiva burocrática las capacidades de desarrollar
 
 
proyectos de software para contratistas del gobierno estadounidense, en particular la Fuerza
 
Aérea de los EEUU, se elaboró a mediados de los 80s el Modelo de Capacidad y Madurez
(Capability Maturity Model o CMM) como un instrumento para formalizar y optimizar procesos
 
 
involucrados en el desarrollo de software.  

 
 

   

 
 

 
 

 
 

 
 

 
 

 
 

 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 
 

 
 

 
 

 
 

 
 

 
 

 
 

 
 
 

 
El modelo se fundamenta en suponer que si una organización que desarrolla software mejora
sus procesos siguiendo el modelo prescrito por CMMi, mejorará la calidad del software
 
 
resultante. La evidencia ha demostrado que este supuesto con frecuencia no se cumple, ya que
es necesario considerar a las personas más allá de los procesos, de allí surgieron el ​Personal
 
Software Process​ (PSP) y el ​Team Software Process​ donde el PSP debe encajar. 
Lo más llamativo es que el modelo CMMi se ha extendido sin tener ningún tipo de base teórica
 
 
más allá de representar la opinión de expertos. En realidad, no existe una evidencia clara y
 
 
 3
contundente de su efectividad ya que la evidencia recabada generalmente por el propio SEI
destaca casos de éxito de las empresas sometidas a CMMi, pero en realidad no muestra
 
comparación entre éxitos y fracasos, ni estudios comparativos con respecto a otras estrategias
 
para mejorar la calidad del software. De hecho, es muy difícil encontrar opiniones positivas del
 
CMMi que provengan de fuentes neutrales, Tampoco se considera el hecho que ​en términos
 
prácticos, muchas empresas simplemente están obligadas a seguirlo para tener la posibilidad
 
de ser contratadas . Esto supone que los vendedores de certificaciones CMMi adapten su
 
discurso, pese a que la metodología CMM­CMMi ha cambiado muy poco en los últimos 10
 
años. 

   
 

 
 
 

 
 

 
 

 
 

 
 
 

   

 
 

 
 

 
 

 
 

 
 

 
 

 
 

 
 

 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Hay alternativas a CMMi, que se muestran como versiones ligeras de éste aunque en el fondo
 
 
parten de los mismos principios y exhiben las mismas carencias. Pese a ello, CMMi se ha
mostrado especialmente inadecuado para equipos de desarrollo pequeños, sobre todo si lo
 
comparamos con los esquemas de trabajo ágiles. 

 
 

 
 

 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 
 

Pero además, son muchos los proyectos libres y no libres que han logrado ser muy exitosos sin
 
necesidad de satisfacer CMMi, desde Microsoft hasta el desarrollo del kernel de Linux. De
 
hecho, ninguno de los proyectos de Software Libre más significativos, con millones de usuarios
 
satisfechos en el planeta, tales como el servidor web Apache, el manejador de bases de datos
 
PostgreSQL o el navegador web Mozilla Firefox están certificados CMMi pues su interés no se
 
centra en participar en licitaciones públicas. Sin embargo, es innegable la calidad de estos
 

 
 
 

 
 
 

 
 

   

 
 

 
 

 
 

 
 

 
 

 
 

 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

3 El Software Engineering Institute de la Carnegie Mellon University, cuya principal fuente de financiamiento 
es el Departamento de Defensa de los EEUU.  
 

productos de software. Es evidente, entonces, que lo que impulsa la calidad de estos proyectos
son los procesos abiertos a su comunidad y la búsqueda permanente de la excelencia. 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Las principales críticas a las certificaciones estilo CMM y sus derivados son (Bach, 1994): 

● No hacen énfasis en la calidad del producto sino en los objetivos de la organización, y
   

 

 

 

 

 

 

 

 

 

 

 

 

 

 

desplaza los objetivos de la organización hacia el cumplimiento del propio CMMi. 
 

● Se enfoca más en los procesos (administrativos) de soporte al desarrollo que en las
 

 
prácticas del propio desarrollo, y en las personas que lo realizan. 

 

 

 

 

 

 

 

 

 

 

 

● Se mide la conformidad con los procesos existentes, sin constatar que estos sean los

 

 

 

 

 

 

 

 

 

 

 

 

 

procesos idóneos. 

● Como están diseñados hacia lo que resulta predecible, distorsionan la capacidad de

 

 

 

 

 

 

 

 

 

 

 

innovación. 

 

 

 

● Es una receta “​entubada​” que no percibe ni se adapta a las condiciones particulares de
 

cada cliente, ni siquiera considera su historial de éxitos o fracasos. 

   

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 
 

 
 

 
 

 
La metodologías de software concebidas como la base de un desarrollo de calidad no
consideran el hecho de que el principal factor en la calidad del software son las destrezas de
 
 
los equipos de desarrollo y de sus miembros, las cuales se refuerzan en el ámbito del software
 
libre de fuentes abiertas en virtud del trabajo colaborativo. En consecuencia, en una primera
instancia ​no hace tanta falta metodologías y certificaciones como el fortalecer las destrezas
 
individuales y colectivas de los equipos de desarrollo​. En especial, cuando ni siquiera se
 
conocen cuáles son las destrezas de los actores involucrados, o de cuáles destrezas carecen. 

   
 
 
 

 
 
 

 
 
 

 
 

 
 

 
 

 
 

 
 

 
 

 
 

 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 
 

En este sentido, es importante comprender que hay procesos organizacionales que, aplicados
de forma correcta, pueden mejorar el
 
trabajo de un grupo talentoso, pero un grupo de
desarrolladores no se hace talentoso sólo mejorando sus procesos actuales. 

 
 

 
 

 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 
 

 

 

 

 
Se recomienda entonces promover un modelo de desarrollo abierto y transparente que pueda
 
convertirse en un proce