E-boekenorganiseersoftware Booklore is offline na opensourcedrama en vibecode

De populaire opensourcetool Booklore is offline. Booklore maakte het mogelijk om e-boeken te beheren in een eigen omgeving, maar de dienst ging ten onder aan drama onder de ontwikkelaars en ruzies over AI-code in de repo. Inmiddels is er een fork die de dienst moet vervangen.

Wat is was Booklore?

Booklore was software om e-boekbibliotheken te beheren. De tool bood een visuele omgeving, waarin het mogelijk was boeken op metadata te ordenen. De voordelen ervan waren dat de tool opensource beschikbaar was en de Docker-image te hosten was. Grimmory belooft hetzelfde te doen en te kunnen als Booklore.

De Docker-image voor Booklore is inmiddels offline, waardoor de tool in zijn geheel niet meer te downloaden is. Ook de website en Discord-server zijn offline.

Het is onduidelijk wat precies de oorzaak is van het verdwijnen van Booklore. De ontwikkelaars noemen verschillende redenen, waaronder dat een van de ontwikkelaars van het project weggelopen is. Maar er was ook veel drama onder de ontwikkelaars. Een van de hoofdontwikkelaars stelde zich autoritair op en steggelde over de gebruikte opensourcelicentie. Ook vermoedden veel gebruikers dat de code grotendeels door AI werd geschreven, wat Booklore overigens ontkende.

Inmiddels is er een fork gemaakt van de tool: Grimmory. Die staat onder andere bij Tweakers in de meuktracker. Grimmory lijkt in veel opzichten op Booklore en maakt het mogelijk boeken te lezen en te ordenen. Bijkomend voordeel is dat het volgens een tweaker met praktijkervaring alleen nodig is om de naam van Booklore naar Grimmory te vervangen in de Docker Compose-bestanden om te migreren.

Reacties (32)

[Sebazzz]

Ook vermoedden veel gebruikers dat de code grotendeels door AI werd geschreven, wat Booklore overigens ontkende.

Nou het gaat wel wat verder:

• People submit real PRs. They sit for weeks, sometimes months. Then the dev uses AI to reimplement the same feature and merges his own version instead. Predictably, this pisses people off. At the time of writing this, the main dev has alienated almost all of the contributors that were regularly supporting, triaging issues and doing good work on features and bugfixes.
  When called out, he apologizes. Except the apologies are also AI-generated. And more than once he forgot to strip the prompt, so contributors got messages starting with something like "Here's how you could apologize—"
• The dev is merging 20k-line PRs almost daily, each one bolting on some new feature while bugs from the last one go unfixed. And the code itself is a giveaway: it uses Spring JPA and Hibernate but is full of raw SQL everywhere. Anyone who actually built this by hand would keep the data layer generic. Instead, something like adding Postgres support is now a huge lift because of all the hardcoded shortcuts. That's not a style preference, that's what AI-generated code looks like when nobody's steering.

[Umbrah]

