La afirmación de Werber sobre la naturaleza del sistema en general
- El experto expresó su opinión de que este era un sistema construido sin ningún estándar y con un nivel muy bajo de profesionalidad, y que sus desarrolladores no actuaban profesionalmente en asuntos básicos clave para el desarrollo de software de manera fiable y exitosa (párrafos 12.2 y 12.1 de la opinión). En cuanto a diversas funciones, el perito también se refirió al hecho de que fueron desarrolladas de baja calidad (Secciones 2.5, 7.3, 10.10-10.5). Sin embargo, el perito aclaró en respuesta a las preguntas de aclaración que no examinó todos los elementos del sistema, sino que se centró en las reclamaciones planteadas en la tabla presentadas por las partes, y que se examinaron otros elementos respecto a la naturaleza del sistema tal y como se detalla en la opinión (p. 5 en respuesta a las preguntas de aclaración).
- Esto incluyó que el experto señalara que el sistema se construyó sin versionado de código (una función similar a "registrar cambios" en un documento), lo cual es esencial para permitir la recuperación en caso de fallo, quién realizó el cambio y por qué; como ayuda al desarrollo futuro (sección 12.4). Se señaló que este es el estándar actual para cualquier desarrollo profesional. El experto también señaló que el sistema se desarrolló sin una gestión de versiones de desarrollo que permita monitorizar todo el sistema y una descripción de los cambios en la versión, lo cual es esencial para compartir entre desarrolladores, administradores y partes interesadas los cambios realizados en el sistema y su fecha (sección 12.5).
Cabe señalar que no hay razón para preferir las explicaciones de Shmulik de que no era necesario frente a la opinión experta en nombre del tribunal. El testimonio de Shmulik es el único testimonio de un litigante, y no hay justificación para su preferencia sobre la opinión experta, que dejó una impresión muy profesional (p. 180 de la transcripción en 4-5; p. 238 de la transcripción en los párrafos 1-6). De hecho, la conclusión probable de las pruebas es que Shmulik trabajó con la gestión de versiones (GIT) en algún momento, contrariamente a su testimonio, pero intentó ocultarlo. En el contrainterrogatorio, Shmulik testificó inicialmente que no trabajaba con la gestión de versiones, y cuando pidió consultar la correspondencia fechada el 30 de mayo de 2018 en la que escribe que está definiendo GIT para el programador (P/3, p. 13, mensaje de 15:37), respondió que "no es necesario" y que no lo recuerda, "pero puede que no se haya usado porque no lo definimos, no fue necesario al final" (p. 180, s. 8, 15-16). Esta respuesta no satisface varias razones. En primer lugar, no se dio ninguna explicación de por qué Shmulik manejó la definición de Git según la correspondencia ni por qué, aunque manejó la definición, no se utilizó como testificó. Segundo, este es el único testimonio de un litigante que no dejó una impresión positiva en su testimonio. En tercer lugar, los acusados se abstuvieron de citar al programador Michal, que es un testigo clave, para que declarara. Cuarto, la conducta de los demandados, que antes del procedimiento negó a los demandantes el acceso al sistema y, además, en el propio procedimiento, intentó impedirles acceder al sistema con fines de examinarlo, aunque la actividad empresarial era insignificante en ese momento, como se refleja en la opinión experta (p. 24), apoya la conclusión de ocultación (en vista de la baja calidad y los problemas que surgen de la opinión del experto).
- El experto también consideraba que existía confusión e inestabilidad en el sistema porque en el "entorno del producto" del software (el que realmente se utilizó) se realizaban pruebas y errores, no se limpiaban restos de experimentos y se mezclaban datos experimentales con datos reales. El experto explicó que, en un desarrollo adecuado, el ensayo y error se realiza en un entorno de desarrollo separado, transfiriendo únicamente el código final y los datos reales al "entorno del producto" para que este entorno sea fiable y libre de problemas. El perito explicó además que, incluso si existiera un entorno de desarrollo (pruebas de que existía pero fue eliminado por una empresa de almacenamiento), esto no cambia su conclusión porque el trabajo se realizó en el entorno del producto que debería haberse hecho en un entorno de desarrollo (sección 12.6 junto con la p. 21 para responder a las preguntas de aclaración).
- El experto también señaló que el sistema se construyó sin pruebas automatizadas, que son un estándar profesional aceptado para sistemas con lógica compleja, con el fin de asegurar que el núcleo del sistema funcione según lo necesario (Sección 12.7). El perito en nombre de los demandados declaró que las pruebas automatizadas en el entorno WordPress no son comunes (p. 69 de la transcripción en los párrafos 20-29), pero debería preferirse la opinión del perito del tribunal. El perito del tribunal causó una impresión muy seria y profesional, como se ha indicado, y por el hecho de ser un experto en nombre del tribunal, debe atribuirse un peso significativo a su opinión. Por otro lado, el perito de los demandados justificó su opinión sobre la calidad del sistema basándose en fundamentos, como mínimo, según explicó el perito del tribunal. Así, por ejemplo, el experto en nombre de los demandados puede conocer la complejidad y calidad del sistema a partir del alcance de las líneas de código escritas, donde la mayor parte del código se tomó de plugins genéricos desarrollados por terceros. También alegó la satisfacción del usuario como prueba de calidad, pero resultó que la supuesta satisfacción se basaba en datos selectivos y tergiversación de los mismos, cuando en realidad la actividad en el sistema era marginal tras un año (pp. 24-25 de la opinión experta; p. 20 en respuesta a las preguntas de aclaración; p. 72 de la transcripción en los párrafos 10-12). Esto probablemente perjudicará el peso del testimonio y la opinión experta en nombre de los acusados.
- El experto también explicó que es común confiar en un sistema de código abierto que incluya componentes gratuitos, cuando el componente ya hecho se adapta exactamente a las necesidades o cuando los desarrolladores saben cómo hacer ajustes profesionales. El experto señala que los componentes principales no se ajustaban exactamente a las necesidades y que el ajuste no se realizó profesionalmente, y señaló como ejemplo el problema mencionado que identificó, que permite ver los recorridos de forma gratuita.
- El experto también consideraba que el sistema no se mantenía profesionalmente. El experto explicó que en un sistema de código abierto, los hackers tienen un incentivo para encontrar debilidades de seguridad y, para proteger el sistema de esto, es necesario realizar un mantenimiento adicional de los plugins listos instalados en él y comprar un código de licencia para recibir correcciones de errores y actualizaciones de seguridad de los desarrolladores de los plugins. Sin embargo, el experto concluyó que los componentes clave operan sin una licencia que permita recibir actualizaciones de dichos desarrolladores, y que la solución para recibir actualizaciones a través de un software llamado nobuna.com plantea dificultades porque es una solución indirecta de terceros (y no directamente del fabricante oficial del plugin) y, por tanto, pone en riesgo el sitio (p. 23 de la opinión, pp. 8-9 y 22 en respuesta a las preguntas de aclaración).
- En la conclusión de la opinión, el perito expresa su opinión de que las características existentes en el sistema no funcionan de forma fiable; El sistema fue construido de manera poco profesional y de baja calidad (existen fallos y debilidades en fiabilidad, privacidad y seguridad), y que se construyó sin un proceso de desarrollo ordenado. Su conclusión final fue que se trataba de "un sistema no estándar con funcionalidad deteriorada."
- Cabe señalar que, a la pregunta del tribunal, si se hubiera pedido al experto examinar el sistema y organizar lo que se requería, cuál habría sido la importancia en términos de costes y recursos de tiempo, el experto respondió: "No me habría tomado el tiempo de resolver el sistema existente. Es mejor reescribir" y más adelante "Es un desastre atómico" -no por la dificultad de que alguien más escriba el código, sino "tras comprobar que veía los problemas" (p. 90 de la transcripción en los párrafos 11-18), cuando, en respuesta a la pregunta del abogado de los demandados, aclaró que era "consideración económica del cliente cuánto vale la pena invertir" en reparaciones y considerando el coste de reconstruir el sistema, lo cual no ocurrirá: del orden de 50.000 a 100 mil ILS (donde 100.000 ILS es el precio por un trabajo excelente) (p. 90 de la transcripción, pp. 73-74).
- Cabe señalar que los hallazgos del experto sobre la baja calidad del desarrollo del sistema están respaldados por la correspondencia en tiempo real de Alexandra con uno de los freelancers que trabajó en el código, un programador indio (llamado Subash Poudel), en el que escribe que ve que el sitio se construyó sin pensar en la velocidad, la calidad del código y la incompatibilidad de los plugins (Apéndice 34 en la p. 485 para la evidencia de Werber):
Veo que el sitio fue creado sin tener en cuenta la velocidad, la calidad del código y la incompatibilidad de plugins y temas.