¿Se debe compartir el código interno con los no desarrolladores en una organización?

Donde trabajo, tenemos muchos desarrolladores y una gran cantidad de código que ejecuta nuestras aplicaciones propietarias utilizadas por el personal y los clientes por igual.

También contamos con una gran cantidad de personal de soporte inteligente al que le gusta comprender el funcionamiento interno de nuestros sistemas para brindar un mejor soporte a nuestros clientes, y tal vez incluso enviar un parche de vez en cuando.

¿Deberíamos abrir nuestro código para que nuestro personal que no es de desarrollo pueda leer? ¿Qué factores debemos tener en cuenta al tomar esta decisión? Me he encontrado con un montón de argumentos y contraargumentos en cada sentido y me gustaría tomar una decisión basada en la experiencia de los demás, así como en los riesgos bien entendidos.

Algunos argumentos hasta ahora:

• Las contraseñas en VCS están expuestas (solución: deshazte de las contraseñas, para empezar no deberían estar allí)
• El código está abierto a ataques de seguridad de caja blanca (contraargumento: esto solo mantiene fuera a los atacantes honestos / perezosos)
• El personal de soporte puede preguntar a los desarrolladores "cómo" funcionan las cosas (contador: enseñar a un hombre a pescar, etc.)

¿Alguien abre su código al personal de su organización? ¿Ha causado algún problema?

No creo que haya una respuesta general a esto. Las organizaciones difieren enormemente en su tamaño, extensión geográfica, cultura de la empresa, políticas de derechos de autor, tipo de software que se está desarrollando, etc.

Por ejemplo, para una empresa que desarrolla software de tipo de productos básicos / infraestructura, puede ser fácil abrir el código fuente, incluso abrirlo, como hizo Cisco hace algunos años con su software de controlador de impresora (IIRC).

Para una empresa que desarrolla un software propietario poco común, que puede incluir algoritmos especiales o cosas que les brindan una ventaja competitiva sobre su competencia, puedo entender muy bien si se esfuerzan por mantener su código en secreto. Por ejemplo, AFAIK Google limita muy estrictamente el número de personas a las que se les otorga acceso a su implementación de algoritmo de búsqueda central.

Además, una organización multinacional se extiende hoy en día en muchos países, zonas horarias y culturas, y por razones de seguridad, probablemente segmenten su intranet y usen firewalls para controlar el tráfico entre diferentes segmentos / dominios. Por lo tanto, hacer que un repositorio SCM sea responsable para "toda la empresa" puede, de hecho, requerir mucho trabajo adicional para los administradores de sistemas y un riesgo adicional para la seguridad. Si bien generalmente no trae ningún beneficio en general, ya que los empleadores que trabajan en un continente diferente en cosas totalmente diferentes probablemente ni siquiera saben sobre nuestro proyecto aquí, y mucho menos para contribuir positivamente.

Entonces, si tiene sentido dentro de su departamento , y / o para las personas asociadas con el proyecto de alguna manera, ¿por qué no? Pero en general, solo por "apertura", no estoy seguro de que valga la pena.

Una nota final: incluso cuando las personas de soporte son inteligentes y están ansiosas por contribuir con parches, yo diría que sus contribuciones siempre deben ser revisadas por un desarrollador antes de integrarse en el sistema.

En la mayoría de las organizaciones en las que he trabajado, el repositorio de código estaba abierto a todos los desarrolladores.

En algunos también se usaba para almacenar documentos (como especificaciones y requisitos) para versionarlos junto con el software. En ese caso, la mayoría de los otros empleados también tenían acceso. Cuando el repositorio solo se usaba para el código, los no desarrolladores generalmente no tenían acceso, pero nunca escuché a nadie quejarse, por lo que probablemente no fue un gran problema de ninguna manera.

Recomendaría la mayor apertura posible, así que si la gente quiere acceso, déselo a menos que haya un problema obvio. Pero esa es realmente una cuestión de la cultura de la organización ...

Comparto una visión general / pragmática de esto y también puedo depender de la naturaleza del trabajo / organización. Pero sí creo que la base del código debería estar abierta a todos (también mostrará apertura y confianza dentro de la organización).

También trabajo en una configuración similar a la que mencionaste, donde tenemos un equipo de soporte / asistencia que se ocupa de las solicitudes de los clientes. Sin embargo, ciertas áreas complejas del sistema requieren ayuda adicional. En mi caso, el código base está abierto a todos, no hemos encontrado ningún problema.

• Creo que al abrir la base del código, otros miembros del equipo de soporte que estén interesados ​​también pueden verificar la base del código y familiarizarse con las reglas / área de negocios que les interesa o necesitan encontrar respuestas (y posiblemente mejorar su comprensión técnica y mirar algo diferente a la monótona rutina si el tiempo lo permite;)). Esto también podría resultar útil cuando los miembros del equipo de soporte obtienen problemas y registros de los clientes y podrían apuntar / ayudar en las posibles áreas del código donde esto sucede mirando el stacktrace, por ejemplo (obviamente dependerá del problema, etc.). Esto también ahorrará tiempo con el desarrollador, pero dependiendo del problema, por supuesto.

También será útil tener una documentación / wiki actualizada del producto que contenga todas las reglas / decisiones comerciales. Pero, por supuesto, debe asegurarse de que la wiki se actualice constantemente para volver a crear nuevas mejoras y / o correcciones de errores (donde el comportamiento cambia). Mis pensamientos honestos

En general, desde el punto de vista de la organización: las personas van y vienen; El proyecto (o producto) necesita continuar evolucionando. Por lo tanto, en la mayoría de las organizaciones, generalmente hay un Abierto para todos los repositorios para mantener el código.

Por lo general, existen derechos de acceso, etc., para evitar el acceso no autorizado y desapercibido (para evitar el robo de código, etc.), pero la mayoría de los superiores no están realmente excluidos de esto. Dentro de una organización, uno debe confiar en las personas (lo suficiente) para que pueda confiar en ellas con código. Ocultar el código de los empleados (o colegas) es un gran factor de desmotivación.

En nuestra organización, incluso cuando las personas realmente no contribuyen al código, ¡tienen acceso directo al código que ayuda porque intentan combatir / solucionar los problemas en el campo (con propiedad) en lugar de devolver las cosas al desarrollador y dormirse!