PDF download Pdf downloaden PDF download Pdf downloaden

Het schrijven en gebruik van open software is niet gewoon maar een vorm van programmeren (ook wel 'hacken' in de wereld van programmeurs), het is een soort filosofie. Hoewel je alleen maar een programmeertaal hoeft te kennen om te kunnen programmeren, gaat dit artikel over hoe je kunt deelnemen aan de community, vrienden kunt maken, kunt samenwerken aan geweldige projecten en een gerespecteerd specialist kunt worden met een profiel die je elders niet kunt krijgen. In de wereld van de open software kan je vrij gemakkelijk taken toebedeeld krijgen die in een bedrijf alleen de elite, programmeurs van topniveau, mogen doen. Denk er eens aan hoeveel ervaring je dit kan opleveren. Als je echter eenmaal hebt besloten om een programmeur te worden van open software, dan moet je bereid zijn om tijd in dit doel te investeren. Dit geldt ook als je al IT-student bent. Let wel, dit artikel gaat niet over hoe je een hacker of cracker wordt.

  1. GNU/Linux is één van de meest populaire om in te programmeren, maar GNU Hurd, BSD, Solaris en (tot op zekere hoogte) Mac OS X worden ook vaak gebruikt.
  2. Je kunt veel meer doen met Unix-achtige besturingssystemen als je de opdrachtregel gebruikt.
  3. Anders kun je geen code bijdragen (het belangrijkste onderdeel van ieder softwareproject) aan de open softwaregemeenschap. Sommige bronnen stellen voor om in een keer met twee talen te beginnen: één systeemtaal (C, Java of vergelijkbaar) en een scripttaal (Python, Ruby, Perl of vergelijkbaar).
  4. Ze hebben een hogere leercurve, maar je kunt er dan ook veel meer mee doen.
  5. Versiebeheer is waarschijnlijk het belangrijkste instrument van de samenwerking voor gedeelde softwareontwikkeling. Begrijp het maken en toepassen van patches. De meeste open softwareontwikkeling in de community wordt gedaan via het creëren, bespreken en toepassen van verschillende patches.
  6. De meeste van dergelijke projecten vind je tegenwoordig op SourceForge.net. Een geschikt project hoort:
    1. De programmeertaal te gebruiken die je kent.
    2. Actief te zijn, met recente releases.
    3. Al te bestaan uit drie tot vijf ontwikkelaars.
    4. Versiebeheer te gebruiken.
    5. Een deel te hebben waar je meteen aan kunt beginnen, zonder de bestaande code te veel te hoeven wijzigen.
    6. Behalve de code, beschikt een goed project ook over actieve discussielijsten, foutrapporten, krijgt en implementeert het aanvragen voor verbetering, en vergelijkbare activiteiten.
  7. In een klein project met weinig ontwikkelaars zal je hulp meestal onmiddellijk worden geaccepteerd.
  8. De regels van de programmeerstijl of de noodzaak van het documenteren van je wijzigingen in een afzonderlijke tekstbestand vind je misschien eerst belachelijk. Echter, het doel van deze regels is om gedeeld werk mogelijk te maken -- en de meeste projecten werken ermee.
  9. Luister zorgvuldig naar wat de beheerder en andere projectleden te zeggen hebben. Behalve programmeren heb je een heleboel dingen te leren. Maar als je iets echt niet prettig vindt, stop er dan gewoon mee en stap over op een ander project.
  10. Zodra je merkt dat je met succes kunt werken in dat team, is het tijd om naar iets serieuzers uit te kijken.
  11. De meeste van dergelijke projecten zijn eigendom van GNU of Apache-organisaties.
  12. Waarschijnlijk zal je worden gevraagd om de eerste tijd te werken zonder directe schrijftoegang tot de code-repository. Het vorige underground-project zou je echter veel moeten hebben leren -- dus na enkele maanden een productieve bijdrage te hebben geleverd, kun je de rechten opeisen waarvan je denkt dat je die zou moeten hebben.
  13. Het is de hoogste tijd. Wees niet bang. Ga door, ook als je merkt dat de taak veel moeilijker is dan je aanvankelijk had gedacht - in deze stap is het belangrijk niet op te geven.
  14. Maar maak je niet druk als de toepassing niet wordt geaccepteerd, want ze hebben veel minder gefinancierde posities dan dat er echt goede programmeurs zijn.
  15. Zoek een geschikte conferentie gebeurt in de buurt ('Linux-dagen' of iets dergelijks) en probeer om je project daar te presenteren ( het hele project , en niet alleen het deel dat je programmeert). Nadat je vertelt dat je een serieus gratis/opensource-project vertegenwoordigt, zullen de organisatoren je vaak vrijwaren van de conferentievergoeding (als dat niet het geval is, zal de conferentie waarschijnlijk toch ongeschikt zijn). Breng je Linux-laptop (als je er een hebt) en laat enkele demo's zien. Vraag de projectbeheerder naar het materiaal dat je mag gebruiken ter voorbereiding van je presentatie of poster.
  16. Zoek op internet naar aankondigingen over een installatie-gebeurtenis in de buurt en probeer eerst als gebruiker deel te nemen (let op alle problemen die zich voordoen en hoe hackers die oplossen) en bied de volgende keer aan om programma's te installeren.
  17. Je bent klaar! Om zeker te zijn, probeer dan om sommige van de programmeurs aan het project in levende lijve te ontmoeten en samen een glas bier te heffen op het resultaat.
  18. Voor een beter begrip kijk je naar een echt voorbeeld van de ontwikkelingsgeschiedenis van een open softwareproject (zie boven). Elke stijgende curve vertegenwoordigt een bijdrage (regels code) van een enkele ontwikkelaar. Ontwikkelaars zijn geneigd om met het klimmen van de jaren minder actief te worden, maar het project versnelt vaak zelfs als nieuwe mensen toetreden. Dus als je arriveert met enkele nuttige vaardigheden op zak, dan zijn er geen redenen waarom het team je niet zou uitnodigen.
    Advertentie

