He estado trabajando para empresas grandes y pequeñas, durante los últimos 5 años. He notado que nadie, o al menos en los lugares donde he trabajado, se preocupa por el código fuente de las aplicaciones. Por ejemplo, en cualquier momento podría traer mi llave USB y obtener una copia de todo el sistema, algunas compañías ponen en un contrato que no puede tomar el código fuente, pero si nunca hace pública su copia, nadie lo notará. tomaste ese código.
Entonces mi pregunta es, ¿cómo podría organizar un proyecto/empresa para evitar que los desarrolladores roben el código fuente?
¿Podría ser una buena opción hacer que todos trabajen solo en una parte del software y luego hacer que el gerente lo fusione y solo se arriesgue a que el gerente obtenga una copia? Por ejemplo, ¿un desarrollador de software que trabaje en Salesforce o en Adobe tendrá una copia completa del código fuente en su PC?
Gracias :)
Como mínimo, debe proporcionar a los desarrolladores el código en el que trabajan. Esto limita su capacidad para restringir su acceso. Puede proporcionar bibliotecas para otras secciones de código, pero esto puede crear barreras para resolver errores.
Ha habido casos en los que los empleados robaron código e intentaron crear servicios de la competencia. Los que conozco han sido tratados con éxito a través de medios legales después del hecho. La propiedad del código debe ser manejada por términos contractuales con aquellos que lo usan. También se pueden aplicar los derechos de autor.
Aparte de los marcos y las bibliotecas, que se extraen o están cada vez más disponibles en la comunidad de código abierto, hay poco código en el que he trabajado que sería de mucha utilidad en proyectos futuros. Los marcos internos que he usado no eran tan sólidos como los marcos de código abierto de la competencia.
He trabajado en entornos de control de código restrictivos, pero solo tenían puntos de control y el trabajo de código futuro se realizó en una versión de código no extraída del entorno de control de código. Esto condujo a problemas importantes, donde el código fuente de las versiones publicadas no se pudo recuperar porque no se rastreó en ninguna parte.
Hacer que los administradores fusionen el código limita el acceso a la copia completa. Sin embargo, es más probable que los gerentes puedan hacer uso de ese acceso con éxito. Preferiría restringir el acceso al código a los desarrolladores.
La mayoría de los desarrolladores solo tendrán el código que necesitan para trabajar en su sistema. Esto puede ser una parte importante del sistema, pero probablemente no el sistema completo. Con una buena reutilización del código, pueden tener una parte importante del sistema disponible como bibliotecas. Los sitios más grandes generalmente tienen múltiples repositorios y limitan el acceso a los equipos que requieren acceso. Los navegadores de código pueden permitir a los desarrolladores buscar el código de otros proyectos que necesitan para resolver errores relacionados.
Los sistemas de bloqueo de código tienden a agregar fricción al proceso de desarrollo. He visto poco o ningún valor agregado por el bloqueo de código. La buena comunicación y el seguimiento de revisiones agregan un valor significativo. Hacer que un administrador fusione el código parecería ser otro enfoque para el bloqueo de código.
Existen ventajas en el uso de un proceso de revisión para introducir cambios en el código publicado. Hay varios enfoques que se pueden utilizar. Todos requieren cambios de seguimiento, lo que aumenta la sobrecarga de gestión de cambios.
Todd A. Jacobs
jmort253
Bruno Quintana Fleitas