¿Qué tan serio es perder el código fuente? [cerrado]

9

Si una compañía de software pierde el código fuente de uno de los productos que está vendiendo, ¿qué tan serio sería, en términos que podría explicarle a un lego? ¿Sería demasiado fuerte el término "negligencia grave"? O "incompetencia grave"? Obviamente nadie fue asesinado, pero ¿no es tan grave como una negligencia financiera que la gente tenga tiempo en la cárcel?

EDITAR: Digamos que no se trata de una unidad de disco que falla, un desastre natural o algo así. Simplemente lo extraviaron.

JoelFan
fuente
37
Hay una historia detrás de esta pregunta, y quiero escucharla. Solo esperaré a que aparezca en Daily WTF.
BlairHippo
44
@ Josh K - ¡Mala analogía! Un niño no puede ser reemplazado. El código fuente puede. (y estoy seriamente conmocionado si crees que source_code == kid). Pero, supongo que no tienes uno (todavía).
Torre
66
@Rook: ¿Por qué es una mala analogía? El código fuente no se puede reemplazar exactamente, solo se puede replicar de manera similar. De acuerdo, esto no es tan extremo como perder un hijo, pero el símil sigue siendo sólido.
Josh K
66
@Rook: Te estás perdiendo el punto de que si bien uno (los niños) son obviamente mucho más importantes que el código fuente, la posesión de ambos todavía es muy apreciada. Descarta mi analogía porque los niños son más importantes que el código fuente sería como descartar Yahoo! como empresa de búsqueda porque Google es mucho más grande. Mi punto es que ambos son enormes, el hecho de que uno sea ~ 10 veces más significativo / importante que el otro no importa. Decirle qué, pierda el repositorio (y todas las copias del código) para la aplicación principal de su empresa y vuelva a contactarme en 5-10.
Josh K
55
No entiendo cómo solo podría haber una copia "extraviada" en primer lugar. Me suelen tener por lo menos dos o tres copias yo mismo en varias etapas de correcciones, actualizaciones y parches que estoy trabajando. Mis colegas tendrían sus propias copias. En el peor de los casos, puede perder el historial en su repositorio de origen (si está utilizando un repositorio central sin copias de seguridad) ... Simplemente no veo cómo esto es posible ...
Dean Harding

Respuestas:

27

Digamos MS pierde la fuente para Windows Phone 7 ... personas han muerto por muuuuchas menor que el estimado de $ 400 millones que costó a desarrollarla.

Dependiendo del producto, no hay un término que pueda pensar que sea "demasiado fuerte".

Steven Evers
fuente
1
Si venden software y no tienen el código fuente, sí, es incompetente. Sin embargo, como desarrollador de software personalizado, es sorprendente la frecuencia con la que me he encontrado con pequeñas empresas dirigidas por no programadores que subcontrataron su desarrollo, y ni siquiera tenían copias construibles del código fuente para el software que estaban vendiendo.
Bob Murphy
1
Y no solo las pequeñas empresas hacen eso. Mi firma de consultoría solía hacer mucho trabajo para Informix, que en el pasado era un competidor viable para Oracle. Decidieron trasladar uno de nuestros proyectos a una empresa de tercerización india, y un día el gerente nos llamó: "¡No nos enviaron la fuente!" "Sí, lo hicimos, fue en la fecha X (aproximadamente un año antes), y aquí está el número de seguimiento de FedEx. ¿Lo perdió?" "No claro que no." "Está bien si lo hiciste, porque podemos recuperarlo de nuestros archivos, pero habrá una tarifa". "No, no te molestes". Más tarde descubrimos que, de hecho, lo habían perdido.
Bob Murphy
18

Para una empresa, esto es como perder las joyas de la corona. Si se trata de un producto con un procesador incorporado, pueden continuar fabricando el producto "tal cual", pero pierden la capacidad de mejorarlo o solucionar cualquier problema.

En los mercados actuales, una empresa es IP. Pierde eso y se va a la quiebra.

uɐɪ
fuente
13

Como han señalado los demás, esto probablemente se enmarca en el encabezado "todo depende", por lo que un par de senarios:

Fuente de un videojuego de consola basado en disco : esto probablemente tendría poco impacto en la empresa, ya que tienden a no realizar ningún cambio en el juego una vez que se ha grabado en el disco. De acuerdo, podrían perder algo de tiempo si hay un código de biblioteca que tienen que volver a desarrollar, no sería tan malo.

