Ontwikkelaars bezorgd over invloed IBM op Eclipse 4

Verschillende ontwikkelaars hebben hun zorgen geuit over de grote invloed die IBM heeft op het Eclipse-project. Big Blue heeft echter aangegeven niet uit te zijn op een machtsovername bij de bouwers van de softwareontwikkelomgeving.

Vorige week is door de Eclipse Foundation een lijst gepubliceerd met de namen van een aantal ontwikkelaars die toestemming hebben gekregen om nieuwe broncode aan de bestaande code van Eclipse 4 toe te voegen; deze Eclipse-release moet op 25 juni 2008 verschijnen. Zeventien van deze zogenoemde committers komen bij IBM vandaan, drie bij Innopact en één – een voormalige IBM'er – bij Code 9.

Door enkele andere Eclipse-ontwikkelaars is hierover geklaagd. Zij stellen dat er te weinig diversiteit aanwezig is in het team dat ontwikkelvoorstellen moet doen voor Eclipse 4. Verder ageren ze tegen het feit dat er weinig over ideeën en suggesties gediscussieerd wordt, maar dat er vooral over code gepraat wordt, en dat de Eclipse-gemeenschap weinig betrokken wordt in deze gesprekken.

Volgens Mike Milinkovich, de executive director van Eclipse, is echter iedere ontwikkelaar welkom: "Iedereen die de mogelijkheid heeft om voldoende tijd beschikbaar te stellen om mee te praten en te werken aan de ontwikkeling van Eclipse 4 kan zich aanmelden als committer". Ook IBM heeft laten weten niet uit te zijn op een machtsovername bij het Eclipse-project.

Eclipse was oorspronkelijk een project van de Canadese afdeling van IBM, maar in november 2001 werd de broncode van de software openbaar gemaakt en ondergebracht bij een consortium van bedrijven. In januari 2004 werd de Eclipse Foundation opgericht, een organisatie waarin verschillende softwarebedrijven zijn vertegenwoordigd.

Reacties (30)

[Verwijderd]

IBM is altijd sterk vertegenwoordigd geweest in het Eclipse Platform project. Nogal logisch, ze baseren vrijwel al hun producten op Eclipse technologie: de Rational tooling, Lotus suites en zelfs Websphere.

Het e4 component is pas sinds zeer kort aangekondigd en dient als oprit naar Eclipse 4, dat nog wel minstens 2 jaar zal duren. Volgende week is EclipseCon, de grootste Eclipse conferentie, waarna de plannen wel wat concreter zullen worden over hoe dit "e4" project zich zal ontwikkelen.

Eclipse kent al een tijdje de zogenaamde "Bugdays", waarbij extra aandacht wordt gegeven aan vrijwilligers die graag wat bugs willen pletten. Een leuk idee en het schijnt nog te werken ook. Hou op met klagen zou ik zeggen en schrijf eens wat code!

[xippie]

Het is een oud IBM project, ik vind het dan niet gek dat er veel (oud) IBMers aan werken?

Bij Mozilla werken toch ook redelijk veel mensen van Google?

[Harm]

Het klopt dat Eclipse een oud-IBM-project is en daarom is het op zich wel logisch dat er veel IBM'ers werken. Volledig mee eens. Tegelijk is het wel zo dat het een oud-IBM-project is en dat het daarom goed zou zijn als niet langer IBM de scepter zwaait (of lijkt te zwaaien), maar als ook de andere bedrijven uit de Eclipse Foundation hun steentje bijdragen. Om die bedrijven daar ook de mogelijkheid voor te geven, was het mogelijk beter geweest als nog even gewacht was met het versturen van de lijst met committers naar de buitenwereld, dat had rumoer gescheeld. Aan de andere kant, het zal nu ook wel met een sisser aflopen .

Overigens, Mozilla is geen Google-project. Er werken wel verschillende Google'ers voor Mozilla, maar dat is niet omdat Mozilla uit Google voortgekomen is, zoals je lijkt te impliceren.

[Jeanpaul145]

