Hoofdontwikkelaars van Nginx beginnen eigen fork Freenginx

Een aantal van de hoofdontwikkelaars van Nginx zijn een fork begonnen van de webserver. Freenginx is ontstaan uit een conflict met F5, dat Nginx in 2019 overnam. Een van de ontwikkelaars is het niet eens met het nieuwe beveiligingsbeleid.

Een van de hoofdontwikkelaars van Nginx, Maxim Dounin, kondigt de oprichting van Freenginx aan in een nieuwsbrief. Hij is sinds 2022 niet meer in dienst bij F5 Networks, het bedrijf dat Nginx in 2019 overnam. Sindsdien is Dounin nog wel de belangrijkste ontwikkelaar van de serversoftware, maar Dounin zegt niet blij te zijn met de koers die F5 met de software op wil.

Dounin verwijt het nieuwe management van F5 dat het een bepaald beveiligingsbeleid van Nginx heeft aangepast, waarbij ook de ontwikkelaars werden omzeild. Hij zegt niet wat hij daar precies mee bedoelt, maar zegt dat dat beleid 'onze afspraken heeft geschonden'.

Bovendien ziet Dounin Nginx niet langer als een 'gratis en opensourceproject dat voor het algemeen belang wordt ontwikkeld en onderhouden'. Hij begint daarom een fork van Nginx dat Freenginx heet. Dit moet grotendeels overeenkomen met Nginx, maar breder beschikbaar zijn. Veel details over het project zijn er vooralsnog niet.

Reacties (55)

[roelboel]

Het conflict gaat naar verluidt over deze CVE’s: https://mailman.nginx.org...DIHH5YFBIJYZJN7FGNAV.html

[kodak]

Het conflict is dus dat het management een security advisory liet uitgeven terwijl de ontwikkelaars de bug niet ernstig genoeg vonden.

https://freenginx.org/pip...2024-February/000007.html

Dit zou tegen het securty beleid in zijn. Terwijl de ontwikkelaar er niet open over is of dat ook anders gezien kan worden.

Daarbij noemt de ontwikkelaar dat deze het oneens is met de keuze tot publiceren, omdat 'alle' ontwikkelaars het er over eens zouden zijn dat het waarschijnlijk als gewone bug opgelost zou worden. Waarbij de ontwikkelaar weer weg laat of dit een fout kon zijn.

Het persoonlijk niet accepteren van een uitkomst is ook in de open source wereld gewoon. Het gaat gewoonlijk om wie controle heeft, niet of iedereen het perse eens is. In dit geval lijkt er door de ontwikkelaars geen definitief besluit te zijn genomen en heeft het management kennelijk een besluit genomen. En hoewel de ontwikkelaar dat problematisch lijkt lees ik niet dat deze de mogelijkheden open laat dat fouten gemaakt kunnen worden en de ontwikkelaars zelf fout zaten.

[Reactie gewijzigd door kodak op 23 juli 2024 17:08]

[runnershigh]

Zoals ik het lees, is dit niet per se het hele conflict, maar een recent voorbeeld ervan. Er zijn kennelijk steeds opnieuw zulke situaties.

[kodak]

Zoals ik het lees draait het allemaal om de publicatiekeuze rond de security advisory. Ik heb de reactie aangevuld met wat me opvalt.

Mijn vermoeden is dat de ontwikkelaar gewoon een excuus zoekt om zelf controle te willen hebben. Vooral omdat deze een voorval al genoeg lijkt te vinden en daarbij niet op zoek lijkt naar een antwoord of deze zelf geen fouten heeft gemaakt. Daarbij sluit deze zich niet aan bij een eerdere fork van oud-collega's en toont daar ook geen interesse in.

[CrazyJoe]

Beetje kort door de bocht, dat statement. Maxim Dounin zei dat de bug zat in een experimentele versie van de optionele http3 module en dat deze bug opgelost zou gaan worden in het reguliere ontwikkeltraject van deze module, wat schijnbaar in goed overleg met de andere ontwikkelaars was beslist.

Hij was het dus niet eens met de beslissing het management van F5 om hier een high priority security advisory over uit te brengen. Maar dat was slechts een voorbeeld van wat voor conflict hij had met F5.

