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

Eclipse נחשב לאחד מפרוייקטי הקוד הפתוח המוצלחים ביותר, הודות לנתח שוק של יותר מ-60% מסביבות הפיתוח לג'אווה, כמות השותפים והמוצרים שנבנו על בסיסו ולאיכות המעולה של קוד המקור. לאחרונה בחרו בגוגל ב-Eclipse כסביבת הפיתוח הרשמית שלהם עבור פרויקט ה-Android (הפלטפורמה החדשה לטלפונים סלולריים). מאמר זה סוקר את הפרוייקט ומנסה להדגיש את הנקודות שגרמו להצלחה הרבה של הפרויקט.

הקדמה

ראשית, קצת רקע היסטורי. השנה היא שנת 2000 ושפת ה-Java מתחילה לתפוס תאוצה. בשוק כבר קיימים מספר כלים וסביבות לפיתוח תכניות Java. ביניהם ה-Emacs הוותיק, ה-Forte של סאן, ה-JBuilder של בורלנד, ה-Visual Café של סימנטק וה-Visual Age של IBM. פרט ל-Emacs וה-Forte החינמיים כל הכלים עולים לא מעט כסף ולא מספקים את הסחורה. ה-JBuilder היה איטי להחריד, ה-Visual Café הוצא לחברת הבת Webgain שלא הצליחה להחזיק ולפתח את המוצר ונסגרה כשנה אח"כ. ה-Visual Age היה התאמה של סביבת ה-Smalltalk של IBM לשפת ה-Java. ואם זה נשמע כמו patch, כזה הוא היה (למרות מספר תכונות חדשניות ויוצאות דופן).

הצד הטכנולוגי

IBM הייתה זקוקה לסביבת פיתוח חדשה, והיא מצאה את הבסיס למוצר החדש בחברת הבת OTI הקנדית. על הבסיס הרעיוני של סביבה זו, התחילה לפתח את סביבת ה-Eclipse. בהקשר הטכנולוגי, קיבלו ב-IBM כמה החלטות שהתבררו כנכונות. ראשית, הוחלט לפתח את הסביבה עצמה ב-Java ולא ב-C++ למשל (לפעמים קוראים לזה eating your own dog food). הדבר הוביל למעורבות גדולה יותר של המפתחים כלפי הסביבה, כי כבר משלב מוקדם הם היו גם המפתחים וגם המשתמשים הראשונים שלה. החלטה חשובה נוספת הייתה לפתח ספריית UI רזה ובעיקר מהירה (SWT), כמענה לספריית ה-UI הסטנדרטית של Java שבאותה תקופה הייתה איטית ומכוערת להחריד (מה שהיה למכשול לסביבות האחרות כמו Forte ו-JBuilder).  סביבת ה-SWT אמנם נוסתה עוד קודם במוצר אחר של OTI אבל הייתה חדשנית בכל זאת (והיא שנויה במחלוקת בין מפתחי ה-Java גם כיום).

בצד האנושי גייסה IBM לפרויקט את Erich Gamma, אחד ממחברי הספר המפורסם Design Patterns והוא השתתף בצורה פעילה בתכנון ובפיתוח הארכיטקטורה של הפרויקט.

פתיחות הממשק ותמיכה בהרחבות

הנושא החשוב ביותר והחדשני ביותר ב-Eclipse היה הארכיטקטורה הבסיסית. סביבת Eclipse תוכננה מראש כסביבה פתוחה, שמאפשרת תוספות והרחבות באמצעות מנגנון של plug-ins. התפיסה הייתה חדשנית בכך שהגדירה שכל דבר בסביבת Eclipse, למעט core קטן ביותר הוא plug-in. בצורה טבעית, Plug-in יכול להיות תלוי ב-plug-in אחר ולחשוף שירותים בעצמו ל-plug-ins נוספים. היופי במנגנון הוא האפשרות לשני plug-ins לדבר אחד עם השני בעזרת מנגנוני XML וללא צורך של plug-in אחד להכיר את ה-plug-in השני.

כדי לוודא שהמנגנון עובד - כל ה-plug-ins המרכיבים את Eclipse מדברים בצורה כזאת אחד עם השני. "Eating your own dog food", כבר אמרנו? בנוסף, היות שהקוד פתוח וזמין לכולם, כל אחד יכול למצוא אינספור דוגמאות להרחבות כאלה בתוך Eclipse עצמו.

