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.