¿Es recomendable pedir a los empleados que creen cuentas de GitHub "de trabajo"?

Si hubiera un beneficio, simplemente sería doloroso. Pero nada apesta más que doloroso e inútil. Sólo tienes la cuenta personal única. Dos razones:

• Github tiene un control de acceso increíblemente bueno en sus organizaciones. Si un empleado se va, puede eliminar instantáneamente su acceso. Si tuvieran una cuenta de la empresa, tendría que reclamar la cuenta de alguna manera para obtener los beneficios declarados. En la práctica, es probable que solo elimines el acceso a la cuenta, como si tuvieran una cuenta personal.

• Tener más de una cuenta es doloroso. Iniciar sesión y cerrar sesión entre cuentas duele, y agregar comentarios, a continuación, y todas las cosas sociales cuando usas diferentes cuentas.

Referencias: hago un servidor CI con integración de GitHub , así que tengo muchas cuentas de prueba, y he hablado con clientes con todo tipo de configuraciones extrañas, incluyendo cuentas de trabajo separadas y cuentas personales. Siempre lleva a problemas.

¿El código de su empresa está en repositorios públicos o privados? Si ellos (o al menos algunos) son públicos, y usted permitió que sus empleados usaran sus propias cuentas de GitHub, sería un incentivo para que escribieran un buen código. Su nombre literalmente se adjuntará públicamente. Sin embargo, asumiré que todos tus repositorios son privados.

En general, parece que preferirías que las cuentas de tus empleados no sean visibles públicamente en todo GitHub. Desafortunadamente, ganan dinero vendiendo GitHub Enterprise , así que me imagino que esa es una de las razones por las que no te permiten crear cuentas privadas para organizaciones. En cualquier caso, tener (esencialmente) cuentas de trabajo bloqueadas sería realmente contraintuitivo después de elegir un sitio muy social para alojar tus repositorios.

Imaginemos que configuró cuentas de trabajo para sus empleados. ¿Haría cumplir alguna restricción sobre cómo pueden usar esas cuentas? ¿Les permitiría contribuir con código a proyectos que no son de trabajo con fines laborales? Si es así, entonces sus cuentas se volverán públicamente visibles y le devolverán a su preocupación inicial. Puede simplemente permitirles que hagan las contribuciones con sus cuentas personales, pero luego está creando un punto logístico para ellos. Personalmente, animaría a mis empleados a contribuir con código a otros proyectos como ellos mismos. Esto no solo les da un impulso de confianza, sino que les permite adquirir una experiencia valiosa y desarrollar su credibilidad.

En cualquier caso, no creo que valga la pena el esfuerzo de tener cuentas de trabajo. La interfaz de GitHub te permite controlar fácilmente quién tiene acceso a qué, por lo que eliminar el acceso es simple de cualquier manera. Tampoco creo que tener cuentas separadas realmente "dibuje una línea" entre los proyectos personales y de trabajo más de lo que ya lo hace la interfaz de GitHub.

Además, tenga en cuenta cómo planea lidiar con esto a medida que su empresa crezca. ¿Las políticas que establezca ahora serán escalables desde un punto de vista de gestión? Administrar 5 cuentas en este momento podría estar bien, pero ¿qué sucede cuando aumentas a 20 o 50? Pero una vez que llegue a ese punto, tal vez GitHub Enterprise sea una solución accesible. En ese caso, consideraría averiguar si las cuentas de GitHub se pueden migrar a las instalaciones de GitHub Enterprise. Si es así, puedo ver que es una razón positiva para tener cuentas de trabajo.

No está fuera de cuestión, y en realidad es una buena idea.

Por lamentable que sea, debe planificar que sus empleados abandonen la organización en algún momento de la vida de la empresa. ¿Cómo va a sacar sus cuentas personales del repositorio de la compañía en ese momento?

¿Qué vas a hacer si el empleado se va en malas condiciones? En un mundo ideal, todo seguirá siendo profesional y no habrá ninguna animosidad entre la empresa y el ex empleado. Sería prudente planificar para circunstancias menos que ideales.

Aunque mantener dos cuentas es un dolor, sus empleados deberían agradecer la oportunidad. Proporciona una línea más limpia entre lo que es suyo y lo que es de la empresa.

Editar: Lo preocupante aquí es proporcionar una clara separación entre las contribuciones personales del empleado a los proyectos X, Y, Z, etc., y su trabajo pagado en el producto de su empresa. El uso de una cuenta de trabajo separada ayuda a proporcionar la delimitación necesaria para identificar quién posee qué propiedad intelectual y los derechos de autor asociados.

Por ejemplo, si un empleado utiliza su cuenta personal y contribuye tanto a la empresa como al Proyecto X, ¿cómo identifica en qué momento se desempeñó el empleado en esos momentos? ¿Fue la contribución a X en nombre de su empresa o su propia discreción personal? ¿El empleado o la empresa posee los derechos de autor de ese trabajo otorgado a X? En este caso, si permite contribuciones externas al trabajo de su empresa, ¿cómo distingue si el empleado era un empleado o si fue una contribución voluntaria?

En un sentido más amplio, supongamos que tiene un empleado que se construye una reputación que actúa en nombre de la empresa al contribuir a otros proyectos. Cuando ese empleado se retira, ¿cómo indica que la cuenta de usuario personal ya no está asociada con su empresa? Pueden ocurrir problemas graves de marca sin una descripción clara de para qué es una cuenta en particular.

Cuando empiezas a pensar en los posibles escenarios, es bastante fácil caer en un rastro de conejos de propiedad, marca y derechos de autor. Usar cuentas de trabajo separadas ayuda a eliminar algo de esta ambigüedad. La empresa debe poder reclamar las contribuciones hechas en su nombre.

