GitHub geeft ontwikkelaars optie om private repo's voor sponsoren op te zetten

GitHub breidt het Sponsors-platform uit zodat sponsoren toegang kunnen krijgen tot privé-repositories. Zo kunnen gebruikers die een ontwikkelaar ondersteunen exclusieve repo's zien en gebruiken, zoals een early-access-build van code.

De nieuwe functie is beschikbaar voor alle gebruikers van GitHub Sponsors, zowel individuele gebruikers als bedrijven. Die kunnen hun sponsoren dan toegang verlenen tot 'Sponsors-only repositories', schrijft GitHub. Voor iedere aangeboden tier van sponsoring kunnen gebruikers een aparte repo beschikbaar maken zodat ze verschillende toegangsniveaus kunnen opzetten. GitHub noemt zelf als gebruikersvoorbeeld dat een sponsor toegang krijgt tot unieke projecten, early access van builds voordat die breed beschikbaar worden en discussies voor donateurs.

Het platform komt ook met een paar andere veranderingen. Zo wordt het mogelijk een minimumbedrag in te stellen voor sponsoren. Ook kunnen gebruikers aparte welkomstberichten instellen voor nieuwe donateurs en het wordt mogelijk om te zien waar een sponsor vandaan komt via utm-codes in url's.

Reacties (49)

[Justice]

Zodra er geld mee speeld dan worden beslissingen anders genomen, dit gaat direct tegen de idealen van GitHub in (samenwerken en versprijden van open source) en voor mij is dit duidelijk het begin van het einde voor GitHub. Ja op deze manier kunnen mensen die niet kunnen coden wel "bijdragen aan de voorgang van het project" maar dat kan zonder deze feature ook al.

Ik voorspel dat we karige "vrije" software zullen zien waarbij de essentiele functionaliteit achter een sponsor-wall verstopt zit.

De platform (github) waarop de content (source code) zit heeft invloed op het gedrag van zijn klanten, en dit injecteerd kapitalisme in een proces dat tot vandaag open code belangrijker vond dan prive code.

Misschien dat ik een slechte morgen heb?

[Reactie gewijzigd door Justice op 22 juli 2024 20:42]

[teek2]

Je hebt denk ik wel een slechte morgen. Net als veel open source devs die wereld kritisch spul onderhouden uit een soort van plichtsgevoel en wel donaties zouden willen ontvangen maar dat niet doen want mensen zeuren over Paypal of bitcoin en stripe is te lastig, of complex of kost geld, of je belasting aangifte wordt een nachtmerrie omwille van een paar honderd euro.

Meer opties voor devs om geld te verdienen lijkt me alleen maar goed, we hebben het hier over free as in freedom, en de freedom om distributieopties te kiezen die bij de dev passen valt daar ook onder.

[Reactie gewijzigd door teek2 op 22 juli 2024 20:42]

[P_Tingen]

Dit dus precies; ik heb een tool die door een paar honderd Progress 4GL ontwikkelaars wordt gebruikt. Deze staat ook gewoon op GitHub (hier) en de reden dat ik dat doe is inderdaad dat ik het leuk vind om er aan te werken en een eventuele opbrengst is zó laag dat het niet in verhouding staat tot de rompslomp die ik daar van zou hebben; betalingen, refund, klanten die ineens eisen gaan stellen, want betaald. Nu geeft het voor mezelf ook vrijheid; ik heb al een paar keer features verwijderd omdat ik feature-bloat tegen wilde gaan. Bij betalende klanten kan je dat weer gezeur opleveren.

Ik zie dit als verrijking voor het platform; wie zijn code open en vrij wil houden zal dat ongetwijfeld blijven doen. Wie extra dingen wil, kan dat nu ook doen. Een mogelijkheid is om bv maatwerk-constructies te leveren; ik heb wel eens vragen gehad van gebruikers die een specifieke aanpassing wilden hebben. Nu keur ik het af en doe ik het niet als het té gebruikersspecifiek is, maar met dit systeem /zou/ ik een deel van de repo specifiek voor die ene gebruiker kunnen maken. Al dan niet tegen betaling. Vind ik eigenlijk niet zo gek en al helemaal niet haaks staan op de open-source-gedachte.

