WebGang/CityGang

Post Open vraag en antwoord

Vervolg van het vragenlijstje aan Bruce Perens.
(vorige keer: inleiding over Bruce Perens)

En dan de vragen, vrij vertaald en samengevat:

1. Is het de bedoelilng weer een soort “shareware” licentie te maken, zoals er vroeger al bestonden?

Nee, niet echt, zegt Perens. Hij gaat uit van de vraag: Wie zou er het meest gebaat moeten zijn met Open Source?
Dat lijken voor hem vooral individuen en kleine bedrijven te zijn. Die hebben nood aan goedkope of gratis software.
Grote bedrijven hebben andere noden. Die willen garantie over de hele lijn dat de software betrouwbaar is, dat er bv geen achterdeurtjes in binnengesmokkeld worden, die een bedreiging zou vormen voor heel hun bedrijf.
Ze willen ook professionele ondersteuning, als er een probleem is moeten ze iemand kunnen aanspreken of inschakelen.
En ze hebben garanties nodig dat de software voldoet aan allerlei wettelijke bepalingen, bv privacy enz.

Maar wat gebeurt er in de praktijk? Het zijn de grootste, wereldwijd grootste en rijkste bedrijven, die massaal gebruik maken van Open Source software, gratis, terwijl zij wel de middelen hebben om bij te dragen. Zij gaan wel op zoek naar spelers die hen kunnen ondersteunen in het gebruik van al die gratis software, en daarvoor schakelen ze consultants en andere “tussenpersonen” in die dan wel geld verdienen. Maar dat geld zou in de eerste plaats moeten toekomen aan de programmeurs die de code gemaakt hebben, en dat gebeurt nu niet. Er is niets voorzien, geen systeem om daar voor te zorgen.

Dus was de vraag, hoe dat probleem oplossen? Hoe ervoor te zorgen dat de programmeurs betaald krijgen voor hun creaties?
En hoe de software bedrijfsvriendelijker maken? En hoe ondersteuning bieden aan de bedrijven bij het gebruik en aanpassen van de software? Enz.

Het idee van Bruce Perens: bedrijven die meer dan 5 miljoen dollar inkomsten hebben, beginnen te betalen voor de software. En hoeveel ze betalen moet stijgen met de hoogte van die inkomsten, maar met een limiet van maximum 1 procent van hun inkomsten. Het woord “inkomsten” betekent hier niet de winst van het bedrijf, hier is letterlijk bedoeld het geld dat binnenkomt, dus het is een graadmeter voor wat het bedrijf doet. Winst of verlies maken is dikwijls een wisselende boekhoudkundige kwestie, en het moet duidelijker zijn dan dat.

Het is nu ook niet zo dat BP verwacht dat grote bedrijven zullen toehappen en spontaan gaan betalen. Hij ziet het eerder gebeuren dat kleine bedrijven, startups, in die nieuwe vorm open source (of post-open) beginnen te gebruiken, en als ze succesvol zijn en ze groeien, dan komen ze op een punt dat ze beginnen te betalen.

Er moet een organisatie zijn die dat int, en dat is dan Post-Open, die betalen de programmeurs dan uit, zodat die er zich niet mee bezig moeten houden en kunnen doen wat ze liefst doen: programmeren.

Post-Open moet dan van bedrijven verslag krijgen van de software die ze gebruiken. Post-Open kan dat verifieren, de gelden innen, en het bedrijf “in orde” verklaren voor een jaar. Post-Open checkt dan de software, het is open source, dus ze checken de repositories om te kijken wie de software schrijft, en die informatie gebruiken ze om de programmeurs uit te betalen.

Er zitten nog veel gaten in natuurlijk, software wordt dikwijls niet door 1 persoon geschreven, dus hoe verdelen? Wat met documentatie voor de software? Wat voor de makers van de graphics in de software? enz.. Veel vragen nog, maar het idee is te beginnen met betaling voor programmeurs en schrijvers van documentatie.

2. Zijn er al reacties?

Ja, inderdaad, en interessant genoeg van juristen. Een bedrijf van juristen heeft al toegezegd om zonder betaling mee te werken aan het opstellen en uitwerken van de juridische kant, zoals het uitschrijven van de licenties, checken t.o.v. andere wetgeving als copyright, patenten, exportbeperkingen enz.
Inderdaad gelden er momenteeel ook exportbeperkingen op software, omdat die in wapensystemen kan gebruikt worden.

3. Hoe kan je het eerlijk houden?

Dat is een goede vraag, want er zijn al orginisaties die werken in het open source ecosysteem, denk maar aan de Linux Foundation, de Mozilla foundation, enz. Daar zie je inderdaad dat de organisatie een vet-betaalde top lijkt te ontwikkelen, en dat maar een marginaal klein deel van de geldstroom uiteindelijk ten goede komt aan de programmeurs. Bij Linux zou dat bv maar 3% zijn. Mozilla had ook een dure topvrouw, die wel veel geld binnenbracht door een deal met Google, maar het contrast met de niet-betaalde programmeurs bleeft toch groot.

Dus er is een soort grondwet nodig voor de organisatie, die op papier zet dat de voordelen voor het management beperkt.
Eén stap zou bv al zijn om de programmeurs stemrecht te geven. Maar dat uitwerken is nog een hele karwei, en dat zal met vallen en opstaan moeten gebeuren.

4. De geschiedenis heeft bewezen dat geld corrupt maakt, hoe pak je dat aan?

Daar is transparantie een belangrijk hulpmiddel. Goede organisatie met goede regels.

5. Eerlijk delen, hoe?
Hoe kan je het geld eerlijk verdelen onder de bijdragen? En is burocratie toevoegen aan zo’n spontane wereld van open source wel een goed idee?

Wel, helemaal eerlijk verdeeld is wel utopisch, maar misschien is een niet-perfecte benadering wel waardevol. De meeste open source programmeurs krijgen nu helemaal niets.

6. Hoe kan het vertrouwen gegarandeerd worden?

Nog eens: transparantie. Lidmaatschap dat meekijkt. Audits. En er kunnen nog meer dingen zijn, dit is ook een oproep om er mee over na te denken, dus laat maar komen..

7. Wat voor verantwoordelijkheid krijgt de betaalde open source programmeur?

Ze zullen zich moeten identificeren natuurlijk. Wat ook goed is om te vermijden dat er backdoors door schimmige spelers in projecten wordt gesmokkeld. Een mogelijkheid is een soort 2FA, misschien met een speciaal versleutelingsapparaat dat de ontwikkelaar eenmalig krijgt. Alle communicatie met de organisatie kan dan daarmee versleuteld worden.

ps: in het geval van de backdoor in de XZ Utils, was de oorspronkelijke programmeur ook serieus misleid geworden door de fraudeur: er waren valse gebruikers accounts aangemaakt die allerlei valse bugreports maakten en extra eisen begonnen te stellen, waardoor de ontwikkelaar zich wat overdonderd voelde, en iets te snel een hulpvaardige onbekende programmeur mee toeliet controle over het project te krijgen.

8. Hoe zit het met de verantwoordelijkheid in geval van beveiligingsproblemen met de software? Mag de programmeur nog op vakantie gaan bv?

Daar zou de organisatie een belangrijke rol kunnen spelen, omdat de gebruikers zich tot de organisatie wenden, waar professionele opvang is. Daar kan worden beslist om vanuit de organisatie de programmeur te contecteren, en als die niet beschikbaar is, om te kijken wie wel ingeschakeld kan worden uit de kennis en de medewerkerspool en daarbuiten.

Muziek

1): 9-10- 2): 01, 02, 03, ? 04