Overeenkomst met programmeur

[Michiel Hennink]

Beste ondernemers,

 

Bij het inhuren van programmeurs wil ik voortaan alles wat professioneler aan gaan pakken. Niet door slechte ervaringen, maar wel omdat ik vind dat dit als bedrijf nou eenmaal hoort en omdat ik denk dat dit problemen in de toekomst kan voorkomen.

 

Hierbij hoort dat alles op papier in orde is, en dan met name op het vlak van de intellectuele eigendom e.d. van het werk door de programmeur en betalingen. Ik heb hiervoor een kleine overeenkomst opgesteld (als non-jurist).

 

Nu vroeg ik me af of hier wat mensen zitten die er eens een blik op zouden willen werpen. Nogmaals, ik ben geen jurist maar heb wel goed gekeken naar de meest voorkomende opbouw van contracten, en ik heb gewoon logisch nagedacht over belangrijke punten en de mogelijkheid tot het creëren van juridische veiligheid bij deze punten.

 

Ik ben benieuwd of wellicht sommigen zin hebben om wat inhoudelijke kritiek te leveren!! Alvast bedankt,

 

Michiel.

 

/Edit: en uiteraard verwacht ik niet dat men dit helemaal zal gaan doorspitten op deze zonnige dag, maar het zou mooi zijn als iemand het even zou willen screenen op belangrijke missers!

Overeenkomst_met_programmeur.pdf

[willemj]

Als programmeur:

 

Onderdeel 2 punten 6 en 7 rammelen. Je beschrijft niet op welke punten je de opgeleverde code accepteert. Daarnaast heb je volgens de wet een redelijke termijn om een gebrek op te lossen. Geen idee of twee weken redelijk is. Maar na een éénmalige poging het gebrek te verhelpen en dan (zonder duidelijk omschreven criteria) eenzijdig het contract kunnen ontbinden lijkt me niet redelijk.

 

Onderdeel 4 punt 1, volledig overdragen van rechten, ga ik zelf nooit mee akkoord. Ik gebruik een hele berg zelf ontwikkelde code waar mijn klanten hun voordeel mee doen. Daar kan ik de rechten, al zou ik het willen, niet eens van overdragen omdat derden al een licentie hebben.

 

Bij onderdeel 3 punt 2, kosten grove nalatigheid/opzet, mist volgens mij nog redelijkerwijs.

 

Oh ja, onderdeel 4 punt 1, overdracht rechten: pas na volledig voldoen van alle facturen (en eventuele (buiten)gerechtelijke kosten ter verkrijging daarvan) door Ad Summa ;-)

[Michiel Hennink]

Onderdeel 2 punten 6 en 7 rammelen. Je beschrijft niet op welke punten je de opgeleverde code accepteert. Daarnaast heb je volgens de wet een redelijke termijn om een gebrek op te lossen. Geen idee of twee weken redelijk is. Maar na een éénmalige poging het gebrek te verhelpen en dan (zonder duidelijk omschreven criteria) eenzijdig het contract kunnen ontbinden lijkt me niet redelijk.

 

Onderdeel 4 punt 1, volledig overdragen van rechten, ga ik zelf nooit mee akkoord. Ik gebruik een hele berg zelf ontwikkelde code waar mijn klanten hun voordeel mee doen. Daar kan ik de rechten, al zou ik het willen, niet eens van overdragen omdat derden al een licentie hebben.

 

Bij onderdeel 3 punt 2, kosten grove nalatigheid/opzet, mist volgens mij nog redelijkerwijs.

 

Oh ja, onderdeel 4 punt 1, overdracht rechten: pas na volledig voldoen van alle facturen (en eventuele (buiten)gerechtelijke kosten ter verkrijging daarvan) door Ad Summa ;-)

Bedankt voor je reactie! Ik heb hier veel aan. Over enkele van je punten heb ik een vraag, andere heb ik direct doorgevoerd. Zie de bijlage voor het resultaat! :)

[*]Goedkeuring van levering: hier was ik inderdaad vaagjes over. Dit heb ik aangepast en verduidelijkt met overzichtelijke criteria.

[*]Overdragen van de rechten: ik heb in de overeenkomst een zinnetje opgenomen waarmee het mogelijk wordt hier andere afspraken over te maken, in bijvoorbeeld de gevallen die jij noemt.

[*]Redelijkerwijs bij het onderdeel Aansprakelijkheid: klopt, toegevoegd.

