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

14

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

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

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

Algunos argumentos hasta ahora:

  • Las contraseñas en VCS están expuestas (solución: deshacerse de las contraseñas; para empezar, no deberían estar allí)
  • El código está abierto a ataques de seguridad de casilla blanca (contraargumento: esto solo mantiene alejados 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?

    
pregunta Mark McDonald 14.02.2012 - 08:00

4 respuestas

8

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

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

Para una compañía que desarrolla algún software propietario raro, que posiblemente incluya algoritmos especiales o cosas que les otorguen una ventaja competitiva sobre su competencia, puedo comprender muy bien si se esfuerzan por mantener su código en secreto. P.ej. AFAIK Google limita muy estrictamente la cantidad de personas a las que se les otorga acceso a la implementación de su algoritmo de búsqueda principal.

Hoy en día, una organización multinacional se extiende en muchos países, zonas horarias y culturas, y por razones de seguridad, probablemente segmenten su intranet y utilicen cortafuegos para controlar el tráfico entre diferentes segmentos / dominios. Por lo tanto, hacer que un representante de SCM sea accesible para "toda la empresa" puede requerir mucho trabajo adicional para los administradores de sistemas y un riesgo de seguridad adicional. Si bien, por lo general, no brinda ningún beneficio en general, ya que los empleadores que trabajan en un continente diferente en cosas totalmente diferentes probablemente ni siquiera conocen nuestro proyecto aquí, y mucho menos que contribuyan 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 muy 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.

    
respondido por el Péter Török 14.02.2012 - 09:39
5

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

En algunos también se usaba para almacenar documentos (como especificaciones y requisitos) para la versión junto con el software. En ese caso, la mayoría de los otros empleados también tenían acceso. Donde 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.

Recomendaría la mayor apertura posible, de modo que si las personas desean acceder, entréguelas a menos que haya un problema obvio. Pero eso realmente es una cuestión de la cultura de la organización ...

    
respondido por el sleske 14.02.2012 - 10:18
4

Yo comparto una opinión general / pragmática sobre esto y también puedo depender de la naturaleza del trabajo / organización. Pero sí creo que el código base debería estar abierto a todos (también mostrará franqueza y confianza dentro de la organización).

También trabajo en una configuración similar a la que mencionó, en la que contamos con 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 de códigos, otros miembros del equipo de soporte que estén interesados también pueden revisar la base de códigos y familiarizarse con las reglas / áreas comerciales en las que están interesados o necesitan encontrar respuestas (y posiblemente mejorar su comprensión técnica y mirando algo diferente a la rutina monótona si el tiempo lo permite;)). Esto también puede ser útil cuando los miembros del equipo de soporte técnico obtienen problemas y registros de los clientes y podrían señalar / ayudar en posibles áreas del código donde esto ocurre 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 mejorar las nuevas mejoras y / o correcciones de errores (donde el comportamiento cambia). Mis pensamientos honestos

    
respondido por el MalsR 14.02.2012 - 11:06
3

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

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

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

    
respondido por el Dipan Mehta 14.02.2012 - 08:13

Lea otras preguntas en las etiquetas