ingenieria Cómo iniciar un proyecto de software libre
Por François Marier:
Empezar un proyecto de software libre y ponerlo a disposición de la
comunidad puede ser confuso la primera vez para los desarrolladores de
software. Sin embargo, hay un par de cosas que vale la pena saber, que
te ayudarán a atraer a más usuarios y a incrementar la probabilidad de
que tu software sea parte de una distribución libre como Debian.
Idea, nombre y licencia
Lo más importante es que un proyecto de software libre empieza con una
idea. Ésa es la razón por la cual escribes el software en un primer
momento. La cosa se empieza a poner interesante cuando piensas que tu
software le podría ser útil a otras personas. Aquí es cuando deberías
empezar a pensar en compartir tu código.
Desde luego que una de las primeras decisiones que necesitarás hacer es
elegir un nombre para tu proyecto. Seguro que esta es una decisión muy
personal, pero si estás luchando por encontrar algún nombre excitante y
a la moda, puedes considerar escoger algo que:
* ya no esté en uso,
* que sea fácil de recordar y
* que dé una idea de lo que va el proyecto.
Otra decisión que necesitas tomar antes de tu primera liberación es la
licencia. Puede que esto no te sea familiar o interesante pero te
recomiendo encarecidamente que consideres cuidadosamente tus opciones,
pues la elección de tu licencia puede influir en el tipo de comunidad
que se formará en torno a tu proyecto.
Liberación pública
Hacerle publicidad a tu proyecto puede ser tan simple como dejar caer un
tarball (NdT: denominación de archivos comprimidos en tar) en una lista
de correo. De todas formas, si quieres que se enteren de tu proyecto
todos los usuarios a los que les podría ser útil, hay unas cuantas cosas
que podrías querer hacer.
Una de estas cosas es darle un sitio en internet a tu proyecto. Esa
página debería dar acceso a todos los servicios relacionados con tu
proyecto. Tales servicios generalmente incluyen un control de las
fuentes, un servicio de reporte de fallos, listas de correo y un área de
archivos. Tengo algunas ideas de lo que la página debería contener más
adelante pero lo primero es lo primero, así que echémosle un vistazo a
lo que debería contener el tarball.
Contenidos del tarball
La mayoría de la gente que descargue tu código fuente serán tanto los
usuarios finales como los mantenedores de distribuciones. Esto es lo que
estarán buscando:
* Código fuente completo incluidos los archivos de datos necesarios
para usar tu software.
* Guía de instalación, explicando cómo compilar e instalar tu
proyecto en una de las plataformas soportadas. Generalmente a este
archivo se le pone el nombre de INSTALL.
* Una guía de inicio rápido. Generalmente es parte del contenido
del README y debería proveer a los nuevos usuarios de todos los comandos
o instrucciones para trabajar con tu software en uno o dos minutos.
* Una copia completa de los términos de la licencia, generalmente
en el archivo denominado COPYING.
* Información de contacto para las ayudas o contribuciones. Los
pequeños proyectos compartirán, generalmente, la dirección de correo del
autor principal y un enlace a la página del proyecto, si está
disponible. Tradicionalmente esta información se localiza en el archivo
AUTHORS o directamente en el README.
Esto es poco más de lo mínimo que necesitas proveer en la liberación de
tu código para que sea útil y legalmente distribuido por otras personas.
Hay unas cuantas cosas más que deberías tener en cuenta si quisieras
incrementar la probabilidad de que tu software se incluya en una
distribución de software libre.
Después de juntar todo esto, deberías estar listo para la liberación
pública inicial de tu proyecto y dar el siguiente paso: apoyando a tu
creciente comunidad.
* Fuentes:
o
http://feeding.cloud.geek.nz/2008/09/starting-free-software-project.html
libre Escoger la licencia apropiada para tu proyecto de software libre o
código abierto
Por François Marier:
Escribir el software sólo es una parte del éxito de un proyecto de
software libre. Si quieres construir una comunidad en torno a tu
proyecto preferido, hay algunos asuntos importantes que necesitas hacer
pero que, típicamente, caen fuera del trabajo de «hacer código». Una de
estas tareas es escoger una licencia.
La elección de una licencia es muy personal por implicar poner por
escrito los permisos y protecciones que quieres para tu código. Sin
embargo, tu elección tendrá varias implicaciones.
«Una licencia puede arruinar una perfecta porción de software»
Jon Stevens
Siempre que sea posible, trata de evitar:
1. escribir tu propia licencia
2. escoger una licencia incompatible con la GPL
Para asegurar que tu proyecto se puede incluir en una distribución de
software libre como Debian, y hacer que tu código sea lo más útil
posible para los demás, es muy recomendable que escojas una licencia
estándar. Las más comunes son: GPL, LGPL, licencia BSD Modificada y la
licencia Apache. Puedes encontrar una lista más exhaustiva en la página
de la Free Software Foundation.
La comunidad entiende bien las licencias comunes y éstas han superado la
prueba del tiempo. Su compatibilidad con otras licencias también está
muy clara. Esto es importante si quieres que tu código pueda ser usado
en otros proyectos, pero también si quieres incluir código de otras
fuentes en el tuyo.
Las licencias estándar también están mejor comprendidas en el ámbito
internacional. La última versión de la GPL, por ejemplo, fue revisada
por abogados de todo el mundo. En cualquier caso, no es probable que te
importe tal nivel de control. Si crees que las licencias existentes no
satisfacen tus necesidades, escribe a [email protected] para discutir tu
situación y evitarte problemas.
Tomate un tiempo para familiarizarte con las licencias comunes y luego
decide qué protecciones le quieres dar a tu código. A continuación,
añádele esto a tu tarball antes de publicar tu código fuente en internet:
1. una copia de la licencia
2. una clara declaración de derechos de autor (copyright) en un
archivo como el README
Aquí tienes un ejemplo de declaración de derechos para una porción de
software bajo la última versión de la GNU General Public License: (NdT:
La dejo en inglés por ser la forma más común de encontrarla)
«Email-Reminder - Receive emails for events like birthdays and
anniversaries Copyright (C) 2004-2008 by Francois Marier ([email protected])
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 (at your
option) 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/ .»
Esto obliga a los distribuidores y contribuidores a establecer
explícitamente la versión de la licencia, así como el nombre y datos de
contacto del titular del derecho de autor.
* Fuentes:
o
http://feeding.cloud.geek.nz/2008/05/choosing-right-license-for-your-new.html
anuncio Promocionando tu proyecto de software libre
Por François Marier:
Después de gastar una considerable cantidad de tiempo liberando tu
proyecto de software libre al público, probablemente querrás estar
seguro de que llegue a la mayor cantidad de gente posible y así, ser de
mayor utilidad. Aquí tienes algunas cosas por las que puedes empezar.
Página web: ¿Es este software para mi?
La primera cosa en la que probablemente pensarás es en crear una página
web para promocionar tu proyecto. Hay muchos consejos por los que te
puedes guiar para crear una página web efectiva, pero aquí me centraré
en los contenidos que deberías incluir.
Los pantallazos son uno de los elementos más importantes que puedes
incluir en tu página. Los que te visiten por primera vez sólo gastarán
unos segundos antes de decidir si la información les interesa o no.
Tienes que ser capaz de resumir en unas cuantas imágenes la temática de
tu proyecto.
¿Estarías dispuesto a leer extensas páginas o a seguir muchas
instrucciones sólo para enterarte de que el software no se adapta a tus
necesidades? Probablemente no. Asegúrate de que puedes ayudar a los
usuarios a que capten la idea en unos segundos, aunque ni siquiera tu
software tenga una interfaz gráfica.
Seguramente también querrás describir el proyecto en pocas palabras y
mostrar los enlaces al código fuente y otros servicios que puedas tener
disponibles.
Opciones de alojamiento
Dónde poner tus contenidos es una elección personal pero hay unas
cuantas cosas que deberías tener en cuenta.
Lo primero de todo, dependiendo del tamaño de tu proyecto y los datos
relativos, el lugar de alojamiento podría tener que necesitar una gran
cantidad de espacio y ancho de banda. Además, debes comprobar que el
proveedor del alojamiento recoja las estadísticas de las descargas.
Aunque no sea estrictamente necesario, ¡puede ser muy motivador ver como
crecen esos números!
Los sitios de alojamientos de software libre como Google Code, Source
Forge y LaunchPad también proveen diferentes servicios como reporte de
errores y repositorios de control de código fuente.
Hay gente que prefiere un enfoque distribuido para controlar el código
fuente y los temas de seguimiento para evitar tener que confiar a
terceras personas su copia principal de los datos. Configurar un
repositorio de código separado en sitios como Github o Gitorious es una
opción a considerar.
Todos estos proveedores de alojamientos promocionan el software que
alojan de distintas formas. Compara las distintas opciones antes de
decidir donde debes aparcar tu proyecto.
Anunciar tu liberación
Finalmente, ¿qué sería un sitio web sin enlaces desde otros sitios? El
lugar obvio por donde empezar sería los principales motores de
búsquedas, pero eso de por sí es probable que no mejore demasiado el
tráfico, por lo menos en los primeros días de tu proyecto.
Los sitios dedicados al software libre tienen más posibilidades de
atraer más visitantes a tu brillante proyecto. El lugar más famoso con
las novedades en liberaciones de software libre es Freshmeat. Visites o
no regularmente este sitio, deberías saber que sus contenidos son
ampliamente leídos y sindicados; y no deberías dejar pasar esta gran
oportunidad para hacer saber de tu software.
Otros directorios que podrían ser de tu interés son Free Software
Foundation Directory y Ohloh (especialmente si quieres ofrecer un
servicio de repositorio para tu código fuente).
Ahora que das a conocer tu software, ¡es hora de empezar a pensar en
cómo apoyar a tus nuevos usuarios!
* Fuentes:
o
http://feeding.cloud.geek.nz/2008/09/promoting-your-free-software-project.html
comunidad Hacer crecer la comunidad alrededor de tu nuevo proyecto de
software libre
Por François Marier:
Una vez que tu nuevo proyecto de software libre ha tenido cierta acogida
y está ganando usuarios, probablemente querrás ampliar su página web
inicial con algunos servicios extra. Sin embargo, los aspectos más
importantes de gestionar una comunidad de software libre están más
relacionados con los seres humanos.
Interacciones sociales en pequeños proyectos
En los primeros tiempos de tu proyecto, las solicitudes de apoyo
generalmente sólo venían a través de correos personales al desarrollador
más importante. Para construir tu comunidad, tienes que hacer que los
nuevos usuarios se sientan bienvenidos:
* Sé amistoso e informal en tus respuestas. Coloca el nombre de la
persona al principio de tus correos.
* Sé rápido y positivo en los comentarios y solicitudes de ayuda.
La mayoría de los desarrolladores de software libre están bastante
ocupados por lo que se trata de que el usuario sepa que le responderás y
agradécele sus sugerencias y comentarios. Muy pocas personas se toman la
molestia de contactar con los autores para indicarles sus problemas. Es
importante apoyar a los que lo hacen.
* Mantén la calma cuando respondas a comentarios negativos. Ayuda
mucho tomarse un día entero para pensarse la respuesta antes de
responder. Agradece los comentarios, pero recuérdales que no estás
cobrando por el trabajo de este proyecto y que lo haces por diversión en
tu tiempo libre. Algunos usuarios parece que se olvidan de esto.
Más herramientas para proyectos en crecimiento
Como tu proyecto crece y manejar todos los problemas reportados empieza
a ser una gran carga, considera dos cosas: documentación y soporte
distribuido.
El mejor modo para empezar una guía de documentación es empezar por
reunir todas las respuestas que le enviaste a los usuarios. Este es el
significado original de una FAQ: respuestas a cuestiones reales enviadas
por usuarios reales. Rellena tus FAQ con cuestiones irrelevantes y los
usuarios no se molestarán en leerlas y luego te enviarán un correo.
Además, para proveer una buena documentación, también deberías pensar en
crear una lista de correo o un foro donde los usuarios puedan escribir
sus preguntas (Google Groups te provee de una buena mezcla de las dos
tecnologías). Este servicio tiene dos grandes ventajas:
* el soporte lo pueden realizar todos los usuarios del software
* las preguntas y respuestas son archivadas por los motores de
búsquedas
Como incluso tu proyecto puede seguir creciendo, probablemente también
estarás interesado en un seguidor de fallos y una wiki.
* Fuentes:
o
http://feeding.cloud.geek.nz/2008/09/growing-community-around-your-new-free.html
distros Conseguir que tu proyecto se incluya en una distribución de
software libre
Por François Marier:
Después de la liberación en el mundo de un nuevo proyecto de software
libre, puede que te interese verlo incluido en una distribución
importante Linux o en una distribución de software libre. Después de
todo, para los usuarios es la forma más fácil de descargar e instalar tu
software.
Aquí tienes unos cuantos detalles técnicos que incrementarán las
posibilidades de que tu proyecto se incluya en una distribución.
¿Puedo distribuir este software?
La primera cuestión que necesitarás responder a un mantenedor de una
distribución es esta: ¿Puede mi distribución incluir legalmente esta
porción de software?
Hay dos formas en las que puedes ayudar:
* Haz claramente visible tu tu licencia (normalmente en un archivo
llamado COPYING o LICENSE).
* Incluye explícitamente una copia de los derechos de autor en tu
documentación (dentro del README, por ejemplo).
Una vez que tu software pase esta prueba, la siguiente cuestión es:
¿funciona realmente?
¿Funcionará en mi distribución?
Para responder a esta pregunta, el mantenedor tendrá que instalar el
software y averiguar todas las dependencias externas necesarias.
Por tanto, tu tarball debería incluir:
* todos los pasos (y comandos exactos) que sean necesarios para
instalar tu software en una distribución estándar de software libre
* una lista de librerías externas y herramientas necesarias para
ejecutar tu software
¿Qué ha cambiado?
Otro elemento que les hace la vida más fácil a los mantenedores de tu
software una vez incluido en una distribución, es indicar los cambios de
una versión a otra.
Un detalle importante es usar un sistema simple indicador de versión. Lo
que significa:
* Los números de las versiones siempre deben ir incrementándose
(por ejemplo: en clasificación normal ASCII, 1.0pre1 viene después de 1.0).
* Cualquier cambio en los contenidos del tarball debe hacer cambiar
la versión.
* La diferencia en los números de versiones, entre una versión y la
siguiente, debe ser indicativa de la magnitud del cambio (menor o mayor).
Otra cosa que debes incluir es una lista de cambios (normalmente en un
archivo denominado CHANGES o CHANGELOG) (NdT: en los comentarios indican
que ahora este archivo se suele llamar NEWS). Este documento lo usarán
los mantenedores para decidir cuando actualizar a una nueva versión y
averiguar los errores corregidos en la nueva versión. Debe contener:
* una fecha de la liberación
* número de versión
* índice de los cambios desde la última versión
Finalmente, para asegurar que los mantenedores de una distro no se
olviden de las nuevas versiones de tu software, registra tu proyecto en
Freshmeat y anuncia las nuevas versiones.
Proponer tu paquete a las distribuciones
En Debian, la principal forma que tienen los usuarios y desarrolladores
de programas de sugerir la inclusión de paquetes en el archivo, es a
través de Debian Bug Tracking system. Los errores se llenan de
pseudo-paquetes especiales wnpp (paquetes en espera o que necesitan ser
trabajados) (NdT: Work-needed and Prospective Packages) y que son
nombrados con algo como «RFP: superfoo -- bringing more foo to the
desktop», donde RFP significa solicitud de paquete (NdT: Request For
Package).
Otra alternativa, si eres un usuario de Debian/Ubuntu, puede ser que
quieras construir y mantener el paquete por ti mismo. En tal caso,
necesitas encontrar un patrocinador (NdT: sponsor).
Otras distribuciones tienen diferentes procedimientos. Puedes dejar un
comentario explicando cuáles (nota).
En la wiki de Debian puedes encontrar información más detallada de cómo
conseguir paquetes para Debian.
(nota) Abhishek dejó el siguiente comentario explicando el procedimiento
para Arch:
Para Arch, los pasos para hacer paquetes son muy simples, sólo necesitas
hacer un PKGBUILD que contiene una función build() para construir el
paquete. Una vez hecho un PKGBUILD, lo puedes enviar a AUR. Si consigue
suficientes votos (o le gusta a un usuario de confianza, conocidos como
TU), será adoptado y movido al repositorio binario community.
* Fuentes:
o
http://feeding.cloud.geek.nz/2008/09/getting-your-project-included-into-free.html
Tomado de
http://www.esdebian.org/foro/30037/noticias-proyecto-debian-software-libre-edicion-esdebian
_______________________________________________
Cancelar suscripción
https://listas.softwarelibre.cu/mailman/listinfo/linux-l
Buscar en el archivo
http://listas.softwarelibre.cu/buscar/linux-l