Eigenlijk is dit weer een casus die zowel vóór als tegen AI is (waarbij dit eigenlijk vooral een casus tegen is, waarbij een lead dev bovendien nogal wat mensen-problemen heeft waarvoor ik niet bevoegd genoeg ben om te oordelen maar lijkt mij mogelijk dat zo'n iemand andere hulp nodig heeft)...

• In de handen van een goede developer kan het een enorme versnelling zijn als een soort aggregator/task maker/boilerplate generator
• In de handen van een slechte developer (en ik beargumenteer dat ik goed/slecht misschien ook in termen als "ambitie/lui" of "junior/senior" kan uitdrukken -- er is een multidimensionaal spectrum hier) kan het erg gevaarlijk zijn, waarbij bepaalde architectuurbeslissingen waar vanuit gegaan wordt in de gehele code genegeerd worden omwille van iets er aan plakken (zie je heel vaak in de web-wereld waar toepassen van alembic/sqlalchemy voor migratie van backend api zaken op echt datamodellen soms ineens genegeerd wordt) niveautje "snel snel snel", waarbij dingen als "geen tijd" of "geen zin" (ik had altijd user based access, m'n app moet nu ook role based access, hey chatbot, maak ff een OIDC integratie en lijm "groepen" aan m'n app waarbij gebruikers lid mogen zijn van een groep) kan het ronduit chaotisch zijn, puur omdat zowel chatbot (die onthoud immers max 258k tokens of zoiets dus kan nooit een hele applicatie, én architectuur, én de schat aan docs over de gebruikte API's in geheugen houden) kunnen zorgen voor ronduit gevaarlijke situaties.

Eigenlijk denk ik dat in de handen van een senior het net zo'n soort evolutie is als toen we van webpagina's in notepad bouwen naar frameworks en IDE's gingen. Best spannend. In de handen van een junior is het gevaarlijk. Maar dat maakt de arbeidsmarkt ook risicovol, want hoe kan iemand ervaring opdoen? Commerciële devs hebben nu al de vraag of ze productiever willen worden (coding is een van de plekken waar AI wél nuttig kan zijn) -- wat soms ook gewoon werkt (vaak ook niet), waardoor er met minder mensen meer werk kan worden gedaan.

Tel daarbij de wereldeconomie, oorlogen, en de rampocalypse... en nieuwe devs vinden niet alleen geen werk, maar ze kunnen ook minder zelf leren of uberhaupt hardware betalen... wat ironisch is want een LLM met 258k tokens "geheugen" voor de senior dev die in z'n eentje nu 4 man werk doet (en mogelijk minder resultaat levert) heeft ENORME hardware nodig (alleen verstoppen we het in hyperscalers die niet kostendekkend zijn, zelfs niet met de $200/maand abo's)

[Reactie gewijzigd door Umbrah op 23 maart 2026 08:59]

[divvid]

helemaal gelijk in. Hier zie je het nog 'out in the open' gebeuren als je uit het "raam" kijkt , maar gezien de staat van sommige commerciële software denk ik dat dit soort drama ook op de werkvloer gebeurt.

Persoonlijk heb ik veel baat bij AI, vooral als hulpje bij het vinden van de juiste aanpak. Het blijft alleen wel noodzakelijk om de manuals te blijven checken en alles dubbel te controleren.

[cheersmate]

Het ligt toch nog echt wat genuanceerder, zoals ook blijkt uit wat er over de kwestie is gesteld:

And the code itself is a giveaway: it uses Spring JPA and Hibernate but is full of raw SQL everywhere. Anyone who actually built this by hand would keep the data layer generic. Instead, something like adding Postgres support is now a huge lift because of all the hardcoded shortcuts. That's not a style preference, that's what AI-generated code looks like when nobody's steering.

De code die AI kan genereren kan op een heel hoog niveau zijn, maar op dit moment moet AI nog wel enorm worden bijgestuurd. Vergelijk het met elektrisch gereedschap. Daar kun je enorm snel, veel mee bereiken, maar het moet wel met beleid worden gebruikt. De schade die er mee kan worden aangericht is anders nog vele malen groter.

[StefanJanssen]

Als software developer die begon met programmeren voordat hij 10 was en dus meer dan 20 jaar ervaring heeft kan ik zeggen dat elke keer als AI in mijn workflow gestopt wordt ik minder effectief werk.

Zelfs dingen waar een AI goed in zou moeten zijn als boilerplate code doe ik 9 van de 10 keer sneller met live templates, regexes en/of multi cursor editing (ten opzichte van als ik zelf of als iemand die AI dagelijks gebruikt)

Juist voor ervaren ontwikkelaars met een goede workflow zie ik nul meerwaarde voor AI. Zelfs als het voor bepaalde dingen iets sneller is zie niet hoe misschien een uurtje tijdswinst het afweegt ten opzichte van alle negatieve effecten van AI.

[P_Tingen]

Ook gezien bij de klant waar ik zit. Daar moeten we een optimalisatieprogramma maken voor een machine in de fabriek, wat vrij complex is, dus is er met AI een proof-of-concept gemaakt. Alleen, die werkte prima! Dus werd er al snel gezegd: niks meer aan doen & implementeren. Ik ben ervoor gaan liggen (voor zover mogelijk, ik ben ook maar ingehuurd) met als argument dat die code er heel anders uitziet dan hoe wij normaliter programmeren. En aangezien programma's minstens 100x vaker worden gelezen dan geschreven, is het wel verstandig code te hebben die je zelf begrijpt.

Men wilde er niet aan, want "als het werkt, dan werkt het". Tot een van de eigen ontwikkelaars het programma ging aanpassen om het te koppelen aan onze eigen omgeving, dus data lezen uit onze eigen db, optimaliseren en terugschrijven. Hij kwam er niet lekker uit omdat - insert tromgeroffel - de code slecht te volgen was omdat het haaks staat op hoe wij zelf ontwikkelen.

Nu gaan we het gebruiken zoals het bedoeld is: als proof of concept en inspiratiebron

[Reactie gewijzigd door P_Tingen op 23 maart 2026 10:42]

[ChrsL]

Dit is waar ik ook op de vloer tegenaanloop. Terugduwen totdat code echt beheersbaar en leesbaar is zoals een mens dat zou doen.

AI kiest voor alles het beste pad uit, maar dat is niet altijd hoe wij als mens functioneren. Tenminste, met hele andere context, waaronder beheersbaarheid, en vast wel meer.

[olafmol]

Interessant en geeft goede context. Het is best boeiend om te zien hoe AI en/of het "AI excuus" bestaande problemen in processen en organisaties mooi blootlegt

[iqcgubon]

Het is volgens mij wel vrij duidelijk wat de oorzaak is.

PSA: Think hard before you deploy BookLore : selfhosted

Main dev is een absolute kloothommel. Steekt telemetry in het product en probeert het onder de mat te vegen (checkbox om telemetry te disablen doet helemaal niks). Negeert PRs om de code dan maar zelf te schrijven/laten schrijven. Wilde na de feiten de license aanpassen (kan helemaal niet zomaar). Begon te janken dat mensen "zijn code stelen" omdat ze forks maken. Wilde een betaalde app introduceren, helemaal zijn volste recht, maar schroefde ook de local API volledig dicht om te verhinderen dat anderen zelf apps zouden ontwikkelen. Heeft lang ontkent dat er AI gebruikt werd maar deed wel PRs van 20k lijnen code waar toevallig nog verwijzingen naar Claude in zaten. Verwijderde de Discord, verwijderde de repo, begon dan te bleiten op reddit dat hij slachtoffer was van "targetted attacks".

Zijn nog wel wat redenen te vinden in die thread trouwens. Dus dit is echt geen donderslag bij heldere hemel lol.

[buglife]

Afsplitsingen komen regelmatig voor bij opensourceprojecten. Dat is ook wel een voordeel van opensource. Als jij denkt dat het beter kan, kan je suggesties aandragen, maar als dat niet wordt opgepakt kan je er, afhankelijk van de gebruikte licentie, ook zelf gewoon mee verder gaan.

Booklore kende ik zelf nog niet. Ik gebruik Calibre om mijn bibliotheek te beheren. Binnenkort Grimmory eens een kans geven. Het ziet er veelbelovend uit.

[lenwar]

Als jij denkt dat het beter kan, kan je suggesties aandragen, maar als dat niet wordt opgepakt kan je er, afhankelijk van de gebruikte licentie, ook zelf gewoon mee verder gaan.

Dit is natuurlijk wel een heel geromantiseerd beeld 😊. Het vereist ook dat je het ‘kan’ (als in programmeren op een bepaald niveau), en er tijd voor hebt.

[buglife]

Dat is zeker waar, maar ik had ook niet gezegd dat het gemakkelijk is. Gelukkig kan ik wel wat qua programmeren en heb er de tijd voor. In het verleden best wel wat projecten geforkt en weer nieuw leven ingeblazen. Om ze vervolgens ook weer te laten verslonzen omdat ik het zelf niet gebruik.

[lenwar]

In het verleden best wel wat projecten geforkt en weer nieuw leven ingeblazen. Om ze vervolgens ook weer te laten verslonzen omdat ik het zelf niet gebruik.

En dit is dan weer tegelijk een zwakte van Open Source. Want dit gebeurd ook heel vaak. Uiteraard niets negatiefs naar de mensen die met alle goede intentie ergens aan beginnen. Dat is 100% kudo's, maar op een gegeven moment wordt het 'werk' (iets maken is leuk, maar iets onderhouden, en vervolgens al die vervelende IWABs die alleen maar tegen je aan kunnen zeuren, en wat je allemaal verkeerd doet (als in dat zij het anders zouden doen.)) Dan is de motivatie natuurlijk als snel minder. (En terecht!!) En dan krijgen we 'nog meer' niet/slecht onderhouden dingen.

Uiteindelijk is software iets waar je van op aan moet kunnen. Het ene product is essentieler dan het andere natuurlijk

[Robbaman]

Ach nee joh, met AI kan toch iedereen programmeren 🤣

[Piet Zaman]

Ik gebruik ook Clibre. Mis daar eigenlijk niks aan :-) Lekker portable...