[*]Overdracht rechten en volle eigendom: inderdaad toegevoegd dat dit pas gebeurt na het voldoen van de facturen door mijn bedrijf!

Ik ben benieuwd wat je er nu van vindt!

Overeenkomst_met_programmeur_-_UPDATE.pdf

[postbus73]

Denk nog steeds dat je punt 5 moet aanpassen.

Ik heb de afgelopen 10 jaar libraries opgebouwd met code die ik steeds hergebruik. 1 opdracht voor Ad Summa en ik zou het recht m'n eigen libs te gebruiken verliezen?

 

Misschien kan je beter gebruiksrecht en/of distributierecht bedingen. (Al zal voor mij persoonlijk ook afdwingen van distributierecht betekenen dat ik een klus zal weigeren.)

[Michiel Hennink]

Denk nog steeds dat je punt 5 moet aanpassen.

Ik heb de afgelopen 10 jaar libraries opgebouwd met code die ik steeds hergebruik. 1 opdracht voor Ad Summa en ik zou het recht m'n eigen libs te gebruiken verliezen?

 

Misschien kan je beter gebruiksrecht en/of distributierecht bedingen. (Al zal voor mij persoonlijk ook afdwingen van distributierecht betekenen dat ik een klus zal weigeren.)

Ik denk dat je eroverheen hebt gelezen, ik heb al ingevoegd dat hier andere afspraken over gemaakt kunnen worden! ;)

Overdragen van de rechten: ik heb in de overeenkomst een zinnetje opgenomen waarmee het mogelijk wordt hier andere afspraken over te maken, in bijvoorbeeld de gevallen die jij noemt.

[Dick Marjot]

Auteursrecht vind ik bij software altijd een lastig verhaal. Meermaals heb ik opdrachten afgewezen omdat de opdrachtgever de broncode wilde hebben. Niet onlogisch op zich maar gezien het feit dat veel software ontwikkelaars werken met eigen bibliotheken met standaard functionaliteiten is het vaak niet zo dat de opdrachtgever voor de algehele ontwikkeling van de software betaalt (althans bij mij niet). Dien ten gevolge regel ik het meestal zo dat het intellectueel eigendom op de code bij mij blijft maar het intellectueel eigendom op de functionaliteit (soms lastig te scheiden) in het geheel van de applicatie/website bij de opdrachtgever ligt.

Werkt over het algemeen prima. Voor gevallen waarbij de opdrachtgever meer zekerheid wil zijn er altijd nog mogelijkheden voor ESCROW-achtige overeenkomsten (deponeren bij een derde partij).

[Michiel Hennink]

Auteursrecht vind ik bij software altijd een lastig verhaal. Meermaals heb ik opdrachten afgewezen omdat de opdrachtgever de broncode wilde hebben. Niet onlogisch op zich maar gezien het feit dat veel software ontwikkelaars werken met eigen bibliotheken met standaard functionaliteiten is het vaak niet zo dat de opdrachtgever voor de algehele ontwikkeling van de software betaalt (althans bij mij niet). Dien ten gevolge regel ik het meestal zo dat het intellectueel eigendom op de code bij mij blijft maar het intellectueel eigendom op de functionaliteit (soms lastig te scheiden) in het geheel van de applicatie/website bij de opdrachtgever ligt.

Werkt over het algemeen prima. Voor gevallen waarbij de opdrachtgever meer zekerheid wil zijn er altijd nog mogelijkheden voor ESCROW-achtige overeenkomsten (deponeren bij een derde partij).

Ik begrijp het probleem. In zulke gevallen is de overeenkomst natuurlijk altijd deels aan te passen. Doordat het echter hele specifieke aanvullingen (vaak unieke functies) zijn aan een bestaand systeem, verwacht ik niet dat er vaak gebruik kan en zal worden gemaakt van standaard componenten.

 

Wat denk je verder van de overeenkomst in zijn geheel? Is het wat? :)

[Dick Marjot]

Overeenkomst is een behoorlijke basis om samenwerkingen wat professioneler aan te pakken, zonder meer.

 

Echter, punt 3.4 is in de praktijk ook wel eens lastig. Sowieso is eenmalig onredelijk in mijn ogen (hoe vaak moet je zelf niet wat aanpassen op sites als gevolg van interpretatieverschillen met de opdrachtgever?) en mijn ervaring leert dat opdrachtgevers nog wel eens een idee wat willen bijschaven als de eerste (deel)versie er eenmaal staat. Ik vind het prettiger werken in een iets opener samenwerking waarbij binnen grenzen mogelijkheden liggen tot verbetering van de functionaliteit als gevolg van voortschrijdend inzicht. Niet zelden is een opdracht niet zo strak te definiëren dat het zich niet laat vatten in een strakke beschrijving passend bij een dergelijke overeenkomst.

 