[CodeCaster]

Er zijn tijdens de oprichting honderden miljoenen dollars in gestopt. Dit heeft men niet gedaan om open source een boost te geven, maar om op een gegeven moment winst te gaan maken. Alles aan dat platform kost geld, veel ervan is gratis te gebruiken.

Die winst komt niet van opensourceprojecten, maar van betalende klanten.

Ik snap Stallman-achtige praktijken niet zo. Niet iedereen kan een of meerdere vrije projecten gratis onderhouden en daarnaast verdienen met implementaties bij klanten, lezingen, donaties of wat dan ook. Hardware om je code vrijwel altijd tot je beschikking te hebben, gebackupt tot op zekere hoogte, die CPU-tijd, I/O en netwerkverkeer verbranden tijdens het runnen van actions, kost gewoon geld. De mensen om die hardware en bijbehorende software te onderhouden, kosten ook geld.

Het onbetaald zijn van vrijwilligers is een steeds groter wordend probleem, neem als enig voorbeeld maar de recente uiting van de faker/colors.js-maker.

[Reactie gewijzigd door CodeCaster op 22 juli 2024 20:42]

[SampleUser]

ik vraag mij zelf af: ben je als ontwikkelaar ook gebonden aan een opensourcelicentie die je voor je eigen project kiest? De GPL verplicht dat een ontwikkelaar op verzoek broncode beschikbaar stelt. Hierop is door organisaties als de FSF (volgens mij) succesvol geprocedeerd tegen organisaties die Linux forken en de patches niet beschikbaar stellen.

Zou een organisatie als de FSF kunnen procederen tegen een ontwikkelaar die zijn repo van de een op de andere dag achter een paywall zet, en daarmee dus de broncode ontoegankelijk maakt? Het is wel zijn eigen software

[hackerhater]

Edit, spuit 12.
Eerst op F5 drukken voor ik reageer

@SampleUser
Mijn eigen framework is een mooi voorbeeld. Vrijgegeven onder LGPL 3 or later en er is code toegevoegd door derden.
Ik kan dus wel de licentie veranderen naar bijvoorbeeld LGPL 4 mocht die ooit komen, maar ik kan de licentie niet naar iets anders veranderen dan de LGPL. Om de simpele reden dat niet alle code van mij is.

[Reactie gewijzigd door hackerhater op 22 juli 2024 20:42]

[RoestVrijStaal]

Ik kan dus wel de licentie veranderen naar bijvoorbeeld LGPL 4 mocht die ooit komen, maar ik kan de licentie niet naar iets anders veranderen dan de LGPL. Om de simpele reden dat niet alle code van mij is.

Als alle andere contributors ermee instemmen wel.

[hackerhater]

LGPL 3 or later

Dit is letterlijk de licentie van de code Waar ze mee ingestemd hebben. Dat or later heb ik aan het begin er voor een reden opgezet.

[sjettepetJR.]

hij bedoelt denk ik dat het wel mogelijk zou zijn om de licentie aan te passen naar een non-LGPL licentie. Als je een overeenkomst kan sluiten met alle personen die meegewerkt hebben aan een bepaalde versie, dan zou je de licentie van die versie kunnen aanpassen.

[hackerhater]

Ja in theorie, praktijk vergeet het maar
Hetzelfde probleem heeft de Linux kernel.

[Loller1]

Je kan in princiepe ook de code waar je niet overeen over komt er gewoon uitgooien en herschrijven.

[rjd22]

Zo ver ik weet mag je altijd als auteur van de code de licentie aanpassen. Alleen mag je dit niet doen voor de code die door andere developers toegevoegd is aan je project.

Je kan alleen niet de licentie aanpassen voor de vorige versies van de code dus iemand is altijd gerechtigd je project te forken en deze te releasen onder de oude licentie en daar aanpassingen aan doen zolang deze licentie intact blijft.

Dit werkt natuurlijk per elke licentie net iets anders maar voor de meeste opensource licenties kan het bovenstaande zonder problemen.