Fuente de un videojuego descargable : esto probablemente sería malo ya que los clientes probablemente van a esperar que se reparen los errores, no poder hacerlo podría hacer que los clientes pierdan la fe en la compañía y podrían afectar negativamente las futuras versiones.

Fuente para un juego en desarrollo : la mayoría de las compañías de videojuegos no pueden permitirse perder el código de un juego actualmente en desarrollo a menos que sea extremadamente temprano en el ciclo de desarrollo (es decir, días, tal vez semanas). Para una empresa pequeña, perder la fuente porque su lanzamiento emblemático podría hacer que cierren.

Fuente para una aplicación de pequeña empresa con un público de lanzamiento limitado : es poco probable que cause problemas a la empresa, aunque podrían perder un par de clientes.

Fuente para una aplicación comercial grande con un público de lanzamiento limitado : otra situación en la que puede hacer que la empresa cierre su negocio debido a la pérdida de fe de sus clientes. Incluso en la mayoría de los mercados pequeños, suele haber más de una empresa en funcionamiento y esto podría ser suficiente para que el negocio se mueva a un competidor.

Fuente para una aplicación importante de una gran empresa : aquí es donde realmente todo depende y es probable que sea muy estricta, caso por caso. Los productos emblemáticos (por ejemplo, Microsoft Windows) generalmente tienen contratos de soporte asociados con ellos y no poder soportar el producto podría dar lugar a demandas por incumplimiento de contrato. Si tuviera que dar una estimación, diría que la mayoría de las personas involucradas en la pérdida del código hasta el liderazgo de esas personas podrían estar buscando un nuevo empleo.

Sin embargo, en general, diría que la persona que perdió el código buscaría un nuevo trabajo (¡y podría tener dificultades para encontrar uno!) Y también podría enfrentar demandas de la empresa.

rjzii
fuente
Es común reutilizar grandes partes del código fuente de un juego lanzado anteriormente cuando se desarrolla un próximo juego, especialmente cuando se desarrolla su secuela. Sin embargo, dada la vida relativamente corta de los estudios de juegos, no ha sido raro escuchar sobre las pérdidas de fuentes de juegos durante las últimas décadas.
wip
3

Si bien ciertamente hay casos en los que podría ser cataclísmico, creo que hay muchos donde no lo es (al menos desde la perspectiva de la compañía de software).

Creo que hay demasiadas variables para dar una respuesta general sobre si hay alguna repercusión legal, pero algunas preguntas a considerar para determinar eso incluirían:

  • ¿Cuál es la naturaleza del programa? Si es algo que perdieron porque las aplicaciones como esta cuestan diez centavos por docena y no es importante , ¿y qué? Si es el producto comercial insignia de la compañía, solo se han perjudicado a sí mismos. Si se trata de un software personalizado para el que han sido construidos, ahí es donde podría ser interesante, pero deben preguntar ...
  • ¿Quién poseía los derechos de autor del código? (Si el cliente posee los derechos de autor, entonces su propiedad podría haberse perdido / destruido)
  • ¿Está el cliente siendo perjudicado activamente por la desaparición del código?
  • ¿Había contratos vigentes con respecto al desarrollo futuro que se violarían como resultado de la desaparición del código?
  • ¿Qué tan importante es poder recrear el software existente? Si se trata de algo así como un script de shell para realizar tareas de mantenimiento, la compañía de software consume el tiempo necesario para crear uno nuevo que haga lo mismo. Si se trata de una suite ofimática, desempolva el currículum.

Y estoy seguro de que hay muchos otros factores que deberían considerarse. Siéntase libre de agregar.

Ahora sí dije "desde la perspectiva de la compañía de software". Todavía puede ser catastrófico en la mente del cliente debido a los planes que tenían para cambios, mejoras o cualquier otra cosa. Sin embargo, un contrato para tales cosas o la propiedad de los derechos de autor puede enojar seriamente al cliente, pero sin ninguna obligación por parte del desarrollador, aparte de hacer lo que pueda para mantener buenas relaciones con los clientes.

Blumer
fuente
Y para ampliar aún más la parte de la "perspectiva del cliente", lo que quiero decir es que no sé cuál es la historia detrás de la pregunta, pero no sería extraño que el cliente piense que tiene el derecho a esperar que el código fuente esté protegido como Fort Knox, mientras que el desarrollador lo considera "desechable" cuando el cliente no ha solicitado ninguna modificación o trabajo adicional en los tres años posteriores a la implementación.
Blumer
Tenga en cuenta que hacer cosas que enojan seriamente a un cliente también puede ser incumplimiento de contrato y legalmente procesable. También puede provocar que el cliente se queje públicamente.
David Thornley el
3

