Sobre la integridad del código

Tema: 

Acabo de leer un artículo (http://www.techweekeurope.co.uk/news/open-source-code-is-cleaner-than-proprietary-says-coverity-62518) referente a la calidad del código de proyectos open source en comparación con proyectos propietarios (privativos, aunque no es lo mismo propietario es el termino que se uso en el artículo).

En todo caso se hablo de un reporte realizado escaneando millones de líneas de código en software open source y del otro. En promedio el software open source tenía una densidad promedio de defectos (número de defectos por cada 1000 líneas de código) de 0.45 (mientras que en el software propietario era de 0.64).
Pero lo que mas me gusto fue que el mismo reporte decía que la densidad promedio de defectos en el caso de PostgreSQL 9.1 era de solo 0.21.

¿Pero como se logra esto? Cualquiera creería que siendo un proyecto open source habría muchas mas fallas. Pero la verdad es a la inversa. La razón, al menos en el caso de PostgreSQL es el modelo que tiene para aceptar código.

1) No cualquiera puede grabar cambios (commit) en el código base. Sino solo un pequeño grupo de personas llamados, lógicamente, committers (http://wiki.postgresql.org/wiki/Committers). Cada committer es responsable de los cambios que realiza al código base (aunque el código provenga de una tercera persona).

2) Cualquiera que proponga un cambio y provea el código para ello (parche) debe cumplir con una serie de requisitos (pueden ser mas o menos a criterio del committer pero en general se mantienen):
- La característica debe hacer lo que se supone que hace.
- Presentar pruebas de que el cambio es útil. Si el cambio añade mucha complejidad y la utilidad es limitada
(tendiendo a cero) probablemente el parche será rechazado.
- Documentación. Si el parche genera cambios visibles al usuario debe traer documentación, y siempre debe haber
suficientes comentarios para que cualquier otro desarrollador entienda lo que esta pasando.
- No debería haber fallas conocidas. En realidad, a veces se aceptan parches con "cabos sueltos" cuando la
característica es tan interesante que hace que uno o varios committers se comprometan a cerrar esos cabos sueltos
antes del fin del ciclo de desarrollo.

En general para cumplir con esos puntos existe un proceso que conocemos como commitfest en el cual varios desarrolladores revisan los parches de otros desarrolladores hasta que los consideren listos para que un committer les de su atención.

Es un proceso bueno y como vimos la integridad del código base se mantiene. Pero a veces esto hace que parches que consideramos buenos se demoren en entrar. Debido a que se pide que el parche se generalize mas o algún otro cambio y el resultado final ya no gusta. Para muestra un botón: el parche conocido como FOR KEY SHARE.
Este es un parche de Álvaro Herrera diseñado para eliminar la necesidad de bloquear un registro que actua como FK mientras se modifica el registro que hace referencia a el. (Probablemente super simplifique el problema que el parche resuelve).
Lo mismo ocurre con un parche mio, aunque de menor relevancia.

Claro que aun no esta todo dicho sobre los parches pendientes para el 9.2, especialmente con el parche de Álvaro pues el mismo es un committer. Sea lo que sea que pase se hará con el objetivo de mantener la integridad del código al máximo.

Sí, contribuir a un proyecto como este puede ser complicado y un dolor de cabeza a veces. Pero no cabe duda que los beneficios a largo plazo lo valen. Uno aprende a programar a un nivel tan alto que el código base no llegue a tener mas de un 0.21 de promedio de densidad de defectos.

Comentarios

Interesante

Imagen de iknaxio

Interesante el post, me permitió tener una visión más detallada de lo que hay detrás del desarrollo de un proyecto OS como PostgreSQL.

"Transporta un puñado de tierra todos los días y construirás una montaña" - Confucio
floss.iknaxio.net

Pues yo creo que la densidad

Imagen de yahuar_kuntur

Pues yo creo que la densidad de defectos no depende si el software es abierto o cerrado, depende mas de las "convenciones" y "politicas" (no me gusta mucho esta palabra pero creo que me entienden heheh) como las que presenta Jaime. Muy interesante este aporte que de cierta forma desmiente lo que se pensaba sobre el codigo abierto y un grato "Kudos" a PostgreSQL el motor de base de datos mas AVANZADO del mundo :D

Saludos,

bueno, es lógico que sea de

Imagen de deathUser

bueno, es lógico que sea de esa manera, ya que el código cerrado solo lo verán los "dueños" del código y en el mejor de los casos unos pocos de sus clientes con acceso especial, mientras que en el open source y en el free software hay cientos y hasta miles o cientos de miles de usuarios y programadores que tienen acceso al código, pudiendo encontrar y reportar fallos de diseño, errores o mejoras, claro que dependerá también mucho de su política de aceptación de parches la calidad de los fuentes y su densidad de errores...

bye
;)