A nivel filosófico, el tema de las compilaciones reproducibles o reproducible builds, es sin duda algo que me preocupaba. Veamos, hay multitud de software de código abierto, pero hasta que punto es verdaderamente abierto, ¿si no hay terceros que sean capaces de recompilarlo y verificar que los resultados obtenidos son idénticos a los oficiales?

Muchos usamos OpenOffice o LibreOffice por ejemplo. Pensamos que son seguros, porque cualquiera puede revisar el código fuente, y encontrar problemas. Lógicamente, el primer requisito, es que el proyecto tenga el código fuente disponible. No necesariamente debe ser libre, pero si que tiene que poder ser revisado. Si el código es cerrado, pues ocurre como la polémica de los motores TDI de Volkswagen.

Después hace falta que alguien esté dispuesto a invertir su tiempo en revisar el código, y que tenga la capacidad de detectar el problema. Sino, recordad el problema de Heartbleed en OpenSSL, que llevaba varios años allí.

Hasta aquí es el punto que todos conocíamos, y que no tiene nada que ver con las compilaciones reproducibles. La iniciativa de Reproducible Builds, lo que pretende es facilitar que ese código fuente, pueda ser verificado como que en efecto genera el ejecutable oficial. Trata de facilitar que gente externa pueda acceder al código, y recompilarlo.

Este proceso, ha sido siempre posible, con mayores o menores dificultadas. Personalmente he compilado SQlite (para DOS y Windows), PHP y extensiones (para Linux), SumatraPDF (para Windows) o ClamAV (para Windows).

Incluso he compilado y contribuido con proyectos más complejos como Netscape, MAME, DOS32/a u OpenWatcom.

He usado sin problemas proyectos de código abierto en mis desarrollo propios. Por ejemplo FileOptimizer contiene binarios de gifsicle, jpegoptim y jsmin compilados por mi. O zRecompress que utiliza el LZMA SDK.

Por tanto el primer objetivo de la iniciativa, es extender el uso de instrucciones de compilación claras, y el acceso a los fuentes. Desgraciadamente, no es suficiente. Hablando desde mi experiencia de proyectos de código abierto que tenéis disponibles en mi página de proyectos en Sourceforge, me refiero a FileOptimizer, TBClamAV, SMETAR, MEMTRACE, XPlorer, ZEROFILL o RLE64 he apoyado ese tipo de iniciativas. Con archivos BAT que automatizaban la construcción, y con el código fuente disponible. Incluso he ido mejorándolo, haciéndolo más fácil en bastantes aspectos, con un repositorio SVN y un mirror en Github.

Ahí es donde entran en juego las compilaciones automatizadas (automated builds), servicios que se encargan de compilar automáticamente nuestros proyectos como la Farm de Sourceforge. Igualmente contamos con herramientas de pruebas continuas (continous test), como Coverity Scan, que es un analizador de código al estilo de CppCheck o Lint. De hecho, hasta contamos con servicios de integracion continua (continous integration), que combinan los dos, con servicios como App Veyor o TravisCI.

Para las compilaciones automatizadas, la cosa no es tan sencilla, porque aunque doy el código fuente, explicaciones de como usarlo, y facilito su acceso, suelo utilizar C++ Builder en la mayoría de proyectos (también Delphi, Lazarus
OpenWatcom, Visual C++ o MASM). C++ Builder, es un entorno de desarrollo propietario, y de pago. Igual que Visual C++ y Delphi, lo que exige disponer de él para poder colaborar. Por mucho que el proyecto sea libre y gratuito, las herramientas de desarrollo no lo son, ni siquiera para uso no comercial. Claro que tenemos Visual C++ Express, y C++ Builder Starter o Delphi Starter, pero son tan limitados, que no servirán para la mayoría de proyectos. Eso implica que estos servicios, no disponen de estas herramientas, por lo que son ineficaces.

La solución, sería que Embarcadero, proporcionada licencias gratuitas, de manera que más proyectos de código abierto las utilizaran, pero dudo que lo hagan.