[84hannes]

Je kan alleen niet de licentie aanpassen voor de vorige versies van de code

Kleine verduidelijking: volgens mij mag je wel een licentie toevoegen. Je kunt een vrijgegeven versie dus alsnog óók onder een commerciële licentie verkopen (dual license).

[The Zep Man]

Kleine verduidelijking: volgens mij mag je wel een licentie toevoegen. Je kunt een vrijgegeven versie dus alsnog óók onder een commerciële licentie verkopen (dual license).

Zolang de tweede licentie niet conflicteert met de eerste. Als je het verkoopt, dan moet je ook de broncode beschikbaar stellen van delen die onder de GPL vallen aan de partij aan wie je het verkoopt, onder de voorwaarden van de GPL zonder dat deze beperkt worden door de tweede licentie.

Je kan wel eigen code van GPL strippen/van een andere licentie voorzien, maar voor de grote projecten zijn er zoveel mensen die code bijdragen dat je dat juridisch nooit waterdicht gaat krijgen. Je kan in dit soort projecten niet meer spreken van 'eigen code', tenzij je alle commits gaat terugdraaien en het zelf m.b.v. clean room design opnieuw gaat ontwikkelen.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 20:42]

[Wolfos]

Nee. Je bezit zelf het copyright op de code en mag ermee doen wat je wilt, zonder dat je daarvoor jezelf een licentie hoeft te geven. Ga je anders jezelf aanklagen?

Daarnaast verplicht de GPL niet dat de broncode openbaar beschikbaar is, maar dat het met de software geleverd word. Je kunt dus bijvoorbeeld alleen de broncode aan je klanten geven.

[Reactie gewijzigd door Wolfos op 22 juli 2024 20:42]

[downtime]

Volgens mij niet. Als oorspronkelijke ontwikkelaar ben jij niet aan de beperkingen van de gekozen licentie gebonden. Althans niet met de gangbare open source licenties. Maar dat geldt alleen als het product 100% door jou geschreven is en jij zelf geen gebruik maakte van andermans code.

[aequitas]

