Audacity gaat toch geen telemetrie in software zetten na kritiek van gebruikers

Audacity gaat toch geen telemetrie toevoegen aan zijn software. Het bedrijf zegt overvallen te zijn door de vele negatieve reacties op dat plan. Het bedrijf wil in de toekomst mogelijk wel kijken naar alternatieven.

Martin Keary, de nieuwe eigenaar van Audacity, zegt in een GitHub-issue dat het ontwikkelteam 'verrast was' door de kritiek op het plan. Audacity besloot eerder deze maand Universal Google Analytics en Yandex Metrica toe te voegen aan de software. Dat kwam het bedrijf al op veel boze reacties te staan van gebruikers, die het een dark pattern noemden. Er kwamen honderden boze reacties op het oorspronkelijke voorstel, ook al ging het om een opt-in-functie. Het plan kwam slechts een paar dagen nadat het bedrijf was overgenomen door de makers achter Ultimate Guitar.

De ontwikkelaars benadrukken nu dat het nooit hun intentie was om data te verkopen en dat het de dienst altijd gratis wil houden. Het bedrijf legt ook verder uit dat het telemetrie alleen wilde gebruiken om te weten hoe mensen de software precies gebruiken. "Ik dacht dat het opt-in maken de privacyzorgen weg zou nemen, maar nu dat niet het geval is hebben we besloten de telemetrie helemaal te laten vallen", schrijft Keary in het nieuwe issue.

Keary houdt de optie open om in de toekomst alsnog iets soortgelijks te implementeren. "We kunnen kijken naar acceptabele alternatieve oplossingen die hetzelfde doel hebben", schrijft hij. Hij benadrukt daarbij ook feedback van gebruikers te vragen. In de tussentijd gaat Audacity door met de gebruikelijke manier van gebruikersonderzoek, waaronder gebruikerstests, gesprekken en feedback op GitHub en sociale media.

Door Tijs Hofmans

Nieuwscoördinator

17-05-2021 • 14:14

95

Submitter: TheVivaldi

Reacties (95)

Sorteer op:

Weergave:

Het is, simpel gezegd, een audiobewerkingstool. Hoeveel 'analytics' wil je daar nou van weten? Mensen nemen geluid op en/of bewerken deze. Zit er nou zoveel meer functionaliteit in dat je daar onderzoek naar wilt doen? Willen ze functies toevoegen? Weinig gebruikte functies verwijderen? Tips en Tricks geven op basis van omslachtige werkwijzen?

Lijkt mij dat een community die daar achter zit zelf wel mee komt.
Juist voor dit programma lijkt het mij wel handig te weten welke features, tools en settings meer worden gebruikt dan andere. Het is een ontzettend uitgebreide tool die al heel lang bestaat. Als je dan besluit om erin te investeren en het naar een hoger niveau te tillen, wil je dat het liefste doen met onderbouwing waarom je welke delen gaat uitbreiden/verbeteren/vernieuwen.

Gelukkig werkt software ontwikkeling tegenwoordig zo. Luisteren naar consumenten, experimentatie A/B om te bepalen welke feature beter werkt etc.

Dus ik begrijp het wel. Maar daar heb je geen advertentiebedrijf voor nodig. Zeker niet het #1 advertentiebedrijf, want het heeft niks met ads te maken. Daarom mijn bovenstaande suggesties.
Juist voor dit programma lijkt het mij wel handig te weten welke features, tools en settings meer worden gebruikt dan andere. Het is een ontzettend uitgebreide tool die al heel lang bestaat. Als je dan besluit om erin te investeren en het naar een hoger niveau te tillen, wil je dat het liefste doen met onderbouwing waarom je welke delen gaat uitbreiden/verbeteren/vernieuwen.
Wat er dan gebeurd, is dat er in functionaliteit gesneden gaat worden.

Een fenomeen dat eerder de regel dan de uitzondering is als een applicatie en/of dienst naar een zogenaamd "hoger niveau" wordt getild.

In de praktijk wordt de applicatie meer dumbed down, want een aantal poppetjes op sleutelposities van het open source project vinden dat hun digibete grootmoeder ook met de applicatie moeten kunnen werken.

Gevolg? Een applicatie waarmee je per jaar steeds minder kan.

[Reactie gewijzigd door RoestVrijStaal op 24 juli 2024 04:23]

Dat is inderdaad de laatste jaren steeds vaker het geval met programma's maar ook met websites en misschien eigenlijk wel bijna elk stukje software dat ergens voor gebruikt kan worden!

Echt een vreselijk irritante trend wat mij betreft! :F
Tja.. IT industrie. Zo’n beetje de enige industrie die een oplossing verzint voor een probleem dat nog gemaakt moet worden.
De rest kan er ook wel wat van...

Maar software/websites wijzigen om het wijzigen vind ik toch wel het irritantst! :/
Als je dan besluit om erin te investeren en het naar een hoger niveau te tillen, wil je dat het liefste doen met onderbouwing waarom je welke delen gaat uitbreiden/verbeteren/vernieuwen.
Met investeren moet je ook de risico's aanvaarden. Bij open source is dit dat gebruikers ten alle tijden een fork kunnen beginnen op het moment dat je over de schreef gaat. Dat risico had men ook moeten incalculeren...
Het bedrijf zegt overvallen te zijn door de vele negatieve reacties op dat plan.
Wat zij duidelijk niet gedaan hebben.
In de categorie 'gewoon doen', zoals dat hier op t.net gebeurd met de A/B testen, kan naar mijn idee alleen maar op nagativiteit rekenen. Dat is dan overigens wel een direct resultaat en daar kun je dan gelijk wat mee.

Nu ben ik er zelf niet veel mee bezig, en dat is wellicht ook wel het probleem. Maar op een gegeven moment is een bepaalde functie gewoon verandert. Is het de eerste week even mopperen en na een maand hoor je niemand meer over de wijziging. Maar of er écht naar de community wordt geluisterd of dat er op de achtergrond iemand aan de touwtjes trekt van 'Dit gaan we doen, en niks anders' is voor mij vooralsnog een raadsel. Er komen in de feature request al jaren herhaaldelijk zeer nuttige toevoegingen voorbij waar niks mee wordt gedaan.

Of je dan op basis van gedrag van de gebruiker maar eigen conclusies gaat trekken en daardoor je website, of om on-topic te blijven, je software eigenhandig gaat aanpassen lijkt mij dan niet de weg die je moet bewandelen. Dan krijg je bij weerstand van de gebruikers gelijk te horen 'Maar uit ons onderzoek kwam naar voren dat deze manier of functie toch veel handiger is, dat blijkt ook uit de statistieken'.
Dan heb je vervolgens een eigen conclusie getrokken en dat is vervolgens een hit or miss, ipv 'democratisch' naar je userbase te luisteren.

Ik zie overigens niks in het weghalen van functionaliteit omdat een functie (bijna) niet meer zou worden gebruikt. Of daar moet een echt verbeterd alternatief voor zijn (en niet een omslachtige omweg binnen nieuwe functionaliteit).

Ik ervaar dat 'luisteren naar consumenten' overigens meer als 'We hebben 10 suggesties gekregen, maar 8 daarvan zijn te duur, en van de 2 overgebleven opties kost die ene de minste tijd/geld'.
En wanneer er weer budget is zijn er weer 10 andere nieuwe ideeën en die 9 van de vorige keer alweer vergeten.
Als je keen bent met je privacy maak dan een betaalde variant en een gratis versie. Hoeveel werk krijg je klaar als alles gratis is?

Bovendien is Audacity wel de meest archtype onder de audiotools.
Ten eerste was het was optioneel om aan te zetten en stond het niet bij default aan.
Just to reiterate, telemetry is completely optional and disabled by default.

