🚀 go-pugleaf

Philip Paeps <philip+usenet@paeps.cx> wrote:

> John Bokma <john@castleamber.com> wrote:
>> Philip Paeps <philip+usenet@paeps.cx> wrote:

[ .. ]

>> Met als leuk resultaat dat het bedrijf failliet kan zijn voor het af
>> is. 
> 
> Dat heet "resource management" :-)

Als de resources er niet zijn, kan je ze ook niet managen. Ik lever 
regelmatig lijmoplossingen. Soms tussen CS en OSS, soms tussen OSS en 
OSS en soms tussen CS en CS. Ik heb nog niet kunnen ontdekken dat het 
een goedkoper is dan het ander.

>> Een mythe van Open Source is dat iedereen er ook echt mee aan de slag
>> kan. 
> 
> Dat is geen mythe maar een feit.

Dan heb je nog nooit serieus naar de source van een gemiddeld OS project 
gekeken.

> De mythe is dat het een silver
> bullet zou zijn, wat het dus niet is.  Het voordeel is dat eens je er
> mee aan de slag bent, je veel effici�nter knelpunten kunt oplossen dan
> met proprietaire software.

Misschien moet je voor de grap eens naar het history bestand van Firefox 
kijken... Of wellicht gewoon eens een willekeurig OSS project op source 
nivo doorwerken. Als er bakken met geld zijn, dan is het inderdaad geen 
probleem, maar dan is het vaak ook geen probleem om eventjes een aan de 
telefoon te hangen met de makers van het CS project.

>> Eventjes een OS programma reverse engineeren (noem 1 OS project met
>> goede documentatie op source nivo, ontwerpbeslissingen
>> gedocumenteerd, etc), aanpassen, debuggen enz. kan nogal wat
>> manmaanden kosten. 
> 
> Klassieke voorbeelden zijn de BSD kernels en de Linux kernel.  Er zijn
> boeken over geschreven die de lezer van naaldje tot draadje uitleggen
> hoe het geheel in elkaar past.  Ik denk aan de "Design and
> Implementation" boeken en aan "Understanding the Linux Kernel".
> 
> Met een beetje ervaring met kernel werk, kan een blocking bug of
> ontbrekende feature in dergelijke kernels snel opgelost worden.  Als
> je op de vendor van een proprietair systeem moet wachten, ben je al
> snel een aantal maanden of jaren verder.

Het hangt simpel weg af van de kosten. De ene keer kan het schuiven van 
een zak geld naar een CS bedrijf het toevoegen van een feature 
bespoedigen, en veel goedkoper zijn dan het vinden van een programmeur 
die ff een OS project induikt. Iemand met ervaring met kernel werk moet 
je maar kunnen vinden. Ik gok/vrees dat het meestal neerkomt op het 
huren van iemand die C kan programmeren, en de kernel wel ff in wilt 
duiken.

Mijn ervaring (jaren :-) ) is dat ik bijna altijd ingehuurd wordt om 
mijn programmeerkennis, en niet om de kennis met een bepaald systeem. En 
dat komt vaak neer dat ik "eventjes" mijzelf ergens in moet verdiepen. 
De ene keer is dat een API van een stukje CS, de andere keer is dat OSS. 

Wat mij erg opvalt, gemeten over 10+ jaar, is dat een API voor CS keurig 
gedocumenteerd is, dat er met een telefoontje of email vaak binnen een 
uur een reaktie binnenkomt op een support vraag, en zelfs voorstellen 
voor verbeteringen extreem snel doorgevoerd werden. 

Met OSS is mijn ervaring dat de documentatie soms 1 jaar (en soms nog 
meer) achter loopt op de werkelijkheid (ik vrees dat dat met de door 
jouw genoemde kernel boeken helaas ook het geval is, soms valt daar mee 
te leven, soms niet). Dat een vage foutmelding in Google stoppen soms 
een fix opleverd, en soms tig meldingen van mensen met hetzelfde 
probleem. Dat support soms ver te zoeken is (ja, eh, niet zeuren he, tis 
wel allemaal gratiz), niet meer werkende email adressen, maintainers die 
het al 5 keer naar anderen doorgeschoven hebben, enz. En als je dan al 
een verbetering durft voor te stellen mag je hopen dat je niet tegen een 
betonblok opbotst waar een ego achter schuil gaat waar ik bang van word.

Natuurlijk zijn er ook gevallen dat het prima werkt, dat OSS, en dat ik 
er probleemloos doorheen rol. Maar als ik ff snel over 10 jaar heen 
kijk, vrees ik dat ik meer tijd gestoken heb in al dat OSS gekloot 
versus al dat enge, vendor locked in CS.

>> En tja, die kosten kunnen ver boven de beschikbare resources
>> uitstijgen, en dan doet het er bitter toe dat het OS is voor dat
>> bedrijf. 
> 
> Als bedrijf zet je natuurlijk geen "newbie" als leerling tovenaar op
> een project, maar iemand die weet waar hij mee bezig is...

Ik doe nogal eens werk voor bedrijven met 4-5 man. Daar is geen geld en 
ruimte voor een leerling tovenaar. Niet eens voor een leerling 
programmeur. 

> Een goede
> developer is niet goedkoop, maar spaart wel tijd en kosten uit op
> langere termijn. 

Als er geld is om te investeren, uiteraard. Maar ik zie regelmatig 
bedrijven die een idee hebben, en denken dat het met OSS goedkoop te 
realiseren is (kost geen drol, geen licentie kosten, patches en de hele 
she-bang gratiz, gratiz). Om er vervolgens achter te komen dat een 
leerling tovenaar, de dagelijkse geit die geofferd moet worden, en 1x 
per maand een schone maagd, toch meer geld kost dan gewoon je ziel 
verkopen aan Microsoft of een andere CS toko.

-- 
John Bokma
                 Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Ervaren Perl / Java programmeur beschikbaar:  http://castleamber.com/
Tevreden opdrachtgevers:     http://castleamber.com/testimonials.html