Open source participant of user?

14-04-2009 15:50 | Door Mylene Reiners | Lees meer artikelen over: Java, Apache | Lees meer over het bedrijf: Google | Er is 1 reactie op dit artikel | Permalink
Computable Expert
Mylene Reiners
Mylene Reiners

Productmanager OSCE, Architect

Expert van Computable voor de topics: Open Source en Cloud Computing

Meer

Velen gebruiken open source als besturingssysteem (Ubuntu Linux) en als hulpmiddel bij het ontwikkelen van Java EE-applicaties. In dat kader moet je denken aan ontwikkelhulpmiddelen als Eclipse en Maven en (vaak heel) veel tools die het werken met Java EE nou eenmaal gemakkelijker maken, zoals Spring, Hibernate, veel Apache-projecten en dergelijke. De meesten zijn echt open source minded, zolang je het hebt over gebruik. Slechts een enkeling is actief bezig met bijdragen aan een of andere open source community. Zou het kunnen zijn dat het gebrek aan committers de open source-beweging de das om kan doen?

Als basis voor het principe van open source heb ik het document 'The Cathedral and the Bazaar' van Eric S. Raymond genomen (Nederlandse vertaling). Hierin wordt een negentiental principes genoemd die de open source-beweging (de bazaar) sterker maken dan closed source (de kathedraal). Ik heb er een drietal uitgelicht en geprobeerd redenen te vinden waarom het aantal participanten kan teruglopen.

Deelname in of het starten van open source-projecten heeft vaak te maken met 'de persoonlijke jeuk van de programmeur' (principe 1). Wat is er mooier dan een goed stuk software schrijven voor een probleem dat je tegenkomt, zodat meer mensen er iets aan hebben? Hier lijkt Google tegen te werken; code voor het oplossen van een (deel)probleem of een tool dat dat al voor je doet, is snel gevonden en de creativiteit van de ontwikkelaar blijft steken in het kunnen 'lijmen' van alle voorgekauwde oplossingen. Dat goed lijmen zou natuurlijk toch weer tot een leuk project kunnen leiden: 'Goede programmeurs weten wat ze moeten schrijven, hele goede weten wat ze moeten herschrijven (en hergebruiken)' (principe 2). Maar ja, waarom zou je? Iedere gek kan toch die oplossingen vinden die jij vond? Zo werkt de stelling 'Als je de juiste instelling hebt, vinden interessante problemen je' jammer genoeg niet meer! Een ander punt dat hier tegenin gaat, is het moeten verdienen aan het 'committer-zijn'. Meestal moet je dan problemen of bugs oplossen die de bestaande committers minder interessant vinden (anders hadden zij ze allang opgelost) en blijf dan maar enthousiast! Ik heb ooit twee-en-een-half jaar geprobeerd committer van een project te worden, wat niet gelukt is, al was men blij met mijn bijdragen. Dat is best vervelend en motiveert echt niet!

Een volgend punt zijn je bètatesters. 'Gegeven een voldoende grote omvang van bètatesters en ontwikkelaars kan bijna elk probleem snel worden benoemd en is de oplossing ervan voor iemand voor de hand liggend' (principe 3). Dé bron om nieuwe ontwikkelaars te vinden en de code getest te krijgen. De waan van de dag, en (vaak) de opdracht van je baas om een project op een bepaald moment af te hebben, geeft je niet veel tijd om een mogelijk nieuw initiatief dat jouw probleem oplost te volgen. Je bent zelf al bezig met het oplossen van dat probleem en als je dat eenmaal gedaan hebt, moet je wel erg trots op je code zijn, tijd hebben en redelijk zwaar in het onderwerp geïnteresseerd zijn, om die code (als dat überhaupt mag) nog te doneren aan de open source-gemeenschap! Toch moet je je bètatesters halen uit geïnteresseerden, die liefst hetzelfde probleem herkennen, en er genoeg verstand van hebben om zinvolle tests te kunnen doen (en te zien waar die falen!) en willen helpen om dat op te lossen (met goede ideeën en/of code).

Waar haal je die mensen vandaan als je alleen nog maar 'gebruikers' hebt, waar op zich natuurlijk niks mis mee is? Dit kan toch niet het begin van het einde van de echte open source zijn?

Reacties op dit artikel
Geen ratingEric D. Schabell, 20-04-2009 10:10
Even wat punten uit dit interessante overzicht opmerken:
 
- Het proberen mee te werken aan FOSS projecten in de Java wereld is in mijn ervaring een zeldzaamheid als je werkgever dat niet ondersteunt. Ik heb ook in verschillende (vooral Linux gerelateerde) FOSS projecten bijgedragen, vooral in mijn eigen tijd. Het is vrij normaal dat je iets tegenaan loopt in je werk, waarbij het probleem/oplossing/bugfix verder in je eigen tijd wordt uitwerkt. Ik mis die mentaliteit in de "Java" wereld. Tuurlijk zijn er uitzonderingen (geen Flamers gezocht!), maar over het algemeen komt het idee niet snel op om een bijdrage te leveren aan een FOSS project.
 
- Opmerking over een project die je niet toelaat. Dit soort 'gesloten' projecten zijn je tijd niet waard. Het is niet verkeerd om te verwachten dat je eerst je tijd en waarde moet bewijzen aan een project, maar 2 jaar klinkt als verspeelde tijd. ?Time to move on!? Er zijn veel andere FOSS projecten die je graag zouden willen hebben.
 
Als je geen gemeenschap hebt om feedback te geven over je releases enz., dan heb je te maken met natuurlijke selectie. Het is juist een effect van FOSS dat je alleen de meest bruikbaar, werkbaar, en effectief oplossingen overblijven.
59 vacatures
Pielen in PHP, of on Rails in Ruby?

ForecastXL (via Quoratio BV) , Groningen

Senior SAP BW Specialist - Tilburg

Achmea , Tilburg

Java Developer

Allshare B.V. , Hoofddorp

Talend Developer

Allshare B.V. , Hoofddorp

Software Designer die trots is op wat hij al kan met Java of C#

Technolution , Gouda

Top 10 Reagerende members
  Aantal reacties
met 3+ sterren
Gemiddelde
waardering
Klik voor meer info1 1571 6.2
Klik voor meer info2 1305 6.0
Klik voor meer info3 1271 6.2
Klik voor meer info4 1072 6.2
Klik voor meer info5 980 6.1
Klik voor meer info6 901 6.1
Klik voor meer info7 755 6.2
Klik voor meer info8 524 6.1
Klik voor meer info9 405 6.2
Klik voor meer info10 399 6.0