Telemetry collection is optional and configurable at any time. In case of data sharing is disabled - all calls to the telemetry Report* functions are no-op.
Ten tweede ze wouden alleen deze informatie verzamelen om beter te kunnen inschatten hoeveel effect een bepaalde wijziging zou kunnen hebben(OS, versies etc.) en dat ze beter iets zouden kunnen debuggen.
https://github.com/audacity/audacity/pull/835

[Reactie gewijzigd door Hydranet op 24 juli 2024 04:23]

Qua feiten ga ik met je mee (het staat inderdaad nog default uit), echter niet met de intenties erachter.

Althans niet de intenties van Ultimate Guitar. Zij hebben een geschiedenis van niet bestaande tabs verkopen, verdienen over de rug van gebruikers, totaal onvindbare (of niet bestaande) mogelijkheid om je abonnement op te zeggen, de christmas scam van 2017 (tijdelijk kerstabonnement voor $3,- terwijl er $39,95 van je rekening werd gehaald en je niet je abonnement kon opzeggen).
Ik denk dat als ze het wel doen er binnen no time een fork is FreeDacity of Auliberty ofzo
Ik denk dat als ze het wel doen er binnen no time een fork is FreeDacity of Auliberty ofzo
Ik vind dit juist weer een van de nadelen van hoe makkelijk er met open source software geforkt kan worden. Dit betreft een opt-in telemetry optie, die standaard geen enkele bit aan telemetrie verstuurd. Dat het een dark pattern betreft is misschien niet netjes te noemen, maar om nu de hele software te forken gaat mij ook wel wat ver. Dan krijg je een versnipperd landschap met allerlei forks die 1 probleem oplossen, het doet me denken aan al die 1-probleems partijen in de 2e kamer. Het beste en meest constructieve is als men gewoon samen tot een oplossing is gekomen, zoals nu blijkelijk is gebeurt in het artikel.

[Reactie gewijzigd door saren op 24 juli 2024 04:23]

Ik vind dit juist weer een van de nadelen van hoe makkelijk er met open source software geforkt kan worden.
Ik niet. Dat houdt producten beschikbaar als de organisatie erachter het (potentieel) verprutst. Zie MySQL/MariaDB, OpenOffice.org/LibreOffice, OpenELEC/LibreELEC, ...
Dit betreft een opt-in telemetry optie, die standaard geen enkele bit aan telemetrie verstuurd. Dat het een dark pattern betreft is misschien niet netjes te noemen,
Als het een dark pattern is, is het dan wel opt-in? Ik prefereer de Debian methode. Standaard is het nee bij handmatige en automatische installaties. De gebruiker moet actief een expliciete keuze maken om het wel te doen. Dit is gewoon slordig.
maar om nu de hele software te forken gaat mij ook wel wat ver.
Dat gaat jou te ver. Maar anderen misschien niet. Dat is de kracht van open source. ;)
Dan krijg je een versnipperd landschap met allerlei forks die 1 probleem oplossen,
En komt er vanzelf weer een fork die de andere forks bij elkaar brengt. Zie bijvoorbeeld OpenWRT en LEDE, wat later gewoon weer samengevoegd werd tot OpenWRT.

[Reactie gewijzigd door The Zep Man op 24 juli 2024 04:23]

Ik niet. Dat houdt producten beschikbaar als de organisatie erachter het (potentieel) verprutst. Zie MySQL/MariaDB, OpenOffice.org/LibreOffice, OpenELEC vs. LibreELEC, ...
Nu noem je allerlei forks op die daadwerkelijk grote, fundamentele redenen hadden om te forken. MariaDB ontstond omdat MySQL uiteindelijk door Oracle was overgenomen, OpenOffice was een dood project. Dit zijn grote redenen, die inderdaad een fork en het risico op versnippering veroorloven.

Ik stel dus de vraag, moet je voor elk wisjewasje al meteen de fork-kaart trekken, of is het soms handiger om gewoon samen te werken en na goed overleg tot een conclusie te komen? Ik denk dat dit laatste in het geval van kleinere geschilletjes zoals een telemetrie-aanbieder keuze van eeen opt-in systeem best de goede oplossing kan zijn. Een fork zou hier zwaar overbodig zijn, en niemand zou er echt beter van worden. Nu is men er samen uitgekomen, en is de telemetrie optie verdwenen.
Jou wel. Maar anderen misschien niet. Dat is de kracht van open source. ;)
De kracht inderdaad, maar ook het zwaktepunt. Ik ben niet van mening dat dit model geen enkel nadeel heeft, en ik hoop ook dat jij dat inziet.
Ik stel dus de vraag, moet je voor elk wisjewasje al meteen de fork-kaart trekken, of is het soms handiger om gewoon samen te werken en na goed overleg tot een conclusie te komen? Ik denk dat dit laatste in het geval van kleinere geschilletjes zoals een telemetrie-aanbieder keuze van eeen opt-in systeem best de goede oplossing kan zijn. Een fork zou hier zwaar overbodig zijn, en niemand zou er echt beter van worden. Nu is men er samen uitgekomen, en is de telemetrie optie verdwenen.
Misschien is men er wel samen uitgekomen omdat een fork dreigde. Een organisatie met gesloten software was hier nooit op teruggekomen.
De kracht inderdaad, maar ook het zwaktepunt. Ik ben niet van mening dat dit model geen enkel nadeel heeft, en ik hoop ook dat jij dat inziet.
Ik verkies vrijheid boven beperkingen. Enkel die vrijheid kan al voorkomen dat anderen over de schreef gaan.

[Reactie gewijzigd door The Zep Man op 24 juli 2024 04:23]

Misschien is men er wel samen uitgekomen omdat een fork dreigde. Een organisatie met gesloten software was hier nooit op teruggekomen.
Dit is slechts speculatie. Ik denk dat het aannemelijker is dat ze gewoon enorm geschrokken zijn van de backlash. Van reddit tot tweakers tot vele andere newssites hebben er (negatieve) publiciteit aan gegeven. Ook dit is echter slechts speculatie
Ik verkies vrijheid boven beperkingen. Enkel die vrijheid kan al voorkomen dat anderen over de schreef gaan.
Ik snap niet goed wat je hiermee nu precies wilt zeggen. Het klinkt een beetje zweverig FSF/Stallman-achtig, maar ik zie de relevantie in deze discussie niet. Met het vrijheid principe van velen in de FOSS gemeenschap ben ik bekend, maar deze discussie gaat over de praktische implicaties ervan. Zoals @grahampje goed uiteenzet in zijn reactie kan de snelle impuls om maar te forken ook veel nadelen meebrengen, ook met het oog op massale adoptie van FOSS, en dit (soort potentiele nadelen) probeer ik dus aan te kaarten.

[Reactie gewijzigd door saren op 24 juli 2024 04:23]

Dit is slechts speculatie. Ik denk dat het aannemelijker is dat ze gewoon enorm geschrokken zijn van de backlash. Van reddit tot tweakers tot vele andere newssites hebben er (negatieve) publiciteit aan gegeven. Ook dit is echter slechts speculatie
Dat is ook speculatie.

Een organisatie die een gesloten stuk populaire software uitgeeft en dit had ingebouwd zou niet terug zijn gekeerd. Daar zijn voldoende voorbeelden van te vinden.
Ik stel dus de vraag, moet je voor elk wisjewasje al meteen de fork-kaart trekken, of is het soms handiger om gewoon samen te werken en na goed overleg tot een conclusie te komen? Ik denk dat dit laatste in het geval van kleinere geschilletjes zoals een telemetrie-aanbieder keuze van een opt-in systeem best de goede oplossing kan zijn.
Dit gebeurd ook best vaak. Lees de forums van een heel aantal Open Source projecten er maar eens op na. Er wordt veel besproken over hoe iets moet werken, en waar meerdere mensen zijn, zijn ook meerdere meningen. Vaak wordt dan gekeken naar de beste manieren om de verschillen te kunnen verenigen. Alleen daar waar een duidelijke verschil is tussen wat persoon A en B willen, en waar het verschil te groot is om intern opgelost te kunnen worden, kunnen forks gemaakt worden.
Ja, geweldig is dat. Dan ga je 1 van product naar een veelvoud vanwege enkele forks die vaak op hun beurt te klein zijn om ook maar in de buurt van de ontwikkelingscapaciteit van het origineel te komen. Dat is je eerste verlies.
Vervolgens besluiten ze de omgekeerde weg te bewandelen en zit je weer terug in de oude situatie.
Dan ga je 1 van product naar een veelvoud vanwege enkele forks die vaak op hun beurt te klein zijn om ook maar in de buurt van de ontwikkelingscapaciteit van het origineel te komen. Dat is je eerste verlies.
Vervolgens besluiten ze de omgekeerde weg te bewandelen en zit je weer terug in de oude situatie.
Niet mijn ervaring met forks. Uiteindelijk komt alles bij elkaar en gaat het meest levensvatbare product door. De organisatie die origineel de fout in ging mag bijdragen, maar krijgt niet meer de regie.