Tips

  • Voordat je een vraag stelt over de praktische voorschriften binnen het project, kun je beter zoeken naar het antwoord in de projectdocumentatie en mailinglist-archieven.
  • Blijf altijd proberen om programmeerwerk waar je mee bent begonnen af te ronden. Kan het niet worden gebouwd, kan het niet worden uitgevoerd, het systeem crasht? Er zijn redenen voor alles, en beschik je over de broncode, dan betekent dit meestal dat je het systeem wel kunt forceren om te doen wat je wilt, vooral met de hulp van wat online onderzoek. Deze regel kent natuurlijk grenzen, maar inderdaad is het belangrijk om nooit al te gemakkelijk op te geven.
  • Noem jezelf alleen een programmeur (of hacker) nadat je door een deel van de echte hacker-gemeenschap als zodanig bent erkent.
  • Kies in het begin een class, module of andere unit waar niemand op dit moment zeer actief aam werkt. Samenwerken aan dezelfde class of zelfs een functie, vereist meer vaardigheden en zorg van alle kanten.
  • Werkgevers van sommige hackers/programmeurs lijken gemotiveerd genoeg om bijdragen onder werktijd toe te staan (meestal omdat de instelling gebruikmaakt van het gratis/opensource-programma dat de programmeur ontwikkelt). Denk na, misschien kun je ten minste een deel van de benodigde tijd op deze manier krijgen.
  • Als je nog steeds niet genoeg vertrouwen hebt in jezelf, begin dan vanuit een deel van de code waarvan je denkt dat die ontbreekt en vanaf nul kan worden geschreven. Wijzigingen in bestaande code zal veel sneller op kritiek stuiten.
Advertentie

