Desarrollo

++PUBLICACIÓN DE CÓDIGO FUENTE DE PROYECTOS

+++Fundamentos para la publicación de código fuente de proyectos**

La creación de herramientas digitales para facilitar las tareas organizacionales y producticas de las entidades e individuos vienen desde los últimos 30 años en un crecimiento vertiginoso abarcando todo tipo de actividades y reemplazando principalmente tareas de redacción, publicación, compartición, documentación de procesos y archivos históricos, facilitación de los procesos documentales y estadísticos, cálculos para la gestión financiera y proyecciónes a futuro de dichas entidades y el sector gubernamental no se encuentra excento de dicho impacto, más aun es el más beneficiado, puesto que dichas herramientas facilitan el proceso de cumplimiento de los objetivos que llevan a mejorar organizativa, económica y transparentemente los procesos que impactan directamente a la población de una ciudad, departamento o nación. Así la incorporación de herramientas de computo libres (sistemas operativos y herramientas de ofimática, redes u otros) que permitan el uso irrestricto no limitado en tiempo o tarea de si misma, poder estudiarla para conocer sus procesos, el poder modificarla cuando se puede mejorar por error o para aumentar prestaciones, y el poder distribuirla sin restricciones legales por el uso, ayuda que los entes (entidades públicas, privadas o individuos), puedan ejercer su libertad y derecho de desarrollar las tareas y proyectarse a trabajos más rápidos y eficases. Con esta ventaja la incorporación de un departamento de desarrollo de herramientas informáticas en las entidades facilitan que dicha institución pueda resolver con mayor rapidez los problemas de traducir el proceso manual lento y burocrático en un proceso transparente, fácilmente auditable y mucho más rápido, eficiente y económico, pero teniendo en cuenta que los procesos de gestión de negocios se caracterizan por la necesidad de testear y corregir las herramientas con una velocidad y eficiencia que en ocasiones supera a la mayoría de los procesos de desarrollo actuales, casi todas las empresas y entidades también optan por publicar el código fuente (es decir, los mecanismo internos) de las aplicaciones, para que sean probados o un número que puede ir de unas decenas hasta cientos de miles de personas que voluntariamente son capaces de informar de fallos tanto minúsculos (como errores de texto) como los más complejos (como fallos a la hora de generar informes estadísticos en situación con variables que muy pocas veces se pueden prever, ay sea por volumen o por los tipos de datos involucrados), así también generar formatos de publicación para que los datos de la entidad sean mejor consumidos por las personas afectadas (publicaciones de planillas de datos o documentos en formato estándar), y el código o la ayuda retroalimenta a si a la entidad mejorando su eficiencia a veces en más de 300% (gobierno británico, RedHat Inc, Ubuntu Canonical, IBM, LibreOffice, Mozilla Corporation, Debian Community, Apache Group, Google Inc, entre otros ejemplos).

Proceso de publicación de Código Fuente bajo GNU GPL

  • Verificar que todo el código y documentación escritos son propiedad de la empresa o individuo, por haber sido escrito por sí mismo o por un tercero que cedió derechos mediante contrato de trabajo que lo estipulaba (en adenlante CÓDIGO LOCAL), esto no descarta de realizar un listado de desarrolladores involucrados.
  • En caso de requerir frameworks, APIs, plugins o interacción con algún portal externo (en adelante MÓDULO-EXTERNO), asegurarse que la publicación del código embebido o datos consumidos por la aplicación desde terceros, no viola el acuerdo de licencia con el que está publicados.
  • Asegurarse de indicar que frameworks, APIs, plugins no corresponden al código propio y si se adjunta incluir datos de origen, contacto y licencia propios de este en el directorio donde se alojan y en la documentación. En caso de encontrarse con un MÓDULO-EXTERNO privativo, intentar que el CODIGO LOCAL pueda funcionar con y sin el MÓDULO-EXTERNO sin que los procesos se vean afectados.
  • Por cuestiones de integridad textual de las licencias GNU GPL se debe implementar en su versión en inglés como texto base, por el cual se debe manejar la defensa legal en caso de disputa, pero puede ser acompañado por la traducción no oficial del texto en idioma local como referencia rápida. La licencia preferentemente debe ser incluida en un archivo de texto plano llamado COPYING (o license.txt) junto con el código fuente (versiones adjuntas en idioma local “COPYING.es_AR”, por ejemplo).
  • En todos los archivos de código fuente debe incluirse en la cabecera la leyenda:
<elemento que indique comentario en el código fuente por bloque o línea por línea>

  <línea con el nombre del programa>

  <que funciones u objetivos cumple>
   Copyright (C) <año de inicio> (seguido de años en que se editó seguidamente)  <nombre del autor original o equipo> (y últimos editores)

   This program is free software: you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
   the Free Software Foundation, either version 3 of the License, or
   any later version.

   This program is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   GNU General Public License for more details.

   You should have received a copy of the GNU General Public License
   along with this program.  If not, see <http://www.gnu.org/licenses/>.