Je impliceert dat open source ontwikkelaars graag werk dubbel doen. Dit is zeker niet waar. ;) Verder helpen zaken als Git om de beste elementen uit verbeteringen van anderen over te nemen. Als iemand een fork maakt met een veelgevraagde functie (zeg, NewPipe met Sponsorblock ondersteuning), dan is dat erg fijn. De originele ontwikkelaars van NewPipe zijn vrij om die fork weer te integreren, maar iemand anders kan dat ook doen met iets als een toekomstige NewPipe+, die ook andere verbeteringen bevat.

Open source is een vorm van vrijheid. Ontwikkelaars bepalen waar zij hun tijd aan besteden en gebruikers bepalen wat zij gebruiken. Als een gebruiker het ergens niet mee eens is, dan kan die zelf gaan ontwikkelen of iemand daarvoor inhuren. Die vrijheid houdt iedereen eerlijk. Het is de ultieme vorm van vrije markt, en organisaties moeten niet protesteren als zij er niet in kunnen overleven.

[Reactie gewijzigd door The Zep Man op 24 juli 2024 04:23]

Niet mijn ervaring met forks. Uiteindelijk komt alles bij elkaar en gaat het meest levensvatbare product door. De organisatie die origineel de fout in ging mag bijdragen, maar krijgt niet meer de regie.
Uhuh. Herinner me even, hoeveel linux-distributies bestaan er momenteel? Hoeveel package-managers zijn er om te supporten? Hoeveel verschillende desktop environments? En hoelang geleden zijn die allemaal al geforked? Die gaan zeker allemaal snel weer samenkomen?

Je noemt wel leuk MariaDB, maar noem dan ook Drizzle en WebScaleSQL. Nooit van gehoord? Het verbaast me niet: beide forks van MySQL waar honderden mensen aan gewerkt hebben, die nu al jaren verlaten zijn.

@The Realone heeft helaas gelijk: er zijn veel meer gefaalde open-source forks dan succesvolle, en als al die dubbele moeite was gebruikt om een enkel product beter te maken, waren er veel meer succesvolle open-source pakketten. In de praktijk komt het erop neer dat een enkele developer zo'n project vooruit trekt, en als die developer er mee stopt is het heel vaak einde oefening.
Herinner me even, hoeveel linux-distributies bestaan er momenteel? Hoeveel package-managers zijn er om te supporten? Hoeveel verschillende desktop environments? En hoelang geleden zijn die allemaal al geforked? Die gaan zeker allemaal snel weer samenkomen?
IMHO een appels en peren vergelijking, want die bestaan allemaal om totaal verschillende redenen :)

Om maar wat te noemen :
- De vele Ubuntu afgeleiden, omdat men meerdere DE's direct beschikbaar wil maken voor nieuwe gebruikers en verschillende doeleinden.
- Andere filosofie : Alleen de binary versie installeren vs. Alles zelf compilen.
- SystemD vs. SysVinit
- Op BusyBox gebaseerde distro's voor routers/accesspoints/ander embedded gebruik.

En dan hebben we nog de *BSD varianten die weer andere ontwikkeld worden en ook een eigen filosofie volgen :)

In sommige gevallen is er misschien TEVEEL KEUZE maar liever TEVEEL dan TE WEINIG keuze wat mij betreft! d:)b
Juist. Allemaal andere filosofieen. En wat gebeurt daar uiteindelijk mee? Nul komma niks. De enige distros met een fatsoenlijk aantal gebruikers zijn allemaal in handen van bedrijven (Canonical, Red Hat, etc) die wel een langdurige visie en support geven, en die niet elke discussie oplossen met "nou dan doe ik wel mijn eigen ding!".

Niet iets wat de OS community wil horen gezien hoe hard ik omlaag gemod word, maar vraag jezelf af: waarom is zelfs ChromeOS populairder dan wat voor distro dan ook? Waarom lukt het Apple wel om een *nix-gebaseerd OS gebruiksvriendelijk te maken? Waarom betaalt bijna elk bedrijf zich scheel aan Office365 terwijl OpenOffice en LibreOffice en NeoOffice en OxOffice en WhatEverElseOffice gratis is? In plaats van "divide en conquer" kunnen bedrijven simpel een "Let them divide themselves" tactiek hanteren, en die tactiek werkt al zeker dertig jaar feilloos.

Die filosofie van "nou dan doe ik wel mijn eigen ding" in plaats van "misschien kunnen we samen de beste oplossing vinden" is een enorm probleem voor OSS. En ironisch genoeg is het eindresultaat dat heel veel van die projecten nooit ver genoeg komen om een volwaardig alternatief te zijn, zodat er juist TE WEINIG keuze is. Kortzichtige eenmansvisies galore, samenwerking ho maar.
Juist. Allemaal andere filosofieen. En wat gebeurt daar uiteindelijk mee? Nul komma niks. De enige distros met een fatsoenlijk aantal gebruikers zijn allemaal in handen van bedrijven (Canonical, Red Hat, etc) die wel een langdurige visie en support geven, en die niet elke discussie oplossen met "nou dan doe ik wel mijn eigen ding!"
Nu ga je ervan uit dat het doel van Linux (en open source in het algemeen) adoptie van de massa moet zijn. Voor een commercieel produkt klopt dat wel omdat die altijd moeten groeien om hun aandeelhouders te vriend te houden. Voor een nonprofit product is er echter geen probleem dat het een niche blijft. Waarom moet Linux voor iedereen zijn? Met een commerciele visie sluit je ook een heleboel ontwikkelingsrichtingen uit, die mogelijk voordelen kunnen geven, puur omdat ze geen geld opbrengen (of nog erger, omdat niet gedacht wordt dat ze geld kunnen gaan opbrengen)

Als je wel een commerciele distro wil, zijn er inderdaad de opties die je aangeeft. Nou heb je wel kans dat die de stoelpoten onder je vandaan zagen als er te weinig geld voor ze binnen komt, zoals RedHat pas heeft gedaan met CentOS. Dat is de andere kant van het verhaal.

Persoonlijk ben ik heel blij met de keuzes die je hebt. Ik heb een hekel gekregen aan de commerciele distributies omdat die altijd hun eigen IP willen doordrukken om greep te houden op de markt. Canonical met snaps (en daarvoor Mir, Upstart enz) en RedHat met systemd en van alles. Daarom gebruik ik juist een niche distro (alpine). Overigens is alpine niet echt een niche omdat het veel voor docker containers gebruikt wordt, maar op bare metal is het dat wel :) Ik vind het hebben van die keus een groot goed.

Alpine is nu bezig met het ontwikkelen van een alternatief voor systemd zonder de nadelen daarvan. Zo houd je innovatie fris, in plaats van dat je altijd maar meeloopt met de rest. Dit is juist de aard van Open Source, het hele idee erachter: Wie het beter weet mag het zeggen. Verwachten dat juist dit punt opzij gelegd wordt is mijns inziens niet realistisch.

