Producir Softwarede Código Abierto
buenos programas es el resultado de que un programador tenga un interés personalen ver el problema resuelto.
Fenómeno de Organizaciones
Corporaciones con fines de Lucro
Software no hace lo que debería de haceresto provoca insatisfacciones
Se comparte a todo el mundo
Como que el problema fuera la enfermedad
y el software la medicina
Distribucion de Software Libre
Usuarios
Desarrolladores
Las apariencias importan
Tener un sitio web con buena vista
Indicar claramente que es un proyecto de libre.
Escoger un buen nombre
No debe igualarse a marcas existentes
Dar idea de lo que hace el proyecto
Tener los objetivos claros
Explicar claramente lo que se quiere alcanzar
Declarar que el proyecto es libre
Mostrar que es libre
Lista de Características y Requerimientos
Estado del Desarrollo
Versiones
Beta
Alpha
Descargas
hacer tareas necesarias aunque sean tediosas.
Compilación
Documentación de ayuda
Versionamiento de los paquetes lanzados
Anunciar
Momento para anunciar
En la fase de analisis y diseño
En la fase de codificación, cuando ya se tenga algo de código
Toma tiempo antes de que se unan al proyecto
Puede ser exponencial la cantidad de personas agregadas
Ajustar el Tono
Estabilidad del Poryecto
No viene de políticas formales
Conocimiento colectivo compartido
Dificil de definir
Se desarrolla con el tiempo
Programa de Transmisión
Regular
Repetidamente
Esfuerzo de comunicación activa
Establecer buenos precedentes
Ambiente de colaboración
Evitar discusiones Privadas
Decisiones en privado es anti-voluntariado
Discuciones públicas
efectos beneficiosos
Contribución real a la conversación
Sugerencias
Toma más tiempo pero mejores resultados
Un grupo toma mejores decisiones que pocas personas
revisiones distribuidas masivas
Numerables ideas
Echar a volar la mala educación
Cero toleracia
Practicar Revisiones Visibles al código
Se obtienen mejores resultados
Ver el código de los demás
Hacer las revisiones al código algo regular
Abriendo un proyecto cerrado
Preparar a los programadores
Ser sensible ante la magnitud de los cambios
Advertencias de lo que se avecina
Criticas
Escogiendo una licenciay aplicándola
Tipos de Licencia
MIT/X
No restringe la copia, sin ninguna garatía
GPL
Restricción que no se useen código propietario
ésta es la más usada
Cómo aplicar una licencia
Exponer en la pag. principal del proyecto
Colocar al principio de cada fichero un aviso de copyright, titular, fecha y nombre de la licencia
Control de versiones y Acceso a Bug Tracker
Realizar una infraestructura de control de versiones
Disponibilidad de los paquetes recientes.
Seguimiento de los errores
Registrar y priorizar los errores
Bug-Trackers
Fallos en los programas
Peticiones de mejoras
cambios en la documentación
Tareas pendientes.
Canales de Comunicación
Direcciones de correo
Salas de Chat
Canales de IRC
Foros
Dar Feedback a todas las consultas o dudas.
Pautas de Desarrollo
Contribuir al proyecto
Pautas
Sociales
Técnicas
elementos básicos
Enlaces a foros para la interacción de los desarrolladores
Instrucciones para reportar fallos y dar parches
Indicación de como va el desarrollo
Documentación
Para que la gente lea
Debe ser constante
Es inversamente proporcional
Es muy útil para el que lo lee
No es muy útil para la que la escribe
Debe tener un formato simple
Debe tener un formato Fácil de Modificar
Limitar el Alcance
FAQ
Preguntas de desarrollo y usuarios
Consecuencia del uso diario del proyecto.
Documentación para esarrolladores
Entender el código
Arreglarlo y Extenderlo
Esta documentación es más técnica
Ejemplos de Salidas y Capturas
Ejemplos visuales de cómo funciona la aplicación
Es más fácil de explicar con una imágen
Se puede visualizar fácilmente que la aplicación funciona
Hosting Enlatado
Area web
control de versiones
Gestor de errores
zonas de descargas
salas de chat
backups regulares
Disponibilidad de la Documentación
Lugares donde debe estar
En línea
Esta debe estar toda en una páginapara facilitar la búsqueda de cualquier palabra.
En un solo documento
En la distribución descargable de la aplicación.