Ah, dada esta aclaración tuya (en los comentarios):

Fue desarrollado hace mucho tiempo, sin control de fuente, lo han estado vendiendo todo este tiempo y ahora de repente necesitan actualizarlo.

En esta situación específica , diría que probablemente no sea el fin del mundo. Dado que han estado vendiendo el software durante años sin necesitar el código fuente, entonces solo puede decirle a este cliente que solicita la actualización, "lo siento, no se puede hacer".

Ahora no me malinterpreten, perder el código no es bueno. Va a ser muy costoso para su empresa reescribir o aplicar ingeniería inversa a la versión original (si eso es lo que deciden hacer). Pero no es el fin del mundo. Obviamente han sobrevivido durante tanto tiempo sin necesitar el código, por lo que probablemente continúen sobreviviendo sin él.

Esto supone, por supuesto, que el software que venden es solo una pequeña parte de su negocio. Lo que supongo que debe ser el caso ...

Dean Harding
fuente
Sí, es solo uno de los muchos productos que venden
JoelFan el
No es solo 1 cliente ... ya no funcionará en la última versión del sistema operativo
JoelFan
1

Mientras puedan vender el producto, no creo que tengan problemas. Ahora, si están bajo contrato con un cliente para extender el producto y proporcionar ciertas características nuevas en la próxima versión, eso es mucho más grave porque los está configurando por incumplimiento de sanciones contractuales. Pero no creo que haya un problema legal con la pérdida del código en sí.

Esto no significa que no sea un desastre absoluto para la empresa. Pero es un desastre financiero; No es legal. Probablemente comenzaría con el término "incompetencia grave" y avanzaría desde allí.

Mason Wheeler
fuente
-1: "No creo que estén en problemas" No pueden corregir errores, parchar o hacer cambios cuando Microsoft "actualiza" el sistema operativo. Están totalmente condenados a una base de clientes que disminuye rápidamente y las únicas nuevas ventas serán para completar idiotas. (A no-cero de la población, pero sin mucho dinero para gastar en sfotware.)
S. Lott
@ S.Lott: lo que puede ser más importante, ni siquiera pueden volver a compilar. Si algo cambia en el entorno del cliente, el software no funcionará.
David Thornley
1

Para ser sincero, creo que depende del idioma utilizado. Si pierde una base de código C #, se puede descompilar con extrema facilidad, pero si pierde una base de código C ++, eso es mucho peor.

Nota para uno mismo - piense en un nombre
fuente
Descompilado hasta el punto en que aún podría construirse y ejecutarse, pero ¿aún sería mantenible?
Jay
3
Si siguió una buena práctica de codificación, entonces, por supuesto, . Todos los nombres de métodos y campos se conservan, incluso los privados. Si los métodos son cortos, entonces el propósito de las variables locales debería ser obvio. Los trucos del compilador como métodos anónimos e iteradores pueden parecer intimidantes, pero pueden revertirse (si es necesario) con algo de trabajo. E incluso si el ensamblaje estuviera ofuscado, todavía debería haber una versión de depuración en algún lugar .
Nota para uno mismo - piense en un nombre
A menos que el único código que tenga esté ofuscado, en cuyo caso será un poco doloroso.
MIA
1

Si se corrió la voz de eso, bueno, cualquier proveedor que pueda perder su código fuente por cualquier otro medio que no sea un desastre bastante extendido obviamente no está siguiendo nada como prácticas de desarrollo sólidas, y no se puede confiar en él. Consideraría eso como una evidencia prima facie muy fuerte de incompetencia corporativa bruta.

¿Qué tal "estupidez increíble"?

David Thornley
fuente
0

Lo compararía con otros trabajos que requieren la construcción de un artículo. Probablemente algo físico. por ejemplo, si un arquitecto perdió los planos de un edificio que fue construido; Si una compañía de automóviles pierde los planes para un modelo de automóvil; Si una costurera perdió el patrón para un atuendo que habían hecho; etc.

Hay muchos trabajos que tienen comparaciones físicas para comparar con la creación de software.