[gorgi_19]

Als je het citaat pakt een ander deel van het draadje

quote: https://freenginx.org/pip...2024-February/000007.html

And, more importantly, I no longer able to control which changes are made in nginx within F5, and no longer
see nginx as a free and open source project developed and maintained for the public good.

lijkt het erop dat het een optelsom is van zaken. De kern: hij is niet meer in control van het project, iemand anders bepaald wat er wel en niet met het project gebeurd en daar heeft hij moeite mee.
Hij is het niet eens met de richting, vindt dat de principes van open source geschaadt zijn en hoe de security policies vroeger werkten, prima waren.

Typisch geval van verschillende visies na een overname / nieuw management (zonder uitspraken te doen welke visie beter is).

[Blokker_1999]

Alleen verwacht ik niet dat vele mensen zullen volgend. Als voormalig medewerker is het helemaal niet vreemd dat je geen controle meer hebt. Maar om daarom te zeggen dat het project niet langer FOSS is, klopt niet.

Visies kunnen verschillen, niets mis mee, forken kan en mag. Maar zulke verklaringen zullen door velen direct als negatief ontvangen worden.

[Capzilla]

Er hoeven niet veel mensen te volgen, alleen de juiste. Als freenginx prima werkt en een goede package builder heeft komt het vanzelf wel in distributies terecht. Als F5 dan ook nog maar één rare beslissing neemt of freenginx gewoon beter blijkt maakt Debian het als eerste default en een paar jaar verder kijkt niemand meer naar het origineel, net zoals MySQL praktisch is gedecimeerd door MariaDB.

[Anoniem: 718943]

Vaak gaan dergelijke forks ook over de egootjes van bepaalde devs, denk bijvoorbeeld aan dat hele SearX gebeuren.
Dit voorbeeld vindt ik er ook wel bij passen. De overname zal waarschijnlijk met een zak geld gemoeid zijn geweest. Dus wel geld vangen (sell-out), maar dan gaan lopen klagen dat de overnemende partij zich gaat bemoeien met de ontwikkeling van inmiddels hun product. Wat verwacht je dan?

[Xander2]

Dat geldt toch voor beide partijen?

Ik zat eerst raar te kijken dat die ontwikkelaar van MySQL de boel verkocht aan Oracle en vervolgens ging klagen dat het niet naar zijn zin ging.

Maar dat is onderdeel van de mindset van die ontwikkelaar en die eigenzinnigheid met oogkleppen heeft ervoor gezorgd dat MySQL een succes is geworden.

Als je als bedrijf niet realiseert en erkent waar de waarde precies zit maar zo'n drijvende kracht te veel buiten spel zet voor eigen belangen, wat ook begrijpelijk is, blijft er niets over dan vertrek.

Ik ben dan blij dat de licentie ons, maar ook die developer, de mogelijkheid biedt tot voortzetting gebruik.

Bedrijven mogen zich ook best eens realiseren dat inzet en passie niet simpelweg een eenmalig prijskaartje hebben en ik ben die developer dankbaar voor zijn gratis product en neem zijn kuren voor lief.

[wilmardo]

Dit is al de tweede fork van oud medewerkers, eerder was er al Angie.
https://www.managedserver.eu/angie-the-fork-of-nginx-created-by-former-Russian-employees-fired-from-f5/

[Reactie gewijzigd door wilmardo op 23 juli 2024 17:08]

[GertMenkel]

Ik ben benieuwd waarom de dev zich niet bij Angie aangesloten heeft. Ik kan me voorstellen dat je graag zelf de controle houdt, maar een eenmansfork van nginx gaat het denk ik niet lang redden.

[Frame164]

Dat zal wel met het in een eerdere reactie genoemde ego te maken hebben.

[vrow]

Ik lees Angie niet als een 'open' fork. Daar zit nu een Russisch bedrijf achter. Dus ik weet niet, als je je daarbij wilt aansluiten kom je indirect voor een Russisch bedrijf te werken. Dat lijkt me momenteel ook niet heel er handig om te doen.

[jj42]