[friket]

Helaas zie je dit wel vaker bij opensource projecten, ontwikkelaars die elkaar de tent uitvechten. Voordeel is dan wel weer dat iemand anders het werk weer onder andere naam voortzet.

[iAR]

Fijn dat het werk voortgezet wordt. Ik vind het een fijne tool.

Maar het is toch ongebruikelijk om je hele repo te verwijderen!?

[drake7707]

De Grimmory developers zijn dezelfde contributors van Booklore, maar zonder Booklore developer dus eigenlijk is het hetzelfde team.

Ik denk nu de drempel om software te ontwikkelen veel lager is door AI dit nog wel vaker zal voorkomen, dat zijn dan voornamelijk mensen die eigenlijk weinig van de development cyclus en samen werken met anderen afweten en al dan niet vibe coden voor populariteit en/of macht/controle, met het gevolg dat bij de minste (constructieve) kritiek hun impostor syndrome and onzekerheid van geen "echte" developer te zijn de overhand neemt en ze in volle paniek de boel verwijderen zoals Booklore of Huntarr. Ik volg al een tijdje de selfhosted subreddit en ik merk dit gedrag steeds vaker voorkomt, voelt een beetje als tieners op de speelplaats... jammer genoeg.

[thomas_n]

Helaas zie je dit wel vaker bij opensource projecten, ontwikkelaars die elkaar de tent uitvechten. Voordeel is dan wel weer dat iemand anders het werk weer onder andere naam voortzet.

