Ontwikkelaar omarmt open source-tooling

In de beheerhoek kennen we tooling en vanuit de softwarehoek kennen we open source. Wat gebeurt er als je die twee samenvoegt? Dan krijg je open source-tooling; een populair vakgebied in de development-hoek. Ontwikkelaars zetten open source-tooling graag in bij het testen of in de Java-hoek, maar het kan voor meer zaken toegepast worden. Onze experts van de topics Development en Open Source leggen uit hoe en wat.

Maurice Siteur, managing consultant, Capgemini Nederland

De open source-tools van tegenwoordig doen niet onder voor closed source-tools, maar hebben nog steeds het imago van ‘kan niet goed zijn'. Open source-tools gebruiken voor het ontwikkeltraject, kan zeer nuttig zijn. Niet alleen om kosten te besparen, maar ook om relatief eenvoudig en snel tools beschikbaar te hebben voor ondersteuning van de ontwikkelprocessen. Voorwaarde hierbij is wel dat er mensen aanwezig zijn met kennis en kunde om de tools in te richten en te beheren. De continuïteit hiervan is erg belangrijk. Hiervoor zijn derde partijen in te schakelen via outsourcing-constructies die garant staan voor de open source-tools en support bieden indien nodig.

Mylène Reiners, productmanager OSCE/architect, Atos Origin

In ‘mijn' wereld, Java EE-ontwikkeling, is nagenoeg alle tooling open source. Open source van (vaak) uitstekende kwaliteit. Zo zeer zelfs dat een deel van deze tooling is uitgegroeid tot dé de facto-standaard. Dit heeft voor ontwikkelaars veel voordelen: toegang tot een weelde aan documentatie en kennis, snelle adoptie van nieuwe ontwikkelingen en keuzevrijheid: blijf je bij MySQL, Hudson, jBPM, etc., of stap je over op MariaDB, Jenkins, Activiti of …?. Tools moeten gewoon goed zijn om breed geaccepteerd te worden. Net zoals Java EE beter is geworden door de competitie met .Net en de open source-communities, zal al deze tooling ook moeten innoveren om concurrerend te blijven.

Willem Massier, founder en ceo, Terrazur/Covide

Voor de ontwikkeling van software zijn voldoende open source-tools beschikbaar: Wikipedia (om de technische beschrijving actueel te delen met potentiële ontwikkelaars), Trac (gebruikers melden wensen en bugs; projectmanagers wijzen ontwikkelaars opdrachten toe), SVN (ontwikkelaars pikken de actuele code op; zij maken er ook de patch in aan; door een projectleider wordt er een commit gemaakt naar een van de actuele codeversies; kortom het systeem achter het versiebeheer), Reviewboard (ontwikkelaars leveren er hun patches aan; een projectleider communiceert en begeleidt tot de patch 100 procent is) en tenslotte Eclipse en Aptana (de ontwikkelomgeving).

Sandor Nieuwenhuijs, technical director, Oracle Nederland

Met name in de Java-wereld zijn open source-tools niet meer weg te denken. Denk bijvoorbeeld aan Eclipse of Netbeans. In het verlengde daarvan ligt de noodzaak om één of meerdere frameworks te kiezen. Deze keuze is cruciaal en tegelijkertijd riskant. Frameworks, een noodzakelijk kwaad in het bereiken van hoge productiviteit, uniformiteit en voorspelbaarheid, zijn namelijk erg modegevoelig net als vele andere aspecten van open source. De laatste jaren is het Spring wat de klok slaat, maar wie al eerder voor Apache Struts gekozen heeft, voelt zich in de steek gelaten. Kijk daarom bij de keuze van een ontwikkeltool ook naar de hulpmiddelen eromheen en de toekomst daarvan.

Nico Verwer, software architect, Withart

Voor bijna alle fasen van een ontwikkelproject bestaan open source-tools. Het bekendst zijn de IDE's Eclipse en NetBeans. Hiervoor bestaan allerlei plug-ins voor het ontwerpen, schrijven, bouwen en testen van software. Deze maken vaak weer gebruik van tools zoals Subversion en Git voor versiebeheer en Ant en Maven, die het bouw- en testproces automatiseren. Verder zijn er open source-tools voor allerlei taken, die vanaf de command-line of een GUI te gebruiken zijn. Het verschil met het werken in een gesloten omgeving is dat je keuzes moet maken en uitvinden wat de handigste combinatie van tools is. Dat vereist inzicht in hoe het ontwikkelproces in elkaar zit.

Rodger Mol, sr. consultant/projectmanager, Desit

Het idee achter open source is dat iemand een stuk software maakt om vervolgens deze applicatie, inclusief source-code, aan iedereen ter beschikking te stellen. Het idee is leuk maar is het beter dan betaalde tools? Wat beter is zit hem in de functionaliteit. De tool moet precies doen wat ik wil. Bij het maken van een keuze kijk je naar wat het doel is van de software, wat het kost en of je support krijgt. Naast bovenstaande is er een groot nadeel aan open source; de tool is bedacht vanuit de techniek (de programmeur). Laten we eerlijk zijn: een automonteur laten we toch ook geen auto bouwen.

