בעולם של היום הדבר הכי קל בפרויקט זה להוסיף תלות בעוד ספריית קוד פתוח. צריכה הצפנה? יש מודול ב pip שעושה את זה. צריך לפתוח קובץ זיפ? פשוט תריץ npm install. לפעמים נדמה לי שחצי מהעבודה שלנו היא למצוא את המודול המתאים בשביל לפתור את הבעיה.

הבעיה שכשהפרויקט מתבגר כך גם ספריית הקוד הפתוח ששילבתם, ולא בטוח שאהבת הנעורים מלפני שנתיים היא השותפה המושלמת גם לפרויקט של היום. הרבה (מאוד) ספריות קוד פתוח התחילו בתור רעיון או צורך של מתכנת פרטי, לא זכו למימון וננטשו אחרי שהפסיקו להיות "כיף" לאותם מתכנת או מתכנתת שכתבו אותם במקור. אפילו פרויקטי קוד פתוח מסחריים רבים ננטשים, כשהחברה שבנתה אותם רואה שזה לא מביא להם את יחסי הציבור הטובים אליהם הם קיוו, או כשהסטארט אפ שבנה אותם נסגר כי נגמר המימון. בקיצור זה לא מוזר בכלל לעבוד על פרויקט שחצי מהתלויות שלו כבר לא נתמכות.

ואם זה גם המקרה שלכם הנה כמה רעיונות פרקטיים שאפשר לנסות:

1. להתעלם - זוכרים את "אם זה עובד לא נוגעים"? אז הרבה פעמים אנחנו רואים פרויקטים שתלויים בספריות קוד פתוח שכבר שנים לא מתוחזקות, ולאף אחד לא אכפת. בדרך כלל בפרויקטים כאלה יהיו כל מיני כללים מוזרים כמו "אסור לשדרג את node כי אז כלום לא יעבוד", וכולם מתכננים יום אחד לשדרג את התלות הלא מתוחזקת אבל לא מגיעים לזה.

2. ליצור fork מתוחזק - כש kreeti שמו לב שספריית הריילס האהובה עליהם ננטשה, הם יצרו פורט מתוחזק. וכן יש אפילו כלי שעוזר למצוא פורקים קיימים לספריות שננטשו.

3. להיפרד מהתלות ולהמשיך הלאה - רוב הסיכויים שאם הבעיה שלכם מעניינת יש גם אנשים אחרים שנתקלו בה ויש לה פיתרונות אחרים, טובים יותר מהפיתרון הישן ההוא שכבר לא מתוחזק. בדוגמה שקישרתי אליה קודם של פייפרקליפ, יש כבר פיתרון מובנה בריילס שפותר בדיוק את אותה בעיה (זאת הסיבה שהספריה המקורית ננטשה). אם הפרויקט שלכם מספיק חשוב, שווה להשקיע את הזמן ולעבור לפיתרון החדש יותר.

האפשרות השלישית היא המועדפת עליי. למרות שאפשר להישאר עם פיתרונות ישנים ולגרום לכל דבר לעבוד, אין כמו הכיף בלעבוד על פרויקט שהכל בו חדש, ושאפשר בקלות למצוא תיעוד רלוונטי ולשלב יכולות חדשות או כלים חדשים בלי התנגשויות מוזרות.