כותרות TheMarker >
    ';

    פרטי קהילה

    מחקר ופיתוח

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

    אינטרנט והייטק

    חברים בקהילה (1517)

    eicher077
    1. שלח הודעה
    2. אוף ליין
    3. אוף ליין
    היזם
    1. שלח הודעה
    2. אוף ליין
    3. אוף ליין
    nonetheless
    1. שלח הודעה
    2. אוף ליין
    3. אוף ליין
    אמיר לשם
    1. שלח הודעה
    2. אוף ליין
    3. אוף ליין
    ששת שצ
    1. שלח הודעה
    2. אוף ליין
    3. אוף ליין
    kobi345
    1. שלח הודעה
    2. אוף ליין
    3. אוף ליין
    יוסי קרמר
    1. שלח הודעה
    2. אוף ליין
    3. אוף ליין
    לואיס קרול
    1. שלח הודעה
    2. אוף ליין
    3. אוף ליין
    תנועת כמוך
    1. שלח הודעה
    2. אוף ליין
    3. אוף ליין
    פטשניק
    1. שלח הודעה
    2. אוף ליין
    3. אוף ליין

    Eclipse - איך בונים פרויקט קוד פתוח מצליח

    3/10/07 22:01
    0
    דרג את התוכן:
    2008-01-08 23:27:00
    1. שלח הודעה
    2. אוף ליין
    3. אוף ליין

    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 - איך בונים פרויקט קוד פתוח מצליח"

    נא להתחבר כדי להגיב.

    התחברות או הרשמה   

    14/12/07 22:55
    0
    דרג את התוכן:
    פורסם ב: 2007-12-14 22:55:55
    1. שלח הודעה
    2. אוף ליין
    3. אוף ליין

    תודה גנאדי, בהחלט ממצה ומעניין.

    16/12/07 00:52
    0
    דרג את התוכן:
    פורסם ב: 2007-12-16 00:52:57
    1. שלח הודעה
    2. אוף ליין
    3. אוף ליין
    תודה ליאור!

    --
    מנהל קהילת מחקר ופיתוח:
    http://randd.cafe.themarker.com
    8/1/08 23:27
    0
    דרג את התוכן:
    פורסם ב: 2008-01-08 23:27:00
    1. שלח הודעה
    2. אוף ליין
    3. אוף ליין

    שלום לכולם,

     

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

     

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

    1. מידת ההתאמה של הכלי לארכיטקטורת החומרה ולמערכת ההפעלה על גביהן הוא ירוץ.

    2. מידת ההתממשקות של הכלי ליישומים חיצוניים שכבר רצים בארגון (ניהול תצורה, אבטחת מידע, ניטור ובקרה ועוד).

    3. מידת ההתאמה של הכלי לסביבת העבודה שהארגון מעדיף, לשפת התכנות ולטכנולוגיות השונות:  Web, Java, C, RealTime, SOA, סלולר ועוד).

    4. נוחות הממשק (כולל פונקציונאליות של refactoring).

    5. יעילות העבודה וזמני תגובה.

    6. אמינות.

    7. יכולות הרחבה (plugins).

    8. ניתן לחשוב על עוד.

     

     גיא

     



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

    /null/text_64k_1#

    מה אתם חושבים? מעתה קל יותר להוסיף תגובה. עוד...
     

    הוספת תגובה על "Eclipse - איך בונים פרויקט קוד פתוח מצליח"

    נא להתחבר כדי להגיב.

    התחברות או הרשמה