Een overeenkomst is dus zeker goed maar geef daar zeker ook aan dat overleg over genoemde voorwaarden mogelijk is om tot een prettige samenwerking te komen.

[Michiel Hennink]

Overeenkomst is een behoorlijke basis om samenwerkingen wat professioneler aan te pakken, zonder meer.

 

Echter, punt 3.4 is in de praktijk ook wel eens lastig. Sowieso is eenmalig onredelijk in mijn ogen (hoe vaak moet je zelf niet wat aanpassen op sites als gevolg van interpretatieverschillen met de opdrachtgever?) en mijn ervaring leert dat opdrachtgevers nog wel eens een idee wat willen bijschaven als de eerste (deel)versie er eenmaal staat. Ik vind het prettiger werken in een iets opener samenwerking waarbij binnen grenzen mogelijkheden liggen tot verbetering van de functionaliteit als gevolg van voortschrijdend inzicht. Niet zelden is een opdracht niet zo strak te definiëren dat het zich niet laat vatten in een strakke beschrijving passend bij een dergelijke overeenkomst.

 

Een overeenkomst is dus zeker goed maar geef daar zeker ook aan dat overleg over genoemde voorwaarden mogelijk is om tot een prettige samenwerking te komen.

Wat je beschrijft is het risico dat elke overeenkomst met zich meebrengt: stijfheid en een minder prettige samenwerking. Ik maak me hier echter geen zorgen om: dit is geen richtlijn tot een manier van werken, maar een juridische stok achter de deur. Uiteraard wordt er vaak bij het programmeren na onderling overleg nog het een en ander aangepast en/of toegevoegd.

 

Deze overeenkomst zorgt er echter voor dat er bij een faliekant misgelopen samenwerking, op een voor beiden duidelijke wijze een afronding plaats kan vinden. De eenmalige termijn voor het verhelpen van de gebreken is dan om in ieder geval het broodnodige voor elkaar te krijgen.

 

Ik ben erg benieuwd of er nog meer mensen zijn die tekstuele en/of inhoudelijke mankementen zien!

[John B]

Beste Michiel,

 

Ik weet niet wat voor gegevens er in de databases zitten die aan je website zijn gekoppeld, maar als dit klantgegevens of anderszins vertrouwelijke gegevens zijn, dan zou ik hier iets explicieter over zijn. Nu staat er in 2.3 onder welke voorwaarden de Programmeur deze gegevens mag inzien / gebruiken, maar ik zou nog ergens iets opnemen in de trant van "Programmeur zal met betrekking tot gegevens van Ad Summa waarvan deze kennisneemt tijdens de uitvoering van een Programmeeropdracht geen mededeling doen naar derden en deze op generlei wijze aan derden verstrekken."

 

Kijk ook goed of je jezelf niet teveel belemmert met deze overeenkomst. Stel dat een programmeur binnen de tijd een puinhoop oplevert, wil je deze dan echt nog 14 dagen de tijd geven om dit te herstellen, terwijl je eigenlijk al weet dat dit niet gaat lukken?

 

Wil je dat een programmeur alle gegevens verwijdert na het beeindigen van de overeenkomst of na het beeindigen van elke programmeeropdracht (artikel 6.2)? In het eerste geval heb je niet afgedekt dat er code en gegevens in zijn bezit zijn die wel relevant waren voor de afgeronde opdracht, maar niet meer voor de nieuwe opdracht. Hoeft geen probleem te zijn, maar misschien toch even over nadenken.

 

Waar staat dat zinnetje over het maken van andere afspraken over het eigendom van de code?

 

Nog wat taaldingetjes:

- 3.3 - een factuur te sturen

- 3.5 - niet zijn verholpen

- 3.6 - op welke wijze dan ook te gebruiken (nog kan weg)

- 4.2 - dat deze veroorzaakt is

- 5.1 - het volle eigendom dat

- 6.2 - alle gegevens die het eigendom zijn van Ad Summa van zijn of haar opslagmedia te verwijderen.

 

Groet,

 

John

[willemj]

In je nieuwe overeenkomst lees ik nu:

 

