Open source software, veel van de lezers gebruiken het al in meer of mindere mate. Misschien niet altijd bewust, maar het zit al op zoveel plaatsen verweven dat we er haast niet meer om heen kunnen. Het is echter ook zo dat de meesten niet echt de sources gebruiken, maar reeds gebouwde producten, gebaseerd op open source code. Op het moment dat je met de broncode aan de slag gaat kun je voor een paar leuke uitdagingen komen te staan.
Onlangs kreeg ik de vraag om eens te kijken of ik één van de open source pakketten die we gebruiken ook zelf gebouwd kon krijgen, dit in verband met lange-termijn onderhoudsverplichtingen (tot nu toe was er een reeds gebouwde versie in gebruik). Zo gezegd, zo gedaan … dacht ik.
Het downloaden van de source code was uiteraard het begin, en met behulp van internet was al snel gevonden hoe je zou moeten kunnen bouwen. Dit begon met het downloaden van een drietal ondersteunende producten. Na het nodige gestoei om systeemvariabelen en paden goed te zetten lukte het zowaar om te bouwen. Uiteraard volgde daarop een test om te kijken of een en ander nog werkte, die al snel faalde op missende header files in het gebouwde product. Een zoektocht op internet leverde na verloop van tijd op dat er blijkbaar een regeltje ontbrak in de instructie die ik gevonden had.
Om een lang verhaal niet nog langer te maken: na zeven additionele tools/libraries geïnstalleerd te hebben was ik eindelijk in staat de binaries te reproduceren. Alhoewel… bij de gedownloade binaries stond nergens vermeld welke versies van de additionele tools/libraries gebruikt zijn bij het bouwen van die ene versie, dus of ik nu echt hetzelfde heb gereproduceerd is nog maar de vraag.
Voor het vervolgproject is al aangegeven dat men naar een nieuwere versie van betreffend open source product wil. Tijdens het zoeken naar de instructies voor de huidige versie bleek dat het bouwen van de nieuwe versie wezenlijk verschilt van de bestaande. Ik zie de bui dus al weer hangen.
De oudere jongeren onder ons, die eind jaren negentig al met Linux werkten, herkennen wellicht veel van dit verhaal. Destijds moest je ook, om één pakket aan de praat te krijgen, talloze andere pakketten downloaden en zelf configureren en bouwen. De hele exercitie leverde me dan ook een groot déjà-vu gevoel op. Nu, zo’n vijftien jaar later is Linux veel volwassener geworden, en neemt het package management systeem je nagenoeg al het werk uit handen.
Hopelijk krijgen we op termijn voor het zelf bouwen van open source iets vergelijkbaars.
Dat is er al lang.
Bijv. Maven of Gradle.
Volgens mij hangt het sterk af van de soort applikatie. Wanneer je met GCC werkt kom je onvermijdelijk terecht in dit soort versie vraagstukken.
Bij zoiets als Perl is dat al aanmerkelijk minder. Toegegeven, ik ben geen C-ontwikkelaar, hoeft ook niet vanwege het pakketmanagement dat programma’s praktisch gebruiksklaar levert en de updates nalevert.
Wat ik in deze markt zie, is dat er reklame gemaakt wordt met “open source” voor produkten waar dan voor het onderhoud betaalt wordt. Daar is niets mee mis maar vaak probeert men zijn markt dan toch te beschermen door gebrek aan dokumentatie of ingebouwde onnodige komplexiteit.
Het nadeel van open source is nu eenmaal dat je alleen aan de service kunt verdienen en niet aan het produkt. Dat is zakelijk een moeilijke afweging omdat je verdienmodel anders is/wordt en dus een ander soort konkurrentie voortbrengt de kunst is daaruit voordeel te halen.
Juist dit punt is lastig bij de selektie van open source software, kies je het verkeerde dan klapt zo’n projekt in zichzelf in elkaar.
@Peter: voor bepaalde open source producten zal je uitspraak vast en zeker gelden, maar als het zo eenvoudig was voor alles dan had ik het artikel niet geschreven
@Jan: ik weet niet of het opzet is (de marktbescherming), interessante gedachtengang. Wat ik wel merk is dat het ook heel erg afhangt van het platform. Vooral op het moment dat je cross platform gaat werken wordt het soms behoorlijk tricky en complex (bijv. iets wat oorspronkelijk op linux ontwikkeld is proberen te bouwen met visual studio)
Dit is een interessant artikel, maar de beschreven problemen zijn niet representatief voor alle open source software. Zoals Peter al aangeeft maakt veel OSS gebruik van Maven, Gradle, of iets vergelijkbaars.
Helaas zal dit artikel door sommige mensen gebruikt worden om te roepen dat alle OSS rotzooi is.
Commerciele software heeft de beschreven problemen niet, want die kan je niet zelf bouwen. Maar als je die wilt uitbreiden of aanpassen loop je tegen dezelfde soort problemen aan. Ga maar eens een extensie voor Sharepoint (of Alfresco, maar dat is OSS) maken. Of een SAP implementatie, wat Jacob Spoelstra vandaag vergelijkt met ‘slow TV’.
Even het één en ander op een rijtje:
De “open source” software is wel degelijk eens gemaakt, en de maker(s) had(den) inzicht in hoe het product gemaakt is.
Goede software maken is zeer moeilijk en niet iedereen kan dat.
De IT arbeidsmarkt is behoorlijk verziekt met mensen die niet deskundig en vakbekwaam zijn; die op de verkeerde plek zitten.
Ik vrees dat er een nieuwe lichting is die niet meer in staat is om het oude niveau te halen.
@Steven: iets een keertje maken is één, iets reproduceerbaar herhalen en goed documenteren is iets anders.
Ik ben het met je eens dat de schoolverlaters meer moeite hebben dit te reproduceren. De instructie die ik gemaakt had wilde ik laten checken door een schoolverlater die momenteel hier rondloopt, en die ging behoorlijk de mist in door
a) slecht lezen
b) gewoon op “next” of “ok” klikken zonder te lezen wat er nu stond
c) geen idee hebbend wat hij nu aan het doen was
Wat ik in de loop der jaren vaak gezien heb is dat iets op de PC van een ontwikkelaar of open-source-thuiswerker bouwt, maar op het moment dat de code geporteerd wordt naar een andere PC de problemen van het reproduceerbaar bouwen beginnen. De ontwikkelaar heeft bepaalde libraries ooit geïnstalleerd gehad, welke nu gebruikt worden, maar weet niet meer waarvandaan en welke versie. Op zijn PC staan wat aliasses en andere settings die op het andere systeem niet staan en ga zo maar door. Je moet dan in een woud van variabelen in installaties gaan zoeken naar de 10 verschillen.
@Nico: waar sommigen nog wel eens de mist mee ingaan op dit gebied is dat men source code management goed in place heeft, maar vergeet dat je ook de omgeving moet managen wil je iets kunnen reproduceren. Bij bedrijven die de kost verdienen met sw producten is hier wellicht wat meer aandacht voor dan bij een open source gemeenschap.
PaVaKe, zoals altijd weer leuke opinie van jou hand.
Ik gebruik steeds meer codenvy.com dat lost het probleem op dat iedere computer anders is ingericht…
Wat betreft aanpassen van open source… als je de master / origin van de source niet kan aanpassen met je verbeteringen, wees dan inderdaad bewust welk pad je inslaat. Ik ben veel geforkte open source tegen gekomen en die paden lopen vrijwel altijd dood of zijn zeer duur om te onderhouden, als er voldoende markt is, pak dan de essentie van iets wat doet wat je wilt en maak het volledig eigen, dus je eigen (open) source.
Niets is zo frustrerend om je conformeren aan een architectuur die net even anders opgezet is dan voor jouw probleem en onderhoud is een drama.
Dus of zelf goed maken of adopteren en eventueel de source verbeteren….
@Paveke
[quote]Wat ik in de loop der jaren vaak gezien heb is dat iets op de PC van een ontwikkelaar of open-source-thuiswerker bouwt, maar op het moment dat de code geporteerd wordt naar een andere PC de problemen van het reproduceerbaar bouwen beginnen. De ontwikkelaar heeft bepaalde libraries ooit geïnstalleerd gehad, welke nu gebruikt worden, maar weet niet meer waarvandaan en welke versie. Op zijn PC staan wat aliasses en andere settings die op het andere systeem niet staan en ga zo maar door. Je moet dan in een woud van variabelen in installaties gaan zoeken naar de 10 verschillen. [/quote]
Dit probleem is volgens mij niet uniek voor open-source, maar een probleem voor alle omgevingen waar software gemaakt wordt. Daarom zie je ook steeds meer (open en closed source) integration en build omgevingen opkomen.
Zo snel je met meer dan 1 ontwikkelaar zit te werken aan dezelfde codebase is het sowieso verstandig om een dedicated build machine te maken. Tegenwoordig een stuk makkelijker met de eenvoudige tools om b.v. een VM in te richten.
Story of my live….
Soms ben ik dat ook wel een beetje zat hoor,dan neem je de elende van ongewenste nieuwigheden gnome3, systemd ect maar voor lief, je wil ook verder.
Feit is dat je dit probleem met commerciele closed source software ook hebt, al eens geprobeerd Quartus 10.1 op een 64bit Linux systeem werkend te krijgen ? Je heb die versie nodig als je iets met Cyclone-I FPGA’s wil doen…
@PaVaKe
waarom zou je een ontwikkel-omgeving van Linux naar Windows porteren?
Een virtuele Linux is toch geen groot probleem meer, of wil je de tools behouden die je gewend was, dan is die keuze wellicht niet de beste.
Crossplatform vindt je hoofdzakelijk bij java-applikaties en webapplikaties. Crossover van codeweavers
(https://www.codeweavers.com/) om Windows-software op linux te draaien heeft ook zo zijn beperkingen maar kan evt. je probleem oplossen.
@Henri
Dat forks vaak doodlopen klopt, maar ook projekten die aan 1 ontwikkelaar hangen dragen een risiko, namelijk dat die er mee stopt. Overigens wanneer je een projekt ombouwt voor je eigen gebruik, stel het dan ook weer ter beschikking, dat hoort bij FOSS.