מיקרוסופט מינתה לאחרונה "צאר איכות". בלי תקציב. בלי צוות. בלי סמכות אמיתית.
זה כמו למנות אחראי כיבוי אש שאסור לו לגעת בזרנוקים.
בפרויקט GitHub עם 2,400 כוכבים ניסו להחליף את כל הקוד ב-AI-generated code ולשנות את הרישיון, תוך שמירה על אותו שם. הדיון ברשת התמקד בשאלה המשפטית: האם שכתוב קוד מאפשר רישוי מחדש? הם פספסו את הסיפור האמיתי.
כל המוצר הטכנולוגי שלכם כנראה תלוי בקוד שנכתב על ידי מתנדבים. מתנדבים שאינם מקבלים תגמול, ושנשחקים בדרך.
שלושה סיפורים שמדברים על אותו הדבר: מנהיגות טכנולוגית אמיתית היא לא תארים, כוונות טובות, או ניצול נסתר של עבודת אחרים. היא מחייבת סמכות, משאבים, ואחריות.
תרבות שינוי שנכשלת: התבנית המוכרת
12 שנות תקריות אבטחה ב-Windows, מחקרים על תרבות ארגונית שמחלישה עובדים, ומיקרוסופט מגיבה עם מינוי של אחד.
אי אפשר לפתור בעיות איכות מערכתיות עם תארים וכוונות טובות.
זה מזכיר כל "שינוי ארגוני" שראיתי שנכשל. התבנית תמיד זהה: יוצרים רעש כאילו אכפת, ממנים תואר שנשמע חשוב, ואז נמנעים מהעבודה הקשה של לשנות באמת תהליכים ומבנים.
שינוי אמיתי בארגון מחייב לפחות שלושה דברים:
- סמכות לקבל החלטות, לא רק להמליץ
- תקציב ליישם אותן, לא רק לדון
- אחריות על התוצאות, לא רק על הדוחות
בלי שלושת האלמנטים ביחד, המינוי הוא תיאטרון. הוא יוצר אשליה של פעולה בלי השפעה. ולפעמים זה גרוע מאי עשייה, כי הוא נותן לארגון "עדות" שמשהו מטופל, בעוד שמשהו בכלל לא מטופל.
מנהיגות טכנולוגית שמשנה דברים מתחילה בשאלה: "למי יש כוח להכריח שינוי אמיתי, ואיך גורמים לו לבנות מערכות שמובנית בהן האיכות?"
קוד פתוח: הבסיס הבלתי נראה
דן לורנק מ-ChainGuard בילה 10 שנים בגוגל. הוא ראה את App Engine צומח מלפני שקטגוריית ה-PaaS בכלל נוצרה. הכל בנוי על יסודות קוד פתוח.
אבל מה שאנשים לא מדברים עליו: אין "קהילת קוד פתוח" אחת שמנהלת את הכל. יש אנשים אקראיים שמעלים קוד לרשת תחת רישיון. רבים מהם לא מקבלים שכר, נשחקים עם הזמן, ומפסיקים לתחזק.
כל הבסיס הטכנולוגי שלכם (מהספרייה שאתם משתמשים בה עד לספריות האבטחה שאתם לא יודעים שקיימות) תלוי בבני אדם שיכולים להחליט מחר שאין להם יותר כוח.
זה לא תיאוריה. זה קרה. ה-Heartbleed bug ב-OpenSSL (קוד שהגן על חלק ניכר מהאינטרנט) תוחזק על ידי שניים שלושה אנשים ללא תמיכה ארגונית משמעותית.
כדאי שתקצו משאבים לתחזוקת קוד פתוח. לא כנדיבות, אלא כניהול סיכונים. כמו שאתם מתקצבים אבטחה ו-SLA, תקצבו את היסודות שעליהם אתם בנויים.
AI ובעלות על קוד: הסיפור הלא נכון
בפרויקט chardet (ספריית Python לזיהוי תווים עם 2,400 כוכבים) ניסה מתחזק אחד להחליף את הקוד כולו בקוד שנוצר על ידי AI ולשנות את הרישיון. הדיון ברשת: "האם שכתוב קוד ב-AI מאפשר רישוי מחדש?"
אבל זו השאלה הלא נכונה.
כמתחזק של פרויקט CNCF, אני יכול לומר: כתיבת הקוד אף פעם לא הייתה עיקר העניין בקוד פתוח. הבעלות על פרויקט קוד פתוח היא ניהול תהליכי האינטגרציה, הפריסה, הבדיקות, התיעוד, וניהול תקלות. זה המשאב שנבנה לאורך שנים, שאי אפשר לשכתב ב-AI.
אי אפשר פשוט להחליף את המנוע ולקרוא לזה מכונית אחרת, חדשה, בנויה מאפס. השלדה, המותג, הקשרים, אמון הקהילה, מוניטין המשתמשים, ההחלטה איך לדלוור את המוצר למשתמש: הם מגדירים את הרכב.
יש כאן גם אזהרה עמוקה יותר לכל מנהל טכנולוגיה: כשתלות ב-AI הופכת לכלי לעקיפת תרומות מקוריות, אתם מסכנים את אמון הקהילה שהופכת פרויקטים לחיים. הפיצול הוא תמיד האפשרות, אבל הקהילה שלא עוברת איתך היא לא עוד נכס שיש לך.
נקודות לסיכום
שלושת הסיפורים האלה (צאר האיכות של מיקרוסופט, chardet, ומתנדבי הקוד הפתוח) מדברים על מנהיגות בסביבה שבה הכלים משתנים, אבל עקרונות המנהיגות לא:
- שינוי ארגוני דורש סמכות + תקציב + אחריות. כל מרכיב בנפרד לא מספיק.
- הקוד הפתוח שאתם מסתמכים עליו הוא תלות, לא רקע. ניהלו אותו בהתאם.
- AI משנה מי כותב קוד, לא מי אחראי עליו. האחריות נשארת אצלכם.