Naar eigen zeggen omdat achter Angie ook een bedrijf zit:

> Why yet another fork? I mean why just not "angie", for instance?

The "angie" fork shares the same problem as nginx run by F5: it's
run by a for-profit corporate entity. Even if it's good enough
now, things might change unexpectedly, like it happened with F5.

https://mailman.nginx.org...YZ2QRA3WF6SRPGIBDBKI.html

[kiptandoro]

Goede ontwikkeling, je ziet het steeds vaker dat bedrijven proberen opensource projecten te kapen.

[RiDo78]

Veel bedrijven begrijpen open source ook niet. Daar zit een inherente kloof die je financieel belang zou kunnen noemen. De meeste bedrijven zijn van nature gebouwd om producten of diensten te verkopen en daar geld aan te verdienen. En als je een kleine concurrent hebt die langzaamaan een bedreiging lijkt te worden, dan koop je het bedrijf op, geef je het personeel een leuke bonus en/of een kleine salarisverhoging en voor de klanten beloof je dat alles bij het oude blijft of je geeft ze een migratiepad en een mooie korting op de licenties en iedereen is blij.

Het 'free for all' concept druist daar compleet tegen in. De software is licentie-technisch beschermd dat er simpelweg een fork van gemaakt kan worden waardoor de klok even wordt terug gedraaid en er praktisch een kopie van de software ontstaat, de ontwikkelaars die er aan werken doen dat met een bepaalde filosofie en die zijn niet allemaal met een zakje geld te overtuigen om te blijven en het belangrijkste, de klanten zien dat ook en rennen bij je weg om weer met de fork verder te gaan.

Een mooi voorbeeld daarvan is MySQL. Prima database voor dagelijks gebruik, doet wat het moet doen en er is weinig op aan te merken. Natuurlijk mis je wat features die je wel de 'grote commerciële' jongens als MSSQL Oracle hebt. Maar het kan op minimale hardware draaien, er is veel personeel te vinden met ruime ervaring, het is gratis én werkt subliem samen met bijvoorbeeld PHP. Wat precies de beweegredenen van Oracle waren weet ik niet maar ze namen het MySQL project over. Misschien dat ze wat code eruit gebruikt hebben in het Oracle product en dat ze wat Oracle code in MySQL hebben gestopt om het wat van waarde te geven. Maar het heeft niet lang geduurd voordat de oorspronkelijke ontwikkelaars Oracle de rug toekeerden en MariaDB in het leven riepen. Natuurlijk zal daar niet de 'beschermde' Oracle code in zitten, maar de vroegere MySQL doelgroep zat daar ook niet zo om te springen. Voor hen volstond MySQL prima en die zijn nu tevreden met MariaDB. En dan heb ik het nog niet eens over diegenen die uit principe al helemaal niets met Oracle te maken willen hebben.

Natuurlijk kun je moet open source ook winst maken; je kunt support-contracten voor je gratis product aanbieden (zoals Ubuntu dat doet) of je combineert open source met een klein beetje eigen code en verkoopt dat (zoals Red Hat). Maar wil dat slagen, dan moet je open source als bedrijf niet alleen begrijpen, maar het moet ook in je DNA zitten. En je moet zorgen dat je geen blunders begaat zoals een opensource project closed-source te maken. Zoals (wederom) Oracle heeft gedaan met een project om een running kernel te kunnen updaten. Red Hat heeft er veel in geïnvesteerd en Oracle heeft het overgenomen. Daarom kun je in Oracle Linux (mits juist gelicenseerd) de kernel upgraden en actief maken zonder de machine te moeten herstarten, iets wat bij andere distributies niet kan. Zelfs niet bij Red Hat, de distributie waar Oracle Linux van afgeleid is. Met dergelijke acties bewijs je als bedrijf dat je niet te vertrouwen bent wat open source aan gaat. Je reputatie gaat daarmee snel down-the-drain.