Wanneer Ad Summa niet akkoord gaat het met geleverde en de Programmeeropdracht annuleert zoals beschreven in 3.5 is het zowel de Programmeur als Ad Summa niet toegestaan het resultaat (de Code) later op welke wijze dan ook nog te gebruiken (bijv. voor eigen gebruik of verkoop).

 

Tenzij ik met het gebruik van die code inbreuk maak op enig ander recht lijkt het me dat ik kan doen en laten wat ik wil met code die ik produceer.

 

In onderdeel 4 punt 2, aansprakelijkheid, bedoelde ik dat 'redelijkerwijs' bij de kosten hoort te staan :) Sowieso zou ik er als programmeur graag een beperking van aansprakelijkheid in willen hebben.

 

 

[R.I.P. | Peter Bonjernoor]

Als programmeur bevestig ik bij deze dat ik, om de hierboven genoemde redenen, met absolute zekerheid zou weigeren om hier een krabbel onder te zetten.

 

Het is allemaal puur vanuit jouw belangen geschreven, en mist daardoor alle evenwicht.

[Michiel Hennink]

Bedankt voor jullie waardevolle reacties!

Ik weet niet wat voor gegevens er in de databases zitten die aan je website zijn gekoppeld, maar als dit klantgegevens of anderszins vertrouwelijke gegevens zijn, dan zou ik hier iets explicieter over zijn. Nu staat er in 2.3 onder welke voorwaarden de Programmeur deze gegevens mag inzien / gebruiken, maar ik zou nog ergens iets opnemen in de trant van "Programmeur zal met betrekking tot gegevens van Ad Summa waarvan deze kennisneemt tijdens de uitvoering van een Programmeeropdracht geen mededeling doen naar derden en deze op generlei wijze aan derden verstrekken."

Slim! Staat er nu wel in.

Kijk ook goed of je jezelf niet teveel belemmert met deze overeenkomst. Stel dat een programmeur binnen de tijd een puinhoop oplevert, wil je deze dan echt nog 14 dagen de tijd geven om dit te herstellen, terwijl je eigenlijk al weet dat dit niet gaat lukken?

Het lijkt me niet onredelijk ieder een kans te geven om de gebreken te verhelpen. Als ik ervan overtuigd ben dat de betreffende programmeur enkel puin zal leveren, dan ga ik desnoods ondertussen al met een ander aan de slag.

Wil je dat een programmeur alle gegevens verwijdert na het beeindigen van de overeenkomst of na het beeindigen van elke programmeeropdracht (artikel 6.2)? In het eerste geval heb je niet afgedekt dat er code en gegevens in zijn bezit zijn die wel relevant waren voor de afgeronde opdracht, maar niet meer voor de nieuwe opdracht. Hoeft geen probleem te zijn, maar misschien toch even over nadenken.

Ik denk dat het niet nodig is dat de programmeur na iedere opdracht gaat zitten deleten. Het gaat mij er om dat de data verwijderd wordt na het stopzetten van de samenwerking.

Waar staat dat zinnetje over het maken van andere afspraken over het eigendom van de code?

Dat was wat onduidelijk, 5.1 is nu verduidelijkt.

Nog wat taaldingetjes:

- 3.3 - een factuur te sturen

- 3.5 - niet zijn verholpen

- 3.6 - op welke wijze dan ook te gebruiken (nog kan weg)

- 4.2 - dat deze veroorzaakt is

- 5.1 - het volle eigendom dat

- 6.2 - alle gegevens die het eigendom zijn van Ad Summa van zijn of haar opslagmedia te verwijderen.

Allemaal verwerkt! Echt super dat je de overeenkomst met een dusdanige nauwkeurigheid hebt gelezen dat dergelijke fouten je opgevallen zijn!!

Tenzij ik met het gebruik van die code inbreuk maak op enig ander recht lijkt het me dat ik kan doen en laten wat ik wil met code die ik produceer.

Een lastig punt. Het gaat mij hierom, je kunt het vergelijken met een filmmaker die aan de gang gaat het het script van een scenarist: als de filmmaker vervolgens bagger levert, wil de scenarist niet dat deze bagger (maar met zijn script) verkocht wordt aan een derde. Het probleem is dat een scenarist zekerheid heeft door het auteursrecht: dit bestaat bij ideeën voor website(functies) niet. Ik laat de bepaling erin staan op hoop van zege :).