[Reactie gewijzigd door GekkePrutser op 24 juli 2024 04:23]

En wat gebeurt daar uiteindelijk mee? Nul komma niks.
Dat is dus niet waar! Kijk maar eens waar Alpine Linux allemaal op draait! ;)
De enige distros met een fatsoenlijk aantal gebruikers zijn allemaal in handen van bedrijven (Canonical, Red Hat, etc) die wel een langdurige visie en support geven, en die niet elke discussie oplossen met "nou dan doe ik wel mijn eigen ding!".
Ook totaal overdreven en absoluut niet waar! :)
vraag jezelf af: waarom is zelfs ChromeOS populairder dan wat voor distro dan ook? Waarom lukt het Apple wel om een *nix-gebaseerd OS gebruiksvriendelijk te maken? Waarom betaalt bijna elk bedrijf zich scheel aan Office365 terwijl OpenOffice en LibreOffice en NeoOffice en OxOffice en WhatEverElseOffice gratis is?
Dat is simpel :

Slimme marketing richting domme onwetende consumenten/managers/enz... :)

Kijk maar naar de verkoop van LCD producten door de jaren heen of hoe Samsung al zijn telefoons slijt en van onbelangrijke speler naar zo'n beetje de grootste van alle Android modellen is gegaan!

Klinkt hard, maar het is gewoon de waarheid waar je niet omheen kan en daarom heeft men ook zo fel gereageerd op de zoveelste poging om nog meer tracking/telemetry en waarschijnlijk op een bepaald moment ook ads/adware toe te voegen : Die onzin moet gewoon een keer ophouden! :/
Dat is dus niet waar! Kijk maar eens waar Alpine Linux allemaal op draait! ;)
En kijk dan ook gelijk eens waar LEAF op draait. En dat had mooi opgeteld kunnen worden, maar nee, er moest geforked worden. En dan hebben we het nog niet eens over de twee dozijn andere populaire router/firewall distros. Niet eens dubbel werk, maar twintig-dubbel werk. Gefeliciteerd, wat was je punt?
Slimme marketing richting domme onwetende consumenten/managers/enz... :)
|:( Natuurlijk. Mensen gebruiken geen OSS omdat ze dom zijn en in de afgelopen dertig jaar niemand gehoord heeft van alternatieven.

Je begrijpt hopelijk hoe arrogant en kortzichtig je klinkt? Vergelijk de gebruikerservaring eens tussen, ik noem maar iets, OpenBSD en MacOS, of tussen Plasma Mobile en Android. Snap je echt niet waarom mensen liever de laatste variant gebruiken? Wil je serieus beweren dat dat een kwestie van marketing is? Dat geloof je zelf toch zeker niet?
Je begrijpt hopelijk hoe arrogant en kortzichtig je klinkt?
Zei de pot tegen de ketel ?! :)

Blijkbaar heb je geen idee van de invloed van marketing de afgelopen 30 jaar en denk je dat het allemaal om andere redenen is gegaan zoals het is gegaan :?

HINT : Dat is niet zo!
En dan hebben we het nog niet eens over de twee dozijn andere populaire router/firewall distros.
Leuk dat je een lijstje hebt gevonden, maar heb je ook daadwerkelijk tijd gestoken in het vergelijken van die oplossingen :?

OpenWRT is bijvoorbeeld totaal niet te vergelijken met pfSense of Kerio :)


Grappig dat je Plasma Mobile noemt trouwens : Een veel mooier stukje software dan Mr. "Fake Linux" genaamd Android en de Java ellende die daarbij hoort! ;)
Uh ja, dat is net het punt met forken en dan is Linux/BSD een perfect voorbeeld wat het probleem ermee is. Ze hebben allemaal hun eigen redenen om een nieuwe distro te ontwikkelen en dan krijg je dus een wildgroei.
Het idee is leuk, maar je gaat nooit een distro krijgen die perfect aan iemands wensen voldoet, dat is onmogelijk. Zeker in professionele omgevingen waar betrouwbaarheid, stabiliteit en een lange-termijn visie belangrijk is doet het juist meer kwaad dan goed. Men doet concessies en accepteert dat sommige zaken totaal haaks staan ook hun ideaal, simpelweg omdat het onder aan de streep de beste keuze is.

Teveel keuze lijken we dus aardig te kunnen defineren, maar wat is te weinig? 1? 10? 1000?
Het idee is leuk, maar je gaat nooit een distro krijgen die perfect aan iemands wensen voldoet, dat is onmogelijk.
Dat kunnen jij en ik niet bepalen : Iedereen heeft zo zijn voorkeuren! :)

Die van mij is bijvoorbeeld FreeBSD terwijl een ander Debian helemaal geweldig vindt of zelfs gewoon MacOS of Windows 10 ;)

Wat betreft de professionele omgevingen :
Daar filtert de boel zich vanzelf wel uit en krijg je al gauw soort van uit zichzelf ontstane standaarden voor e-mail, databases, fileservers, webservers, virtualisatie, enz...
Die van mij is bijvoorbeeld FreeBSD
Bedoel je dan FreeBSD, Darwin, DesktopBSD, DragonFlyBSD, FreeSBIE, GhostBSD, FreeNAS, TrueOS, MidnightBSD, m0n0wall, NAS4Free, OPNsense of pfSense?
Niet zo flauw doen en gewoon lezen wat er staat : FreeBSD :P

Maar pfSense is inderdaad een mooie DIY Router distro ;)
Totdat je merkt dat OpenOffice nog altijd het meest bekende alternatief is voor MS Office. Dat je nog altijd MySQL als database moet selecteren als je met MariaDB werkt, en ga zo maar verder.

Vanuit een idealistisch standpunt is het kunnen forken zeker een mooi gegeven, maar vanuit praktisch oogpunt, vanuit het oogpunt van adoptatie introduceert het weer nieuwe uitdagingen waarop men geen goed antwoord weet te vinden.
Klinkt heel romantisch, maar de praktijk is dus dat je er als professionele organisatie niet op kunt vertrouwen en overgeleverd bent aan de grillen van enkele ontwikkelaars. Als die morgen besluiten dat ze het ergens niet mee eens zijn verdwijnen ze bij het originele project en hop, een fork! Kun je ervoor kiezen om bij het originele project te bijven met een uitgehold ontwikkelaarsteam of je springt in het diepe en hoopt dat de fork zijn beloften in zal lossen en niet op korte termijn uiteenvalt (al dan niet in nog meer forks).

Nou is er genoeg te zeggen over closed source ontwikkelaars, maar mijn ervaring is dat deze in ieder geval redelijk stabiel zijn met hun ontwikkeling en roadmap. Dat heeft als nadeel dat geen invloed hebt op de ontwikkeling maar het idee dat je dat wel hebt bij open source projecten is ook weer erg romantisch. "Als het je niet bevalt, dan kun je het zelf veranderen!" hoor je vaak, maar is niet realistisch.
Wat is dat nou voor opmerking? Ik reageer op een discussie dat het eenvoudig forken van projecten niet per se een geweldige oplossing is. Ik ben helemaal niet anti-FOSS, maar ik zie wel dat het een aantal serieuze problemen en risico's met zich mee brengt en het forken van software is daar 1 van.
De openheid van de software als probleem en risico aandragen is nogal apart. Als ik een hele specifieke functie aan een stuk opensource toevoeg en die beschikbaar stel voor eventueel andere gebruikers (als fork) is dat een probleem? Mensen zijn niet verplicht die "fork" te gebruiken. Bij closed source is die mogelijkheid er geheel niet. De gebruikers bepalen uiteindelijk toch wel welke "fork" ze het liefst willen gebruiken.
Wat jij daar noemt klinkt erg handig inderdaad, maar je gaat er daarmee voor het gemak volledig aan voorbij dat "die hele specifieke functie" ervoor zorgt dat je volledig nieuw project opzet waarbij dus je dus de gehele code bij zal moeten houden. Het is niet zo simpel als een stukje code tegen het origineel aanplakken. Leuk dat je software hebt geforkt en ik als gebruiker daarop overstap omdat ik die functie graag wilde, maar als dat vervolgens alles is wat jij gedaan hebt en zult doen, dan zit ik dus met een dood project met een leuke functie.