Kees Kranenburg, portfoliomanager, Atos Origin

Het aanbod van open source-tools is groot en van verschillend niveau. Waar leveranciers van gesloten tools een product pas vrijgeven als het af is, verdient dit bij de selectie van open source-tools extra aandacht. Vragen die gesteld moeten worden zijn: Is het tool actueel en volwassen? Is er voldoende community support? Selectie van goede tools is echter geen probleem. Open source-tools zijn makkelijk toegankelijk en worden door de gebruikers zelf in de praktijk getest. De selectie vind dus plaats op basis van toepasbaarheid en productiviteit. Dit in tegenstelling tot gesloten, commerciële tools die vaker via de boardroom worden verkocht op basis van korting en politiek.

André Weber, delivery manager, Capgemini Nederland

Dat open source-tooling gebruikt kan worden voor ontwikkelen is alom bekend. Minder bekend is dat open source-tooling heel goed voor testen ingezet kan worden. De mogelijkheden en kwaliteit van deze tools moeten niet onderschat worden. De toepassingsmogelijkheden zijn divers, zoals performance-testen, testen van xml-services en scannen van standaard eisen aan websites. Met het gebruik van deze tools kunnen aanzienlijke besparingen bereikt worden. De kosten voor performance-testlicenties lopen snel op, terwijl een goede technische tester vaak ook met open source-tooling uit de voeten kan. Webscantools kunnen in korte tijd handmatige activiteiten geautomatiseerd uitvoeren.

Eric Schabell, JBoss solutions architect Benelux, Red Hat

Ontwikkelaars zoeken zelf naar tools waar zij graag mee willen werken. Het is immers zo te verkrijgen en voor niets. Open source-tooling is overal om je heen. Als je rondloopt op een ontwikkelafdeling en een lijst maakt van wat je allemaal tegenkomt bij ontwikkelaars, zul je zien dat niet iedereen van het gehele aanbod gebruikmaakt. Maar ik weet zeker dat het niet mogelijk is een ontwikkelaar te vinden die geen open source-tool in zijn gereedschapskist heeft liggen. Het is niet van belang of je wel of niet met gesloten softwarecomponenten werkt, maar het gaat er juist om wat wij als ontwikkelaars willen gebruiken om ons dagelijkse werk uit te voeren. Gelukkig is open source-tooling geschreven door ontwikkelaars en dat is merkbaar. Het is 'van ontwikkelaars, voor ontwikkelaars'.

De beste tooling drijft dan naar boven qua functionaliteit, bruikbaarheid en vooruitstrevendheid. Dit soort tooling krijgt immers direct input van de gebruikers. En wel realtime via communicatiekanalen die 24/7 open zijn. Dit is haast niet bij te benen voor de statische, gesloten tooling-leveranciers. Het meest belangrijke resultaat van het gebruik van tooling die een ontwikkelaar zelf uitzoekt, is dat je dan een blije ontwikkelaar hebt. Want blije ontwikkelaars zijn productieve ontwikkelaars.

Hans Beemsterboer, senior ontwikkelaar, Beemsterboer Software

Enkele jaren geleden was ik op zoek naar een Java-tool waar ik muziek mee zou kunnen maken. Na wat online zoeken, vond ik de open source-tool JFugue. Deze tool bleek precies te zijn wat ik nodig had en bood zelfs de mogelijkheid om op eenvoudige wijze de code uit te breiden met nieuwe functionaliteit. Deze mogelijkheid greep ik met beide handen aan. Ik had namelijk een andere open source-tool ontdekt waarmee schitterende tabulatuur gemaakt kon worden: LilyPond. Door wat code toe te voegen aan JFugue, kon ik nu muziek programmeren en vervolgens de bijbehorende tabulatuur met LilyPond genereren. De code heb ik inmiddels, als committer, toegevoegd aan het JFugue-project.

Vorig jaar was ik op zoek naar een Java-tool voor het maken van een 3D virtuele wereld. Via open source-project jMonkeyEngine kwam ik terecht bij het Open Wonderland-project. Wederom was dit precies wat ik zocht. Ook dit project heeft goede uitbreidingsmogelijkheden. Zo hebben studenten van de Nanjing-universiteit in China onlangs een nieuwe module toegevoegd: een piano waar je op kunt spelen in de virtuele wereld. Je raadt het al, de pianomuziek wordt gemaakt met… JFugue.

Robbrecht van Amerongen, expertisemanager projectmanagement en software engineering, Amis Services