Waarschuwingen

  • Je hacker-status binnen het gemeenschapsproject, is meer een afspiegeling van je heden dan je verleden. Als je een aanbeveling of iets dergelijks wilt van de projectleider, vraag dit dan als je nog steeds actief bijdraagt.
  • Begin niet aan kleine codeoptimalisaties, extra opmerkingen, verbeteringen van de coderingstijl en andere soortgelijke 'kleinschalige' dingen. Dit kan op veel meer kritiek stuiten dan een serieuze bijdrage. In plaats daarvan kun je deze wijzigingen meenemen in een enkele 'cleanup' patch.
  • Als je van plan bent om de hackers van open software persoonlijk te ontmoeten, laat je Windows-laptop dan thuis. Mac OS wordt iets meer getolereerd, maar is ook niet echt welkom. Als je je laptop meeneemt, dan moet het Linux draaien of een ander besturingssysteem dat zij als 'open software' beschouwen.
  • Als je e-mailclient HTML-berichten ondersteunt, dan kun je deze functie beter uitschakelen. Voeg nooit documenten als bijlage toe die alleen commerciële software (zoals Microsoft Word) goed kan openen. Hackers beschouwen dit als beledigend.
  • Meld je niet als vrijwilliger aan voor projecten van een bedrijf waarvan delen van de code niet onder een goedgekeurde opensource-licentie vallen. In dergelijke gevallen zullen de echt belangrijke onderdelen van het project waarschijnlijk achter gesloten deuren van de eigenaar blijven, wat je ervan weerhoudt om iets nuttigs te leren.
  • Vermijd elke vraag over de fundamenten van het programmeren of programmeertools. De tijd van een open softwareprogrammeur is kostbaar. Bespreek in plaats daarvan de grondbeginselen van het programmeren in groepen voor amateur- of beginnende programmeurs.
  • Gevestigde en zeer succesvolle projecten hebben mogelijk geschreven of ongeschreven beleid over het nooit vergoeden van je werk (geen geld, geen mogelijkheid tot promoten van jezelf, geen verhoogde status ongeacht je bijdrage, etc. -- zie : Do_not_expect_reward Wikipedia ). Als je hier niet mee akkoord kunt gaan, houd het dan bij meer gangbare projecten die een dergelijke houding niet kunnen veroorloven.
  • Begin niet aan een eigen project, tenzij je altijd in trotse eenzaamheid door wilt brengen. Om dezelfde reden kun je beter niet beginnen aan een poging om een reeds verlaten project dat zijn vorige team al heeft verloren, te doen herleven.
  • In het geval van een informele bijeenkomst over het project waar je nooit enige code aan bij hebt gedragen, zal je het onaangename gevoel hebben volledig genegeerd te worden. Maak je geen zorgen, sommige hackers kunnen later goede vrienden worden, nadat je hun respect hebt verdient met je eigen code.
  • Grote open softwareprojecten, vooral die rond het domein van de GNU, behandelen je baan niet als je persoonlijke zaak. Nadat je de baan binnen een software-gerelateerd bedrijf hebt gekregen, vragen ze je werkgever om bepaalde overeenkomsten [1] te ondertekenen, welke het bedrijf wel of niet zal ondertekenen. Dit kan je ertoe dwingen om een project met minder dwingende eisen te selecteren.
Advertentie

Benodigdheden

  • Linux. Veel open softwareprojecten zijn ingewikkelder om onder Windows te bouwen, of zijn helemaal niet correct te bouwen. Dit geldt met name voor geavanceerde projecten, gewijd aan de programmering van mobiele telefoons , USB-sleutels en andere apparaten.
  • Een computer met een relatief goede internetverbinding. Als je dual-boot met Windows wilt houden, dan zou een tweede harde schijf of partitie voor Linux een goede oplossing kunnen zijn.
  • Basiskennis van ten minste één programmeertaal en een sterke intentie om meer te leren. De meest populaire talen momenteel lijken C en Java te zijn.
  • Een aanzienlijke hoeveelheid tijd, ten minste vijf uur per week (een typische hardcore programmeur draagt maar liefst 14 uur bij).
  • Hoewel formeel IT-onderwijs je weg een stuk gemakkelijker zal maken, is dit niet een verplichte voorwaarde en geen echte hacker-gemeenschap zal je er ooit naar vragen. Programmeurs/hackers oordelen over elkaar door iemands programmeerwerk, niet nepcriteria zoals cijfers, leeftijd, ras of positie. Let wel, ten minste 60% van de open-sourcehackers die je patches beoordelen hebben wel de 'juiste' universitaire graad en zullen niet toestaan dat je onzin bijdraagt aan het project.
  • Tijdens de laatste stappen (conferentie en 'install party') kun je profiteren van een eigen laptop. Maar het is niet goed om er thuis aan te werken, dus koop er alleen een als je de tweede machine kunt veroorloven.
  • Het beschreven pad om 'hacker' van open-sourcesoftware te worden, vergt minstens twee jaar om te voltooien.

Over dit artikel

Deze pagina is 2.135 keer bekeken.

Was dit artikel nuttig?

Advertentie