Afgezien daarvan is "die hele specifieke functie" ook niet datgene wat in de praktijk tot een fork uitgroeit. Vaak is het onvrede over beleid of richting in een veel bredere context.

[Reactie gewijzigd door The Realone op 24 juli 2024 04:23]

Wat jij daar noemt klinkt erg handig inderdaad, maar je gaat er daarmee voor het gemak volledig aan voorbij dat "die hele specifieke functie" ervoor zorgt dat je volledig nieuw project opzet waarbij dus je dus de gehele code bij zal moeten houden. Het is niet zo simpel als een stukje code tegen het origineel aanplakken.
Niet helemaal waar : Kijk maar naar de browsers die een afgeleide zijn van Firefox bijvoorbeeld :)
Leuk dat je software hebt geforkt en ik als gebruiker daarop overstap omdat ik die functie graag wilde, maar als dat vervolgens alles is wat jij gedaan hebt en zult doen, dan zit ik dus met een dood project met een leuke functie.
Dat is inderdaad een risico, maar dat betekent natuurlijk niet dat het altijd zo zal gaan! :)
Afgezien daarvan is "die hele specifieke functie" ook niet datgene wat in de praktijk tot een fork uitgroeit. Vaak is het onvrede over beleid of richting in een veel bredere context.
Precies! d:)b

Dat lijkt iedereen een beetje te vergeten in deze hele discussie : Al die forks zijn er niet omdat men het leuk vond voor de grap of zo, maar omdat het simpelweg nodig was!
Dat lijkt iedereen een beetje te vergeten in deze hele discussie : Al die forks zijn er niet omdat men het leuk vond voor de grap of zo, maar omdat het simpelweg nodig was!
Omdat een aantal personen het nodig vonden staat niet gelijk aan "omdat het nodig was".
Stel dat men nu Audacity gaat forken omdat er aan aantal personen het niet eens waren met telemetry, dan splits je dus ontwikkelkennis op in 2 projecten en mag ik als eindgebruiker kiezen 2 forks die op halve kracht ontwikkelen, of op z'n minst een stuk minder efficient zullen zijn omdat ze niet direct meer samenwerken. En dat terwijl mij die telemetry als gebruiker niet zou boeien. Wie is er dan de dupe?
Omdat een aantal personen het nodig vonden staat niet gelijk aan "omdat het nodig was".
In het geval van de voorbeelden die worden aangedragen was dat zeer zeker wel zo! :)
En dat terwijl mij die telemetry als gebruiker niet zou boeien.

Wie is er dan de dupe?
Als je het zo stelt : Ik en vele anderen die dat wel belangrijk vinden! ;(
En wat nou als de ontwikkelaars van de fork zonder telemetry straks besluiten dat "functie X" gaan implementeren die ook een hoop mensen niet aanstaat en er wordt weer geforkt? En later weer want functie Y? En wat als die paar ontwikkelaars van die fork er na een tijdje besluiten langzaamaan mee te stoppen?
Punt is dat je soms concessies moet doen.
Je bent aan het "doomdenken" en zwaar aan het overdrijven : Niet doen! :)
Wie is er dan de dupe?
Waarom zou er iemand de dupe zijn? Alleen degenen die obscure functie X in fork Y belangrijker vinden dan de laatste versie te hebben, zullen de fork gebruiken. De rest blijft gewoon bij het hoofdproject. En degenen die overstappen kunnen ook net zo snel weer terug als ze het idee hebben dat ze met dode software werken. Het geeft dus meer vrijheid. Wil je die vrijheid niet? Blijf bij de mainline. Het bestaan van die fork is voor jou toch geen belemmering? Net zoals het voor mij geen belemmering is dat er naast MariaDB nog meer MySQL forks ontstaan zijn. Die laat ik gewoon lekker links liggen. Maar ik ben maar wat blij dat we niet perse verder moesten met de grillen van Oracle.
Omdat een aantal personen het nodig vonden staat niet gelijk aan "omdat het nodig was".
Stel dat men nu Audacity gaat forken omdat er aan aantal personen het niet eens waren met telemetry, dan splits je dus ontwikkelkennis op in 2 projecten en mag ik als eindgebruiker kiezen 2 forks die op halve kracht ontwikkelen, of op z'n minst een stuk minder efficient zullen zijn omdat ze niet direct meer samenwerken.
In de zeldzame gevallen waarin ik zo iets heb zien gebeuren was dat nooit een 50/50 split maar eigenlijk altijd meer in de buurt van 80/20. De meeste mensen maken dezelfde keuze.
Typisch zie je direct na de fork een periode van verwoede ontwikkeling waarna er 1 fork dominant wordt. Die ene fork kopieert vervolgens de meeste verbeteringen uit andere forks waarna de rest een stille dood sterft of een heel andere richting of specialisatie kiest.

Maar laten we niet doen alsof dit een normale situatie is. Het is juist extreem zeldzaam. De kans dat een bedrijf wordt overgenomen of besluit met een product te stoppen is veel groter en dat is al vrij zeldzaam.
Nou nee de grap is dat ik geen verplichting heb om voor anderen dan behalve mijzelf die software te onderhouden. Het zou verstandig zijn om regelmatig een merge te doen vanuit het oorspronkelijke project als dat kan, maar in bepaalde gevallen zal dat niet kunnen. Als bijvoorbeeld de licentie gewijzigd is zal dat niet gaan. En als jij die feature wil gebruiken zal je of zelf die versie moeten gaan onderhouden of die wijziging in de oorspronkelijke versie laten mergen bijv.

Wat jij omschrijft als fork is niets anders dan een fork om een andere reden dan een specifieke feature. En ook daarin ben ik van mening dat daar niks mis mee is. Dat je het niet eens bent met de redenering van die feature kan. En uiteraard kan je het vervelend vinden dat er fragmentatie door ontstaat. Maar dat is wmb precies wat opensource inhoudt.

edit ps: mijn "fork" van een projectje op github:
https://github.com/raugustinus/templating-resources :)

[Reactie gewijzigd door Verwijderd op 24 juli 2024 04:23]

Ja leuk, nu ga je een hele specifieke situatie noemen in een poging je gelijk te halen, maar een dergelijke fork is niet waar het in deze discussie om ging. Het gaat om de situaties die veelvuldig voorkomen waarbij ontwikkelaars uit project stappen om aan een fork te gaan werken. Dat is totaal anders dan voor jouw eigen situatie software forken.
Maar jij kaart in dezelfde post waar je het apart vindt aan waarom het een probleem is. Iedereen gebruikt de fork die ze willen, oftewel je krijgt ultieme versplintering van software. Want niet iedere fork blijft up-to-date met nieuwe functies, of in verschillende forks zitten verschillende functies.

Open source heeft vele krachten, maar forken is er daar niet 1 van. En zeker voor een professionele omgeving is dat denk ik de reden dat open source niet snel groot zal worden, je wilt immers niet dat je bedrijf draait op de grillen van degene die jouw fork beheert.
Mijn laatste respons op @The Realone hierboven geeft aan dat ik het pertinent niet eens ben met je statement. Het is wmb precies de kracht van opensource.

En de stelling dat het voor een professionele omgeving niet groot zal worden is natuurlijk al lang en breed ontkracht. RedHat, springsource (onderdeel van VMware), elasticsearch en gitlab om er een paar te noemen.
Het één sluit het ander niet uit. Een kracht kan ook een zwakte zijn; een kracht kan ook een risico zijn.
Het zijn 2 aspecten (van vele) van dezelfde waarheid.