Het voordeel van open source-tooling is dat het beter is, niet omdat gratis is. Het open source-model stuurt direct op kwalitatief betere tools. Het is gebaseerd op schaarste waardoor er allen wordt geïnvesteerd in praktische en bruikbare oplossingen. Alle overbodige features worden weg gelaten, deze kunnen alleen maar zorgen voor verstoring. Ontwikkelaars worden publiekelijk onderworpen aan strenge kritiek van hun collega's en zijn gedreven om te laten zien dat ze kwalitatief hoogwaardig werk afleveren. Vaak werken de beste developers aan een open source-product. De code is openbaar, fouten worden snel gevonden en opgelost. Het open source-model zorgt automatisch voor natuurlijke selectie. Een product dat niet werkt, niet gebruikt wordt of de verkeerde techniek gebruikt, sterft af. Een goede tool met veel gebruikers wordt automatisch beter.

Open source-tooling vult de behoefte aan praktisch bruikbare middelen in. Dat doet het echt. Er zit zo een krachtig idee achter open source-tooling, dat ik niet begrijp waarom bedrijven hun tools voor zichzelf houden. Uiteraard wil je als ict-bedrijf geld verdienen, maar doe dit dan op diensten op een goed product en niet op het verlopen van licenties. Product gratis, dienstverlening betalen. In de ict-wereld kom ik regelmatig zeer onpraktische tools tegen. Deze hebben alleen bestaansrecht omdat klanten hiervoor (te veel) willen betalen. Stop daarmee, alstublieft!

Nathalie Rooseboom de Vries van Delft, managing consultant, Capgemini

Als softwaretester, maar natuurlijk ook als ontwikkelaar, kun je vanuit twee kanten naar tools kijken, en dat geldt voor zowel open source als closed source. Je bent een ontwikkelaar er van (in mijn geval tester) of een gebruiker. Ik ga nu uit van de gebruiker van open source (testing)-tools.

Open source vond ik in het begin maar eng; code die door een ieder maar aangepast kon worden en gebruikt. Als tester was dat voor mij een nachtmerrie; ik zag overal beren op de weg, vooral beveiliging en onderhoudbaarheid waren in mijn ogen een grote zwakte van het open source-principe. Inmiddels ben ik wel ‘om', een kwestie van mindset en gewenning denk ik. Daarbij denk ik dat open source inmiddels ook behoorlijk volwassen geworden is en dat de kwaliteit van de tools daarmee ook steeds beter is geworden.

De grote waarde van open source vind ik dat een grote(re) community zich bezig houdt met de ontwikkeling. Daarbij komt dat open source (vaak) liefdewerk oud papier is, dus de tools zijn gemaakt vanuit een overtuiging of een noodzaak. Dat levert toch andere software op dan de commerciële tools. Groot voordeel vind ik de kosten. Doordat de open source-tools veelal gratis zijn (of een kleine donatie vragen), ben ik sneller geneigd om een tool te proberen en kan dat voor een langere tijd (in tegenstelling tot de beperkte demonstratietijd van een commerciële tool) doen. Het voordeel vind ik ook dat als het nagenoeg naar mijn zin is en ik een klein onderdeel wil aanpassen of een feature wil toevoegen, ik dat ook ‘gemakkelijk' kan doen. Op die manier heb ik een toolbox met een verzameling aan tools die voor mij datgene doet en bevat wat precies bij mij en mijn werk past, zonder dat het me veel heeft gekost, behalve mijn tijd en wat donaties.

Het nadeel van open source is dat de service en ondersteuning er vaak minder of niet is en dat het vaak niet getest is zoals dat bij closed source wel het geval is. Die ondersteuning kan echter ook veel beter zijn als er een bijbehorend forum is, al moet je maar afwachten of je een antwoord krijgt op je vraag. De user interface of gebruikersvriendelijkheid laat vaker te wensen over en ook een nadeel vind ik dat je soms een specifieke ontwikkeltaal c.q. compiler/omgeving nodig hebt, zoals Ruby bij de tool Cucumber of mod_perl/mySQL bij Litmus. Het is niet vanzelfsprekend dat er een kant-en-klaar installatiepakket van de betreffende tool is en dat kost, soms, extra tijd om een tool te doorgronden en zo in te stellen dat het ding doet wat het, voor mij, moet doen. Daarnaast kosten die extra ontwikkelomgevingen/compilers ook extra ruimte op mijn machine. Een nadeel is soms ook dat een tool soms gewoon niet meer werkt omdat de techniek of code erachter verouderd is. Vaak is er wel een vervangende nieuwe versie, maar soms heb je gewoon pech en heb je de keuze om zelf een upgrade te doen of het zonder te stellen.

Een absolute favoriete site van mij is: www.opensourcetesting.org. Een leuke ontwikkeling is ook de ‘weekendtesters' (http://weekendtesting.com). Dit van origine Indiase initiatief test veel open source (testing)-tools, gewoon om te leren testen. Dit komt de geteste software/tool enorm ten goede.