Zoals IBM al aangeeft kan iedereen met voldoende tijd zich aanmelden als committer. Als initiatief ontbreekt bij de andere bedrijven om mensen in te zetten bij de ontwikkeling van Eclipse vind ik dat dat hun probleem is.
Hiernaast, als IBM werkelijk de scepter wilde zwaaien over eclipse dan haden ze de code simpelweg niet vrijgegeven lijkt me.
Nog een derde punt: als ik het goed begrijp wordt er geklaagd dat er te veel over code en te weinig met UML, OCL, etc wordt gedaan. Dit zijn leuke tooltjes op papier, maar bij een klein project dat ik nu aan het doen ben aan de TU Delft blijken zaken al snel zo complex te worden dat de UML bijna even onoverzichtelijk wordt als de code zelf. Om dat soort dingen goed te gebruiken moet je er de tijd voor nemen, als je zaken haast gaat het geheid fout.
Hiernaast blijkt vaak genoeg dat je tegen dingen aanloopt die je over het hoofd hebt gezien in de ontwerp (UML) fase. Dan maar geen tijd verdoen met UML lijkt me, maar gewoon aan de slag.

[humbug]

"Geen tijd verdoen met UML"

OK, TU Delft impliceert al "student" en geen enkele werkervaring, maar je zou toch van een "student" verwachten dat hij begrijpt dat een techniek die al jaren succesvol in de industrie gebruikt wordt geen tijdsverspilling is.....

[Jeanpaul145]

Daar heb je het mis. Ook in de professionele wereld is UML lang niet de beste oplossing (m.n. wanneer management snel resultaten wil zien en verder weinig te maken heeft met HOE je die resutaten bereikt).
Zoals ik al aangaf: om iets als UML effectief te kunnen gebruiken moet je er de tijd voor nemen, je kan je dan niet haasten.

[Verwijderd]

HAHA "er wordt teveel over code gepraat"... dat is denk ik ook de reden dat Eclipse zo succesvol is. Het gaat bij Eclipse om krachtige code en niet om een stel aan elkaar geplakte bibliotheken zoals veel software tegenwoordig wordt gebouwd. Wel appart trouwens dat dit van IBM komt ... bij IBM zou ik juist toch snel denken aan design ... design .. design ... UML ... UML... ipv code ... code ... code .

[Verwijderd]

Eclipse is dan ook gebaseerd op een heel sterk design. De man achter het ontwerp van Eclipse is dan ook niemand minder dan Erich Gamma (GoF).
Is het trouwens niet Eclipse 3.4 ipv Eclipse 4?

[Mr_Light]

Vermeld er dan even bij dat hij op dit moment voor/aan IBM Rational, Jazz project werkt.

Het argument dat er diversiteit zou moeten zijn is onzin, dat mag geen doel op zichzelf zijn. Als het tot gevolg heeft dat er twijfelachtige dingen gebeuren mbt de besluitvorming of input on-beargumenteerd genegeerd word hebben we het over andere dingen,

Dat de mensen die de kar trekken bij opensource projecten uit een bepaalde hoek komen, omdat dit bv handig is mbt communicatie, is niet ongewoon. En vaak werkt dit prima, preventief het proces frustreren(mischien beetje te sterk woord) om mogelijke problemen te voorkomen terwijl ze nog geen probleem zijn; en wanneer ze een probleem vormen makkelijk op te lossen zijn, vind ik persoonlijk onzin.

Daarnaast het is opensource; forken kan altijd.

//edit
De orginele blogs gelezen, beetje een storm in een glas water. Zeker in het licht van:

"But now we know: OK, e4 is a place to showcase the experimental code and grow ideas about the Eclipse 4.0 platform, not some coup d'etat. OK, the perception is not reality, just unfortunate communication. OK, the platform team wants to solicit feedback from the community. OK, so you would rather show it in code than in colorful diagrams (given the audience, that makes sense)."
http://occasional-eclipse...-architecture-stupid.html

Tja, het is gewoon een inrichting van een lab achtig iets waar voorzieningen voor zijn getroffen waaruit ideeën moeten komen. Waar weer uit gekozen word; binnen een heel ander proces. De mensen die invloed hebben binnen dit proces kunnen weer hele andere mensen zijn. Dit was verkeert opgepakt in de zin dat mensen dachten dat wat er binnen e4 bedacht wordt, het ook meteen moet worden. (en dus voor de rest niemand inspraak meer had)