Leg een munt op zijn zijkant en jij kijkt naar kop en ik naar munt. Toch zien wij dezelfde waarheid.
Verwijderd @Loft17 mei 2021 18:34
Dat is zeker waar en dat valt ook hier weer duidelijk op aangezien ik het echt als plusplunt zie maar anderen duidelijk niet :)
je wilt immers niet dat je bedrijf draait op de grillen van degene die jouw fork beheert.
Dat is altijd zo. Ieder bedrijf in de wereld (met mogelijke uitzondering van Microsoft) is afhankelijk van software die door anderen wordt ontwikkeld en beheerd. Tegenwoordig brengt iedereen z'n spullen onder in "de cloud". Bij die Cloud-applicaties is het standaard dat er functies worden toegevoegd en verwijderd wanneer het de beheerder dat uitkomt. Soms kun je een verandering een tijdje uitstellen maar tegenhouden gaat toch niet.
Als je dat echt controle wil hebben (en bereid bent de prijs te betalen) dan zul je het zelf in beheer moeten nemen, bijvoorbeeld door te forken.
Ik ben helemaal niet anti-FOSS, maar ik zie wel dat het een aantal serieuze problemen en risico's met zich mee brengt en het forken van software is daar 1 van.
Dat is juist een sterkte van Open Source.
Als het wordt overgenomen door een bedrijf als Oracle (zoals MySQL), dan heb je helaas weinig keus. Dan moet je wel forken en dan is het heel fijn dat het kan.
Ik niet. Dat houdt producten beschikbaar als de organisatie erachter het (potentieel) verprutst. Zie MySQL/MariaDB, OpenOffice.org/LibreOffice, OpenELEC vs. LibreELEC, ...
Maar dit lijstje geeft toch eigenlijk aan waarom het, zeker voor een product dat veel gebruikt wordt, een probleem is. Heel veel stukken software die net genoeg van elkaar verschillen dat het irritant is of niet werkt, maar in essentie hetzelfde proberen te doen.
Dat gaat jou te ver. Maar anderen misschien niet. Dat is de kracht van open source. ;)
Alleen die kracht is dus ook wat het tegenhoudt, zulke versplinterde software zal het namelijk moelijk krijgen om bij het grote publiek aan de orde te komen. Voor de Tweaker is het leuk, zoeken naar de beste optie. Voor een bedrijf wil je niet alle 20 forks langs om te zien welke het goed doet en ondersteund wordt, om er achter te komen dat ook die fork weer 3 varianten heeft die allemaal anders werken. Dus misschien de kracht richting de enthousiast, maar de zwakte als het aankomt op de grote markt.
En komt er vanzelf weer een fork die de andere forks bij elkaar brengt. Zie bijvoorbeeld OpenWRT en LEDE, wat later gewoon weer samengevoegd werd tot OpenWRT.
Nu doe je alsof dit een oplossing is, maar het is in weze niks anders dan nog een fork die weer wat andere problemen oplost. Want je moet ook maar net weten dat er weer fork 101 is die fork 1 t/m 30 heeft samengevoegd maar wel de slechte dingen uit 12 en 13 er uit heeft gehaald.

Begrijp me niet verkeerd, open source heeft zeker voordelen. Maar het forken om iedere functie die je niet aanstaat, zeker als er nog oplossingen kunnen komen, is in mijn ogen wat open source tegenhoudt om tot een groot iets te komen en wat het in die niche houdt.
Wat een raar probleem schets je hier bij forken. Het is uitermate handig dat ik een specifieke wens in een bepaald stukje software in kan bouwen en kan delen. Niemand is gedwongen om gebruik te maken van die fork.
Alleen die kracht is dus ook wat het tegenhoudt, zulke versplinterde software zal het namelijk moelijk krijgen om bij het grote publiek aan de orde te komen.
Als het doel is om het bij het grote publiek aan de orde te komen, dan wordt er vanzelf wel een fork met alle gewenste functionaliteit populair genoeg. Als dat niet lukt, dan heeft het publiek gewoon weinig interesse.
Nu doe je alsof dit een oplossing is, maar het is in weze niks anders dan nog een fork die weer wat andere problemen oplost. Want je moet ook maar net weten dat er weer fork 101 is die fork 1 t/m 30 heeft samengevoegd maar wel de slechte dingen uit 12 en 13 er uit heeft gehaald.
Dat hoef je niet te weten. Dat lost zichzelf namelijk op. :+
Begrijp me niet verkeerd, open source heeft zeker voordelen. Maar het forken om iedere functie die je niet aanstaat, zeker als er nog oplossingen kunnen komen, is in mijn ogen wat open source tegenhoudt om tot een groot iets te komen en wat het in die niche houdt.
Forken, eigenlijk alleen al de mogelijkheid van een fork, zorgt er juist voor dat er dingen groot worden op een manier dat het de gebruiker (waar het uiteindelijk om draait) niet benadeeld.

[Reactie gewijzigd door The Zep Man op 24 juli 2024 04:23]

Als het doel is om het bij het grote publiek aan de orde te komen, dan wordt er vanzelf wel een fork met alle gewenste functionaliteit populair genoeg. Als dat niet lukt, dan heeft het publiek gewoon weinig interesse.
Die populaire was er al, namelijk het origineel. Echter, als die versplinterd in 1 of meerdere forks deel je dus je kennis en ontwikkelaars op en zul je altijd inboeten op snelheid en/of kwaliteit. Je kunt code van elkaar overnemen, maar dan ben je altijd inefficient langs elkaar heen aan het werken. Het is wat lastig meetbaar, want de voortgang van projecten hangt van vele factoren af, maar je hebt maar een x-aantal ontwikkerlaarsuren tot je beschikking.

Er zijn projecten waarbij het origineel volledig stil is komen te liggen en het gros naar een fork is vertrokken, maar dan praat je eerder over een 'change of management'.
Forken, eigenlijk alleen al de mogelijkheid van een fork, zorgt er juist voor dat er dingen groot worden op een manier dat het de gebruiker (waar het uiteindelijk om draait) niet benadeeld.
Nee, forken zorgt ervoor dat ontwikkelaars hun ideologie kunnen volgen, net als dat bij het origineel ook gebeurde. Het is een utopie om te denken dat dit altijd beter is voor de gebruiker. Want vergeet niet, 99,99% (fictief, maar je snapt em vast) van de gebruikers draagt nooit een regel code toe aan het project.
Echter, als die versplinterd in 1 of meerdere forks deel je dus je kennis en ontwikkelaars op en zul je altijd inboeten op snelheid en/of kwaliteit. Je kunt code van elkaar overnemen, maar dan ben je altijd inefficient langs elkaar heen aan het werken. Het is wat lastig meetbaar, want de voortgang van projecten hangt van vele factoren af, maar je hebt maar een x-aantal ontwikkerlaarsuren tot je beschikking.
Als iedereen het eens was over het einddoel was en hoe je dat moet bereiken dan zou ik het met je eens zijn. Ik zie het liever zoals de natuur aan ontwikkeling doet, namelijk door parallelle evolutie. Verschillende "partijen" proberen verschillende varianten uit. Daarvan blijken sommigen succesvol te zijn en anderen niet. Dat is jammer voor de varianten die niet werken, maar de soort als geheel wordt er beter van omdat je minder snel vast komt te zitten op een verkeerde keuze.