בנקודה זו Eclipse שונה מאוד מהרבה מאוד פרויקטים אחרים שפיתוח ההרחבות אליהם הוא מורכב ומסובך הרבה יותר. 

אז איך בונים פרויקט קוד פתוח?

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

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

הצד הקהילתי

מנגנון ההרחבות והרישוי הנוח של Eclipse הוא הבסיס לבניית "קהילת Eclipse". רשיון הקוד הפתוח של IBM (CPL ואח"כ EPL) הוא בין הבודדים שמאפשר שימוש חופשי ומסחרי בקוד הפתוח, וזאת לעומת רשיון GPL הנפוץ שלא מאפשר שימוש מסחרי כלל (ולעומת שלל הרשיונות הדואליים הקיימים שבהם התורמים מרשים לבעלי הפרויקט גם שימוש מסחרי מלא).

IBM גם יצרה קהילה של שותפים עסקיים שהתחייבו להשתתף ב-Eclipse, לתרום לו קוד ולבסס את מוצריהם על בסיס הפלטפורמה (כך למשל הדור החדש של ה-JBuilder של בורלנד הוא מבוסס Eclipse). לשותפים "הגדולים" אלה יש כמובן עניין עסקי טהור וחלקם אף שותפים ב-Eclipse Foundation ומנסים להשפיע על "מפת הדרכים" של Eclipse. אבל קיימת גם קהילה גדולה של שותפים "קטנים" שמפתחים הרחבות ומספקים את מגוון הצרכים שלא באים לידי סיפוק על ידי החברות הגדולות. כיום רשומים באתר ההרחבות הרשמי יותר מ-1000 הרחבות שונות (חלקן קוד פתוח וחלקן מסחריות). עושר הרחבות זה מתחרה בהצלחה בהרחבות ל-Visual Studio של מיקרוסופט.

Eclipse היום היא לא רק סביבה ל-Java. היום מפותחים plug-ins להרבה שפות וסביבות פופולריות, כמו c++, פייתון, php (ע"י חברת זנד הישראלית) ועוד.

הצד העסקי

IBM לא היו חייבים להוציא את Eclipse כפרוייקט קוד פתוח. רוב סביבות הפיתוח שרצו בזמנו על windows לא היו פרויקטי קוד פתוח. עם השקעה מתוכננת של 40 מליון דולר צעד זה בוודאי לא היה קל, אבל IBM חשבו שיוכלו לעשות יותר כסף עם Eclipse כפלטפורמה פתוחה.
אז מה יוצא מכך ל-IBM? המודל העסקי של Eclipse אומר שאמנם החברות יתרמו את הקוד בחינם ואף ירשו לכל אחד לעשות שימוש מסחרי בקוד, אבל בתמורה הן יקבלו פלטפורמה יציבה ואת הזכות לעשות את אותו שימוש מסחרי בקוד של אחרים. כך למשל חברת בורלנד יכולה למכור את ה-JBuilder שכולל קוד שנכתב ע"י IBM וחברות אחרות, ללא צורך לקבל רשות מאף אחד. IBM בונה כמובן את הכלים שלה על בסיס Eclipse ומוכרת אותם במחירים לא זולים בכלל.

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

סיכום

לסיכום, סביבת Eclipse היא סביבה פתוחה לפיתוח Java ובעלת הרחבות חופשיות ומסחריות למגוון רחב של שפות וצרכי פיתוח. המודל המסחרי עליו מבוסס Eclipse מזמין חברות ומפתחים רבים לפתח הרחבות ומוצרים משלימים לסביבה. המאמר הזה נגע ממש בקצה המזלג בפרויקט הענק הזה שרץ כבר 6 שנים והוא אחד מפרויקטי הקוד הפתוח המצליחים ביותר. למידע נוסף בקרו באתר http://www.eclipse.org/

ופינת "הידעת?"

• השם Eclipse התחיל כשם קוד פנימי (אולי מרמז על התחרות מול חברת Sun), אבל כנראה שהיה כל כך מוצלח עד שהוחלט להשאירו.

עוד מעניין לראות את אחד הראיונות הראשונים על Eclipse:
http://www.ibm.com/developerworks/linux/library/l-erick.html

זה כלי נהדר.

כל טכנולוגיה חדשה שניסיתי, היה לי נוח לעבוד איתה מכיוון שהיה תוסף ל eclipse.

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

הי יונתן,

יש כמובן איזורים ספציפיים שבהם Eclipse הוא לא הכלי האידאלי (כמו למשל עבור c++ על windows), אבל ה-design שלו מאפשר לו להשתפר בקלות יחסית.

במקרה הספציפי של PHP קיימים בשוק מספר plug-ins חינמיים מתחרים ולאחרונה התווסף ל-Eclipse עצמו גם כלי PHP שפותח ע"י Zend: (לפרויקט קוראים PDT)

http://www.eclipse.org/pdt/

כמובן ש-Zend או כל אחד אחר יכולים להרחיב אותו בצורה חופשית או מסחרית.

גנאדי

חידשת לי הרבה על ההיסטוריה של הכלי.

אני אישית משתמש בכלי כבר מספר שנים ולא מוכן להחליף אותו

אני משתמש בו לפיתוח בJAVA ובPHP.

הכלי הוא מאוד חזק ,ובעל יכולות מדהימות,

שמקצרות את תהליך הפיתוח והופכים אותה למאוד נחה.

כל הכבוד. 

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

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

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

הגב העסקי (IBM, עכשיו בורלנד ועוד) תורם יציבות, אינטגרציה ואפליקציות מורכבות בתשלום, תמיכה מקצועית ברמה גבוהה ועוד.

שוב תודה ושבוע טוב,

אודי 

הי גנאדי. פוסט טוב.

אותי מעניין השלב הבא והוא אפליקציות עסקיות וקוד פתוח

כאן הסיבוך הכלכלי (במיוחד לטווח ארוך) עולה והתמונה פחות ברורה.

למשל הפוסט המעניין הבא דן בנושא בדרך של סיפור על מנמ"ר שניסה את זה

http://arielt11.blogspot.com/2007/11/when-business-applications-meet-open.html

תודה לכולם על הכוכבים!

אריאל - אני חושב שכל כלי או תשתית שמכניסים לארגון צריכים להיבחן לפי כל הקריטריונים הרגילים, כמו שפירטת בבלוג, ועלות היא רק פרמטר אחד. יש אכן פרויקטי קוד פתוח באיכות ורמת תמיכה שלא מתאימים לסביבות שהן mission critical. אני לא רוצה להישמע כמו פרסומת, אבל בין השאר יבמ מוכרת שירותי תמיכה גם ל-Eclipse הבסיסי (בנוסף לתמיכה למוצרים שאפשר לקבל ממנה ומ-borland וחברות אחרות).

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

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

הערה קטנה לגבי הרשיון.

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

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

צטט: ori_idan 2007-12-10 19:47:08

הערה קטנה לגבי הרשיון.

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

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

 

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

ההבדל בין הרשיונות הוא בין השאר בבניה של הרחבות ותוספות. ב-EPL ההרחבות (plug-ins של Eclipse) לא חייבים להיות EPL וניתן להפיץ (את ההרחבות!) כקוד סגור, בעוד שב-GPL כל ההרחבות חייבות להיות GPL (ולכן קוד פתוח) גם כן (ויהיה קשה למכור אותן). EPL הוא נוח יותר לסביבה מסחרית ומעודד צמיחה של שותפים עסקיים גדולים כקטנים, שלא כולם יכולים לחיות רק משירותי יעוץ ותמיכה. הסיבה שפיתחו את EPL ולא השתמשו ברשיון קוד פתוח קיים היא לדעתי יותר עניין של שליטה בעדכונים עתידיים של הרשיון.

צטט: גנאדי 2007-12-09 10:15:24

תודה לכולם על הכוכבים!

אין צורך להצטנע.

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

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

בינתיים "סביבת הפיתוח" שלי היא vi, בשילוב ...gcc+make+etc 

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

אבל אני כמובן חורג מנושא הדיון...

אז בקיצור, תודה על מאמר מאלף!

אלי, תודה :)

עדיין לא שמעתי על סביבת פיתוח וובית "מלאה", אבל ב-Eclipse יש פרויקט שנקרא RAP והוא עושה צעד בכיוון:

http://www.eclipse.org/rap/

http://rap.eclipse.org/rapdemo/rms

http://eclipsediscovery.yoxos.com/discovery/rap

גנאדי