Wat F5 networks aangaat, het is niet duidelijk wat nu het geschil met de ontwikkelaar(s) is, maar het feit dat er weer een 'gratis' fork wordt uitgebracht door de voormalige hoofdontwikkelaar zegt al dat er iets niet volgens plan gaat. Ik ben benieuwd of er binnenkort meer duidelijkheid komt over het pad wat F5 networks dacht te gaan volgen. Als het iets is in de trend van dat je voor toekomstige updates en upgrades moet gaan betalen, dan is F5 het zoveelste bedrijf wat zich met opensource in de vingers snijdt. Dan zal het niet lang duren voordat de meeste Nginx installaties vervangen worden door hun FreeNginx equivalent.

En waarom Red Hat wel succesvol is? Ze investeren veel in open source projecten en nemen die projecten vaak ook over. Maar het grote verschil is wel dat ze de projecten doorgaans open laten. De enige actie van Red Hat die ik kan bedenken die echt veel stof heeft doen opwaaien is de overname van het CentOS project om daar vervolgens de stekker uit te trekken. Maar CentOS was dan ook te goed om waar te zijn. Het was feitelijk een kopie van de geteste en enterprise waardige Red Hat code die gratis beschikbaar werd gesteld. Dus waarom zou je nog Red Hat nemen als je exact hetzelfde gratis kunt krijgen? Het grootste verschil met Oracle is wel dat Red Hat niet 'zomaar' CentOS de nek om draaide. Ze hebben het feitelijk een andere plek in de keten gegeven en hernoemd naar CentOS Stream. Maar nu is het Red Hat die profiteert van de CentOS (Stream) code in plaats van omgekeerd. Met als belangrijkste verschil, CentOS Stream is geen kopie meer van de geteste enterprise waardige code, maar van een minder geteste, niet enterprise-waardige, maar wel stabiele code. Je kunt dus nog steeds gebruik maken van de gratis CentOS (Stream), alleen je hebt minder garanties. Wil je die wel? Dan neem je maar een RHEL licentie af. En datzelfde gaat ook op voor de meeste andere Red Hat producten. Wil je bijvoorbeeld gratis Ansible Tower? Dan neem je maar de AWX upstream.

Hoewel ik niet voor anderen kan spreken heb ik het gevoel dat zelfs Microsoft veel beter in de open source community ligt dan Oracle. Ook Microsoft heeft closed-source, maar heeft voor zover ik weet geen blunders begaan door te proberen open source technologie aan het publiek te onttrekken. Ze investeren veel in open source projecten en zullen de code die het oplevert ook gebruiken in hun eigen software. Maar ze laten het oorspronkelijke project wel in ere. Al ben ik wel benieuwd wat er met GitHub gaat gebeuren, nu Microsoft die heeft overgenomen. Maar daarvoor is het wachten tot de stofwolken weer gaan liggen.

[pennywiser]

Github is al een jaar of 6 van Microsoft, ik denk niet dat je nog kan spreken van stofwolken.

Ben het met je eens dat Microsoft sinds de komst van Nadella een positief deelnemende partij is in de OSS community. Ik heb al horen zeggen dan Red Hat bijna het nieuwe Microsoft aan het worden is .

[Kenhas]

Heb je dan meer achtergrond informatie? Jij ziet het als een bedrijf die iets kapot maakt maar het kan ook "gewoon" een ontevreden werknemer zijn. Het is niet omdat het conflict tussen een bedrijf en een ex-werknemer is, dat het automatisch het bedrijf is dat in de fout gaat.

Voor alle duidelijkheid, ik zeg niet dat het de ontwikkelaar die in fout gaat of zo. Het is perfect mogelijk dat het aan het bedrijf ligt. Maar er worden nog redelijk snel veronderstellingen gemaakt

[MrDrako]

Kijk maar naar redhat/centos, Oracle en mysql, daar kun je nou niet echt gelukkig van worden.

[Kenhas]

Sorry maar dat is wel zeer gemakkelijk. Het is niet omdat een ander bedrijf iets doet, dat automatisch alle bedrijven zo zijn.

[MrDrako]

In dit geval ligt het ook anders, maar de vraag was of grote bedrijven open source projecten kapen, en dat was bij de 2 voorbeelden wel het geval.