Bij gesloten projecten komt dit natuurlijk net zo goed voor, alleen is het dan niet publiek. En heb je inderdaad niet de vluchtweg van een fork.

Een goed opgezette organisatiestructuur kan voorkomen dat het zo erg misgaat als hier, maar dat is helaas zowel bij gesloten als open softwareontwikkeling lang niet altijd het geval.

[zierbeek]

Huntarr is op vergelijkbare manier ten onder gegaan

[Oon]

Ik ken Booklore niet, maar Huntarr was dan ook wel een echt gevibecode app, dus vol enorme security issues en niet te volgen wat er allemaal gebeurde.
AI is leuke voor een kleine fucntie of het voortzetten van een patroon, maar is nog láng niet klaar om dergelijke apps zonder enige sturing op te zetten

[The Zep Man]

Een van de hoofdontwikkelaars stelde zich autoritair op en steggelde over de gebruikte opensourcelicentie.

Booklore (samen met fork Grimmory) valt onder AGPLv3 zonder verdere ongewenste voorwaarden zoals een contributor license agreement. AGPLv3 is een licentie die goed voor opensource-ontwikkelaars en eindgebruikers is.

Als de geciteerde tekst klopt, dan is dat een rode vlag die een fork legitimeert. Het kost veel moeite om licentievoorwaarden te veranderen van een FLOSS-project waar anderen bijdragen aan leverden, en het is onwaarschijnlijk dat het resultaat in het voordeel is van ontwikkelaars en eindgebruikers.

Gemorrel met licenties hebben we eerder gezien met Redis, dat binnen Linuxdistributies ondertussen vervangen is met fork en drop-in replacement Valkey. De les daaruit is simpel: bedenk voordat je een project start welke licentie je vindt passen bij je langetermijnvisie. Misbruik FLOSS niet om in een vroeg stadium populariteit te winnen, want je betaalt later een prijs.

[ajbu]

Bijkomend voordeel is dat het volgens een tweaker met praktijkervaring alleen nodig is om de naam van Booklore naar Grimmory te vervangen in de Docker Compose-bestanden om te migreren.

het gaat hier om het vervangen van de grimmory/grimmory verwijzing naar de Docker image. Dus image: booklore/booklore:latest wordt image: grimmory/grimmory:latest.

[DikkieDick]

Hmm... Booklore niet al te lang geleden geïnstalleerd op mijn NAS. Ziet/zag er veelbelovend uit. Begreep wel dat na een laatste update er heel veel wijzigingen waren waardoor ook de database vernaggeld kon raken dus die had ik ook nog niet geïnstalleerd. Voor het beheer gebruik ik toch nog steeds Calibre. Op zich volstaat dat ook en soms even handmatig wat boeken op de e-reader zetten. Misschien binnenkort maar weer eens een poging wagen met Grimmory. Maar prio is bijzonder laag.

[rens-br]

Ik gebruik zelf Calibre, via calibre web automated en dat werkt ook erg goed. Er zit ook Kobo sync op, waarmee je direct vanuit je kobo boeken kan downloaden, ideaal.

[Wienen]

👆🏻 Dit idd 😁

[iqcgubon]

Ik was eigenlijk net van CWA overgestapt om ik geen fan ben van het calibre-database systeem. Metadata syncing werkte eigenlijk naar mijn gevoel ook veel beter in Booklore, en die deed ook native kobo sync. Dus het was wat mij betreft wel een heel goed alternatief. Heel jammer van alle drama.

[vanhooijdonk]

Oh shoot.