No se trata de los aspectos técnicos de la separación de la cuenta de usuario, son las preguntas legales las que pueden hacerte tropezar.

Tenga en cuenta que esto puede ser un punto discutible si todos los productos de su compañía se publican como código abierto bajo licencias permisivas y / o no están preocupados por los posibles problemas de marca.
(Hat tip a Paul Biggar para solicitar esta edición)

Como todos parecen estar de acuerdo con la falta de necesidad del empleador de separar a los dos, aquí está mi corta experiencia al haber intentado usar mi cuenta personal en proyectos profesionales y contribuciones de código abierto realizadas en el contexto del trabajo.

Solo para completar el contexto: no me preguntaron nada con respecto a las cuentas, en realidad GitHub es desconocido para la mayoría de las personas en mi lugar de trabajo. Simplemente pude obtener luces verdes para el código abierto del proyecto en el que voy a trabajar y obtuve la menor cantidad de trabajo, es decir, utilizando mi cuenta personal.

Desde el punto de vista de un empleado, hay una cosa que realmente odio: recibir notificaciones en mi correo electrónico personal para el trabajo.

A partir de esa observación, me di cuenta de que es una ruptura flagrante de la barrera profesional / personal: si quiero contribuir a un proyecto en mi tiempo libre, todavía recibo todas las actualizaciones de mis proyectos de trabajo ... Y puede traer confusión. para colaboradores externos, quienes podrían contactarlo sin saber que está fuera del proyecto .

Entonces, por supuesto, hay un equilibrio para encontrar con el hecho de que su reputación personal puede ganar con sus contribuciones laborales. Pero, de nuevo, podría ser lo contrario si su nombre se asocia con un proyecto deficiente ...

Al final, a medida que la pregunta se hace desde el punto de vista de empleador , y considerando todas las demás respuestas, diría que probablemente no tenga mucho sentido aplicar el trabajo - cuentas dedicadas . Pero no debe prohibirlo, para que los empleados que prefieren levantar la barrera personal puedan hacerlo, y tal vez insinúen sobre esos riesgos ...

Como nota adicional, con respecto a la seguridad, ya que parece haber un fácil despido en otras respuestas:

Por supuesto, una cuenta de "trabajo" no sería más o menos segura que una cuenta "personal" con respecto a las contraseñas. Pero cuando estás usando GitHub, puedes presionar con una clave SSH. Y esa clave generalmente se encuentra en la sesión de uno ... Entonces, la cuenta personal puede comprometer a todos los repositorios de trabajo con un simple robo de computadora personal (sin el conocimiento de la contraseña), mientras que una cuenta de trabajo dedicada probablemente tendría su clave solo en la máquina de trabajo, por lo que más seguro físicamente (con suerte).

Yo votaría "No". Es bastante complicado para sus desarrolladores y le brinda seguridad en la oscuridad: si alguien está apuntando activamente a sus desarrolladores, hay muchos otros vectores de ataque para que alguien obtenga su código.

Además, como inicio, a menos que tenga muchos algoritmos mágicos de tipo salsa secreta en juego, alguien que obtenga su código sería vergonzoso, terrible y desagradable, pero no debería dar como resultado una ventaja competitiva significativa (quién podría ¿Utiliza legalmente su código?) o lo hace salir del negocio.

¿Tan baja probabilidad de orden vs. productividad del desarrollador? Tomaría la productividad del desarrollador, pero ese es mi cálculo. :)

Yo diría que debería ser una elección que se deja al empleado. Una cosa que diría es que no los obligue a usar su cuenta personal de github si no lo desean. Estaba en una empresa que usaba GitHub y aunque no era un requisito, personalmente quería crear una cuenta separada. La razón principal fue para proteger los proyectos de mi persona. No quería que la compañía tratara de decir que uno de mis proyectos personales era suyo, porque estaba en la misma cuenta de github que usaban para sus proyectos cómodos (no estoy seguro de si eso se vería en los tribunales, sin embargo, no tengo mucha fe). en el sistema legal cuando se trata de cosas como esta). Creo que tener esa limpieza separada puede ser algo bueno.

Lo estamos haciendo en nuestra empresa. No quiero iniciar una discusión "qué es más seguro, github o un servidor debajo de su mesa que todos tengan acceso de root, no estoy seguro de si la copia de seguridad está funcionando, etc.". Nuestro enfoque fue:

• cada desarrollador, debe crear una nueva cuenta, no relacionada con su cuenta de github personal
• debe utilizar el correo electrónico de la empresa.
• Debe cumplir con nuestras reglas de seguridad (requisito de nombre de usuario y contraseña).
• No pueden mostrar / tener ninguna actividad pública.
• Es propiedad de la compañía. No su cuenta.
• Todas las cuentas están conectadas con una compañía, nombre aleatorio también. No hay actividad pública también.

Reconozco que esta Q & A tiene algunos años, por lo que tal vez no estaba disponible antes, pero específicamente se indican en Diferencias entre cuentas de usuario y organización que:

  

Puede ser tentador tener más de una cuenta de usuario, como para uso personal y uso comercial, pero solo necesita una cuenta.

GitHub ha creado buenas herramientas para activar / desactivar las notificaciones por repositorio y más, por lo que parece que la combinación de personal / trabajo tiene más sentido.

La gente aún debe confiar en los servidores de origen basados en la nube. Github cuenta con muchas empresas web de la nueva era que se han registrado con ellos, pero el hecho es que la mayoría de las personas tienen sus propios servidores para mantener el código fuente. En mi experiencia, la mayoría de ellos utiliza Clear-case o SVN. Git aún no se ha adaptado en un entorno empresarial. Incluso los servidores de correo corporativo no son realmente apreciados fuera de las instalaciones de la compañía.