<agregar los mecanismos para contactar, correo y/o teléfono/dirección>

<fin elemento que indique comentario en el código fuente>

… así también el en “acerca de…” de la aplicación debe figurar la misma cita (junto con la excepción sobre elementos no propios) seguido, si es posible, de la lista de personas o grupos involucrados en la edición del código, multimediales, o manuales.
  • Debe crearse un archivo de cambios en la raíz del documento con el nombre “ChangeLog” (conteniendo el historial de cambios del repositorio) para facilitar el conocimiento de los cambios de mejoras o seguridad, con la siguiente estructura (o similar):
<año>-<fecha>-<dia> (<evento> o <autor del cambio>:

  * cambio realizado o comentario sobre el código publicado.

ejemplo (http://ftp.gnu.org/gnu/denemo/denemo-0.8.12.tar.gz/ChangeLog):

2010-01-01 Release 0.8.12:
  * MIDI playback by internal synth (Fluidsynth)
  * MIDI input available from all platforms (using Fluidsynth)
  * Uses latest LilyPond version
  * New Paste command Paste Command Script
  * Adding movements keeps the staff/voice arrangements of the current movement.
  * Find routines. Find next note lower than cursor.
  * Support for wheel-mouse
  * Rhythm entry now creates non-printing notes until pitches are applied
  * Metronome markings for any duration, slur direction control, memorize and return to the cursor position,
  * Set up multiple JACK output devices with multiple ports on each. Assign staffs to these device/port names.
  * Bug fixes: cursor position on directives

2008-07-17 <rshann>
   * view.c more internationalization fixes, and minor improvements to tooltips.
   * denemoui.xml apply RR's fix for order of menu items.

2008-07-17 <jjbenham>
   * exportlilypond.c prints out more info in /paper properties on music excerpt
  • Los manuales de la aplicación preferentemente deben publicarse con licencia GPL FDL, con el historial de actualización del mismo al final del documento. Para la incorporación de materiales como imágenes, materiales audiovisuales, portal web y logos se recomienda la implementación de licencia Creative Commons 3.0 Unported (original en inglés por razones similares de defensa legal internacional más la traducción no oficial para uso local).
  • Debe generarse un archivo README en la base del proyecto con la información general de los pasos para ponerla en funcionamiento, aplicaciones o configuración de ambiente requerido. Así también el archivo puede referenciar a un portal donde se tenga actualizada la información o de origen de la aplicación.
  • Una vez completados los ítems anteriores puede ser disponibilizado el proyecto en algún medio accesible sin restricciones físicas, técnicas o legales fuera de las herramientas propias de un desarrollador o internauta estándar (navegadores, herramientas de descarga o compartición).

Razones y ventajas del uso de la licencia libre GNU GPL en un proyecto de software

  • Las infraestructuras cerradas de desarrollo de software como un equipo de software de una empresa, pueden desarrollar herramientas, a partir de herramientas de software libres ya disponibles en el mercado, sin restricciones más allá de las limitaciones de las licencias (“compartir igual”).
  • Las licencias virales (las que condicionan la utilización de la misma licencia a los productos derivados del original) como las GNU, en detrimento a las MIT/BSD o el Dominio Público, favorecen la evolución de las herramientas liberadas, posibilitando tanto el desarrollo de nuevas herramientas en la comunidad a partir de la liberada, como la retroalimentación a la herramienta con la participación de más personas involucradas en el desarrollo como en la puesta a prueba de la misma.
  • El uso de licencias libres en los productos favorecen a que los usuarios finales participen más activamente en la corrección de errores, o aportando nuevas ideas para incorporarlas al producto.
  • Involucrando a más personas en el desarrollo se fuerza no solo a utilización de estándares en el desarrollo de las herramientas, sino también a la incorporación de técnicas de desarrollo más eficientes, optimizadas y robustas, como la prueba en situaciones que un equipo de desarrollo cerrado no podría prever (mal uso de la herramienta por parte de los usuarios, mala configuración, recursos informáticos menores o ampliamente mayores), los que no se pensaría o no se tendría acceso (redes distribuidas).
  • La institución y los miembros originales involucrados en el desarrollo se convierten en referentes de la comunidad técnica y la sociedad. Siendo invitados a formar parte de proyectos o redes de proyectos de gran trascendencia o participando como oradores en talleres, charlas y conferencias sobre desarrollo social sostenible.

Referencias:

KSEltar
20130716181900

Unless otherwise stated, the content of this page is licensed under GNU Free Documentation License.