De heisa over het 'code' verhaal betrekt zich tot het feit dat de mensen die nu binnen e4 werken meer heil zien in een prototype dan een mooi document met diagrammetjes.

[Reactie gewijzigd door Mr_Light op 24 juli 2024 09:16]

[Comp_Lex]

Wat is volgens jou precies zo slecht aan aan elkaar geplakte bibliotheken en waarom is het niet goed om van te voren goed na te denken over het ontwerp voordat je gaat programmeren? (Je post schijnt dit te impliceren)

[xdcx]

Omdat het wel heeeeeeel toevallig zou zijn dat er al precies libraries bestaan die precies, en niets meer of minder, doen zoals jij je programma precies wilt hebben.
(Het woordje precies komt 3x voor, en daar word wel duidelijk uit dat libraries vaak een gegeneraliseerd iets (of veel te veel) kunnen. voor tè specifieke dingen bestaat dan nog geen library.)

[Reactie gewijzigd door xdcx op 24 juli 2024 09:16]

[Verwijderd]

Maar dit is dan weer de kracht van OOP, hè. Object inheritance en gaan met die banaan!

[Nijn]

En toch besparen deze libraries bakken met geld en tijd. Of wil jij iedere keer dat je een programma download ook het .NET Framework downloaden?

Of heb je soms liever dat ieder programma een eigen code heeft en in het geheugen laad voor het tekenen van een dialoog of scherm?

[MadEgg]

Om het nog maar niet te hebben over de gigantische overdosis aan bugs die in elke nieuwe implementatie van de dialog-drawing-code zal zitten...

Libraries zijn goed omdat het tijd bespaart voor de ontwikkelaar, ruimte op de PC's van de gebruikers en omdat het door velen uitgebreid getest en gebugfixed is, iets wat je met je eigen implementatie nooit zo snel voor elkaar zal krijgen.

[Verwijderd]

Uiteraard is het goed om eerst over het ontwerp na te denken. Maar het is inmiddels wel duidelijk geworden dat het doel altijd moet zijn om zo snel mogelijk executable
code op te leveren om zo snel mogelijk 'echte' feedback te krijgen. Je kan nadenken tot je een ons weegt, maar je zal het toch aan de werkelijkheid moeten toetsen.

Dat doe je niet met ontwerpen maar met een afgerond programma.

In de autoindustrie maken ze na een schets (ontwerp) ook heel snel een kleimodel
van het ontwerp om te kijken of het allemaal wel uitgewerkt kan worden.
In de software heb je niet het probleem dat je hele dure prototypes hoeft te maken
waar je naderhand niets meer aan hebt.

Je kan gelijk beginnen met code schrijven en die zo vaak als je wilt aanpassen.
Kosten voor het produceren van je product zijn ook minimaal, je kan hetzelfde
programma zo vaak je wilt op cd branden.

Het uitwerken van een ontwerp in UML kost bijna evenveel moeite als het uitwerken in code (code generatie vanuit UML en roundtrip engineering).

En @aToMac :
De kracht van OOP? OOP is handig maar echt geen silver bullet.
Al ben ik wel groot voorstander van OOP (gebruik zelf dagelijks java).

[Comp_Lex]

Prototypen is inderdaad geen punt, maar als het programma complexer wordt dan wil je in principe wel een goed ontwerp maken alvorens je gaat coden, want anders is de kans groot dat je spaghetticode krijgt. Het kost dan bakken tijd en geld om zaken te herschrijven.

[Martin Sturm]

Het probleem wat de developers hebben gaat niet over het punt wat jij nu probeert te suggereren.
Binnenkort is EclipseCon, een conferentie waar over de toekomstige ontwikkelingen van Eclipse wordt gediscussieerd. Het probleem wat veel betrokkenen hebben op het huidge core-development team, is dat ze met kant-en-klare functionaliteit komen en dat presenteren. Hierdoor is het nauwelijks mogelijk om te discussieren hoe iets het beste kan worden geïmpelementeerd en welke features van belang zijn voor de toekomst. De invloed van buitenstaanders is dus vrij klein door deze tactiek.
Het heeft dus niets met het al-dan-niet aanwezig zijn van UML-diagrammen, design-documenten of iets dergelijks, maar dus puur met hoe het ontwikkelproces plaatsvindt. Misschien wordt dat niet heel duidelijk uit de nieuwspost.

