Los n�meros ofrecidos en las secciones anteriores no son m�s que estimaciones. Pueden darnos al menos �rdenes de magnitud, y permitir las comparaciones, pero no deben ser tomados como datos exactos, hay demasiadas fuentes de error, as� como margen para diversas interpretaciones. En esta secci�n discutiremos algunas de las presunciones m�s importantes que se han hecho, con el objetivo de aportar contexto al lector para interpretar los n�meros.
Ya que dependemos de la herramienta sloccount de David Wheeler para medir el SLOC, tambi�n dependemos de su definici�n de "l�neas f�sicas de c�digo fuente". Por tanto, podemos decir que contabilizamos una SLOC cuando sloccount lo hace, si bien sloccount ha sido cuidadosamente dise�ado para responder a la definici�n habitual de SLOC f�sicas: " una l�nea f�sica de c�digo fuente es una linea que acaba en un marcador de nueva l�nea o de fin de fichero, y que contiene al menos un car�cter que no es un espacio en blanco ni un comentario.;" .
Hay otra medida similar que se prefiere en ocasiones, el SLOC "l�gico". Por ejemplo, una l�nea escrita en C con dos punto y coma ser�a considerado como dos SLOC l�gico, mientras que ser�a un solo SLOC f�sico. En todo caso, para los prop�sitos de este art�culo (como para casi cualquier otro), las diferencias entre ambos SLOC son despreciables, especialmente comparadas con otras fuentes de error e interpretaci�n.
Las mediciones de l�neas de c�digo presentadas en este art�culo no son m�s que estimaciones. En ning�n caso pretendemos afirmar que sean exactas, especialmente cuando se refieren a agregaci�n de paquetes. Hay varios factores que causan imprecisiones, algunas debidas a las herramientas empleadas para contar, otras, debidas a la selecci�n de los paquetes.
Algunos ficheros pueden no haber sido medidos de forma precisa.
Si bien sloccount incluye heur�sticos cuidadosamente dise�ados para detectar ficheros de c�digo fuente, y para distinguir las l�neas de c�digo de los comentarios, estos heur�sticos no siempre funcionan de la manera prevista. Adem�s, con frecuencia es dif�cil distinguir los ficheros generados autom�ticamente (que no deber�an ser contados), aunque sloccount hace un buen esfuerzo para reconocerlos.
No todos los lenguajes de programaci�n son reconocidos.
Para capturar los datos usamos la versi�n 1.9 de sloccount, que reconoce unos 20 lenguajes distintos. De todas formas, algunos de los lenguajes empleados en Debian (como Modula-3 o Erlang) no est�n soportados. Obviamente esto lleva a una infra-estimaci�n en los paquetes con ficheros escritos en estos lenguajes.
Distintas percepciones en la agregaci�n de familias de paquetes y en la selecci�n de los representativos.
Como comentamos en la subsecci�n donde tratamos sobre la selecci�n de la lista de paquetes a medir, las razones para incluir o excluir un paquete no son incuestionables. �Deber�amos contar distintas versiones del mismo paquete? �Deber�amos contar s�lo una vez el c�digo presente en varios paquetes o no? El criterio habitual para medir SLOC es "l�neas de c�digo fuente distribuido". Desde este punto de vista, todos los paquetes debieran ser considerados tal y como aparecen en la distribuci�n Debian. En todo caso esto es dif�cil de aplicar cuando algunos paquetes son claramente evoluciones de otros. En vez de considerarlos todos como "distribuidos", parece m�s productivo considerar los m�s antiguos como "versiones beta". De todas formas en el �mbito del software libre es bastante frecuente el distribuir versiones estables cada 6 o 12 meses. Estas versiones estables representan mucho trabajo s�lo para asegurar su estabilidad, aunque s�lo sean la base para posteriores versiones.
En la mayor�a de los casos, hemos adoptado una decisi�n intermedia: Contar s�lo familias de paquetes que sean una l�nea de evoluci�n (como en el caso de emacs19 y emacs20, pero contar por separado familias de paquetes que comparten algo de c�digo pero que son en s� mismas desarrollos destinos (como en el caso de gcc y gnat).
Los modelos de estimaci�n actual, y espec�ficamente COCOMO, s�lo consideran modelos cl�sicos de desarrollo de software propietario. Pero los modelos de desarrollo de software libre son bastante distintos. De esta forma s�lo podemos estimar el coste del sistema si hubiera sido desarrollado por m�todos convencionales, pero no los costes reales (en esfuerzo o dinero) del desarrollo del software incluido en Debian 2.2
Algunas de las diferencias que hacen imposibles el uso de estos modelos de estimaci�n son:
Proceso continuo de distribuciones. El modelo COCOMO est� basado en el concepto de "SLOC de versiones distribuidas" , lo que implica un punto en el ciclo de vida del proyecto en que el producto es distribuido. A partir de ese momento, el principal esfuerzo de desarrollo est� dedicado al mantenimiento. Por el contrario, la mayor�a del software libre libera versiones con tanta frecuencia que podr�a ser considerado como un proceso de distribuciones continuas. Esto conlleva una casi continua estabilizaci�n del c�digo, al mismo tiempo que evoluciona. Los proyectos de software libre suelen mejorar y modificar los programas al mismo tiempo que los preparan para los usuarios finales.
Control y soluci�n de error. Mientras que todos los sistemas de software propietario precisan de costosos ciclos de depuraci�n, el software libre cuenta con la ayuda de voluntarios ajenos al proyecto, en forma de valiosos informes de errores e incluso soluciones para ellos.
Reutilizaci�n, evoluci�n e intercambio del c�digo. En los proyectos de software libre es com�n la reutilizaci�n de c�digo de otros proyectos de software libre como una parte central del sistema en desarrollo. Tambi�n es frecuente que varios proyectos evolucionen del mismo sistema base, e incluso todos usen c�digo de todos al mismo tiempo. A veces esto mismo puede suceder en desarrollos propietarios, pero incluso en grandes empresas con muchos proyectos abiertos, no es com�n, es mucho m�s frecuente en proyectos de software libre.
Modelo de desarrollo distribuido. Aunque algunos sistemas propietarios son desarrollados por equipos distribuidos geogr�ficamente, el grado de distribuci�n que suelen presentar los proyectos de software libre es varios �rdenes de magnitud superior. Hay excepciones, pero en general los proyectos de software libre corren a cargo de personas de diferentes pa�ses, que no trabajan en la misma empresa, que dedican distinta cantidad de esfuerzo al proyecto, que cooperan principalmente a trav�s de Internet, y que, la mayor parte de las veces (especialmente en proyectos grandes), el equipo de desarrollo nunca ha coincidido f�sicamente en un mismo sitio.
Algunos de estos factores incrementan el esfuerzo necesario para construir el software, mientras que otros lo decrementan. Sin analizar detalladamente el impacto de estos (y otros) factores, los modelos de estimaci�n en general, y COCOMO en particular no son directamente aplicables al desarrollo de software libre.
Para poner en contexto las cifras mostradas anteriormente, aportamos estimaciones del tama�o de algunos Sistemas Operativos, y una comparaci�n m�s detallada con las estimaciones de la distribuci�n Red Hat Linux.
Como se indica en [Lucovsky2000] (para Windows 2000) [Wheeler2001] (para Red Hat Linux) [Schneier2000] (para el resto de los sistemas) este es el tama�o estimado para varios Sistemas Operativos, en l�neas de c�digo. (Siempre en cifras aproximadas):
Microsoft Windows 3.1: 3.000.000
Sun Solaris: 7.500.000
Microsoft Windows 95: 15.000.000
Red Hat Linux 6.2: 17.000.000
Microsoft Windows 2000: 29.000.000
Red Hat Linux 7.1: 30.000.000
Debian 2.2: 56.000.000
Casi todas las estimaciones (en realidad, todas, excepto las de Red Hat) no son detalladas, por lo que es dif�cil saber qu� consideran una l�nea de c�digo. De todas formas, las estimaciones deber�an ser lo suficientemente pr�ximas a las mediciones de SLOC como para que sean v�lidos para una comparaci�n.
N�tese que mientras que Red Hat y Debian incluyen muchas aplicaciones, con frecuencia varias aplicaciones del mismo tipo de programa, tanto los Sistemas Operativos de Microsoft como los de Sun son mucho m�s limitados en este sentido. Si las aplicaciones m�s usadas en estos entornos fueran contabilizadas juntas, el tama�o ser�a mucho mayor. En todo caso, tambi�n es cierto que todas esas aplicaciones ni son desarrolladas ni integradas por el mismo equipo de desarrollo, como en el caso de las distribuciones basadas en Linux.
A partir de estas cifras, queda claro que las distribuciones basadas en Linux, en general, y Debian 2.2 en particular, son unas de las mayores colecciones de software nunca integradas por un equipo de desarrollo.
El �nico Sistema Operativo para el que hemos encontrado medidas detalladas de l�neas de c�digo fuente es Red Hat Linux (consultar" Estimating Linux's Size" y "More Than a Gigabuck: Estimating GNU/Linux's Size;"). Siendo tambi�n una distribuci�n basada en Linux, donde los paquetes software incluidos en Debian y en Red Hat son bastante similares, la comparaci�n puede ser ilustrativa. Adem�s, siendo Red Hat Linux una distribuci�n muy com�n, probablemente la m�s conocida, la comparaci�n con ellas puede aportar un contexto apropiado para el lector familiarizado con ella.
Lo primero que nos sorprendi� cuando medimos Debian 2.2 fue su tama�o, comparado con Red Hat 6.2 (Distribuido en Marzo de 2000) y con Red Hat 7.1 (distribuido en Abril de 2001). Debian 2.2 aparece en agosto de 2000 , y su tama�o es casi el doble que el de Red Hat (Distribuido unos seis meses despu�s) y m�s de tres veces el tama�o de Red Hay 6.2 (distribuido cinco meses antes)_ Algunas de estas diferencia pueden ser debidas a diferentes consideraciones sobre qu� paquetes incluir al medir, pero con todo aportan una buena idea de los tama�os relativos.
El principal factor causante de las diferencias es el n�mero de paquetes incluidos en cada distribuci�n, en el caso de Debian hemos considerado 2630 paquetes fuente (con una media de unos 21.300 SLOC por paquete), mientras que Red Hat 7.1 incluye s�lo 612 paquetes (de unos 49.000 SLOC por paquete)
Cuando se comparan los paquetes mayores en ambas distribuciones, encontramos en Debian todos los incluidos en Red Hat, lo que no es cierto a la inversa: Varios paquetes que suman una buena cantidad de SLOC en Debian no est�n presentes en Red Hat. Por ejemplo, entre los 11 mayores paquetes en Debian 2.2, los siguientes no est�n en Red Hat 7.1: PM3 (unos 1.115.000 SLOC), OSKit (unos 859.000 SLOC), GNAT (688.000), NCBI (591.000). Por el contrario, entre los 11 paquetes mayores en Red Hat 7.1, no echamos ninguno en falta en Debian 2.2.
De todas formas hay una gran colecci�n de paquetes software presentes en Red Hat 7.1 y no en Debian 2.2: El escritorio KDE y sus utilidades. Debido a problemas de licencia, Debian decidi� no incluir software KDE hasta despu�s de Debian 2.2, cuando la licencia para Qt cambi� a GPL. Por tanto, podemos decir que Debian 2.2 es mayor, incluso sin todo el c�digo de KDE. S�lo para dar una idea, los mayores paquetes KDE en Red Hat 7.1 son kdebase, kdelibs, koffice, y kdemultimedia, que suman sobre 1.000.000 SLOC. Todos ellos est�n ausentes en Debian. Esto sugiere que si las medidas hubieran sido hechas en la distribuci�n actual Debian (A�n no distribuida oficialmente), las diferencias hubieran sido mayores.
Las diferencias entre el mismo paquete en cada distribuci�n son atribuibles a las diferentes distribuciones incluidas en ellos. Por ejemplo, el kernel Linux suma 1.780.000 SLOC (Versi�n 2.2.19) en Debian 2.2, mientras que el mismo paquete suma 2.437.000 SLOC (Versi�n 2.4.2) en Red Hat 7.1. XFree incluye 1.270.000 SLOC (Versi�n 3.3.6) en Debian 2.2, mientras que la versi�n incluida en Red Hat 7.1 (XFree 4.0.3) suma 1.838.000 SLOC. Estas diferencias hacen dif�cil el comparar directamente Red Hat y Debian.
El lector debe percatarse de que hay una diferencia metodol�gica entre el estudio de Red Hat y el nuestro sobre Debian. El primero extrae todos los paquetes fuente y usa "checksum" MD5 para evitar duplicados entre todo el c�digo de la distribuci�n. En el caso de Debian, hemos extra�do los paquetes uno a uno, evitando paquetes duplicados pero no ficheros individuales repetidos. De todas formas, la suma total no deber�a verse muy afectada por esta diferencia.