In dit geval van f5 vind ik de ontwikkelaar geen gelijk hebben, het ging over het beleid hoe ze omgaan met Security advisories, en er was nu 1 boze rus die niet blij is met de lijn die het Amerikaanse bedrijf heeft ingezet. Nginx is geen hobby project meer dus dan gelden er ook andere regels met juridische gevolgen.

[graey]

Het gebeurt wel vaker als een bedrijf daadwerkelijk de regie/eigenaarschap overneemt. Zelfs als de licentie hetzelfde blijft, er komt dan een niet-originele partij die bepaalt wat de koers is, en welke bijdragen van derden wel of niet worden geaccepteerd.
Je ziet dan vaak dat de (lange termijn-)visie gaat afwijken; het gebeurt meer dan niet dat een overnemende partij vooral geinteresseerd is in gebruik van het overgenomen project en enige vorm van zekerheid. Dat is een groot verschil met vooral de passieprojecten van ontwikkelaars die niet zijn begonnen voor winst of zelfs gebruikscijfers, maar vanuit een principekwestie en/of passie.
Overname is verder ook helemaal niet nodig om continuiteit of stabiliteit te garanderen; je kan forken, je kan contribueren zonder eigenaar te zijn. De Linux Foundation is een goed voorbeeld van hoe grote partijen deel kunnen nemen en mee kunnen werken zonder dat eigenaarschap verandert en de koers eenzijdig aangepast wordt.

[dakka]

Terraform ook

[bassekeNL]

Zo uit mijn hoofd:

* Hashicorp die zijn OS producten onder een andere licentie brengt
* Oracle, die de tests uit MySQL haalt
* RedHat/IBM die source niet meer beschikbaar stelt aan derden.

Allemaal conform de verschillende licenties, maar het beperkt de vrijheden van derden. Thierry Carrez had er een lezing over op FOSDEM dit jaar.

Ik ben het er overigens niet helemaal mee eens. Doordat er een bedrijf risico neemt, wordt er een product ontwikkeld. Op het moment dat er dan een breuk is, heb je toch software die je anders niet gehad zou hebben, en die je op dat moment kunt forken.

[Frame164]

Het is wel de manier om open source mainstream te maken en houden. Met een community van vrijwilligers kan je geen contracten afsluiten.

[Henk Poley]

Hoewel je waarschijnlijk "kapen" bedoelt als ze een project minder toegankelijk maken, is ook goed te verdedigen dat open source juist iets voor bedrijven is. Het heeft alleen bestaansrecht als er iets anders is dat de rekeningen betaalt, promo doet, forum beheer, etc.

Naja, video legt het uit:

De spreker betoogt dat “de open source manier” een strategie is voor bedrijven om overstapkosten te verminderen en te voorkomen dat ze worden opgesloten door een dominante platformaanbieder. Hij geeft het voorbeeld van hoe Google en Microsoft open source gebruiken om te concurreren voor browser marktaandeel en verkeersacquisitiekosten. Hij contrasteert dit met de situatie van onafhankelijke taalontwerpers, die hoge ontwikkelingskosten en lage inkomstenmogelijkheden hebben, en die niet kunnen vertrouwen op dezelfde voordelen van open source als grote bedrijven. Hij suggereert dat open source geen haalbare optie is voor individuele taalcreators, tenzij ze een duidelijk bedrijfsmodel of een krachtige beschermheer hebben. Hij bekritiseert ook de onrealistische verwachtingen die gebruikers en gemeenschappen hebben van open source projecten, die vaak de economische realiteiten en uitdagingen negeren waarmee auteurs worden geconfronteerd.

[Reactie gewijzigd door Henk Poley op 23 juli 2024 17:08]

[The Zep Man]

MySQL -> MariaDB
OpenOffice.org -> LibreOffice
ownCloud -> Nextcloud
pfSense -> OPNsense
XenServer -> XCP-NG

En nu mogelijk Nginx -> Freenginx

Life is good wanneer een fork zich afsplitst vanwege ontevredenheid over de commercieel/zakelijk ingeslagen koers van opensource software, en de fork het goed doet. Door in te zetten op opensource software hou je deze mogelijkheid open, en krijg je niet dit soort situaties waarbij er geen gelijke vervanger is.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 17:08]

[pennywiser]

Terraform -> OpenTofu
OpenElec -> LibreElec

