בחירת ספרייה או מסגרת של JavaScript

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

מהן ספריות ומסגרות של JavaScript

מהי ספריית JavaScript? בצורתה הפשוטה ביותר, ספריית JavaScript היא קוד שנכתב מראש שניתן לקרוא בקוד של הפרויקט כדי להשיג משימה ספציפית.

בפוסט הזה מוזכר בעיקר "ספריות". עם זאת, רוב הדיונים רלוונטיים גם למסגרות. בעיקרון, ניתן לסכם את ההבדל בין השניים באופן הבא:

• עבור ספרייה, קוד האפליקציה מפעיל את קוד הספרייה.
• במסגרת, ה-framework קוראת לקוד האפליקציה שלכם.

הדוגמאות המעשיות הבאות עוזרות להמחיש את ההבדלים.

קריאה לדוגמה לספריית JavaScript

ספריית JavaScript מבצעת משימה ספציפית ולאחר מכן מחזירה את הבקרה לאפליקציה שלכם. כאשר משתמשים בספרייה, אפשר לשלוט בתהליך העבודה של האפליקציה ומחליטים מתי להפעיל את הספרייה.

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

import capitalize from 'lodash.capitalize';
capitalize('hello'); // Hello

כשמפעילים את השיטה lodash.capitalize, המערכת קוראת לקוד JavaScript שנכתב מראש, באותיות רישיות בתו הראשון של מחרוזת.

שימוש לדוגמה במסגרת JavaScript

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

הדוגמה הבאה מציגה קטע קוד שמשתמש ב-JavaScript framework Preact:

import { createElement } from 'preact';

export default function App() {
  return (
    <p class="big">Hello World!</p>
  )
}

לדוגמה, שימו לב של-framework יש הרבה יותר שליטה על הקוד שכותבים, ובמקרים מסוימים ה-framework אפילו קובע מתי להפעיל את הקוד.

למה כדאי להשתמש בספרייה?

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

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

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

בסופו של דבר, השימוש בספריית JavaScript חוסך לך זמן.

מדוע השימוש בספרייה חשוב לך?

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

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

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

יש סביבות JavaScript שלא בצד הלקוח, למשל בשרת (בסביבת ענן) או ב-Raspberry Pi, ויכול להיות שתצטרכו לשנות את הקריטריונים שבהם אתם משתמשים כדי לבדוק את הספריות והמסגרות.

ביצועים

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

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

ככל שספריית ה-JavaScript גדולה יותר, כך השפעת הביצועים על המשתמשים גדולה יותר.

כשמבצעים הערכה של הספרייה או framework של JavaScript או משתמשים בהם, כדאי לשקול את ההצעות הבאות כדי לשפר את הביצועים:

• בהינתן ספריית JavaScript גדולה, כדאי להשתמש בחלופה קטנה יותר. לדוגמה, date-fns מציע פונקציונליות רבה בגודל סביר יותר מאשר אפשרויות אחרות.
• בהמשך מהדוגמה הקודמת של fn-snad, ייבא רק את הפונקציות הנחוצות לך, כגון: import { format } from 'date-fns'. הקפידו לשלב את הגישה הזו עם ניעור עצים, כדי לבנות מטען ייעודי (payload) מינימלי של JavaScript ולשלוח אותו למשתמשים.
• אפשר להשתמש בכלים לבדיקת ביצועים כמו Lighthouse כדי לבחון את ההשפעה על הביצועים של שימוש בספריית JavaScript מסוימת. אם ספרייה גורמת לעיכוב של שנייה אחת בזמן הטעינה של הדף (אל תשכחו לווסת את הרשת והמעבד (CPU) במהלך הבדיקה), ייתכן שתצטרכו להעריך מחדש את הספרייה שבחרתם. בנוסף לבדיקה של טעינת הדף, הקפידו להוסיף לפרופיל כל התנהגות של דף אינטרנט שמפעילה קוד מהספרייה הרלוונטית - הביצועים של טעינת דפים לא מציגים את הסיפור המלא.
• אם מחבר הספרייה מקבל בברכה תגובות, אפשר לשלוח את תצפיות על הביצועים, הצעות ואפילו תרומות לפרויקט. זה המקום שבו קהילת הקוד הפתוח פועלת! אם תחליטו לתרום, ייתכן שתצטרכו לברר תחילה עם המעסיק שלכם.
• אפשר להשתמש בכלי אוטומטי למעקב אחר חבילות, כמו bundlesize, כדי לבדוק אם יש עדכונים גדולים ובלתי צפויים בספרייה. לעיתים קרובות, ספריית JavaScript גדלה עם הזמן. הוספות של תכונות, תיקוני באגים, מקרי קצה ועוד – כל אלה יכולים להוסיף לגודל הקובץ של הספרייה. לאחר שאתם או הצוות שלכם הסכמתם להשתמש בספרייה, עדכון הספרייה עשוי להיות פחות בעיה ולהוביל לשאלות של מעט מאוד אפסי. במקרים כאלה כדאי להסתמך על אוטומציה.
• בדקו את הדרישות שלכם לספרייה ובדקו אם פלטפורמת האינטרנט מציעה את אותה פונקציונליות במקור. לדוגמה, פלטפורמת האינטרנט כבר כוללת בוחר צבעים, שמסיר את הצורך להשתמש בספריית JavaScript של צד שלישי כדי להטמיע את אותה פונקציונליות.

