Eclipse נחשב לאחד מפרוייקטי הקוד הפתוח המוצלחים ביותר, הודות לנתח שוק של יותר מ-60% מסביבות הפיתוח לג'אווה, כמות השותפים והמוצרים שנבנו על בסיסו ולאיכות המעולה של קוד המקור. כבר כמה שנים טובות, יוצא כל יולי release חדש של Eclipse, מלא ב-features חדשים וללא יום של דחייה. מאמר זה סוקר את הפרוייקט מזווית הפיתוח ומהזווית הקהילתית/עסקית.
(גרסה נוספת ופחות טכנית של הדיון פורסמה בקהילת ה-IT)
הקדמה
ראשית, קצת רקע היסטורי. השנה היא שנת 2000 ושפת ה-Java מתחילה לתפוס תאוצה. בשוק כבר קיימים מספר כלים וסביבות לפיתוח תכניות Java. ביניהם ה-Emacs הוותיק, ה-Forte של סאן, ה-JBuilder של בורלנד, ה-Visual Café של סימנטק וה-Visual Age של IBM. פרט ל-Emacs וה-Forte החינמיים כל הכלים עולים לא מעט כסף ולא מספקים את הסחורה. ה-JBuilder איטי להחריד, ה-Visual Café הוצא לחברת הבת Webgain שלא הצליחה להחזיק ולפתח את המוצר ונסגרה כשנה אח"כ. ה-Visual Age היה התאמה של סביבת ה-Smalltalk של IBM לשפת ה-Java ובעצמו היה כתוב ב-Smalltalk. הכלי עצמו היה מעולה ופונקציונלי ביותר אך עקומת הלימוד התלולה והיותו תקוע ב-Java 1.2 כאשר העולם דרש תמיכה ב-Java 1.3, הקשו על שיווקו. ה-Forte, אגב היה כל כך בלתי ניתן לשימוש עד שפשוט התייאשתי.
הצד הטכנולוגי
IBM הייתה זקוקה לסביבת פיתוח חדשה, והיא מצאה את הבסיס למוצר החדש בחברת הבת OTI הקנדית. על בסיס סביבה זו, התחילה לפתח את סביבת ה-Eclipse. בהקשר הטכנולוגי, קיבלו ב-IBM כמה החלטות שהתבררו כנכונות. ראשית, הוחלט לפתח את הסביבה עצמה ב-Java ולא ב-C++ למשל. פרט לנושא התדמיתי הדבר הוביל למעורבות גדולה יותר של המפתחים כלפי הסביבה, כי כבר משלב מוקדם הם היו גם המפתחים וגם המשתמשים הראשונים שלה. לכן הם דיווחו על באגים לעמיתיהם או פשוט תיקנו אותם בעצמם. הם קראו לזה – Eating your own dog food. החלטה חשובה נוספת הייתה לפתח ספריית UI רזה ובעיקר מהירה (SWT), כמענה לספריית ה-UI הסטנדרטית של Java שבאותה תקופה הייתה איטית ומכוערת להחריד (מה שהיה למכשול לסביבות האחרות כמו Forte ו-JBuilder).
בצד האנושי גייסה IBM לפרויקט את Erich Gamma, אחד ממחברי הספר המפורסם Design Patterns והוא השתתף בצורה פעילה בתכנון ובפיתוח הארכיטקטורה.
יכולות הממשק וההרחבות
אכן הנושא החשוב ביותר והחדשני ביותר היה הארכיטקטורה הבסיסית. סביבת Eclipse תוכננה מראש כסביבה פתוחה, שמאפשרת תוספות והרחבות באמצעות מנגנון של plug-ins. התפיסה הייתה חדשנית בכך שהגדירה שכל דבר בסביבת Eclipse, למעט core קטן ביותר הוא plug-in. בצורה טבעית, Plug-in יכול להיות תלוי ב-plug-in אחר ולחשוף שירותים בעצמו ל-plug-ins נוספים. אולם, הדבר המלהיב ביותר במנגנון הזה הוא בהפרדה מוחלטת בין שפת התקשורת בין plug-ins למממשים ולמשתמשים. כך למשל, קיים ב-Eclipse מנגנון של הרחבת תפריטים בפעולות נוספות. נניח ש-Plug-in מסוים החליט שהוא מציג תפריט Right Click כאשר לוחצים לחיצה ימנית על קובץ שהוא אחראי עליו. Plug-in אחר החליט שהוא רוצה להוסיף פעולת Right Click לכל הקבצים שמסתיימים בסיומת XML. ה-Plug-in השני יכול להצהיר על הפעולה הזאת, וכל ה-plug-ins שמציגים תפריטי לחיצה ימנית על קובץ יוסיפו את הפעולה, וכך גם ה-plug-in הראשון שלנו. היופי בשיטה הוא שאותו plug-in ראשון לא צריך להכיר כלל את ה-plug-in השני, וכך גם להיפך. כל מה שכותב ה-plug-in הראשון צריך לעשות הוא להצהיר שהוא תומך בהרחבות, וכל ההרחבות, כולל הפעולה הייחודית לקבצי XML ייתוספו אוטומטית. כך מתקיים לו ממשק בין שני plug-in שלא מכירים אחד את השני. וכדי לוודא שהמנגנון עובד – כל ה-plug-ins המרכיבים את Eclipse מדברים בצורה כזאת אחד עם השני. לכן, כאשר מישהו כותב plug-in חדש הוא לא צריך לחפש דרך צדדית כדי להתחבר, אלא הוא נכנס לסביבה דרך הכניסה הראשית.
הצד הקהילתי והעסקי
מנגנון ההרחבות של Eclipse מביא אותנו לנושא הקהילתי. אמנם IBM השקיעו בפרויקט סכום ראשוני של 40 מליון דולר, אבל ב-IBM הבינו שאם ישמרו את הפלטפורמה לעצמם הם ייתקעו עם עוד מוצר proprietary שלא כל כך מעניין את מי שלא עובד עם טכנולוגיות של IBM. לכן, כבר עם ההשקה הראשונית הם הפכו את הפרויקט לפרויקט קוד פתוח. רשיון הקוד הפתוח של IBM (CPL ואח"כ EPL) הוא בין הבודדים שמאפשר שימוש חופשי ומסחרי בקוד הפתוח, וזאת לעומת רשיון GPL הנפוץ שלא מאפשר שימוש מסחרי כלל (ולעומת שלל הרשיונות הדואליים הקיימים). בנוסף לרשיון הקוד הפתוח ושקיפות מלאה בתהליכי הפיתוח (bugzilla, רשימות תפוצה פנימיות וכד'), IBM גם יצרה קהילה של שותפים עסקיים שהתחייבו להשתתף ב-Eclipse, לתרום לו קוד ולבסס את מוצריהם על בסיס הפלטפורמה (כך למשל הדור החדש של ה-JBuilder של בורלנד הוא מבוסס Eclipse).
Eclipse היום היא לא רק סביבה ל-Java. היום מפותחים plug-ins להרבה שפות וסביבות פופולריות, כמו c++, פייתון, php (ע"י חברת זנד הישראלית) ועוד.
אז מה יוצא מכך ל-IBM? המודל העסקי של Eclipse אומר שאמנם החברות יתרמו את הקוד בחינם ואף ירשו לכל אחד לעשות שימוש מסחרי בקוד, אבל בתמורה הן יקבלו פלטפורמה יציבה ואת הזכות לעשות את אותו שימוש מסחרי בקוד של אחרים. כך למשל חברת בורלנד יכולה למכור את ה-JBuilder שכולל קוד שנכתב ע"י IBM וחברות אחרות, ללא צורך לקבל רשות מאף אחד. IBM בונה כמובן את הכלים שלה על בסיס Eclipse ומוכרת אותם במחירים לא זולים.
בשלב מסוים אף החליטה IBM להנתק מהשליטה הישירה בפרויקט ויצרה את Eclipse – הארגון ללא מטרות רווח שמקדם את הפלטפורמה והכלים המבוססים עליה. החברות המסחריות ששותפות ל-Eclipse תורמות את הקוד לפרויקט ומפתחות את המוצרים. מעמדה של IBM בארגון הוא כשל חברה שווה, למרות ש-IBM עדיין מייצרת את מרבית הקוד של Eclipse.
סיכום
לסיכום, סביבת Eclipse היא סביבה פתוחה לפיתוח Java ובעלת הרחבות חופשיות ומסחריות למגוון רחב של שפות וצרכי פיתוח. המודל המסחרי עליו מבוסס Eclipse מזמין חברות ומפתחים רבים לפתח הרחבות ומוצרים משלימים לסביבה. המאמר הזה נגע ממש בקצה המזלג בפרויקט הענק הזה שרץ כבר 6 שנים והוא אחד מפרויקטי הקוד הפתוח המצליחים ביותר. למידע נוסף בקרו באתר http://www.eclipse.org/
ופינת "הידעת?"
- השם Eclipse התחיל כשם קוד פנימי (אולי מרמז על התחרות מול חברת Sun), אבל כנראה שהיה כל כך מוצלח עד שהוחלט להשאירו.
- סימנטק היתה בין הראשונות (לפני סאן) שפיתחה מנוע JIT ל-java
עוד מעניין לראות את אחד הראיונות הראשונים על Eclipse:
http://www.ibm.com/developerworks/linux/library/l-erick.html
הוספת תגובה על "Eclipse - איך בונים פרויקט קוד פתוח מצליח"
נא להתחבר כדי להגיב.
התחברות או הרשמה