frogstarr78
fuente
Excepto que los planes no suelen ser tan importantes. Si el arquitecto pierde los planos, otro aún puede supervisar los cambios en el edificio. Si una compañía de automóviles pierde los planes, sus automóviles aún pueden conducir en carreteras con pavimento recientemente desarrollado. Si pierdo el código fuente, no puedo cambiar el programa de manera significativa, y no puedo volver a compilarlo para que se ejecute en un nuevo sistema operativo o con una versión más nueva de una biblioteca.
David Thornley
@David: No creo que hayas entendido mi analogía. Si un arquitecto pierde los planos de un edificio, tiene que volver a hacer los planos para construir uno nuevo. Tampoco veo cómo otro arquitecto puede supervisar los cambios en un edificio si no tiene planes de abandonarlo. Usted, aplicó totalmente la analogía del automóvil. Sin embargo, usted señaló que era un poco un paralelo débil de todos modos.
frogstarr78
@ frogstarr78: es factible realizar cambios en un edificio sin los planos originales. Hay un edificio allí que se puede observar. La construcción de un nuevo edificio probablemente requeriría nuevos planes, aunque podrían basarse en los antiguos. Los planes para un modelo de automóvil solo serán necesarios para un año modelo; después de eso, es posible examinar el automóvil para obtener la información necesaria. Perder planes para objetos físicos no es bueno, pero no afecta la usabilidad casi tanto como perder el código fuente.
David Thornley
@David: no estoy de acuerdo.
frogstarr78
@David: Me parece que comparas el rediseño de los planos de una casa o un automóvil para ser tan simple como ver un programa en ejecución y poder cambiarlo. Si el programa está compilado (y sí es razonablemente compatible con varias plataformas), o si un automóvil ya está construido o una casa ya está construida, puede usarlos todos. Sin embargo, cuando necesite cambiar cualquiera de estas cosas (como dije que el auto es el ejemplo más semanal aquí), necesitará planes para hacerlo. No digo que estos ejemplos sean perfectos, pero ponen el concepto en el ámbito de algo físico y familiar para la mayoría de las personas.
frogstarr78
0

Creo que, aparte de la opción de descompilar el código, este sería un problema bastante grande, suponiendo que la compañía tuviera la intención de continuar comercializando el producto de software. Si se tratara de una aplicación interna, lo mismo sería cierto en menor grado.

Si no puede restaurar el código fuente, entonces el mantenimiento (corrección de errores) y las mejoras no se pueden realizar, por lo que la aplicación ahora es estática. Si Microsoft o Apple o Apache o quien sea que su plataforma operativa cambie o actualice su código, entonces su código compilado anterior puede no funcionar y no puede solucionarlo. Si está vendiendo esta aplicación a clientes externos, no puede controlar cuándo actualizarán su Windows, MAC OSX, iPhone, navegador web, por lo que tiene un riesgo bastante grande aquí para la reputación de su empresa y posiblemente un riesgo legal también si tiene un contrato de mantenimiento con los clientes

En segundo lugar, el código fuente representa un activo para la empresa. Entonces, para una compañía de software es un activo en los libros. Es algo que puede vender como producto o vender el código fuente y todos los derechos a otra compañía de software. No continuaría vendiendo un producto de software a clientes que sabía que no podía mantener porque perdí el código fuente. Además, dudo que otra compañía de software compraría la aplicación y todos los derechos si no pudieran seguir desarrollando el producto. Por lo tanto, el valor de los activos de esta aplicación debe reducirse.

Para una aplicación interna interna, es posible que tenga más control sobre la plataforma operativa para su aplicación, pero aún así buscaría reemplazar esta aplicación si el código fuente no se puede descompilar en una base de código utilizable para el mantenimiento.

Salud,

Kevin

PD: Espero que esto sea solo una pregunta teórica ... :)

Kevin Horgan
fuente
-1

Si no tienen que corregir ningún error, entonces probablemente no sea tan importante. Por ejemplo, si la compañía hace controles personalizados de ActiveX y pierden la fuente de uno de sus productos heredados, ¿a quién le importa realmente? El producto probablemente no se mantiene activamente, y probablemente tampoco se comercializa agresivamente. Lo venderán siempre que la gente siga usando ActiveX de 32 bits y luego se olviden de ello.

Dicho esto, todavía lo clasificaría como negligencia grave. Obviamente no existe un sistema de gestión de código fuente, que es la incompetencia profesional para una empresa de software.

TMN
fuente
-1: "Si no tienen que arreglar ningún error" Qué nivel de perfección envidiable. ¿Quién tiene un software tan bueno? ¿Nadie?
S.Lott
1
"No tener que corregir errores"! = "Sin errores". Muchas empresas continúan vendiendo software EOL'd con una lista de errores conocidos que no tienen intención de corregir. Como un controlador USB para Win98: están disponibles, probablemente no sean perfectos, pero dudo que alguien esté aplicando correcciones de errores.
TMN