[divvid]

het is te hopen dat eclipse 4 wat sneller wordt en wat minder geheugen vreet, v3 is eigenlijk niet goed remote te gebruiken daardoor.

[YopY]

Dat Eclipse veel geheugen gebruikt is ook deels te wijten aan het gebruik van Java, dat sowieso al 100 MB inneemt. Maar ook daarnaast geef ik toe dat Eclipse veel geheugen gebruikt. Lijkt mij dat het heel veel info cachet, waardoor het redelijk snel veel gegevens kan laten zien. Het is mij wel best - geheugen kost geen barst meer tegenwoordig en de voordelen wegen mijns insziens wel op tegen de nadelen.

[GrooV]

Ben een tijdje lang Eclipse gebruiker geweest, maar ben nu toch echt over gestapt naar Visual Studio voor c* talen en netbeans voor Java. Vind eclipse erg achterlopen met andere IDE's kwa look & feel, het geeft mij altijd een het gevoel of het allemaal maar een beetje aan elkaar hangt.

[Reactie gewijzigd door GrooV op 24 juli 2024 09:16]

[corné]

Dat vind ik ook van eclipse. Het voelt vaak ook een beetje traag aan.
Nu ben ik overgestapt op netbeans, maar dat loopt ook niet altijd even snel. Vooral niet als je veel jsp's met JSTL libraries open heb staan
Zal wel aan java liggen.

[Reactie gewijzigd door corné op 24 juli 2024 09:16]

[Verwijderd]

Heb echt geen klagen van de snelheid van Eclipse, je zorgt best wel voor voldoende geheugen. Met 2GB zou je toch niet veel last mogen.

[Verwijderd]

tja...is maar wat je gewend bent. Ik vind het op mijn 2ghz dual core cpu met 3 GB, een 7200 rpm disk en 1GB turbocache toch traag. Maar ok... als ik een RAID SSD zou hebben dan gaat het misschien sneller.

[MatthiasDS]

Ik vind het enkel iets te traag als ik de eerste keer een bepaald type editor open. Bijvoorbeeld eerste keer JSP editor, eerste keer ant editor, etc. Voor de rest werkt alles zeer vlot. Zelfs met 100+ editors open (don't ask ) blijft alles zeer snappy reageren.

[Martin Sturm]

Eclipse an sich biedt dan ook weinig functionaliteit. Het platform valt of staat met de juiste plugins. In feite is het gewoon een box waarin een hoop plugins draaien die samen een IDE vormen. Dat is (imho) ook juist de kracht van Eclipse, je kunt het heel specifiek aanpassen aan jouw wensen.

[SPee]

Mij kruipt het gevoel dat de ontwikkeling van eclipse niet zo hard gaat als zou kunnen.
Er zijn veel bedrijven bij betrokken die allemaal hun eigen uitbreidingen maken en als product verkopen. Die zullen ook alleen zeer blij zijn als iets wat hun maken niet in het gratis standaard pakket wordt geleverd en ontwikkelaars hun paketten gaan kopen.

[YopY]

Da's vreemd, ik heb zelf namelijk gehoord dat Eclipse enorm snel groeit. Misschien was dat het Eclipse project in het algemeen, inclusief alle plugins en versies e.d. in plaats van alleen de core.

[Verwijderd]

Eclipse, RAD. Ik werk er mee.. Super programma vergeleken met WSAD en Visual Age maar LOMP is het ook. Slurpt geheugen, disk access. Het is traag, te groot en bevat net zoals vele andere tools ontelbaar fouten.. sommige zijn ook echt rottig en andere weer grappig (voor eventjes).

Ik werk er mee en blijf er mee werken. Gelukkig laat IBM hun klantne de boel ook testen zodat er meer fouten gevonden kunnen worden en heb je inspraak (bij RAD) over nieuwe functies.

[SirBlade]

Dan maken die ontwikkelaars toch gewoon een fork van eclipse en laten ze geen IBM-ers meedoen aan hun team?

[Verwijderd]

Die mensen kunnen nu toch ook mee ontwikkelen? Hoe meer mensen met goede kennis hoe beter.