- Lo importante de escribir documentación. No hablo de esa documentación que todos esperamos, no de esa que se genera a partir del código, ni de esa que va encuadernada de 200 páginas con imágenes obsoletas. Hablo de ese README donde están los primeros pasos para empezar con el proyecto. Aquí es donde vendes tu producto. Recomiendo una charla muy buena de jacob kalplan-moss, writting great documentation. De hecho creo que uno de los grandes éxitos de github es tener una portada de proyecto con el README renderizado desde un fichero de texto.
- Cerrar código: un código cerrado no es lo mismo que un código terminado. El típico caso de "no, es que tienes que poner el fichero XXXX.cnf en tal ruta, habilitar el puerto serie, ejecutar tal demonio, cambiar config.h y ya"
- Lo importante de testear. Si una persona quiere aportar a tu proyecto y no hay tests no podrá estar seguro de cada cambio que haga.
- Enseñar tu código te obliga a hacer las cosas lo mejor que puedes, o por lo menos no pasar por alto esas situaciones de "ya lo haré bien". Si tu quickstart son 10 comandos algo no va bien, no?
- Trabajar en un entorno distribuído. Cuando me bajo y uso jquery no tengo a john resig en la mesa de al lado, así que me las tengo que apañar como pueda para solucionar mis problemas. De la misma forma otros no me tendrán a su lado cuando empiecen a usar tus proyectos y la mejor forma de hacer esto es dejar las cosas bien (esto tiene mucho que ver con los anteriores puntos).
- "Compartir es vivir". Si tu desarrollador libera código habrá entendido que compartir es bueno para los demás y para él mismo.
Por tanto, haz que tu empresa libere código y haz que el funcionamiento interno se parezca lo más posible al sistema open source. Ya sabes, empieza por hacer que crear un repositorio y un tracker sea tan simple como en github/bitbucket y da alas a tus empleados a que suban allí su código.
