A afirmação de Werber sobre a natureza do sistema em geral
- O especialista expressou sua opinião de que este era um sistema construído sem qualquer padrão e com um nível muito baixo de profissionalismo, e que seus desenvolvedores não agiram profissionalmente em questões básicas que são fundamentais para o desenvolvimento de software de maneira confiável e bem-sucedida (parágrafos 12.2 e 12.1 da opinião). Com relação a várias funções, o perito também se referiu ao fato de que foram desenvolvidas de baixa qualidade (Seções 2.5, 7.3, 10.10-10.5). No entanto, o perito esclareceu, em resposta às perguntas de esclarecimento, que não examinou todos os elementos do sistema, mas sim focou nas alegações levantadas na tabela apresentada pelas partes, e que outros elementos foram examinados quanto à natureza do sistema conforme detalhado na opinião (p. 5 em resposta às perguntas de esclarecimento).
- Isso incluiu o especialista apontando que o sistema foi construído sem versionamento de código (uma função semelhante a "acompanhar alterações" em um documento), o que é essencial para possibilitar a recuperação em caso de falha, quem fez a alteração e por quê; como auxílio ao desenvolvimento futuro (seção 12.4). Foi observado que esse é o padrão atual para qualquer desenvolvimento profissional. O especialista também destacou que o sistema foi desenvolvido sem gerenciamento de versões de desenvolvimento que permita monitoramento de todo o sistema e uma descrição das mudanças na versão, o que é essencial para compartilhar entre desenvolvedores, administradores e partes interessadas as alterações feitas no sistema e sua data (seção 12.5).
Vale ressaltar que não há razão para preferir as explicações de Shmulik de que isso não era necessário em detrimento da opinião do pericial em nome do tribunal. O depoimento de Shmulik é o único testemunho de um litigante, e não há justificativa para sua preferência sobre a opinião do especialista, que deixou uma impressão muito profissional (p. 180 da transcrição nos págs. 4-5; p. 238 da transcrição nos parágrafos 1-6). Na verdade, a provável conclusão das evidências é que Shmulik trabalhou com a gestão de versões (GIT) em algum momento, contrariando seu depoimento, mas tentou ocultar isso. No contra-interrogatório, Shmulik inicialmente testemunhou que não trabalhava com a gestão de versões, e quando pediu para consultar a correspondência datada de 30 de maio de 2018, na qual escreve que está definindo GIT para o programador (P/3, p. 13, mensagem de 15:37), respondeu que "não é necessário" e que não se lembra, "mas pode não ter sido usado porque não o definimos, não foi necessário no final" (p. 180, s. 8, 15-16). Essa resposta não satisfaz várias razões. Primeiro, nenhuma explicação foi dada sobre por que Shmulik tratou da definição de Git segundo a correspondência e por que, embora tenha tratado da definição, ela não foi usada como ele testemunhou. Segundo, este é o único depoimento de um litigante que não deixou uma impressão positiva em seu depoimento. Terceiro, os réus se abstiveram de convocar o programador Michal, que é uma testemunha-chave, para depor. Quarto, a conduta dos réus, que antes do processo negaram aos autores o acesso ao sistema e, também no próprio processo, tentaram impedi-los de acessar o sistema para efeitos de examiná-lo, mesmo que a atividade comercial fosse negligenciável na época, como aparece na opinião do perito (p. 24), apoia a conclusão de ocultação (em vista da baixa qualidade e dos problemas decorrentes da opinião do especialista).
- O especialista também acreditava que havia confusão e falta de confiabilidade no sistema porque, no "ambiente do produto" do software (aquele que realmente foi usado), foram realizados testes e erros, nenhum vestígio de experimentos foi limpo e os dados experimentais foram misturados com dados reais. O especialista explicou que, no desenvolvimento adequado, tentativa e erro são realizados em um ambiente de desenvolvimento separado, com apenas o código final e os dados reais sendo transferidos para o "ambiente do produto" para que esse ambiente seja confiável e livre de problemas. O especialista explicou ainda que, mesmo que existisse um ambiente de desenvolvimento (evidência de que existia, mas foi excluído por uma empresa de armazenamento), isso não muda sua conclusão, pois o trabalho foi feito no ambiente do produto que deveria ter sido feito em um ambiente de desenvolvimento (seção 12.6 em conjunto com a p. 21 para responder às perguntas de esclarecimento).
- O especialista também destacou que o sistema foi construído sem testes automatizados, que são um padrão profissional aceito para sistemas com lógica complexa, a fim de garantir que o núcleo do sistema funcione conforme necessário (Seção 12.7). O perito em nome dos réus testemunhou que testes automatizados no ambiente WordPress não são comuns (p. 69 da transcrição nos parágrafos 20-29), mas a opinião do perito do tribunal deve ser preferida. O perito do tribunal causou uma impressão muito séria e profissional, como afirmado, e, por ser um perito em nome do tribunal, deve ser atribuído um peso significativo à sua opinião. Por outro lado, o perito dos réus justificou sua opinião sobre a qualidade do sistema com fundamentos, para dizer o mínimo, conforme explicado pelo perito do tribunal. Assim, por exemplo, o especialista em nome dos réus pode aprender sobre a complexidade e qualidade do sistema a partir do escopo das linhas de código escritas, onde a maior parte do código foi retirada de plugins genéricos desenvolvidos por terceiros. Ele também alegou a satisfação do usuário como evidência de qualidade, mas descobriu-se que a alegada satisfação se baseava em dados seletivos e deturpação deles, quando na verdade a atividade no sistema era marginal após um ano (pp. 24-25 do parecer do especialista; p. 20 em resposta às perguntas de esclarecimento; p. 72 da transcrição nos parágrafos 10-12). Isso provavelmente prejudicará o peso do depoimento e da opinião pericial em nome dos réus.
- O especialista também explicou que é comum confiar em um sistema de código aberto que inclua componentes gratuitos, quando o componente pronto é exatamente adequado às necessidades ou quando os desenvolvedores sabem como fazer ajustes profissionais no componente. O especialista observa que os componentes principais não se encaixavam exatamente nas necessidades e que o ajuste não foi feito profissionalmente, e apontou como exemplo o problema mencionado anteriormente que ele identificou, que permite assistir aos percursos gratuitamente.
- O especialista também acreditava que o sistema não era mantido profissionalmente. O especialista explicou que, em um sistema de código aberto, hackers têm incentivo para encontrar vulnerabilidades de segurança e, para proteger o sistema disso, é necessário realizar manutenção adicional dos plugins prontos instalados nele e comprar um código de licença para receber correções de bugs e atualizações de segurança dos desenvolvedores desses plugins. O especialista constatou, no entanto, que componentes-chave operam sem uma licença que permita receber atualizações desses desenvolvedores, e que a solução para receber atualizações por meio de um software chamado nobuna.com apresenta dificuldades porque é uma solução indireta de terceiros (e não diretamente do fabricante oficial do plugin) e, portanto, coloca o site em risco (p. 23 da opinião, pp. 8-9 e 22 em resposta às perguntas de esclarecimento).
- Na conclusão da opinião, o perito expressa sua opinião de que as características existentes no sistema não funcionam de forma confiável; O sistema foi construído de maneira pouco profissional e de baixa qualidade (há falhas e fraquezas em confiabilidade, privacidade e segurança), e foi feito sem um processo de desenvolvimento ordenado. Sua conclusão final foi que se tratava de "um sistema não padrão com funcionalidades prejudicadas."
- Vou observar que, à pergunta do tribunal, se o perito tivesse sido solicitado a examinar o sistema e organizar o que era necessário, qual teria sido a importância em termos de custo e recursos de tempo, o perito respondeu: "Eu não teria dedicado tempo para resolver o sistema existente. É melhor reescrever" e mais adiante "É uma bagunça atômica" - não pela dificuldade de ter outra pessoa para escrever o código, mas "depois de verificar se vi os problemas" (p. 90 da transcrição nos parágrafos 11-18), quando, em resposta à pergunta do advogado dos réus, ele esclareceu que era "consideração econômica do cliente quanto vale a pena investir" em reparos e considerando o custo de reconstruir o sistema, o que não acontecerá: na ordem de ILS 50 a 100 mil (onde ILS 100.000 é o preço por um excelente trabalho) (p. 90 da transcrição, 73-74).
- Deve-se notar que as descobertas do especialista sobre a baixa qualidade do desenvolvimento do sistema são apoiadas pela correspondência em tempo real de Alexandra com um dos freelancers que trabalhou no código, um programador da Índia (chamado Subash Poudel), na qual ele escreve que vê que o site foi construído sem pensar em velocidade, qualidade do código e incompatibilidade dos plugins (Apêndice 34 na p. 485 para as evidências de Werber):
Consigo ver que o site foi criado sem pensar em velocidade, qualidade de código e incompatibilidade de plugins/temas.