אבטחה

לשימוש במודול של צד שלישי יש סיכוני אבטחה מובנים. חבילה זדונית בתוך ה-codebase של אפליקציית האינטרנט שלך עלולה לפגוע באבטחה של צוות הפיתוח ושל המשתמשים.

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

הנה כמה טיפים בנושא אבטחה שכדאי לשקול כאשר משתמשים בקוד של צד שלישי או מעריכים אותו:

• אם אתם משתמשים ב-GitHub, כדאי לשקול את הצעות האבטחה של הקוד, כמו Dependabot. לחלופין, כדאי לשקול שירותים חלופיים שסורקים לאיתור נקודות חולשה בקוד, כמו snyk.io.
• כדאי להשתמש בשירותי בקרת קוד, צוות של מהנדסים שיכולים לבדוק באופן ידני את הקוד של צד שלישי שבו אתם משתמשים.
• נסו לבדוק אם צריך לנעול את יחסי התלות בגרסה ספציפית או להחיל את הקוד של צד שלישי במסגרת בקרת הגרסאות. כך אפשר לנעול את התלות בגרסה ספציפית אחת שנחשבת בטוחה. באופן אירוני, יכולה להיות לכך השפעה שלילית בתחום האבטחה, כי אתם עלולים לפספס עדכונים חיוניים בספרייה.
• סורקים את דף הבית של הפרויקט או את דף GitHub, אם קיים. לבדוק אם קיימות בעיות אבטחה שעדיין לא טופלו, והאם בעיות אבטחה קודמות נפתרו בתוך פרק זמן סביר.
• קוד של צד שלישי שמשתמש בקוד אחר של צד שלישי עלול להיות בסיכון גבוה יותר מאשר ספרייה שיש בה אפס יחסי תלות. חשוב להיות מודעים לסיכון הזה.

נגישות

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

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

• האם הפלאגין של הטיפוגרפיה הרספונסיבי תומך במשתמשים שמגדילים או מקטינים את הדף?
• האם הפלאגין להעלאת קבצים תומך בהעלאות קבצים ממכשירים מסייעים?
• האם ספריית האנימציה מציעה תמיכה למשתמשים שמעדיפים להפחית את התנועה?
• האם הפלאגין של המפות האינטראקטיביות תומך בשימוש במקלדת בלבד?
• האם ספריית נגן האודיו מציעה חוויה מתאימה בקוראי מסך?

סביר להניח שתידרש רמה מסוימת של מעורבות ממך, מפתח האתר, כדי לעמוד בדרישות נגישות כאלה. לדוגמה:

• אם חסרות תכונות, תוכלו להטמיע אותן בתוך ה-codebase שלכם, גם אם תמשיכו להשתמש בספרייה הרלוונטית.
• בעזרת התמיכה של המעסיק שלכם, תוכלו לתרום תכונה כזו שחסרה בספרייה, אם מחבר הספרייה מאפשר תרומה כזו.
• אפשר לפתוח תיבת דו-שיח עם מחבר הספרייה. לדוגמה, האם תכונות הנגישות הספציפיות האלה מופיעות במפת הדרכים שלכם? האם אתם מסכימים שהם שייכים לספרייה?
• בתרחישים נפוצים לדוגמה, אתם יכולים לבדוק אפשרויות נגישות יותר של ספריות. יכול להיות שהן קיימות אבל קשה יותר למצוא אותן.
• במקרה קיצוני, ייתכן שתצטרכו לוותר על הספרייה לחלוטין וליישם את התכונות שלכם מאפס. מצב כזה יכול לקרות כשחוויית הנגישות בספרייה או ב-framework נחלשת, וצריך לבטל חלק גדול ממה שהספרייה או ה-framework מעניקים לכאורה בחינם.

כנסים

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

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

