¿Qué le impide trabajar abiertamente?

Trabajo para una empresa de código abierto en un proyecto de código abierto y todavía me encuentro a diario que las personas que están trabajando en el software de código abierto prefieren trabajar en privado (de vez en cuando). No discuten cuestiones técnicas sobre las listas de correo públicas, la conversación normal, se hace en las salas de chat internas en lugar del IRC público, y las nuevas características son más bien demostradas en canales de vídeoconferencia privadas como por ejemplo, Hangout on Air. Por supuesto, hay buenas razones por las que la comunicación tiene que ser en privado: si los clientes o los datos de los clientes están involucrados, entonces (sobre todo para una empresa pública) se necesitan conversaciones privadas. De forma similar para las cifras de ventas u otros aspectos financieros. Aunque la realidad es que los ingenieros la mayoría de las veces no hablan sobre cifras de ventas. Y la mayoría de los casos de los clientes son sólo problemas de softwaregenerales que se pueden discutir abiertamente mientas que no se mencione el nombre del cliente. Lo que me lleva a la pregunta de por qué las personas no están colaborando abiertamente, sobre todo cuando el código fuente resultante se publique en un repositorio público como GitHub.

El miedo a la fuga

Cuando se trabaja con los clientes, siempre hay grupos como la atención al cliente que no pueden trabajar abiertamente, lo que significa que no se unen a los canales de IRC públicos, sino a privados para mantener los datos de los clientes en privado. Los ingenieros que trabajan en este tipo de casos de clientes siempre pueden tener un miedo latente a que al discutir los detalles del caso puedan filtrarse datos de los clientes y los debates sobre ellos siempre suceden en los canales internos, no importa si cualquier cuestión específica del cliente se discute o no. Lo que me lleva al siguiente punto.

El esfuerzo de selección y conmutación

Cuando se trabaja en los canales internos con datos relacionados con los clientes (y porque los respectivos colegas sólo están disponibles de esa manera), uno tiene que pensar y decidir si un determinado mensaje puede ir a los canales públicos o no constantemente. Uno puede entender que este tipo de comentarios de casos se realizan en los canales internos y para conseguir un flujo coherente de pensamiento se debe permanecer en el canal interno. Las conversaciones sobre otros temas no relacionados con los clientes deben, al contrario, ir a los canales públicos, lo que significa cambiar de canal todo el tiempo. Dicha selección y conmutación de canales sin duda es un esfuerzo que la gente trata de evitar.

Incertidumbre

También puede haber casos en los que los ingenieros están trabajando en una solicitud de función o un fallo (bug) de un cliente que no es específico de cualquier cliente en absoluto. Y todavía hay una incertidumbre persistente sobre si el trabajo puede ser discutido abiertamente o no. Así que en caso de duda la discusión ocurre nuevamente en privado.

El miedo a la distracción

Mientras que la contribución comunitaria es (se dice que es) siempre bienvenidas, también puede ser visto como una fuente de distracción. Un miembro central de un proyecto posiblemente tenga que interrumpir su trabajo, empezar a pensar en el punto de vista del miembro de la comunidad, y luego volver al trabajo anterior. Esto puede ser de vez en cuando una distracción, especialmente cuando se tienen algunos lanzamientos programados (time boxed releases), por lo que esto puede no ser bienvenido.

La percepción de falta de beneficio

Nuestro proyecto tiene una parte bastante pequeña de la comunidad, lo que puede plantear la pregunta ¿por qué discutir las cosas en público si nadie parece interesado? ¿Por qué pasar a través de todos los aros anteriores? ¿Un árbol realmente cae en el bosque si no hay un observador?

La falta de confianza en sí mismo

Otra posible razón puede ser un miedo a la rendición de cuentas y la trazabilidad. Esto puede sonar gracioso en un primer momento dado que el código fuente termina en el repositorio público. La causa subyacente aquí puede ser una falta de confianza en uno mismo. Las discusiones en público que se registran como registros de chat, los vídeos de demostraciones de funciones, o las entradas de una bitácora permiten que otros den retroalimentación crítica y puede hacer que la persona se sienta insegura. Yo soy un firme creyente de que el trabajo en el abierto es bueno. Incluso con una pequeña comunidad. Hacer el trabajo abiertamente permite obtener el aporte de los miembros de la comunidad, lo que enriquece el conocimiento del dominio del problema. Otros dan una perspectiva totalmente diferente y, probablemente, indiquen casos de uso en los que nunca ha pensado. Además, si los miembros de la comunidad se incluyen en la comunidad en general, se sienten mejor y empezar a contribuir más. Para obtener ideas sobre cómo contribuir en formas distintas de código, vea el artículo: 10 maneras de contribuir a un proyecto de código abierto sin necesidad de escribir código.

Mis encuentros con miembros de la comunidad han sido muy buenos, como todo el mundo es muy amable y reunirse con miembros de la comunidad en persona es siempre divertido. Entonces, ¿qué podemos hacer para superar los obstáculos que he enumerado anteriormente?

  • En primer lugar, establecer una política sobre que toda comunicación tiene que estar en los canales públicos de forma predeterminada a menos que existan buenas razones en contra.
  • Recuérdese a sí mismo comenzar el día en los canales públicos. Cuando se se empieza allí, se establece una especie de defecto para uno mismo. Y anima a otros a charlar allí también, por lo que la construcción de una masa crítica para conseguir que las conversaciones continúen.
  • Recuerde a la gente de vez en cuando acerca de la política anterior.
  • Disocie la información del cliente de la información técnica tan pronto como sea posible. Tal vez directamente en el nivel de la persona de soporte. Un NullPointerException es un NPE no importa si es reportado por un cliente que paga o por un miembro de la comunidad.
  • Registre los canales públicos para que los miembros de la comunidad tengan la posibilidad de volver a leer lo que se discutió.
  • Si tiene que trabajar en silencio, entonces no deje fuera únicamente a la comunidad externa. Interrumpa las comunicaciones externas, haga su trabajo y luego regrese – la distracción es una distracción, no importa si proviene de otra persona de la comunidad o de un compañero de trabajo.
  • Si se siente incómodo escribiendo (por ejemplo, una entrada de bitácora que explica su trabajo o una nueva característica) primero pásasela a otra persona de tu confianza. A menos que usted ni siquiera intente ofrecer un buen resultado, no hay mensajes malos. La mejor comunidad siempre agradece cualquier información adicional.

Traducido del original en inglés: http://opensource.com/business/14/10/why-work-open