Ons economische systeem, het kapitalisme, is ook gebaseerd op het idee dat er meerdere aanbieders zijn van ongeveer hetzelfde product en dat klanten daar uit kiezen. Zo groeien de goede producten en verdwijnen de slechte bedrijven. Volgens jouw redenering zou het beter zijn om voor ieder doel één applicatie te schrijven die alles en iedereen dan maar verplicht moet gebrujiken. Voor dat soort economische (en politiek) systemen hebben we ook namen maar die hebben nogal negatieve bijklanken als "communisme" en "planeconomie" of "eenpartijsysteem".
Alleen die kracht is dus ook wat het tegenhoudt, zulke versplinterde software zal het namelijk moelijk krijgen om bij het grote publiek aan de orde te komen. Voor de Tweaker is het leuk, zoeken naar de beste optie. Voor een bedrijf wil je niet alle 20 forks langs om te zien welke het goed doet en ondersteund wordt, om er achter te komen dat ook die fork weer 3 varianten heeft die allemaal anders werken. Dus misschien de kracht richting de enthousiast, maar de zwakte als het aankomt op de grote markt.
Als ik open source bouw dan doe ik dat juist niet voor bedrijven. Als ze er toevallig wat aan hebben dan is dat mooi meegenomen voor ze, maar in principe ben ik er niet zo blij mee. Namelijk, het leidt altijd weer tot zakelijke overnames of investeringen, waarvoor weer geld terug gezien moet worden. Zie het verhaal met open-source projecten die weer dichtgegooid zijn zoals MySQL of ZFS. In het gunstigste geval zie je als open source ontwikkelaar je harde werk als een tweederangs 'community edition' gelabeld worden.
Het begint altijd met de "opt in". Paar patches later wordt dat "opt out". Paar patches later is het allemaal plots closed source. Direct bij de kiem insmoren.
Ik kan je meer dan genoeg FOSS software opnoemen die opt-in telemetrie aanbiedt. Telemetrie is niet slecht, het valt of staat bij de implementatie.

[Reactie gewijzigd door saren op 24 juli 2024 04:23]

Ik ben zelf heel kritisch t.a.v. telemetrie in software. Heel vaak leidt het een namelijk tot het ander, want als de geest eenmaal uit de fles is.... Ook zonder telemetrie kun je prima aan software ontwikkeling doen.
Domeido's artikel hierover slaat wat mij betreft de spijker op zijn kop: https://www.dedoimedo.com...try-should-you-allow.html
Goh ja dan log je een bug en vragen ze je hele logs te uploaden naar github/lab en welke stappen je allemaal al ondernomen hebt en etc. Gros van de gebruikers wilt gewoon zeggen: dit werkt niet, los het op. Met de opt in telemetrie van mij zouden ze voldoende info moeten hebben dat na wanneer ik op enkele knoppen klik er een error naar boven komt. Kernel, distro en DE versie mee in de logs en ze kunnen de boel zelf repliceren.
Een gewone gebruiker zal uberhaupt nooit een bug melden en beperkt zich heel begrijpelijk tot iets van 'los het op'. Als je een bug op Github kunt melden ben je handig genoeg om ook logging op te zoeken en een eigen beschrijving/eerste analyse te maken. Daar is die ingebouwde telemetrie totaal niet voor nodig.
Ik vind een fork beter dan het allemaal maar moeten slikken.
Toch vind ik het maar raar dat men keuze uit forks en veel distro's slecht vind bij OSS, maar bij bijv. auto's kunnen er niet genoeg merken en dochtermerken (die soms ook zijn afgesplitst, dus geforkt, zoals DS bijv.) zijn.

[Reactie gewijzigd door TheVivaldi op 24 juli 2024 04:23]

Ik heb niks met auto's, en heb er ook nooit iets over gezegd. Het kan prima dat mensen die een grote keuze aan auto's fijn vinden een andere groep mensen is dan hen die een overvloed aan FOSS forks een slechte zaak vindt. Sowieso denk ik dat de groep die zich druk maakt om FOSS eigenschappen ontiegelijk veel kleiner is dan de groep die met auto's bezig is, maar dat terzijde.

[Reactie gewijzigd door saren op 24 juli 2024 04:23]

Ik heb niks met auto's, en heb er ook nooit iets over gezegd.
Daarom zei ik ook men, in zijn algemeenheid dus. Het wil dus niet zeggen dat jij je dan aangesproken hoeft te voelen ;)

[Reactie gewijzigd door TheVivaldi op 24 juli 2024 04:23]

Ik vind dit juist weer een van de nadelen van hoe makkelijk er met open source software geforkt kan worden
<knip>
Dan krijg je een versnipperd landschap met allerlei forks die 1 probleem oplossen
Volgens mij is dat een vrij theoretisch probleem. Hoeveel concrete voorbeelden kun je noemen van applicaties waarvan meerdere forks over langere periode actief zijn? In mijn ervaring vinden dit soort forks alleen plaats bij grote conflicten en blijft er daarna vrij snel eentje over. Sowieso is het forken vanwegen conflicten best wel zeldzaam. De meeste forks die ik heb gezien zijn er omdat de oorspronkelijke auteur niet meer actief is.
De theoretische mogelijkheid tot forken houdt de meeste organisaties eerlijk.
Yep, het is opt-in, totdat het opt-out wordt. Totdat het geen optie meer is. Tot ze beslissen dat ze de data misschien toch wel verkopen.

De reden dat zoveel mensen hier tegen zijn ook al is het opt-in komt niet uit de lucht gevallen. Iedereen weet dat dit gewoon de eerste stap is. En niemand zit te wachten op waar het naartoe leidt.
Terechte opmerking en in zekere zin ook een terechte actie mocht het (alsnog) gebeuren: open-source heet open-source met een reden.

Ik heb zelf al tijden geleden de overstap gemaakt richting Ocenaudio (https://www.ocenaudio.com/).
Normaal gesproken een zware voorkeur voor de FOSS-hoek, maar in dit geval een uitzondering gemaakt:

Ik was niet tevreden met de gang van zaken qua ontwikkeling van Audacity en zag dat wel geburen bij Ocenaudio. Tot op de dag van vandaag nog geen spijt gekregen van deze keuze.
Dat forken is (naar mijn mening) mede ook een oorzaak dat veel computergebruikers en ook enthousiastelingen niet overstappen op Linux. Er is zo verschrikkelijk veel om uit te kiezen...!

Heb in het verleden diverse pogingen gedaan om een werkbare desktop in Linux te maken waarmee ik mijn dagelijkse ding kon doen, maar ik viel toch telkens weer terug op Windows.

Zegt misschien ook wat over mij, maar ik kan me voorstellen dat veel mensen het moeilijk vinden om het van Windows platform af te stappen, omdat ze toch telkens weer tegen dingen aanlopen die onder Windows gewoon werken.

Met applicaties hetzelfde. Kijk maar naar PFSense en OPNsense. In de basis hetzelfde, maar tóch moet je van te voren weer kiezen en de pro's en cons afwegen voordat je verder gaat. Als Audacity gaat afsplitsen zal je daar ook weer zien dat bepaalde functionaliteit een bepaalde 'fork' kiest en deze niet meer compatibel is met de basisversie.

[Reactie gewijzigd door Fairy op 24 juli 2024 04:23]

Ja, die dan vervolgens weer naar de main gaat kijken m.b.t. welke "handige features" er toegevoegd worden en daarmee dan dus indirect gebruik maakt van de telemetrie die deze verzameld.
Ik snap het niet.

Om de heisa over Google te omzeilen, kunnen ze toch hetzelfde doen wat een hoop organisaties doen, van kleine tot de grootste Fortune 500 bedrijven en Matomo Analytics of zijn grote zus/met enterprise support Piwik Pro gebruiken?
Precies, maar dat hadden ze toch ook zelf kunnen bedenken. En daar volledig open over zijn over welke informatie dan verstuurd wordt? Dan kweek je begrip... Als een gratis beschikbaar gesteld project daarmee geholpen wordt, dan heb ik geen bezwaar. Zelfs niet al zouden ze een top40 ervan maken. Maar wel duidelijk zijn hoe met de gegevens wordt omgegaan :)

[Reactie gewijzigd door bvdbos op 24 juli 2024 04:23]

Precies. Ik heb er helemaal geen probleem mee als ze wat telemetrie ontvangen in de vorm van gebruikte functies en wellicht mijn systeem specs zodat ze kunnen optimaliseren. Maar GA en Yandex zijn daarvoor niet nodig.
Martin Keary, de nieuwe eigenaar van Audacity, zegt in een GitHub-issue dat het ontwikkelteam 'verrast was' door de kritiek op het plan.
Niet te geloven, onder welke steen heeft die geleefd?