• חשוב להבחין בין קוד המקור של הספרייה לבין ה-API שגלוי לכם (משתמשי הספרייה). קוד המקור הפנימי עשוי להשתמש במוסכמות לא מוכרות, אבל אם ה-API (החלק של הספרייה שאיתו אתם מקיימים אינטראקציה) משתמש במוסכמות מוכרות, אין סיבה לדאגה.
• אם ה-API של הספרייה לא פועל בהתאם למוסכמות התכנות הנפוצות, אפשר להשתמש בדפוס עיצוב של JavaScript, כמו דפוס שרת ה-proxy, כדי לעטוף את כל האינטראקציות עם הספרייה בקובץ אחד ב-codebase. לאחר מכן, שרת ה-proxy יכול להציע ממשק API אינטואיטיבי יותר לחלקים אחרים של הקוד ב-codebase.

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

עדכונים

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

כשבוחרים ספרייה או מסגרת, שימו לב לאופן הטיפול בעדכונים ושימו לב שההחלטות האלה יכולות להשפיע עליכם:

• האם לספרייה יש לוח זמנים סביר לפרסום? לדוגמה, עדכונים למאגר קוד המקור עשויים להתרחש לעיתים קרובות, אבל אם עדכונים כאלה לא 'פורסמו' או 'פורסמו' בהתאם, יכול להיות שתתקשו להוריד עדכונים כאלה.
• האם הספרייה מפרסמת עדכונים באמצעות סכימה הגיונית של ניהול גרסאות תוכנה? ספרייה אמורה לחסוך לכם זמן. אם אתם צריכים לשנות את הקוד באופן בלתי צפוי בכל פעם שאתם מעדכנים את גרסת הספרייה, זה עלול לבטל את המטרה של השימוש בספרייה הזו מלכתחילה. לפעמים בלתי נמנעים משינויים שעלולים לגרום לכשל, אבל באופן אידיאלי, שינויים בלתי תכופים ואינם מאולצים על ידי צרכני הספרייה.
• האם הספרייה משקיעה מאמץ בתאימות לאחור? לפעמים עדכוני תוכנה יכולים לכלול שינויים שעלולים לגרום לכשלים, אבל גם מספקים שכבה של תאימות לאחור. כך צרכן הספרייה יכול להשתמש בגרסת הספרייה העדכנית ביותר עם שינויים קלים בקוד שלו.

רישוי

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

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

אם יש לכם ספק, מומלץ לפנות לייעוץ משפטי מקצועי או לפנות לצוות המשפטי של החברה.

מעורבות

ספרייה או מסגרת שיש בה קהילה גדולה של משתמשים/תורמים יכולות להועיל, אבל זו לא ערובה. באופן כללי, ככל שיש יותר משתמשים בספרייה או במסגרת, כך יש יותר סיכוי להפיק מהם תועלת. כדאי לשקול את היתרונות והחסרונות הבאים להשתתפות בקהילת פיתוח:

יתרונות:

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

חסרונות:

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

מאמרי עזרה

מסמכי התיעוד של התוכנה תמיד יכולים לעזור, בלי קשר למידת המורכבות של ספרייה או מסגרת JavaScript. גם מפתחים מנוסים מאוד משתמשים בתיעוד, במקום להבין את הקוד בעצמם. התיעוד מבהיר את ממשק ה-API שבו עליך להשתמש וכיצד יש להשתמש בו.

התיעוד יכול גם לספק קוד לדוגמה, כדי שיהיה לכם קל יותר להתחיל בעבודה במהירות. כשאתם בוחנים ספרייה או מסגרת, אתם יכולים לשאול כמה מהשאלות הבאות:

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

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

סיכום

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

יש היבטים אחרים של ספריות ומסגרות מומלץ להתייחס אליהם, שלא נדון בהם הרבה בפוסט הזה:

• הרחבה: עד כמה קל להרחיב את הספרייה באמצעות לוגיקה ו/או התנהגות בהתאמה אישית?
• דיווח: אם רלוונטי, האם הספרייה כוללת כלים כמו יישומי פלאגין לעריכת קוד, כלים לניפוי באגים ובניית יישומי פלאגין של המערכת?
• ארכיטקטורה: קוד נקי חשוב, אך האם הארכיטקטורה הכוללת של הספרייה הגיונית?
• בדיקות: האם יש לפרויקט חבילת בדיקות? האם באתר הפרויקט יש תגים או אינדיקטורים שחבילת הבדיקה מעבירה בהשוואה להתחייבות האחרונה?
• תאימות: האם הספרייה פועלת היטב עם ספריות ו/או מסגרות אחרות שבהן אתם משתמשים כרגע?
• עלות: כמה עולה מסגרת? האם זה קוד פתוח או זמין לרכישה?
• מדדי שונות: ערכי אלה צריכים להיות נמוכים ברשימת הקריטריונים שלכם, או אפילו להתעלם מהם לגמרי, אבל מומלץ לשקול 'הצבעות' בפרויקט, חשבונות במדיה חברתית שמייצגים את הפרויקט, ו/או כמה באגים/בעיות פתוחים יש בדף הפרויקט.