Ik weet nog niet of dit een verbetering gaat zijn voor Github en Open Source of niet. Aan de ene kant heb je het probleem dat veel code geschreven wordt door onbetaalde vrijwilligers en dat het wel fijn is om deze een steuntje in de rug te geven door vrijwillig te sponsoren.
Maar met deze feature krijg je steeds meer een voor-wat-hoort-wat cultuur. Iets wat ik niet associeer met Open Source/Free Software cultuur, waar je vaak dingen doet uit intrinsieke motivatie.
Er bestaan natuurlijk al langer andere manieren om geld te verdienen met Open Source software. Zoals betaalde support of open core model waarbij je b.v. betaalde extensies levert op je Open Source kern. Maar daar zie je vaak al wrijving ontstaan als b.v. iemand een feature probeert toe te voegen aan die open core die lijkt op een betaald extensie en de beheerders het niet willen integreren omdat dat in hun verdienmodel vreet (zoals bij Owncloud/Nextcloud: https://archive.fosdem.org/2018/schedule/event/nextcloud/).
Daarnaast schept het natuurlijk ook een bepaalde soort verplichting. Als iemand voor een sponsor tier met een apart repo betaald dan gaan ze misschien opeens wel wat verwachten, ipv dat het gewoon een vrijblijvende gift is. Op dat moment moet je persoonlijk de afweging gaan maken of je voor dat beetje sponsorgeld meer tijd in dat gesloten repo moet stoppen of dat je een feature toch gewoon open beschikbaar stelt zodat het een meer maatschappelijke bijdrage levert. Dus ipv dat je een idyllisch hobby projectje hebt waar je veel lol en voldoening uit haalt, wordt het opeens een tweede baan (met de bijbehorende stress) die niet zo heel veel oplevert en alleen maar veeleisende 'klanten' heeft. Ook zul je veel minder feedback krijgen vanuit de community omdat er gewoon minder mensen bij die nieuwe code kunnen, dus minder hulp bij het bugfixen/troubleshooten. En andere mensen zullen misschien minder de neiging hebben om bij te dragen aan je project, "want he, waarom zou jij betaald krijgen voor het werk wat ik doe".

Nu zijn al dit soort dingen natuurlijk al mogelijk buiten Github om, dus die problemen zijn er vaak al, allen niet op grote schaal. Maar mijn zorg is voornamelijk dat Github als "leider" in de Open Source wereld hiermee niet een bepaalde trend gaat inzetten die slecht zou kunnen zijn voor Open Source cultuur in zijn geheel. Daarnaast vraag ik me af of het een eerste stap is van Microsoft in monitization van Github door een afdracht te vragen van donaties.

[Htbaa]

. Maar daar zie je vaak al wrijving ontstaan als b.v. iemand een feature probeert toe te voegen aan die open core die lijkt op een betaald extensie en de beheerders het niet willen integreren omdat dat in hun verdienmodel vreet (zoals bij Owncloud/Nextcloud: https://archive.fosdem.org/2018/schedule/event/nextcloud/).

Dat een project open source is betekent nog niet dat ze (eigenaar van het project) iedere contributie ook maar moeten mergen. Behalve economische redenen kan het argument ook zijn dat een bepaalde feature niet in de scope van het project past. Genoeg projecten die dat laatste hanteren. Het esbuild project doet dat bijvoorbeeld ook, maar meet het niet minder open source.

I'm planning for esbuild to reach a mostly stable state and then stop accumulating more features. This will involve saying "no" to requests for adding major features to esbuild itself. I don't think esbuild should become an all-in-one solution for all frontend needs. In particular, I want to avoid the pain and problems of the "webpack config" model where the underlying tool is too flexible and usability suffers.

Bron: https://esbuild.github.io/faq/#benchmark-details

[aequitas]

Natuurlijk, er zijn genoeg geldige andere redenen, maar dan is het begrijpelijk en in het belang van het project en alle gebruikers/bijdragers. Maar als je een contributie niet merged, alleen omdat een vergelijkbare feature ook al in je betaalde versie zit dan ontstaat er wrijving. Dan heb je natuurlijk wel de optie om het project te forken en je eigen versie bij te houden met die feature er wel in. Maar dat komt een project ook vaak niet ten goede omdat je dan een gesplitste community krijgt en alle effort dus verdeeld wordt over 2 projecten in plaats van gefocust in 1.

Mijn probleem zit hem er in dat op het moment geld een primaire drijfveer wordt in een Open Source project je het hele stelsel overhoop haalt. Alle afwegingen worden dan op een andere manier gemaakt, wat niet lijdt tot een verbetering. Dan kan je beter gewoon gesloten en commercieel gaan.

Zie het zo: je zou iemand graag vrijwillig en voor niets helpen om een hele dag verhuizen. Maar op het moment dat je daar 1/2 keer het uurloon van een verhuizer voor zou krijgen dan denk je opeens: je probeert je er goedkoop vanaf te maken. Voor 2x dat uurloon zou je het ws wel doen, maar misschien dat je zelfs voor 2x het uurloon liever achter de computer zit dan dozen sjouwt. Zodra ergens geld bij komt kijken is de verhouding anders. Zonder geld is het: hij zou hetzelfde voor mij doen, of ik doe iets maatschappelijks goed, het is meer vrijblijvend. Met geld kan je het opeens concreet vergelijken met andere dingen waar je geld voor krijgt en worden de afwegingen anders.

[wackmaniac]

Ik deel je twijfel. Er is echter een beweging gaande, waarbij maintainers financiële beloning willen voor hun open source werk. Wat je daar ook van mag vinden. Deze stap past in die trend.

Ik ben trouwens benieuwd hoe dit gaat uitwerken met het oog op contributors van een project; Stel project X gaat betaald, omdat de maintainer niet wil dat commerciële organisaties geld verdienen aan zijn/haar werk. Gaat deze maintainer de baten verdelen onder de contributors? Met name met terugwerkende kracht is dit een interessant scenario. Als ik een mooie feature toevoeg op het moment dat het project nog gratis werd gedistribueerd en de maintainer beslist op zeker moment dat er een betaling nodig is. Heb ik dan recht op deel van de opbrengsten? In feite verschuif je de situatie van commerciële partij <> maintainer naar maintainer <> contributor.

[downtime]

Je mist een detail. Open source, en dan met name GPL, is al gebaseerd op een voor-wat-hoort-wat cultuur. Jij mag mijn code gebruiken maar als jij die code aanpast dan wil ik jouw code ook kunnen gebruiken. Het is letterlijk de kern waar GPL om draait. Ik zie het probleem dus niet.

[Dubbeldrank]

voordat die breed beschikbaar worden en discussies voor donateurs.

Ben ik nu heel negatief om te denken dat dit de opstap is naar premium repo's, die dus niet breed beschikbaar komen maar enkel voor mensen die (maandelijks) betalen als verdienmodel?

[MeMoRy]

Je hebt nu al private repos, die je met bepaalde mensen kan delen. Ik schat de kans groot in dat er al zijn die via een (externe) pay site toegang bieden.
Als Microsoft deze functie wil toevoegen, dan is dat mijn inziens niet meer dan redelijk, omdat ze anders gratis hosten van iets waar andere mensen geld mee verdienen.

[Reactie gewijzigd door MeMoRy op 22 juli 2024 20:42]

[Wolfos]

Dat is precies hoe Unreal 4 in het begin werkte. Toegang intrekken na verlopen van het abonnement ging alleen wat minder lekker.

[armageddon_2k1]

Was GitHub niet oorspronkelijk alleen maar private tegen betaling?

[FearZ]

Klopt, dit is aangepast in 2019.

https://github.blog/2019-01-07-new-year-new-github/

[RoestVrijStaal]

Voor iedere aangeboden tier van sponsoring kunnen gebruikers een aparte repo beschikbaar maken zodat ze verschillende toegangsniveaus kunnen opzetten. GitHub noemt zelf als gebruikersvoorbeeld dat een sponsor toegang krijgt tot unieke projecten, early access van builds voordat die breed beschikbaar worden en discussies voor donateurs.

Waarom nou weer een aparte repo voor early releases? Daar is juist de staging of rc branch voor

[BCC]

Ja, maar bijvoorbeeld sidekiq doet het al jaren op deze manier. Er is een "gratis" opensource versie en een "pro" versie, waar je support en extra features krijgt.

Die features zijn ook vaak echt enterprise dingen, zo heeft het admin panel normaliter username/password, maar kun je hem in te pro versie achter een SSO systeem hangen. Zeer wenselijk voor enterprise, totaal zinloos voor Sidekiq zelf, dus ik denk zeker dat er een markt is.

[Reactie gewijzigd door BCC op 22 juli 2024 20:42]

[Barryvdh]

Het is niet altijd ideaal, maar het kan voor sommige projecten wel werken. Sinds het sponsorprogramma heb ik wel wat projecten voorbij zien komen waarbij dit geholpen heeft voor de auteur. Bijvoorbeeld 'Sushi', een project van Caleb Porzio waarbij het Private was tot hij 75 sponsors had:
https://calebporzio.com/sponsorware

By the next evening, I hit 75 sponsors and was now making $1560/mo from GitHub Sponsors 🎉! In two days, I increased my GitHub sponsors monthly revenue from $573 to $1560. That means, over the course of a year, I increased my earnings by $11,844!

Ook voor andere projecten met Early Access kan het helpen, bijvoorbeeld om een proof-of-concept te valideren voordat je er al teveel moeite in gaat stoppen. Al moet je eigenlijk al populair zijn op Twitter wil je hier echt profijt van hebben..

[Reactie gewijzigd door Barryvdh op 22 juli 2024 20:42]

[downtime]

Ik denk dat het goed kan zijn in de groeifase van een project. Beetje vergelijkbaar met Youtube: Daar heb je veel parttime content-creators maar ook mensen die dankzij Youtube en Patreon-inkomsten hun baan kunnen opzeggen en fulltime content-creator worden. Rijk zul je niet worden van een channel met enkele honderdduizenden subs maar het is wel een stuk leuker dan een kantoorbaan en komt de productiviteit en meestal ook de kwaliteit van de content ten goede.

[marrs]

Betalen voor toegang tot een open source project?

[elmuerte]

Niets zegt dat deze projecten Open Source zijn.
Er zijn meer dan genoeg public github repos die niet Open Source zijn. Je kan de code misschien zien, maar je mag het niet gebruiken voor iets omdat er geen licentie aan gekoppeld is die het Open Source maakt.

[Redstone]

Als de bron code te zien is is de Source toch open?

[Reactie gewijzigd door Redstone op 22 juli 2024 20:42]

[elmuerte]

Open source is source code that is made freely available for possible modification and redistribution. Products include permission to use the source code, design documents, or content of the product.

https://en.wikipedia.org/wiki/Open_source

Als ik niet de code mag gebruiker, of aanpassen, of herdistribueren dan is het geen open source.
Als ik geen licentie vermeld bij mijn code valt het onder alle regels van de auteursrecht. Wat inhoudt dan ik het mag lezen, en een persoonlijke kopie maken. Maar verder mag ik er niks mee doen.

Ik kan ook code op github plaatsen waarbij de licentie een van de open source rechten ontneemt, dan is het ook niet meer Open Source.

[passie2009]

De source is wellicht open maar dat wil niet zeggen dat het open-source is.

[Sinnergy]

Hoe noem je het dan?

[elmuerte]

non-free source, proprietary source, source-available, ...

[Redstone]

ik denk dat je foss en open-source door elkaar haalt. https://www.gnu.org/philo...rce-misses-the-point.html

[MeMoRy]

Dat je een boek of film kan kopen/bekijken, betekent nog niet dat je het zomaar maar kopiëren.
Wetten rond code zijn net iets anders, maar het is is hetzelfde.

[Reactie gewijzigd door MeMoRy op 22 juli 2024 20:42]

[die4ever]

nope, de licentie bepaalt of het open source is of niet. Je kan perfect code openbaar zetten met een closed-source licentie. Of mensen dan uw licentie gaan schenden is een andere vraag...

[downtime]

Absoluut niet. De licentie bepaalt of het open source is. Vergelijk het met een boek: Als ik een boek schrijf en het boek (gratis of niet) verspreid, dan kun jij het boek wel lezen, maar is het nog steeds een schending van mijn copyright als jij delen van dat boek kopieert en in jouw eigen boek gebruikt. Daarvoor heb je mijn toestemming nodig.
Dat is met software niet anders. Zonder mijn toestemming mag jij mijn source niet gebruiken en wordt het niet als open source beschouwd. Het is pas open source als ik expliciet toestemming voor hergebruik heb gegeven.

[marrs]

De aankondiging lezende, kwam ik ergens tegen het einde van het verhaal de volgende zinsnede tegen:

What’s next?
The next chapter of GitHub Sponsors will pave the path for more companies to support the open source projects they depend on.

Vandaar mijn opmerking. Ik weet dat github ook gebruikt wordt voor closed source projecten en dat is natuurlijk prima. Ik vind het gek dat er hier gesuggereerd wordt dat er een vorm van open source projecten aankomt waar je voor moet betalen om toegang te krijgen. That's all.

[brinkie2004]

Je zou het wellicht beter kunnen omschrijven, als betalen voor toegang tot een closed source project.

[Kevinns]

Hè, het hele idee van Github is toch dat je kan samenwerken aan projecten? Dan lijkt het me niet handig om mensen die meehelpen een barrière op te werpen. En alle andere mensen hebben toch niks te zoeken in de 'premium' repo.

Ik ben benieuwd wat voor publiek ze hiervoor voor ogen hebben.

[newq]

Als ik het dus goed begrijp, is het een soort OnlyFans voor source code?

[lilmonkey]

Pornografie is volgens mij niet toegestaan, dus meer een Fanhouse voor source code

[neonite]

De OnlyFans voor ontwikkelaars