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