[The Zep Man]

OpenElec -> LibreElec

Dat is niet een fork die gemaakt is vanwege een commercieel ingeslagen koers. Toegegeven, LibreOffice was dat eigenlijk ook niet. Die werd volgens mij wel geforked vanwege zakelijke redenen. Ik heb daarom de omschrijving in mijn reactie verduidelijkt.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 17:08]

[pennywiser]

Oh moest dat, dit bericht zelf gaat namelijk over een conflict over security.

[The Zep Man]

Het was wat ik noemde in mijn eerste post. Maxim Dounin heeft een conflict met F5. Dat gaat over beveiliging, maar daar zit natuurlijk een reden onder. Daarom is het goed dat ik nu wat breder refereer naar "zakelijk", want het hoeft natuurlijk niet commercieel te zijn.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 17:08]

[Piemol]

Maar forks splitsen ook de communities, dus je kan daarmee flink inboeten aan slagkracht en/of ontwikkelsnelheid.

[The Zep Man]

Maar forks splitsen ook de communities, dus je kan daarmee flink inboeten aan slagkracht en/of ontwikkelsnelheid.

Zolang licenties compatibel zijn, kunnen veel zaken zonder problemen van elkaar overgenomen worden. Vaak is er een goede reden voor een fork, en volgt het belangrijkste deel van de community daarbij de fork.

[Keypunchie]

Terraform -> OpenTofu

[_Thanatos_]

Maps.ME -> Organic Maps

[Juris LLM.]

Ook een leuke:

paperless -> paperless-ng -> paperless-ngx

[_Pussycat_]

Ik kijk nog even de kat uit de boom en wacht op openpaperless-ngxlibre.

[Menthalion]

LXD > Incus

[Royale de Luxe]

Maar dan wel eerst allemaal langs de kassa passeren voor vele miljoenen en dan het niet eens zijn met bedrijfsvoering en de boel dan maar forken om dat het licentie systeem het toelaat.

Ik vind het toch allemaal een rare manier van zaken doen.

[The Zep Man]

Maar dan wel eerst allemaal langs de kassa passeren voor vele miljoenen

Als je verdient en (soms verplicht) bijdraagt aan opensource software, dan kan je verwachten dat ook anderen kunnen verdienen aan wat je geschreven hebt. Hate the game, not the players.

[mOrPhie]

Persoonlijk zou ik niet te snel naar FreeNginx kijken, want als het klopt dat het conflict is dat F5 een CVE had uitgegeven en Maxim Dounin vond dat die CVE niet uitgegeven had moeten worden, dan vraag ik mij af hoe dat straks gaat bij FreeNginx... Imho is het dus goed om naar alternatieven te kijken. Als je nginx als reverse proxy gebruikt, is https://caddyserver.com/ mogelijk een optie.

[pennywiser]

Of Apache mod-proxy (ProxyPass). Dit kun je gewoon naast je andere vhosts draaien.

[Reactie gewijzigd door pennywiser op 23 juli 2024 17:08]

[Eric Oud Ammerveld]

Er is een behoorlijk verschil in diepgang, kwaliteit en snelheid tussen apache proxy functionaliteiten en die van nginx, maar als je genoeg CPU's en geheugen over hebt kan het een alternatief zijn.

[pennywiser]

Niet meer sinds Apache 2.4. En tevens heb je geen htaccess flexibiliteit onder Nginx. Voor je dat als vertragend benoemt, je kan het uitzetten/weglaten. Geen htaccess was ook de belangrijkste reden waarom Nginx sneller dan Apache was.

Zie: https://en.wikipedia.org/wiki/Nginx onder "Nginx in comparison to Apache" en https://httpd.apache.org/docs/2.4/mod/mod_proxy.html

[Reactie gewijzigd door pennywiser op 23 juli 2024 17:08]

[Loekie]