In onderdeel 4 punt 2, aansprakelijkheid, bedoelde ik dat 'redelijkerwijs' bij de kosten hoort te staan :) Sowieso zou ik er als programmeur graag een beperking van aansprakelijkheid in willen hebben.

Toegevoegd.

Als programmeur bevestig ik bij deze dat ik, om de hierboven genoemde redenen, met absolute zekerheid zou weigeren om hier een krabbel onder te zetten.

 

Het is allemaal puur vanuit jouw belangen geschreven, en mist daardoor alle evenwicht.

Naar aanleiding van de genoemde punten nu dus een update! Ik ben erg benieuwd wat je er nu van vindt.

Overeenkomst_met_programmeur_-_UPDATE_2.pdf

[willemj]

Tenzij ik met het gebruik van die code inbreuk maak op enig ander recht lijkt het me dat ik kan doen en laten wat ik wil met code die ik produceer.

Een lastig punt. Het gaat mij hierom, je kunt het vergelijken met een filmmaker die aan de gang gaat het het script van een scenarist: als de filmmaker vervolgens bagger levert, wil de scenarist niet dat deze bagger (maar met zijn script) verkocht wordt aan een derde. Het probleem is dat een scenarist zekerheid heeft door het auteursrecht: dit bestaat bij ideeën voor website(functies) niet.

 

Helemaal geen lastige als je goed leest wat ik schrijf. Je voorbeeld klopt dan ook niet omdat de filmmaker bij gebruik van het materiaal inbreuk zou maken op rechten van de scenarist.

 

Ik laat de bepaling erin staan op hoop van zege :).

 

Op welke uitkomst? Dat een programmeur geen zaken met je wilt doen omdat je onredelijke voorwaarden hanteert?

 

Beperking van aansprakelijkheid heb je trouwens niet opgenomen.

[John B]

Wil je dat een programmeur alle gegevens verwijdert na het beeindigen van de overeenkomst of na het beeindigen van elke programmeeropdracht (artikel 6.2)? In het eerste geval heb je niet afgedekt dat er code en gegevens in zijn bezit zijn die wel relevant waren voor de afgeronde opdracht, maar niet meer voor de nieuwe opdracht. Hoeft geen probleem te zijn, maar misschien toch even over nadenken.

Ik denk dat het niet nodig is dat de programmeur na iedere opdracht gaat zitten deleten. Het gaat mij er om dat de data verwijderd wordt na het stopzetten van de samenwerking.

Maar intussen heb je dit wel toegevoegd als artikel 3.7 ;)

 

 

Echt super dat je de overeenkomst met een dusdanige nauwkeurigheid hebt gelezen dat dergelijke fouten je opgevallen zijn!!

Ik kan het niet laten: in je nieuwe versie staat in 3.7 op de laatste regel Programmeuropdracht i.p.v. Programmeeropdracht ...

 

[Edit]

 

Ik ben het overigens met Willem eens dat je 3.6 best zodanig kunt aanpassen, dat de code door de Programmeur kan worden gebruikt mits hiermee geen inbreuk wordt gemaakt op enig recht van Ad Summa.

[Michiel Hennink]

Helemaal geen lastige als je goed leest wat ik schrijf. Je voorbeeld klopt dan ook niet omdat de filmmaker bij gebruik van het materiaal inbreuk zou maken op rechten van de scenarist.

Wel nauwkeurig lezen hè ;). Ik geef zelf al aan dat een programmeur in principe geen rechten schendt door zijn code (door mij afgewezen, maar mijn idee bevattend) alsnog aan een ander te verkopen. Omdat dit echter voor mij net zo vervelend is als voor een scenarist, wil ik dat op deze wijze indekken. Ik vind dat absoluut niet onredelijk: als iemand troep oplevert wil ik de samenwerking kunnen beëindigen zonder gedwongen te worden om óf zijn troep te kopen óf het risico te lopen dat hij zijn troep maar tevens mijn unieke idee aan een ander verkoopt. Let wel: levert een programmeur hetgeen hij beloofd heeft te leveren, dan is deze bepaling helemaal niet van toepassing!!

 

Wil je dat een programmeur alle gegevens verwijdert na het beeindigen van de overeenkomst of na het beeindigen van elke programmeeropdracht (artikel 6.2)? In het eerste geval heb je niet afgedekt dat er code en gegevens in zijn bezit zijn die wel relevant waren voor de afgeronde opdracht, maar niet meer voor de nieuwe opdracht. Hoeft geen probleem te zijn, maar misschien toch even over nadenken.

