טענת ורבר לגבי טיבה של המערכת באופן כללי
- המומחה חיווה את דעתו שמדובר במערכת שנבנתה ללא סטנדרט כלשהו וברמת מקצועיות נמוכה מאוד וכי מפתחיה לא פעלו באופן מקצועי בעניינים בסיסיים שהם מפתח לפיתוח תוכנה באופן אמין ומוצלח (סעיפים 12.2 ו-12.1 לחוות הדעת). בהתייחס לפונקציות שונות המומחה גם התייחס לכך שהן פותחו באיכות נמוכה (סעיפים 2.5, 7.3, 10.10-10.5). עם זאת, המומחה הבהיר במענה לשאלות ההבהרה שהוא לא בדק את כל האלמנטים במערכת אלא התמקד בטענות שהועלו בטבלה שהעבירו הצדדים וכי נבדקו אלמנטים נוספים בנוגע לטיב המערכת כמפורט בחוות הדעת (עמ' 5 למענה לשאלות ההבהרה).
- בכלל זה הצביע המומחה על כך שהמערכת נבנתה ללא ניהול גרסאות קוד (פונקציה שדומה ל"עקוב אחר שינויים" במסמך) שהיא חיונית כדי לאפשר שחזור במקרה של תקלה, מי ערך את השינוי ומדוע; ככלי מסייע לפיתוח עתידי (סעיף 12.4). צוין שזהו הסטנדרט היום לכל פיתוח מקצועי. עוד הצביע המומחה על כך שהמערכת פותחה ללא ניהול גרסאות פיתוח שמאפשר מעקב אחר כלל המערכת ותיאור שינויים בגרסה שהוא חיוני כדי לשתף בין מפתחים, מנהלים ובעלי עניין בשינויים שנעשו במערכת ומועדם (סעיף 12.5).
אציין שאין מקום להעדיף את הסבריו של שמוליק שזה לא היה נדרש על פני חוות דעת המומחה מטעם בית המשפט. עדותו של שמוליק היא עדות יחידה של בעל דין ואין כל הצדקה להעדפתה על פני חוות דעת המומחה שהותיר רושם מקצועי מאוד (עמ' 180 לפרוטוקול ש' 5-4; עמ' 238 לפרוטוקול ש' 6-1). לאמיתו של דבר, המסקנה המסתברת מהראיות היא ששמוליק עבד עם ניהול גרסאות (GIT) בשלב מסוים בניגוד לעדותו אך ניסה להסתיר זאת. בחקירה הנגדית שמוליק העיד תחילה שלא עבד עם ניהול גרסאות, וכשביקש להתייחס להתכתבות מיום 30.5.2018 שבה הוא כותב שהוא מגדיר עבור המתכנתת GIT (ת/3 עמ' 13, הודעה משעה 15:37) השיב ש"לא צריך" ושהוא לא זוכר "אבל יכול להיות שלא השתמשנו בזה כי לא הגדרנו את זה, זה לא נצרך בסוף" (עמ' 180 ש' 8, 16-15). תשובה זו אינה מניחה את הדעת משורה של טעמים. ראשית, לא ניתן הסבר מדוע שמוליק טיפל בהגדרת GIT לפי ההתכתבות ומדוע למרות שטיפל בהגדרה לא נעשה בזה שימוש כפי שהעיד. שנית, מדובר בעדות יחידה של בעל דין שלא הותיר רושם חיובי בעדותו. שלישית, הנתבעים נמנעו מלזמן לעדות את המתכנתת מיכל שהיא עדת מפתח. רביעית, התנהלות הנתבעים שקודם להליך מנעו מהתובעים גישה למערכת וגם בהליך עצמו ניסו למנוע מהם גישה למערכת לצורך בדיקתה למרות שהפעילות העסקית הייתה זניחה באותו זמן, כעולה מחוות דעת המומחה (עמ' 24), תומכת במסקנה של הסתרה (לנוכח האיכות הנמוכה והבעיות כפי שעולה מחוות דעת המומחה).
- המומחה סבר גם שקיימים בלבול וחוסר אמינות במערכת מכיוון שב"סביבת המוצר" של התוכנה (זו שנעשה בה שימוש בפועל) נעשו ניסוי וטעיה, לא נוקו שאריות של ניסויים ונתוני ניסויים מעורבבים עם נתוני אמת. המומחה הסביר שבפיתוח תקין ניסוי וטעיה נעשים בסביבת פיתוח נפרדת כאשר ל"סביבת המוצר" מועברים רק הקוד הסופי ונתוני אמת על מנת שסביבה זו תהיה אמינה ונקיה מבעיות. המומחה הסביר עוד שגם אם הייתה סביבת פיתוח (שהוצגה ראיה לכך שהייתה קיימת אך נמחקה על-ידי חברת אחסון), אין בכך כדי לשנות ממסקנתו מכיוון שבסביבת המוצר נעשתה עבודה שצריכה הייתה להיעשות בסביבת פיתוח (סעיף 12.6 בשילוב עם עמ' 21 למענה לשאלות ההבהרה).
- המומחה הצביע גם על כך שהמערכת נבנתה ללא טסטים אוטומטיים שהם סטנדרט מקצועי מקובל למערכות בעלות לוגיקה מורכבת על מנת לוודא שליבת המערכת עובדת כנדרש (סעיף 12.7). המומחה מטעם הנתבעים העיד שבסביבת WordPress בדיקות אוטומטיות אינן נפוצות (עמ' 69 לפרוטוקול ש' 29-20) אך יש להעדיף את חוות הדעת של מומחה בית המשפט. מומחה בית המשפט עשה רושם רציני ומקצועי מאוד, כאמור, ומתוקף היותו מומחה מטעם בית המשפט יש לייחס משקל משמעותי לחוות דעתו. מנגד, מומחה הנתבעים נימק את חוות דעתו לגבי איכותו המערכת בנימוקים מוקשים, לשון המעטה, כפי שהסביר המומחה מטעם בית המשפט. כך למשל, המומחה מטעם הנתבעים שניתן ללמוד על מורכבות ואיכות המערכת מהיקף שורות הקוד שנכתבו מקום שמרבית הקוד בכלל נלקח מתוספים גנריים שפותחו על-ידי צדדים שלישיים. כמו כן, טען לשביעות רצון של משתמשים כראיה לאיכות, אולם התברר שאותה שביעות רצון נטענת המבוססת על נתונים סלקטיביים והצגה מטעה שלהם כאשר בפועל הפעילות במערכת הייתה שולית לאחר שנה (עמ' 25-24 לחוות דעת המומחה; עמ' 20 למענה לשאלות ההבהרה; עמ' 72 לפרוטוקול ש' 12-10). יש בכך כדי לפגום במשקל עדותו וחוות דעתו של המומחה מטעם הנתבעים.
- המומחה הסביר גם שמקובל להתבסס על מערכת קוד פתוח הכוללת רכיבים חינמיים, כאשר הרכיב המוכן מתאים בדיוק לצרכים או כאשר המפתחים יודעים לבצע התאמות לרכיב באופן מקצועי. המומחה מציין שרכיבים המרכזיים לא התאימו בדיוק לצרכים וההתאמה לא נעשתה באופן מקצועי וציין כדוגמה את הבעיה הנ"ל שאיתר המאפשרת צפייה בקורסים ללא תשלום.
- המומחה סבר גם שהמערכת לא תוחזקה באופן מקצועי. המומחה הסביר שבמערכת קוד פתוח יש תמריץ לפורצים למצוא חולשות אבטחה, ועל מנת להגן על המערכת מכך צריך לבצע תחזוקה תוספת של התוספים המוכנים שהותקנו בה ולרכוש קוד רישיון כדי לקבל מהמפתחים של התוספים תיקוני תקלות ועדכוני אבטחה. המומחה מצא, עם זאת, שרכיבים מרכזיים פועלים ללא רישיון שמאפשר קבלת עדכונים מהמפתחים כאמור והפתרון לקבלת עדכונים באמצעות תוכנה בשם com מעורר קשיים מכיוון שמדובר בפתרון עקיף של צד שלישי (ולא ישירות מהיצרן הרשמי של התוסף) ולכן מעמיד את האתר בסיכון (עמ' 23 לחוות דעת, עמ' 9-8 ו-22 למענה לשאלות ההבהרה).
- בסיכום חוות הדעת מחווה המומחה את דעתו שהתכונות הקיימות במערכת לא פועלות באופן אמין; המערכת נבנתה באופן לא מקצועי ובאיכות נמוכה (קיימות בה תקלות וחולשות של אמינות, פרטיות ואבטחה), וכי היא נבנתה ללא תהליך פיתוח סדור. מסקנתו הסופי הייתה שמדובר ב"מערכת בלי סטנדרט עם פגיעה בפונקציונליות".
- אציין שלשאלת בית המשפט, אם המומחה היה מתבקש לבדוק את המערכת ולסדר את הנדרש מה הייתה המשמעות מבחינת עלות ומשאבי זמן השיב המומחה "לא הייתי לוקח לסדר את הקיים. עדיף לכתוב מחדש" ובהמשך "זה בלאגן אטומי" - לא בגלל הקושי בכך שמישהו אחר כתב את הקוד אלא "אחרי בדיקה שראיתי את הבעיות" (עמ' 90 לפרוטוקול ש' 18-11), כאשר לשאלת ב"כ הנתבעים הבהיר שמדובר ב"שיקול כלכלי של הלקוח כמה שווה לו להשקיע" בתיקונים ובהתחשב בעלות של בניה מחדש של המערכת שהיא לא יקרה: בסדר גודל של 50 עד 100 אלפי ₪ (כאשר 100,000 ₪ הוא מחיר לעבודה מעולה) (עמ' 90 לפרוטוקול, עמ' 74-73).
- יש לציין שממצאיו של המומחה לגבי האיכות הנמוכה של פיתוח המערכת נתמכים בהתכתבות מזמן אמת של אלכנסדרה עם אחד הפרילנסרים שעבדו על הקוד, מתכנת מהודו (בשם Subash Poudel), בה הוא כותב שהוא רואה שהאתר נבנה ללא מחשבה על מהירות, איכות הקוד וחוסר תאימות של תוספים (נספח 34 בעמ' 485 לראיות ורבר):
I can see the site was built without speed, code quality and plugins/theme incompatibility in mind.