Iedereen haat het om bespied te worden.
Het is per definitie geen bespieden wanneer het opt-in is, bespieden betekent namelijk heimelijk/onopgemerkt in de gaten houden.
ALS nieuwe eigenaar van Audacity WIL ik graag weten hoe mensen Audacity gebruiken ZODAT ik weet waar ik me in de doorontwikkeling op moet focussen.

En dan de community laten discussiëren over de aanpak. Niet:
ALS nieuwe eigenaar van Audacity WIL ik Universal Google Analytics en Yandex Metrica inzetten ZODAT ik kan zien hoe mensen Audacity gebruiken.

Je zou kunnen weten dat die tweede alleen maar poep richting de ventilator is.
Opt-in is natuurlijk netjes, maar om nou Google Analytics te gaan gebruiken... tja... Maar ja, als het opt-in is, waarom dan de ophef?
Als ik het goed begrepen heb was het "opt-in" vakje alvast aangevinkt; dwz eigenlijk een opt-out.

Niet erg netjes, dus.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 04:23]

Men slaat een beetje door met de paniek rond het vergaren van data. We krijgen mooie software voor niks. En de software wordt steeds beter door dit soort goedkope oplossingen (telemetrie verzamelen i.p.v. gebruikersonderzoeken)
Maar wat gemeen dat die partijen geld verdienen door op een betere manier advertenties te kunnen tonen. Overal waar je advertenties ziet (televisie, straat) wordt "getarget". Alleen is het een stuk grover getarget op televisie en de straat. Via het internet gaat het gewoon makkelijker om je doelgroep te vinden.
Als we zo krampachtig bezig blijven gaan we meer en meer direct betalen voor diensten en zal software niet veel handiger worden. De end game van deze situatie is dure onhandige software. Ik heb liever gratis handige software. Die advertenties blijven ons toch wel bereiken, ze zullen alleen minder relevant zijn.
Kom maar met de minnetjes :+

[Reactie gewijzigd door pepijntb op 24 juli 2024 04:23]

De software was al gratis en open source en daar probeert een commercieel bedrijf nu data mee te verzamelen, dat vind ik iets anders dan bv Facebookdie je een 'gratis' dienst levert.

Dat je dat doet over het ontwikkelwerk van andere mensen (die de intentie hadden om gratis software te maken) is blatante expoitatie.
Het is makkelijk om Google Analitics toe te voegen, maar daarmee geef je veel informatie weg aan een toch al machtig bedrijf. Dit wordt door de eindgebruikers van Audacity niet als de beste oplossing gezien.

Ik gebruik veel software en maak daarbij altijd de afweging of ik wil bijdragen door het delen van statistieken en log-gegevens. Bij het ene product wel, bij het andere product niet. Als Audacity wil weten hoe ik het programma gebruik mogen ze daar best wat voor inbouwen en daar wil ik ook aan meewerken.

Maar communiceer daar goed over naar de eindgebruiker en Google Analitics is daar zeker niet de beste keus voor de eindgebruiker.

En die advertenties, die zogenaamd relevanter worden, schiet Audacity ook niks mee op. Krijgen ze geen cent meer inkomsten van. De enige winst is de eenvoud van implementeren doordat Google het voorwerk al heeft gedaan.

De wereld is niet zo zwart-wit als jij hier stelt. De ene helft die alles klakkeloos accepteert en de andere helft die krampachtig alles verbergt. Er zijn 5 bedrijven die heel veel winst maken met heel veel aanbieden en combineren. En er is een groep die z'n best doet hier iets van evenwicht/balans in te krijgen.
In gesprek gaan met je gebruikers op basis van opt-in [ OK ]
Google integreren [ NOPE ]
Men slaat een beetje door met de paniek rond het vergaren van data. We krijgen mooie software voor niks. En de software wordt steeds beter door dit soort goedkope oplossingen (telemetrie verzamelen i.p.v. gebruikersonderzoeken)
Na jaren van verwaarlozing zijn we langzaam aan het ontekken dat we wel heel erg nauw in de gaten worden gehouden. Het is logisch dat er een tegenreactie is die zich super kritisch opstelt.
Maar wat gemeen dat die partijen geld verdienen door op een betere manier advertenties te kunnen tonen.
Het gaat hier niet om advertenties.
Dat je telemetrie ter verbetering van de software op een hoop gooit met advertenties laat ook wel een stuk van het probleem zien: mensen zien het verschil niet en kunnen het typisch zelf ook niet beoordelen omdat ze niet kunnen zien wat er achter de schermen met hun data gebeurt.
Overal waar je advertenties ziet (televisie, straat) wordt "getarget". Alleen is het een stuk grover getarget op televisie en de straat. Via het internet gaat het gewoon makkelijker om je doelgroep te vinden.
Als we zo krampachtig bezig blijven gaan we meer en meer direct betalen voor diensten en zal software niet veel handiger worden. De end game van deze situatie is dure onhandige software. Ik heb liever gratis handige software. Die advertenties blijven ons toch wel bereiken, ze zullen alleen minder relevant zijn.
Kom maar met de minnetjes :+
Audacity is al geweldige software die gratis beschikbaar is. Daar zijn geen advertenties of telemetrie voor nodig geweest. Die "end game" klopt dus niet.

Advertenties en tracking zijn ook niet gratis. Die middelen worden ingezet om meer te verdienen. Het is misschien mooi dat je een "gratis" applicatie krijgt waar je anders 3 euro voor had betaald, maar als je vervolgens de rest van je leven 1 euro extra moet betalen ieder keer dat je een vakantie boekt dan weet ik niet of dat nu wel zo'n goede deal is. De adverteerders/trackers zijn alleen bezig met hoeveel zij er aan verdienen, niet aan hoeveel het ons kost. Als ik een fiets steel en voor 10 euro verkoop dan is dat mooi voor mij, maar het slachtoffer heeft 300 euro schade.
Ehm, waarom maakt iedereen zich direct druk?
Waarom zou Audacity internet toegang moeten hebben? En dan nog, netwerk toegang voor die app is gemakkelijk te blokkeren,telemetrie of niet.
Audacity is altijd een gratis (en veelgebruikte) wave editor geweest en recentelijk overgenomen door Ultimate Guitar.

Ditzelfde bedrijf verdiend aan de user input op hun websites (gebruikers maken gratis gitaar- en andere tabs) en je kan een abonnement nemen om er toegang tot te krijgen.

Verder regent het klachten bij muzikanten die toch besloten hebben een trial of abonnement te nemen en lijken ze niet te leveren wat beloofd.

Aangezien veel muzikanten ook gebruikers zijn van wave editors (maar niet perse mensen die weten hoe je netwerktoegang van een applicatie kan stoppen) word er dus uitermate kritisch gekeken naar de voortgang van deze altijd erg populaire app. En als de eerste stap is om telemetrie richting Google te sturen is, snap ik vrij goed het wrange gevoel bij deze overname.
Aangezien veel muzikanten ook gebruikers zijn van wave editors (maar niet perse mensen die weten hoe je netwerktoegang van een applicatie kan stoppen) word er dus uitermate kritisch gekeken naar de voortgang van deze altijd erg populaire app. En als de eerste stap is om telemetrie richting Google te sturen is, snap ik vrij goed het wrange gevoel bij deze overname.

Heel goed. Daar kan ik het mee eens zijn, die mensen mogen ze niet uitbuiten.
Je kunt ook zand door je suiker gooien, want je kunt het er toch weer uithalen, je hoeft alleen maar je suiker op te lossen.
Zo lang je het kaf maar van het koren kan scheiden.
Ze zetten het dus gewoon nog een poosje in de week en proberen het over een poosje opnieuw. Zoals gebruikelijk.

Op dit item kan niet meer gereageerd worden.