Ik denk dat het niet nodig is dat de programmeur na iedere opdracht gaat zitten deleten. Het gaat mij er om dat de data verwijderd wordt na het stopzetten van de samenwerking.

Maar intussen heb je dit wel toegevoegd als artikel 3.7 ;)

Wat een sloddervos ben ik! Als ik het zo zien staan is het misschien toch wel verstandig, wat is jouw mening op dit vlak?

Ik kan het niet laten: in je nieuwe versie staat in 3.7 op de laatste regel Programmeuropdracht i.p.v. Programmeeropdracht ...

Super, dit soort aanmerkingen zijn alleen maar heel erg nuttig!

[Edit] Ik ben het overigens met Willem eens dat je 3.6 best zodanig kunt aanpassen, dat de code door de Programmeur kan worden gebruikt mits hiermee geen inbreuk wordt gemaakt op enig recht van Ad Summa.

Het probleem is dat dit het dus mogelijk maakt voor een programmeur om met mijn ideeën aan de haal te gaan en deze te exploiteren, omdat websiteideeën niet dezelfde bescherming genieten als bijvoorbeeld een filmscript. Met deze bepaling wil ik het deze (hele redelijke) bescherming alsnog geven.

[John B]

Maar intussen heb je dit wel toegevoegd als artikel 3.7 ;)

Wat een sloddervos ben ik! Als ik het zo zien staan is het misschien toch wel verstandig, wat is jouw mening op dit vlak?

Als een programmeur direct na de huidige opdracht een nieuwe opdracht krijgt voor dezelfde onderdelen, dan is het natuurlijk onhandig om eerst alles te verwijderen en dan weer te downloaden. Maar als er een periode tussen zit, dan lijkt het mij wenselijk om alles wel te verwijderen. Het kan namelijk best zo zijn dat je in de tussentijd een andere programmeur aan dat deel hebt laten werken en dan is die code sowieso verouderd. Schat even in hoe dat in de praktijk gaat: werkt dezelfde programmeur meestal aan dezelfde onderdelen en zijn de opdrachten redelijk aaneengesloten, dan zou ik het artikel weghalen. Plaats je opdrachten voor dezelfde onderdelen van de website afwisselend bij verschillende programmeurs of zitten er grote tijdgaten tussen de opdrachten, dan zou ik het artikel laten staan.

[R.I.P. | Peter Bonjernoor]

Ik ben het overigens met Willem eens dat je 3.6 best zodanig kunt aanpassen, dat de code door de Programmeur kan worden gebruikt mits hiermee geen inbreuk wordt gemaakt op enig recht van Ad Summa.

 

Dit vind ik zelfs het grootste bezwaar. Het gaat er in basis van uit dat het intellectueel eigendom overgedragen wordt, terwijl dat in werkelijkheid maar heel zelden gebeurt. In die zeldzame gevallen betaalt de opdrachtgever daar ruim voor.

 

Het probleem is dat dit het dus mogelijk maakt voor een programmeur om met mijn ideeën aan de haal te gaan en deze te exploiteren, omdat websiteideeën niet dezelfde bescherming genieten als bijvoorbeeld een filmscript. Met deze bepaling wil ik het deze (hele redelijke) bescherming alsnog geven.

 

Sorry, maar dit is niet de manier om dat te regelen. Concepten kun je, ongeacht de uitvoering ervan, gewoon vastleggen en beschermen. De technische realisatie valt echter niet onder jouw concept, en daar heb je in mijn optiek dan ook geen enkel recht op, tenzij je er voor kiest dat voor een fatsoenlijk bedrag af te kopen.

 

Maar goed, het is natuurlijk volledig aan jou om te bepalen welke eisen je wilt stellen aan mensen die je inhuurt. Ik denk alleen dat de kans dat iemand hier mee akkoord zal gaan erg klein is omdat het niet realistisch is.

[Minter]

Okey,

 

Wat is in jouw ogen kwaliteit? Wanneer het werkt zoals jij gevraagd hebt of wanneer het volgens bepaalde richtlijnen gedaan is?

 

Om het woordje hallo op het scherm te krijgen zijn honderden mogelijkheden, van echo 'hallo'; tot aan een complete request object met een template. Wat is kwaliteit?

 

Als programmeur zijnde zou ik hier niet mee akkoord gaan. Je zult zelf een voorselectie moeten doen op kwalitatief gebied, normaal is dan om een geheimhoudingsverklaring te tekenen, meer niet.