Ejecuto el proceso en Yahoo (y ocasionalmente chateo con las personas que ejecutan procesos similares en Facebook, Google, Twitter y otros lugares). No me gusta hacer que los desarrolladores salten a través de los aros, la mayoría de ellos eluden ese tipo de aros de todos modos. En cambio, proporciono un servicio de revisión. Verá: una vez que publique el código como código abierto, todos en el mundo podrán verlo. Simplemente insisto en verlo de antemano. ¿Por qué? Porque si hay un problema con el código, puedo arreglarlo o bloquearlo antes de que salga.
¿Qué tipo de problemas hay con el código fuente abierto? He visto muchos tipos diferentes, desde errores ligeramente vergonzosos hasta errores increíblemente costosos. Algunos problemas causan riesgos para la empresa, algunos para el empleado. Limpiarlos en público no es divertido. He estado haciendo este concierto durante un par de años y encuentro nuevos problemas todo el tiempo. Entonces, mi trabajo es hacer un proceso de revisión que sea tan simple e indoloro que los desarrolladores deseen solicitar mi revisión, ya que preferirían asegurarse de que alguien revisó su código una vez más antes que el resto del mundo.
¿Qué pasa si eluden el proceso? Asumen riesgos. Si siguen el proceso, reducen el riesgo. Por lo tanto, siempre que pueda acceder a su código rápidamente, no me ven dando saltos, les aseguro. Una buena parte de mi día lo paso ayudando a los grupos a publicar código (en proyectos Apache, OpenStack, revistas científicas, marcos de prueba, módulos NPM, código relacionado con la seguridad, código de aplicación móvil, código de almacenamiento, código de detección de anomalías, lo que sea). Apruebo la mayoría del código que reviso. En los casos en que no lo hago, explico por qué la publicación sería un problema (y generalmente recibo un agradecimiento de la persona que no se dio cuenta de que había un problema). A veces podemos solucionar el problema, a veces simplemente no vale la pena. Pero la mayoría de las veces la aprobación es bastante simple (generalmente sugeriré o insistiré en algunos cambios, y luego ayudaré a configurar el repositorio y los permisos). A veces es complicado y, a veces, alguien se enoja conmigo por retrasarlo o impedir que hagan lo que quieren. Hago todo lo posible para ser útil, y las personas pueden quejarse o enviar complementos a mi gerente.
- ¿Cuáles son algunos buenos trucos de productividad para trabajar en una MacBook Pro?
- ¿Qué podría haber sido una alternativa a los "archivos" tal como los conocemos hoy?
- Siento que no puedo entender la codificación, ¿debería rendirme y encontrar otro interés?
- ¿Cuáles son las diferentes funciones de los sistemas operativos Windows 7, 8 y 10?
- ¿Vale la pena sacrificar todo para convertirse en un desarrollador de software?
Si una empresa de tecnología no tenía ningún proceso, y permitía que cualquiera publicara algo (como hacen algunas empresas), creo que asumen demasiado riesgo; especialmente una gran empresa tecnológica con bolsillos profundos. Simplemente están invitando a trolls de derechos de autor y partes legítimas para demandarlos, ya que les aseguro que si no tienen cuidado, harán cosas que infrinjan las licencias de código abierto y los derechos de autor. Si no permiten que nadie publique nada, probablemente nieguen que los desarrolladores publiquen código. Sin la orientación adecuada, probablemente lo estén haciendo mal. Entonces, un proceso de revisión simple es la forma más sensata de hacerlo. Sé que he ahorrado a Yahoo muchas más veces mi salario en costos potenciales relacionados con publicaciones de código abierto (y espero que lo recuerden cuando se trata de tiempo extra ;-).
¿Cómo se ve el proceso? Es un boleto de Jira (solía ser un boleto de Bugzilla) y le pedimos al solicitante que ingrese la información pertinente sobre el código (quién escribió el código, dónde puedo ver el código, cuál es su objetivo de publicación, ¿usamos este código? en producción, se prueba, documenta, revisa el código, ¿depende o utiliza otro código fuente de terceros? De ser así, ¿bajo qué licencias publicaremos una publicación de blog sobre esto? ¿Quién mantendrá el código? ¿Alguien más? que el solicitante se preocupa por este código? etc.). Recibo el boleto: yo o alguien de mi equipo virtual mira la información, el código, etc. Dependiendo de muchos detalles, podemos contactar al solicitante para obtener más información. Finalmente, cerramos el ticket y todos los que lo copiaron reciben un correo electrónico con los próximos pasos para la publicación.