Het zou niet de eerste developer zijn die een CVE op boilerplate of experimentele software te ver vind gaan en ergens ben ik het daar wel mee eens.
Zeker als je een proces hebt om dergelijke security-issues op te pakken en op te lossen.
Een CVE is voor ons bij bedrijven makkelijk om verantwoordelijkheid af te leggen of af te schuiven, maar het oplossen daarvan is voor de leverancier. Op een CVE staat natuurlijk meer druk dan op een normale bug en als het niet in productie gedraaid hoort te worden is de vraag of het hele proces van een CVE deponeren wel echt helpt een issue op te lossen.

Het zal een interessante fork zijn, maar zal zich, net als nginx vroeger, nog moeten bewijzen dus we zien het over een jaar wel.

[_Thanatos_]

Wat ik dan weer mis aan dit soort berichten, is de in-depth. Wat was er precies aan de hand? Wat doet Freenginx beter dan Nginx? Maar ook andersom? Hoe belangrijk is het om je eigen projecten ernaar om te zetten (vooral ook al die dockers/containers die tegenwoordig met nginx worden gebouwd)? Moeten we migreren naar Apache? Wat is de impact voor Jan Modaal?

[Deguchi]

Volledig terechte vragen, maar ik denk dat het gewoon te kort dag is om op de meeste daarvan te kunnen antwoorden.
Dit nieuwsbericht komt niets meer zeggen dan: hoofdontwikkelaar stopt bij F5 en begint eigen fork.
Dat is letterlijk het hele nieuwsbericht.

Het kan interessant zijn om dit binnen een jaar op te volgen met een meer in-depth technisch artikel en zien wat/of er verschillen zijn en vooral ook welke weg F5 nu gaat inslaan. Maar daar is het vandaag dus gewoon te vroeg voor.

[_Thanatos_]

Als ik het nieuwsbericht goed begrijp, dan "speelt" dit al sinds ergens in 2022, dus vandaar dat ik er wel vanuit ging dat er meer informatie beschikbaar zou moeten zijn.

Maar dat is niet erg - ik hoop alleen wel dat T.net een followup kan plaatsen, desnoods in een langer artikel ipv een nieuwitem.

[AntoonH]

Zeker. Maar verwacht niet dat F5 input gaat geven op behoorlijk persoonlijke redenen voor een fork. Zeker de “corporate” redenen om uit Moskou te vertrekken destijds en hoe dat gegaan is zal F5 geen energie aan besteden, al was het maar omdat het geen uitspraken zal doen over de personen aldaar.

[graey]

De impact voor Jan Modaal is een beetje een moeilijke vraag, Jan Modaal heeft nu ook geen enkel idee wanneer hij gebruikmaakt van Apache of NGINX.

Verder is de impact op korte termijn beperkt: NGINX heeft best hoge marktpenetratie, dus de komende tijd zullen voorvallen waarin management tegen kundig advies van developers toch (onnodige) security warnings uitgeven nog steeds dezelfde impact hebben.

Als op termijn iets als FreeNGINX net zo actief ontwikkeld wordt en in ieder geval feature parity houdt, en daarnaast minder onnodige waarschuwingen uitgeeft én even goed of beter presteert op veiligheidsvlak, dan gaan devops-mensen wel heroriënteren. Maar dat is gewoon wel een proces van jaren. En zelfs dan merkt Jan Modaal er niks van, gok ik.

[pennywiser]

Het probleem aan dit soort berichten is dat totaal niet duidelijk is waarom. Zie 3e alinea.

Ik denk ook dat op gegeven moment "Nginx" helemaal uit de naam zal moeten verdwijnen. Kan me niet voorstellen dat dat wordt toegelaten.

En gelukkig Apache is nog steeds Apache.

[Reactie gewijzigd door pennywiser op 23 juli 2024 17:08]

[Greetoz]

Hopelijk ondersteunt FreeNGINX wel exchange autodiscover. Daarvoor moet je op dit moment een betaalde licentie bij NGINX afnemen, jammer want daardoor kan ik thuis geen reverse proxy draaien, alhoewel de noodzaak steeds verder afneemt met IPV6

[hachee]

Idem met UDP support, en het gedoe met modules als rtmp met alle ongemakken wat dan dat handmatige gedoe brengt als je geen deployment tools in gebruik hebt die dat voor je kunnen doen.

[mafl]

Een meer of mindere manifestatie van https://xkcd.com/927/