# Do Flamingos Know They're Pink > Articles about how technology works, who it serves, the systems around it, and what it all costs. Digital sovereignty, open source governance, and internet rights. Public Ghost content for AI and LLM tooling. This file includes a bounded export of public pages first, then recent public posts. Append `.md` to any post or page URL to get the content in Markdown (for example, `/example-post.md`). ## Pages ### About this Blog URL: https://tarakiyee.com/about/ Last updated: 2026-09-09T19:54:10.000Z I'm [Tara](https://tarakiyee.com/author/). Do Flamingos Know They're Pink is a personal blog about technology, the systems around it, and what it all costs. The name came to me in a dream. It's the kind of question I keep circling back to: how much do we understand about the systems we're embedded in? Do the tools we build shape us in ways we can't see from the inside? Flamingos aren't born pink, they become pink gradually due to their diet. This blog has been around in some form since the early 2010s. It started as dispatches from the Jordanian tech and blogging scene, went quiet for years, and came back different. The internet changed, and so did I. The internet I used to write about never really existed in the first place. But the impulse to write about it persists, and here we are. The blog covers whatever I'm thinking about: digital sovereignty, open source governance, internet rights, infrastructure, creative writing, the occasional rant. I'm interested in how technology works, who it serves, and what happens when those aren't the same question. Current series: **\*\*Autonomous Stack\*\***, an account of migrating my entire digital life from proprietary services to self-hosted infrastructure. Another internet is possible. This is one attempt to build a small piece of it. Blog cover photo is licensed under the [Creative Commons](https://en.wikipedia.org/wiki/en:Creative%5FCommons?ref=tarakiyee.com) [Attribution-Share Alike 3.0 Unported](https://creativecommons.org/licenses/by-sa/3.0/deed.en?ref=tarakiyee.com) license.Attribution: Thomas Wolf, [www.foto-tw.de](http://www.foto-tw.de/?ref=tarakiyee.com) ### About the Author URL: https://tarakiyee.com/author/ Last updated: 2026-09-09T19:56:12.000Z I'm Tara Tarakiyee, a public interest technologist based in Berlin and a supporter of human rights, a free and open internet, and open source software. My work sits at the intersection of technology and society: helping protect those most vulnerable to surveillance and censorship, and unlocking the potential of information technology as a tool for liberation rather than control. I've managed projects enhancing internet access and digital security, helped essential open source privacy tools gain funding, led advocacy campaigns against online censorship, and conducted research on surveillance infrastructure and policy. I've had the pleasure of working with organizations including the Jordan Open Source Association, which I co-founded, the Association for Progressive Communications, and the Open Technology Fund. At the Sovereign Tech Agency, where I've been since the start, I designed, built and led Sovereign Tech Resilience and co-designed the Sovereign Tech Standards network. Two decades in, I've stopped thinking openness is enough. A licence guarantees you can use, study, modify and redistribute. It guarantees nothing about who gets to decide, and decision-making accrues to whoever contributes most. I sit on Quad9's Privacy, Equity and Human Rights Council, the W3C Advisory Committee, and I've been part of the Public Interest Technology Group since 2017\. I've spoken at SSTIC, RightsCon, FOSS Backstage and the Open Source Summit Europe, helped organise the funding devroom at FOSDEM, and I take part in the IETF. I also perform art as Terrabyte. You can reach me by email at me \[ a/t \] tarakiyee.com and follow me on [Mastodon](https://mastodon.online/@tarakiyee?ref=tarakiyee.com). More about [what I work on](https://tarakiyee.com/work/). ### Privacy Policy URL: https://tarakiyee.com/privacy-policy/ Last updated: 2026-02-22T20:39:26.000Z **Cover Image:** Licenced CC-BY-SA 3.0 [Laitr Keiows](https://commons.wikimedia.org/wiki/User:Laitr%5FKeiows?ref=tarakiyee.com) **Last updated:** 22 February 2026 ## Who I am This is a personal blog operated by Tara Tarakiyee, based in Berlin, Germany. You can reach me at [me@tarakiyee.com](mailto:me@tarakiyee.com). ## Analytics This site uses Umami, a self-hosted, open-source analytics tool. Umami is designed to be privacy-preserving: - No cookies are used. No data is stored in your browser. - No personal data is collected. Your IP address is used to derive an approximate country but is never stored, logged, or shared. - No cross-site tracking. Your activity on this site is not linked to your activity anywhere else. - No fingerprinting. Visitors are not uniquely identified across sessions. The data collected is limited to: page URLs visited, referrer URL, browser type, operating system, device type, and approximate country. All data is aggregated and anonymous. There is no way to identify individual visitors. Analytics data is processed on infrastructure I own and operate (a server in Nuremberg, Germany). No data is sent to third parties. **Legal basis:** Legitimate interest (Art. 6(1)(f) GDPR). I have a legitimate interest in understanding how my blog is read in aggregate. This processing is minimal, anonymous, and does not affect your rights or freedoms. ## Hosting This site is hosted on a virtual private server operated by Hetzner Online GmbH in Nuremberg, Germany. Their privacy policy is available at [hetzner.com/legal/privacy-policy](https://www.hetzner.com/legal/privacy-policy/?ref=tarakiyee.com). ## Server logs Some administrative services on the same server log IP addresses, timestamps, and requested URLs for the purpose of intrusion detection and security. These logs are separate from blog visitor analytics and do not contain blog traffic data. IP addresses are personal data under the GDPR. The legal basis for this processing is legitimate interest (Art. 6(1)(f) GDPR) specifically, the need to detect and respond to unauthorized access or abuse of my infrastructure. I consider this interest proportionate given that the logs are minimal in scope, not used for any other purpose, and retained only briefly. Server logs are rotated by size. ## Your rights Under the GDPR, you have the following rights regarding your personal data: - **Right of access** (Art. 15) — to obtain a copy of any personal data held about you. - **Right to rectification** (Art. 16) — to correct inaccurate personal data. - **Right to erasure** (Art. 17) — to request deletion of your personal data. - **Right to restriction of processing** (Art. 18) — to limit how your data is processed. - **Right to data portability** (Art. 20) — to receive your data in a structured, machine-readable format. - **Right to object** (Art. 21) — to object to processing based on legitimate interest. - **Right to lodge a complaint** — you have the right to lodge a complaint with a supervisory authority. The relevant authority for this site is the [Berliner Beauftragte für Datenschutz und Informationsfreiheit](https://www.datenschutz-berlin.de/?ref=tarakiyee.com). Since this site does not collect or store personal data beyond temporary server logs, there is typically nothing to request. If you have questions or concerns, or wish to exercise any of these rights, contact me at [me@tarakiyee.com](mailto:me@tarakiyee.com). ## Changes I may update this policy if the site's data practices change. The "last updated" date at the top will reflect any changes. ## Posts ### Open Source Is Indefensible URL: https://tarakiyee.com/open-source-is-indefensible/ Last updated: 2026-07-28T22:57:31.000Z On the 22nd of July, the members of Codeberg e.V. voted to stop hosting projects that "mostly consist of code written by 'generative AI'-tools." Another motion passed committing the association never to use hosted code or user data to train models. [The blog post explaining it](https://blog.codeberg.org/protecting-our-floss-commons-from-llms.html?ref=tarakiyee.com) doesn't lead with freedom or with ethics, it leads with the price of a solid state drive: they bought one for about €700 a few years ago and it now costs them about €3,700\. Let's dig into what that means, because many of the reactions I've seen seem to get it wrong. They didn't change a licence. The members of the association that operates Codeberg changed the terms under which Codeberg is willing to host your code. The Open Source Definition governs licences, and clauses five and six constrain what a licence may say about who gets to use software and what for. It doesn't say anything about being forced to host all open source code. I find it very interesting why so many people feel like a rule had been broken when none had been. The rule exists inside the licence: you may not say no to anyone in particular. Conditions are fine sometimes, copyleft is proof of that, but not refusing a use, or a party, and attempts to put that kind of refusal into the licence itself have consistently fallen outside the FOSS boundary, whether that was the SSPL imposing special conditions on offering software as a service, ethical licences restricting harmful or military uses, or RAIL licences naming categories of use. Outside a licence, where the Open Source Definition has nothing to say, it seems like saying no is treated as though it were prohibited anyway. Codeberg updated its Terms of Use and [got called a censor for it](https://xn--gckvb8fzb.com/i-regret-migrating-to-codeberg/?ref=tarakiyee.com). So there is a place where saying no is against the rules, and a place where saying no is not against the rules but you'll be treated as though it were. It seems like what is being refused is the ability to say no. What Codeberg used is a freedom that was always available to all of us. Codeberg is infrastructure held and governed by an association whose members have decided what their shared resources are for. And I think that's the answer to why so many people felt a rule had been broken: a constraint written for licence text became, somewhere along the way, a constraint on who we were permitted to be, and we've been enforcing it on ourselves in places it never had any authority. We're used to reading FOSS as an opposition, and its history makes it seem like it is. But let's examine what a licence does. It doesn't oppose, it disposes. An open source licence is a standing grant made in advance, to persons unknown, for purposes unspecified, without any expectation that they return to ask whether this particular use is acceptable. Openness is a posture of permanent availability. [Openness is not neutral](https://tarakiyee.com/foss-is-more-than-just-licences/). The thing a disposition can't do is establish a relationship by itself. We built the relationships despite the disposition, and for a long time openness still came with friction. Taking code at scale meant understanding it, integrating it, maintaining it, and employing people who knew something about the communities it came from. That never guaranteed reciprocity, but it made complete detachment difficult. Then something arrived that could take all of it at once while bypassing much of the labour that had made the FOSS community structurally relevant. Freedom zero isn't what legally makes model training possible, but the open source tradition did deliberately construct software as something whose downstream use would not require renewed permission from its authors. Non-discrimination is part of what guarantees that the licence cannot withhold those freedoms from a particular recipient because of who is asking or what field they work in. Copyleft is the counterexample, yet it doesn't reach far enough. The GPL is still a disposition, only with conditions attached, and those conditions principally bind people when they redistribute or convey covered software. But LLM training doesn't map neatly onto that trigger. A model trained on GPL code is not automatically a covered derivative work merely because that code was somewhere in the corpus. It's a defence built against one specific enemy hailing back to the 80s, the proprietary fork. But in 2026 the extraction doesn't need to fork the commons at all. There's an interesting asymmetry in the four freedoms. They protect the user from the developer's power, and there's no matching freedom protecting a developer from a user precisely when that user is exercising those freedoms correctly. A defence here is needed, but it has to come from somewhere else. Back to Codeberg, the easy reading would be that they built a fort, and conclude the commons needed a wall all along. But a fort is defined by what it keeps out. An association is defined by what it holds together, and it needs an edge for the same reason any commitment needs one, which is that you can't be obliged to everybody. [Gardens, not roads](https://tarakiyee.com/gardens-not-roads-cultivating-open-source-communities/), as I've put it before: a garden has a gardener and a boundary. Free association has never meant association with everyone on demand. It has included [the freedom to decide who you're doing this with](https://tarakiyee.com/fork-it-or-walk-away/) and on what terms. Nothing in the FOSS definitions ever required us to give that up, so let's stop pretending there was some sort of betrayal of values here. Maybe the mistake was expecting licences to do political work they were deliberately designed not to do. Open Source is indefensible, but maybe it's also not where we build our defences. We don't need to defend the freedom to take from everyone all the time. Our freedom to associate, our freedom to refuse, and our freedom to decide over [infrastructure we reasonably control](https://tarakiyee.com/i-get-no-ideas-inside-the-machine/) all need defending though, and all of that is outside the jurisdiction of licences and code. Thank you Codeberg for reminding us it was there all along. I'd like to hear from people who host things and pay for SSDs and have had to make one of these calls, which is [a thing I've been doing myself lately](https://tarakiyee.com/why-im-doing-the-autonomous-stack-series/) and finding harder than the writing. What did you have available to you, and what did it cost? ### Fork It or Walk Away URL: https://tarakiyee.com/fork-it-or-walk-away/ Last updated: 2026-07-15T22:37:07.000Z "Fork it" sounds like a generous invitation. The code is open, after all, so take it, copy it, and finally build the perfect version you keep insisting should exist. The right to fork is such a fundamental tenet of open source. It just so happens that invoking it often results in ending a conversation. In his book *Governable Spaces*, Nathan Schneider outlines an internet shaped by "implicit feudalism", essentially platforms organized around administrators with near-absolute authority over their domains. The primary check on bad rule is not democracy within the domain but competition between domains. If you do not like this lord, you can simply move to another fiefdom, and find a better benevolent dictator for life. Behind Schneider's argument is Albert Hirschman's *Exit, Voice, and Loyalty*. In it he describes what people do when an institution begins to fail them. They can leave, or they can speak, or just stay out of loyalty. The choices impact each other, for example when leaving becomes easier, fewer people may remain to complain, and the institution may feel less pressure to change. An institution that wants silence can bar the doors, or it can also hold them wide open. Open source by definition keeps the door wide open, legally to boot. But a fork only gives you the code. An open source project is more than its code, it's the sum of its maintainers, infrastructure, trademarks, dependencies, and trust. You can copy the code in seconds, the rest you would need to rebuild from scratch in most cases. The people invoking the right to fork already know this. In the short story "The Ones Who Walk Away from Omelas," Ursula K. Le Guin writes about a city of impossible happiness whose joy depends on a child kept alone in a filthy basement. Everyone knows the child is there, some have even seen the child. A few citizens, after seeing the child, leave the city and never return. We don't know if their departure changes anything, all we know is that Omelas remains, and the joy continues. No one carries the child into daylight or organizes to challenge the imprisonment. The Omelas is the story of a society explaining to you what it values through the exits it provides, and through the exits it refuses to imagine. Omelas has an open gate for the conscience, and a locked door for the child in the basement, and no one using their voice. In open source, you can fork it. You can build another city, but one without the people, joy, or festival. Sometimes that is worth the effort, so we cherish that freedom to fork. Or you can walk away, create a distance between you and the injustice, while the injustice remains. Not ideal, but you can't change everything. But we also have the technology of using your voice. Dissent is a tool, like the other tools we use. Don't let anyone use "fork it" as a euphemism to point at the door. We don't live in the fucking Omelas and we don't bow to kings and lords. ### An Afternoon of Tedium as an Exit Tax URL: https://tarakiyee.com/an-afternoon-of-tedium-as-an-exit-tax/ Last updated: 2026-07-14T21:41:23.000Z Of all the data I moved this year, you probably wouldn't guess what I procrastinated on the longest. Eighty-five thousand emails? Easy. Twelve thousand photos? No problem. Six hundred and seventy documents? Straightforward export. I even made sure everything existed in at least two places. If the entire self-hosted stack were to implode tomorrow, I wouldn't lose anything truly irreplaceable. Recovery would be tedious, but possible. The thirteen two-factor secrets in Authy were the exception. For the longest time, they existed in exactly one place, and extracting them turned into the most boring afternoon of the entire migration. And I couldn't afford to keep putting it off, if I lost my phone or it died, getting back into my accounts would be far worse than tedious. To understand why losing a TOTP seed can be worse than losing a password, it helps to understand how they work. Passwords have recovery paths. You click "forgot password," get a reset link, pick a new one. Annoying, but who amongst us had not had to reset a password. A TOTP seed is different. It's a shared secret, essentially a key that both you and the service hold to generate the same six-digit code at the same moment. When you scan that QR code during setup, you are seeing the only copy you will ever get. Lose it, and the service cannot show it to you again. Your only way back is to prove your identity through some other channel and disable two-factor entirely. Some services offer backup codes. In theory, they solve this problem. In practice, I have never once managed to use them correctly. Ergonomically, they are a mess. Wouldn't it be better to export and back up TOTP seeds securely? Authy, which is owned by Twilio, offers encrypted cloud backups protected by a PIN. For some people, that's enough. For me, trusting Twilio with my TOTP seeds offended my sovereign sensibilities. Unfortunately, they offer no alternative export mechanism. A decision I made over a decade ago quietly locked me in. This isn't a limitation of TOTP itself. It's a decision by Twilio. TOTP is an open standard, defined in RFC 6238, created specifically to avoid proprietary 2FA systems. Any compliant app can generate the same codes from the same seed. The protocol should be portable by design. Authy takes that portable protocol and makes it non-portable in practice. If you ask, they'll probably say it's for your security: seeds that can't be exported can't be stolen via export. It's the same argument every walled garden makes. I don't buy it. I don't want a service that treats me as an adversary of myself, only I am allowed to do that. When it came time to migrate, I looked into extracting my data. Community workarounds exist, but they involved patched apps and felt risky. Installing modified builds on my phone that I couldn't fully trust to handle my secrets would defeat the point. So I sighed, procrastinated for a couple of weeks, and then decided to get it out of the way. For each of the thirteen accounts, I had to: 1. Enter the password 2. Enter the current Authy code 3. Log in 4. Navigate to security settings 5. Enter the password again 6. Enter another Authy code 7. Disable two-factor 8. Sometimes confirm via email 9. Re-enable two-factor 10. Scan the new QR code into my password manager 11. Enter the new code 12. Save recovery codes 13. Delete the Authy entry Thirteen times over. Authy is free, but the real cost is the exit tax. An afternoon of tedious manual re-enrollment that would make most people think twice about leaving. I paid the tedium tax. And now I'm free. The seeds now live in my password manager, alongside their corresponding logins and recovery codes, encrypted, backed up, and replicated like everything else in the stack. Some of you might raise an obvious objection: storing passwords and TOTP seeds in the same vault collapses two factors into one. If my password manager was breached, it would compromise both. However. My vault requires both a master password and a hardware security key. The key cannot be exported, copied, or phished, that's its entire purpose. So the chain remains two independent factors, i.e. something I know and something I have. Whether that trade-off makes sense depends on your threat model, i.e. what is likely to happen to you, not what is theoretically possible. For me, this felt like the right choice. I only wish I hadn't waited so long. The hardest part wasn't technical, it was tedious. And I can't shake the feeling that the tedium was totally by design. --- *This is part of the Autonomous Stack series, documenting my migration from proprietary services to self-hosted infrastructure.* *Previously:* [*I Cannot Be Trusted to Send Email*](https://tarakiyee.com/i-cannot-be-trusted-to-send-email/)*.* *Next: Self-Hosting the Blog.* ### I Cannot Be Trusted to Send Email URL: https://tarakiyee.com/i-cannot-be-trusted-to-send-email/ Last updated: 2026-07-07T22:16:23.000Z For many people who are uncomfortable with Gmail, the reasonable option would be something like Proton, Tuta, or one of the other privacy providers that have spent the last few years advertising to exactly this feeling. These privacy providers are built around encrypted mailbox storage, and their business model does not depend on your data. That does not mean every email sent to an outside provider is automatically end-to-end encrypted by default, but it is still a substantially different privacy model. If this were the *Privacy and Reliability Stack* series, I would be telling you all about how I switched to one of them. But this is the *Autonomous Stack* series. To live up to the name of the series, leaving one internet landlord for a better internet landlord did not feel like sovereigntymaxxing. Many paid email providers will host your own domain, and even though having your first `you@yournamehere.com` address feels like independence, the domain is the most portable part. The mailbox part is less so. When you use any email provider, your mail lives on their drives, and getting it out means some form of export, only to import it somewhere else again. And you had better hope they do not lose it or decide you cannot access it anymore. Proton and Tuta both support custom domains, but that does not make the mailbox itself portable in the same way as the domain. I had twenty-one years of email that I did not want to lose, or keep migrating whenever the "better landlord" did landlord things. And the landlords keep expanding. Private mail now comes with a drive, a VPN, a password manager and, as of late, AI assistants. You are not just choosing an inbox. You are being sold an ecosystem, which is exactly the kind of codependency I am wary of. But I am not going to pretend this is not the best available choice for many people, nor recommend that people do as I do. This series comes with an implicit "Do Not Try This At Home" warning, and I'm going to FA just to FO and tell you about it. However, as unreasonable as I was willing to be, there was one aspect holding me back from fully hosting my own mail infrastructure. As the story goes, email is the great survivor: an open, federated protocol that has outlasted decades of attempts to replace it. It is the one corner of the internet where anyone can, in principle, run their own server and reach everyone else's. On paper, that is. In practice, deliverability has become heavily mediated. Reputation systems now sit in front of every large inbox and decide whose mail is allowed to land, and those systems are opaque by design. A new sending domain or IP starts without an established reputation. Its mail can be deferred, filed as spam, or refused, and the decision-making systems behind those outcomes are not public. Good configuration matters, and so do protocols such as SPF, DKIM, and DMARC, but they are no guarantee your mail will be delivered. You can do everything right and still not be trusted. This asymmetry is a genuinely hard problem: any system that made it easier for independent operators to send mail would also make it easier for spammers. It also just happens that this very asymmetry favours the incumbents. This bothers me because the protocol did not fail, but the ecosystem was captured. But it is not a hill I was willing to die on at this stage of the project. A common refrain in digital sovereignty debates is that "sovereignty is not autarky." Put differently: you can make your own choices without isolating yourself. Email as a protocol is not broken; I can receive email to my heart's content. Sending email reliably, though, would have taken a lot of effort and a lot of pain. So I split the task along that line. I kept the mailbox. It runs on my own server. I chose software called Stalwart: a single program, written in Rust, that handles receiving, filtering, and storing email all at once. The traditional way is to bolt three separate pieces of software together. For my small deployment, Stalwart is one service to run and one storage setup to back up, and I like Rust, so I was willing to risk it with a newer piece of software. For sending mail, I found an external mail service called Migadu. My mail server hands outgoing messages to it, and Migadu sends them through established mail infrastructure rather than through a fresh server IP I would have to operate and build trust around myself. Migadu is a full mail host, but I only need SMTP delivery from them. They seemed reliable, and the price worked especially well for my use case. The plan does come with a strict daily limit, but I rarely send more than ten emails per day. Finally, if I am ever unhappy with Migadu, switching to another relay should be much easier than moving the mailbox itself. My outbound mail still passes through a company, but I think of them less as landlords and more like the post office. One day, I may decide I no longer need friends or hobbies and tackle the complexity of sending mail myself. But until that day comes, trading off complexity for dependence seems to be worth it. The actual migration from Gmail and the Stalwart setup were still plenty of work. I will not bore you with the details, but I ended up duplicating half my mail and had to write a script to fix it. It also took some time to rebuild my filters and folder structure (I will write about this later in the series) and it took me months of tweaking things to figure out why some emails appeared on my mobile app but not on my desktop. (Spoiler alert: It turned out to be a Thunderbird quirk.) I now own my mail, but I still cannot be trusted to send it. Yet this was a major milestone: the Autonomous Stack has now become a load-bearing part of my life. --- *This is part of the Autonomous Stack series, documenting my migration from proprietary services to self-hosted infrastructure.* *Previously:* [*Laying the First Stones*](https://tarakiyee.com/laying-the-first-stones/)*.* *Next: Something about Monitoring, probably.* ### I Get No Ideas Inside the Machine URL: https://tarakiyee.com/i-get-no-ideas-inside-the-machine/ Last updated: 2026-07-05T00:13:48.000Z I recently had the pleasure of running a workshop called "Can We Build Hardware Without Capitalism?" at Cables of Resistance. It was billed as a crash course in the material politics of computation, and the point wasn't to answer the question in the title. It was to build a shared language for asking it. The title isn't bait. I genuinely don't have a definitive answer, and I don't trust anyone who claims to, one way or the other. But I feel a renewed urgency about it, and you might reasonably wonder why an open source software nerd is suddenly this preoccupied with hardware. To explain that I have to be a bit vulnerable. The truth is I've spent this year struggling with a deep disillusionment, a grief really, around open source. That's where this starts. ## Blessed Is the Machine Working in open source software, I've always felt like I was part of something bigger, something trying to make the world a better place for people. I worked on the things I could change, and trusted that others who shared the same values were working on theirs. I wasn't fully naive, or I hope I wasn't. I tried to learn the limits of what my work could do, but knowing them never demotivated me, because I also believed that even where it wasn't true yet, you can build good software for people without exploitation or harm. Or to put it plainly, we can build software without capitalism. The success of open source has two sides. On one hand, it proves that producing software openly and collaboratively doesn't just work, it can produce something more reliable and sustainable than the closed version, something that makes people's lives better. On the other, everyone draws on this common infrastructure while some are far better placed to extract value from it than others, big corporations most of all. That never sat right with me, and the scale of it was daunting, but it didn't break me. Then came the big LLMs, and they came for the heart of what makes open source work. Not the licences, but the collaborative mode of production. The new tools are effective at the hard things, the whole feature, the refactor, the unseen bugs, and they're faster than the slow work of bringing someone new along. So the small first contribution that used to be the way in stops being worth much to anyone, and the person who would have made it never gets the chance to engage with the software long enough to learn what their predecessors did. And it was already fragile before the tools arrived, down to a few tired people holding up things the rest of us only use. And the worst of it is that this isn't only being done to us, it's being done by us. The people holding the projects up are reaching for the same tools, maintainers who know the power and the water a model burns through, the labour it was trained on without asking, yet reach for it anyway, perhaps because they're exhausted and the work doesn't stop. I feel that exhaustion too. But it did cause me a bit of an existential crisis. I no longer feel like I'm part of a bigger movement to make things better. Instead, I feel like I'm part of building the Machine. Let me explain. In 1909, before broadcast radio and decades before television, E. M. Forster wrote a short story called *The Machine Stops*. (I'm about to give away the ending, so treat this as your spoiler warning for a story from 1909.) People live alone in small underground rooms, every need met at the press of a button, speaking to one another only through glowing plates, their bodies gone soft and first-hand experience a thing they've learned to fear. Over the generations they come to worship the Machine that runs it all, reciting the Book of the Machine and forgetting that human hands ever built it. The screens, the messaging, a whole civilisation resting on infrastructure it no longer understands: an astonishing thing to have seen coming. There are two people in the story. Vashti is at home in the Machine, and on the rare occasion of an air-ship journey, she turns away from the window, so as not to look at "the horrible brown earth, and the sea, and the stars when it is dark." "I get no ideas in an air-ship," she says. Her son Kuno wants out. He would rather see her with his own eyes than through the Machine, and he reminds her, "Men made it, do not forget that." On the same air-ship that gives his mother nothing, Kuno looks up and sees a giant laid out in the stars, shoulders and knees, a belt, a sword. We would call it Orion. He has no name for it. Later in the story he reaches the surface and comes alive there, and he begins saying the thing no one wants to hear: that the Machine is stopping, that it is the humans who are dying and the only thing still alive is the Machine. That is the Machine I feel like I've been roped into building, and I know I'm not the only one who feels it. However, it doesn't change what I believe: there's a better way to make software. But software has another layer underneath it, it needs hardware, and beneath the hardware layer lies the answer: are we the ones dying, or is it the Machine? ## What the Machine Runs On (Capitalism) Capitalism runs on cheapness (do not read that as "efficiency"). Jason Moore argues that the whole system stays upright by keeping four things cheap: labour, food, energy, and raw materials. Cheap here doesn't necessarily mean that the cost is lower, but rather that it lands on someone who can't refuse the cost, so that the surplus value between what is paid and what it costs can be collected by someone else. A cobalt miner on two dollars a day isn't a market failure waiting to be corrected, it's capitalism working as designed. Glen Coulthard says that you can't be against capitalism without being against colonialism, because the cheapening is itself the colonial act, turning a person into labour, a place into raw material, a living system into fuel, and calling the result a resource, or as Eduardo Galeano said it, that the wealth of some has always been made out of the poverty of others. This cheapening is often hidden from the people who buy the finished thing, but it's not hidden from the people it happens to. When capitalism is forced to reform, it doesn't change the underlying relation. It just relocates the injury. The green transition traded fossil fuels for lithium, so when the minerals changed, the harm was transposed. Now the Atacama desert is being drained for the rest of the world to have clean energy. Reform that shifts the harm around while leaving the relation intact is capitalism's gentle answer to placate its softest critics, and it is very persuasive. ## A Vocabulary for the Machine's Harms To try and see whether hardware production and capitalism are intrinsically intertwined, I had a plan for this workshop. We needed a common vocabulary to talk about the conditions that enable its harms. So for the practical part of the workshop, I handed out the following six structural conditions of capitalist hardware production. - Extractivism. The mining the whole machine stands on. - Fabrication concentration. Almost every advanced chip is made by a handful of companies in a handful of places. - Supply chain opacity. A chip crosses seventy borders, yet almost no one can say where its parts came from. - Information asymmetry. Hardware, unlike software, does not carry its own blueprint. - Vendor lock-in. A printer that will not print without a subscription. - Displaced harm. The people who bear the cost are never the people who benefit. It is not meant to be a taxonomy, but prompts, so that we can explore the question. For that, I had people rank the six from most fixable to least fixable and argue about it in groups. The second part of the workshop asked which of these each person's own corner of the world refuses to look at, and why. There was general consensus in the room about how to rank them. Vendor lock-in and information asymmetry came out most fixable, because everyone could see the lever: right to repair, mandated documentation, enforceable laws. Extractivism and fabrication concentration sat at the bottom, filed under too big, too physical, too far away to move. The condition people struggled most to place was displaced harm, because it isn't really one condition beside the others, it's the pattern the other five make together. The answer to the second question was sharper. Almost everyone mentioned the extraction. One person put it as focusing on what feels fixable and looking away from what feels structural. The format was built to keep the question open and resist a tidy answer, and mostly it held. I had my feedback, and I plan to work on updating the harms vocabulary and maybe run a longer format workshop in the future to dig into the most intractable parts. I was frankly excited by how many wanted to explore the question with me, and that gave me hope for the first time in months. Yet a few participants still reached for the gentler reform answers the workshop was designed to resist, and that made me think. ## Does the Machine Stand, or Stop? For those who want an easy exit out of the existential disillusion with the Machine, there are a few options. Benjamin Bratton actually mapped our real-world Machine, except he calls it the Stack. He was among the first to describe computation at a planetary scale as a single thing: an accidental megastructure, six layers deep, running from the energy and the minerals at the bottom up to the person holding the phone at the top. If Forster imagined the Machine, Bratton drew the one we actually built. He does not look away from the ground beneath it. The Stack, in his account, eats minerals and energy on a scale nothing else we've made comes close to: the cobalt out of the Congo, the water, the power, the harm that stays invisible to the people holding the finished devices. But his book is a map, and a design brief. It asks how the Machine might be run, governed, redesigned, and it sets aside the older question of whether it should stand at all. That posture, the Machine as a foregone conclusion and a necessity, is the first way out. The thing is here, it is not going anywhere, and the only serious question left is how to run it well. It is a great comfort, but one you have to be able to afford, and from underneath it the Machine as a settled fact is just one more thing being done to you. The other way out is the opposite, and it is the one Forster's story seems to offer. The Machine stops. It seizes up, it fails, and the failing comes almost as a mercy: Kuno and Vashti die in the dark, but they die having "recaptured life." It is a beautiful ending. It is also the thinnest part of the story. Forster shows us the collapse in full and frames the redemption in a single breath. The people who inherit the clean sky, we never actually see. But simply waiting for the collapse to make way for an imagined better future is not a way out either. It borrows all its meaning from a tomorrow that arrives only after everyone in the room is dead. There is capitalism's gentler answer. Care, maintenance, repair. Keep the machines longer, fix instead of replace, tread more lightly. Forster has a name for this too. In his world there is a Mending Apparatus, the system that keeps the Machine running, and over the generations people come to revere it almost as much as the Machine itself, right up until it too breaks down and cannot be mended. Repair conserves the thing it repairs. To be honest and fair, it's also the most decent answer on the table. I can't blame people for reaching for it. Yet none of the three is a way out. The Machine that stands because someone competent is running it, the Machine that falls and frees us, the Machine kept in good repair. The Machine itself does none of these. It doesn't hold and it doesn't stop and it isn't waiting to be mended. It just stands, and keeps standing. ## There Is No Innocent Ground for the Machine to Stand On There is no innocent ground under the Machine. The minerals come from somewhere, and the somewhere has people on it, and water, and a way of governing itself that the company coming to dig never asks. What we call the material layer is land already inhabited and governed and claimed, long before it was anyone's resource, and it became a resource by counting the people who lived there as part of what could be taken. Which means none of the answers reach it, and this is the part I most wanted the technologists in the room to see. A cleaner mine, an open licence, a machine built to last twenty years instead of two, all of it can be real and the thing is still not decolonial if the people whose land and water it runs on cannot make it stop. But if a satisfactory answer doesn't exist, where does the motivation to do the work come from? For me, the question itself is the new motivation. And to tackle a question like whether we can build hardware without capitalism, there are three traditions worth noting here that I believe are needed. One says you don't owe anyone a picture of the world that comes after, that the work is to refuse this one clearly, and the drawing of the alternative is not yours to produce. The second says the things we want to be rid of, the state, the system, are not just objects you smash but relationships, ways we've agreed to treat one another, and you undo them by treating one another differently. The third comes out of decolonial and Indigenous thought, and it says the injury is territorial before it is anything else. What was taken was land, water, jurisdiction, the authority of a people over the place they live, and none of that comes back by refusing capitalism more clearly or by relating to one another more kindly. It comes back by being returned. Anarchists developing better relations to each other or Socialists refusing where they stand do not reach it, because the thing owed is not better behaviour, it is the ground itself. I still can't say I have an answer to the question in the workshop's title, but here's what I want people to take away from it. If we as technologists really believe technology can make people's lives better, then it isn't enough to refuse the bad tools, and it isn't enough to find kinder ways of relating to one another. There is no innocent ground under the Machine waiting to be built on. It has to be given back first. The land returned, the water returned, the people a thing is built on able to refuse it and have the refusal hold. Those are not engineering or design problems, and while it's tempting to hand it to someone else and get back to your work, not all of us get to do so. A technologist who builds the Machine anyway is just building it on stolen ground. In *The Machine Stops*, Kuno is not the only one who got out. There are people living outside the Machine, up on the surface, the ones who were cast out or walked away and did not die. Forster calls them the Homeless. They are the most interesting thing in the story, and he tells us almost nothing about them. They wait at the edges of the plot, and then the story leaves them there, but it seems like they found the answer. I have hope that we can find an answer too, but I can't do that thinking from inside the Machine. That's the thing I learned about myself this year. I get no ideas in here. I need to be on solid ground, looking at the stars. --- *This is not a question anyone works out alone. If it's yours too, I'd like to hear from you.* ### Laying the First Stones URL: https://tarakiyee.com/laying-the-first-stones/ Last updated: 2026-06-23T20:32:22.000Z At this point my autonomous stack project had reached a moment where I needed to go from planning to implementation. I'd mapped the dependencies, drawn the architecture, picked the software, gone back and forth on the trade-offs, and ended up with something that looked good on paper (or in a Markdown file). Yet, as with all well-made plans, they barely survive contact with reality. I thought the first phase would take the better part of a Saturday. The beginning of the plan was straightforward and nothing I hadn't dealt with before. Provision a VPS. Harden the OS. Install Docker. Put a reverse proxy in front. Stand up a password manager. Move the credentials across. What actually happened: I spent an embarrassing stretch of time escaping dollar signs, discovered that a container command which sounds exactly like "reload the configuration" does not reload the configuration, and fell down a DNS hole that had been getting deeper for the better part of a decade. This is normal and something you should expect if you embark on a similar project. In fact, I would argue that the gap between planning and doing is usually the most interesting part of infrastructure work, where you get to flex your detective and research skills. ## Standing up the foundation For the VPS, the choice was simple: I picked a Hetzner VPS, sized for the workload I had planned. I already used them for a game server I've been running for years, so I knew I could rely on them for this. > *Tara from the future:* Hetzner raised prices several times through 2026\. [The April adjustment](https://www.hetzner.com/pressroom/statement-price-adjustment/?ref=tarakiyee.com) applied to existing products as well as new orders, so it reached the server I was already renting. [The larger June standardisation](https://www.hetzner.com/pressroom/standardization-and-price-adjustment-of-our-server-products/?ref=tarakiyee.com), which doubled and in places nearly tripled some lines, applied only to new orders and rescales. AI data centres are buying memory faster than anyone can make it, the three big manufacturers have turned most of their output over to the high-bandwidth memory that feeds accelerators, and [DRAM prices climbed by something close to ninety percent in a single quarter](https://spectrum.ieee.org/dram-shortage?ref=tarakiyee.com). The economics that make self-hosting look like a simple saving are quickly changing. Then I installed the freshest version of Debian I could find before diving into the unglamorous part. Server hardening is a trudge, but given that this infrastructure was going to handle all of my data, it was not to be skipped. I won't bore you with the details, but it was all the standard web server stuff, plus setting up the Hetzner firewall. The one insight was that it's crazy how quickly scanners find new hosts online. Fail2ban was already getting busy long before I had finished the rest of the setup. Then came the part I was somewhat dreading, because it was new to me. The plan is that for every service I deploy, it needs to be reachable over HTTPS, so rather than have each one juggle its own certificates, Caddy (a reverse proxy) sits at the front, terminates TLS, and routes each request to the right backend. A new service is a few lines of configuration and a certificate that provisions itself. Caddy asks Let's Encrypt, the request goes through, and there is valid HTTPS within seconds of the proxy coming up. Even as someone who's followed this work, I'm still amazed by how well-oiled the automatic certificate machinery has become in the last several years. > *Tara from the future:* Since I wrote this, Let's Encrypt has started issuing certificates that last six days and is moving its ordinary certificates toward a forty-five-day life. Renewing by hand at that cadence isn't difficult. It's effectively impossible. I'm glad I took the time to set this up. ## Vaultwarden: the first real migration Vaultwarden, a self-hosted re-implementation of the Bitwarden server, was the first service I deployed and the first real data migration. That order was deliberate. The password manager sits at the very bottom of the dependency graph: every other migration involves logging into something, and every login needs credentials. Deploying it was easy. Configuring it was not. Vaultwarden needs a hash as part of setup, and getting Docker Compose, my terminal, and Vaultwarden to agree on how it should be passed around turned out to be unexpectedly fiddly. Then, when the admin interface finally opened, it again took me several web searches to figure out that, to register my account, I actually had to guess the URL. Once that was out of the way, the software was ready to use. The password migration itself, the part I had been quietly dreading, was the least eventful thing in the whole exercise. I exported a CSV from Dashlane, pointed Vaultwarden's importer at it, and a decade of accumulated logins, seven-odd email identities, and accounts for services that no longer exist all moved across in a few seconds and a single file upload. There is something both freeing and faintly unnerving about looking at a decade and a half of my digital identity sitting in a plain-text file that I'm reading through a text editor. I started using Dashlane out of convenience and stuck with it for years because of what I assumed to be real friction in moving all of my data. I appreciate that they made it easy to leave. ## DNS archaeology At this point, I needed to move my DNS zone from my old hosting provider to Hetzner. Frankly, I had not looked at it properly in years, so I took this as a chance to do some digging. Years of accumulated services meant that my DNS zone was less a configuration file than a sedimentary record of my own internet history. I found subdomains aimed at Bitbucket, which I haven't used in at least ten years, and several A records for Tumblr blogs from a past life. Naturally, there were many verification records for services I no longer have accounts with, some I don't even remember. I had an entire second website on a subdomain that I forgot to retire. Also, a surprising number of ACME challenge records from years of automated renewals, piled up like silt. And then the email records, which at that point were pointing at Google. Cleaning all of that up is a project of its own, and not for today. For now, I added what Caddy and Vaultwarden needed and started laying the groundwork for the email move: DKIM keys for Migadu, the relay I had chosen to handle outbound mail; an SPF record that authorises the new sending path alongside the old; and a DMARC policy. Migadu was one of the compromises I made in my design, as I didn't want to deal with running an SMTP server and the trials and tribulations that come with it. ## Monitoring from day one With the core pieces in place, I decided to deploy Uptime Kuma the same afternoon as Vaultwarden. You might be asking yourself: monitor what, exactly? Two services and a reverse proxy? But monitoring is far easier to stand up when nothing is wrong than when something is on fire and you're trying to work out what happened. Uptime Kuma watches HTTP endpoints, TCP ports, and the health of the individual containers on the host. Building observability in from the start is the infrastructure version of writing the test before the code. It feels like overhead right up until the first time it catches something you would otherwise only have heard about when something stopped working and you needed it most. ## What I learned The technical lessons were interesting, but nothing I didn't know before: shell escaping is hard, container tooling has its quirks, and DNS zones collect debris. The lesson that stuck was about the relationship between planning and doing. I was glad that the plan I had drawn was right about the big things so far: the hosting shape, the choice of software, and where the security boundaries went. But what a plan can't tell you is the kind of detail work that ends up eating all your hours. It is not a failure of planning per se. The value of an infrastructure plan is never that it prevents surprises. The real value is that when a surprise arrives, you can often quickly zero in on which part of the system it touches, and it gives you a framework for evaluating remediation options. The plan largely survived contact with reality. I just needed more time, and considerably more shell escaping, than I had predicted. --- This is part of the Autonomous Stack series, documenting my migration from proprietary services to self-hosted infrastructure. Previously: [*Three Servers and a Tunnel*](https://tarakiyee.com/three-servers-and-a-tunnel/). Next: *Eighty-Four Thousand Messages, One DNS Change*. ### On The Enshittification of Audre Lorde: "The Master's Tools" in Tech Discourse URL: https://tarakiyee.com/on-the-enshittification-of-audre-lorde-the-masters-tools-in-tech-discourse/ Last updated: 2026-06-23T21:16:49.000Z EDIT (30th March 2026): Removed a reference to [Boaventura de Sousa Santos. ](https://en.wikipedia.org/wiki/Boaventura%5Fde%5FSousa%5FSantos?ref=tarakiyee.com) There is a moment in Cory Doctorow's 2025 book *Enshittification: Why Everything Suddenly Got Worse and What to Do About It* where he pauses to pick a fight with Audre Lorde. He calls her "far smarter than I am about nearly everything," then insists that one of her most quoted observations, that the master's tools will never dismantle the master's house, is "manifestly wrong." His argument is that regulation, antitrust law, interoperability standards: these are the tools we need to dismantle the tech monopolies that have captured and degraded the internet. I first encountered this weird argument on a Mastodon thread years ago, and it never sat right with me. It would be a defensible claim if that was the argument Audre Lorde was making in the first place. Something strange happens in that paragraph, something worth sitting with: a writer invoking a Black lesbian feminist theorist in order to dismiss an argument about tech platforms, which she never made. The phrase has been borrowed, stripped of its roots, and sent out to do labour it was never meant to do. And in the act of rebutting a meme, Doctorow becomes part of the meme's problem. Doctorow treats Lorde's line as if it were a claim that instruments of established power can never be used against that power; he then rebuts that claim by pointing to antitrust, regulation, and interoperability. But that is not the argument Lorde was making in the speech he invokes. *Enshittification* is a serious and important book, and the broader project of understanding platform decay as a structural, political phenomenon rather than a personal failing or a market accident is exactly the kind of thinking we need. I will argue two things in this blog post: first, that Lorde's "master's tools" speech is routinely misread in tech discourse as a general proposition about rejecting reform; second, that taking her actual argument seriously would not invalidate enshittification but deepen it, by asking whose experience of technological harm the framework centers, and whose it treats as supplementary. ## Where the "Master's Tools" Actually Comes From On September 29, 1979, Audre Lorde stood at a podium at New York University at a conference celebrating the thirtieth anniversary of Simone de Beauvoir's *The Second Sex*. She had been invited at the last minute to respond to a panel, the only panel in the entire three-day conference where Black feminists and lesbians had been given a voice. She had been listed on the programme not as a speaker but as a "consultant." The organizers had corralled the women of colour and the queer women into a single slot on the final day, the implied message being that these perspectives were supplementary rather than foundational. Lorde's speech, later published in *Sister Outsider* as "The Master's Tools Will Never Dismantle the Master's House," reads in this context not as a claim that reform is impossible or that working within systems is always futile, but as a specific intervention directed at white feminist academia, delivered from a position of structural exclusion, about how the very structures of knowledge production (conferences, panels, theoretical frameworks, the categories of analysis) were reproducing the hierarchies they claimed to oppose. In this reading, the "tools" Lorde was naming were not literal instruments but epistemic ones: the frameworks of thought, the methods of inquiry, the structures of inclusion and exclusion that had been built by and for a particular kind of subject (white, heterosexual, Western) and that continued to operate even within movements ostensibly committed to liberation. The questions she poses make this frame legible: what does it mean to conduct feminist analysis while systematically excluding the voices of poor women, Black women, Third World women, lesbians? What does it mean to theorize liberation using categories that treat those exclusions as incidental rather than structural? "What does it mean," she said, "when the tools of a racist patriarchy are used to examine the fruits of that same patriarchy? It means that only the most narrow perimeters of change are possible and allowable." Her words suggest that such analysis could produce, at best, incremental adjustments within the existing order. It could let you "temporarily beat him at his own game," but not the genuine change, the "dismantling of the house", that would require what the existing frameworks seemed structurally incapable of generating: a reckoning with difference, with the knowledge that comes from the margins, with the ways that interconnected systems of oppression cannot be addressed one at a time by theorists who treat their own particularity as universal. This is not a comfortable argument, and most crucially, it was not addressed to tech companies or policy makers or open source developers. What strikes me most about it is who it *was* addressed to: white feminist scholars, the people ostensibly on the same side, named as part of the problem. That specificity is often absent from contemporary tech discourse citations of the phrase. ## What Tech Discourse Does With the "Master's Tools" From my perspective, in free software and adjacent communities, the phrase has taken on a life entirely detached from its origins. I myself have probably engaged with it that way, to be completely honest. Micah White described it as ["the atomic bomb of discussion enders,"](https://www.activistgraduateschool.org/on-the-masters-tools?ref=tarakiyee.com) a phrase so potent it can be applied to absolutely any argument about strategy and method, often by people who have never encountered the full speech. White's concern is not with Lorde's argument but with what has been done to it: a revolutionary provocation flattened into a reflexive shutdown. It shows up most often as a thought-terminating cliché: using corporate infrastructure, proprietary platforms, or mainstream legal mechanisms to advance liberation goals is self-defeating by definition. The master's tools. End of conversation. And it shows up as a straw person waiting to be knocked down. This is, I believe, what happens in that *Enshittification* paragraph: cite the phrase, acknowledge the authority of the speaker, then dismiss the claim as "manifestly wrong" on the grounds that regulation and antitrust law demonstrably can constrain monopoly power. I'm not the first person to point this out. [A review in DesignWhine](https://www.designwhine.com/book-review-enshittification-by-cory-doctorow/?ref=tarakiyee.com) called the Lorde passage "a particularly discordant note," observing that Doctorow's rebuttal addresses tech platforms rather than the "frameworks of racial and gender oppression that Lorde was addressing." Both the use of the phrase as a cliché and as a straw person share a common structure. They treat it as a proposition about strategy, a claim about whether instruments of power can be redirected, and then debate it as such. In doing so, they evacuate the phrase of its specific context. Read against the speech itself, Lorde's argument seems less concerned with whether antitrust law can break up monopolies and more with whose knowledge counts, who gets to define the problem, and what gets systematically erased when liberation movements reproduce the exclusions of the systems they are opposing. ## How Taking the "Master's Tools" Seriously Can Serve Enshittification Doctorow's enshittification thesis, at its core, is about how platforms extract value from users and suppliers in a structured, predictable way once they have achieved sufficient monopoly power. It is a story about the concentration of capital, the elimination of competitive discipline, the regulatory capture that allows monopolists to write the rules of their own industries. It is, in important ways, a structural analysis of power. But there is a structural analysis that *Enshittification* doesn't seem to be making, and that taking Lorde's speech seriously rather than as a meme might push us toward. Whose experience of platform decay is centered in the enshittification story? Whose experience is supplementary? When we talk about the internet "getting worse," what baseline of "better" are we implicitly invoking, and for whom was it better? The enshittification story, at its most powerful, describes a process by which platforms that once served users well came to exploit them. But this framing assumes a prior state of genuine service, a golden age of the open internet, that was for many people never particularly golden. The early internet was structured around the assumptions of its architects: predominantly white, male, Western, educated, and abled. The exclusions weren't mere flaws; they were perhaps, if we're being generous, deeply structural tendencies that were never seriously interrogated. Consider one concrete example of what the enshittification framing tends to make invisible. In Nairobi, Kenya, [described by one journalist](https://www.codastory.com/authoritarian-tech/kenya-content-moderators/?ref=tarakiyee.com) as ground zero in a battle over the future of content moderation, young workers from informal settlements were employed by Meta's outsourcing partner Sama to review graphic content including beheadings, child abuse, and torture, for wages of between $1.46 and $3.74 per hour. A clinical assessment [submitted to Kenya's Employment and Labour Relations Court](https://blogs.lse.ac.uk/africaatlse/2025/11/03/there-is-a-dark-side-to-content-moderation-in-east-africa/?ref=tarakiyee.com) in late 2024 found that 81 percent of these workers had developed severe PTSD. 185 of them have since sued Meta and Samasource Kenya. In a 2024 townhall, Kenyan President William Ruto [reportedly assured Sama](https://www.aljazeera.com/opinions/2025/4/1/african-workers-are-taking-on-meta-and-the-world-should-pay-attention?ref=tarakiyee.com): "Now we have changed the law, so nobody will take you to court again on any matter." These workers do not fit neatly into enshittification's consumer-facing timeline of decline. The platforms had not "turned against" them after an initial period of serving them well. They were constitutive of the platform's operation from the start, absorbed into its labour structure precisely because Kenyan law offered weaker protections and Kenyan wages were lower. The "good" platforms for users in the Global North was built, in part, on conditions that were never good for workers in the Global South. In [*The Palestine Laboratory*](https://www.versobooks.com/products/2684-the-palestine-laboratory?ref=tarakiyee.com), the journalist Antony Loewenstein documents how the Palestinian territories have functioned for decades as a testing ground for surveillance and control technology, which is then exported to governments worldwide. The Pegasus spyware developed by the NSO Group, the facial recognition systems deployed across Hebron, the AI targeting tools used in Gaza: none of these began as consumer products that later turned exploitative. They were designed from the outset as tools of occupation and population control, refined through use on Palestinians, and sold as battle-tested to authoritarian regimes. This is not the same technological domain as consumer platforms, but it reveals a parallel point: for many users, digital systems did not begin in service and then decay into domination; domination was the design premise. This directly raises important questions about the enshittification timeline. The technology, more often than not, arrived already serving the interests of those who commissioned it. And crucially, the same dynamics that make the Global South available as a testing ground (weaker legal protections, cheaper labour, populations with less political power to push back) are what make the enshittification story possible in the first place. This is not an argument to reject the enshittification analysis. It is an argument to extend it. A decolonial critique of technology is not simply "the internet was always bad." It is rather: the conditions that made the internet harmful to specific communities were never peripheral to its design; they're an integral part of it. And any politics that aims to restore something like the pre-enshittification internet without reckoning with those conditions is doomed to reproduce them. ## What Engaging with the "Master's Tools" Actually Looks Like The decolonial tradition in technology scholarship has been doing this work for many years, often cited but rarely absorbed in mainstream tech discourse. In [*Race After Technology: Abolitionist Tools for the New Jim Code*](https://www.ruhabenjamin.com/race-after-technology?ref=tarakiyee.com), Ruha Benjamin develops the concept of the "New Jim Code," her term for technologies that reproduce existing inequities while presenting themselves as more objective and progressive than the discriminatory systems they replace. Benjamin's argument is a methodological one about how racism operates through algorithms. She writes, "racism thus becomes doubled, magnified and buried under layers of digital denial." One cannot identify or begin to address that if their analysis begins from the assumption that the technical layer is neutral. In [*Algorithms of Oppression: How Search Engines Reinforce Racism*](https://nyupress.org/9781479837243/algorithms-of-oppression/?ref=tarakiyee.com), Safiya Noble makes a related case about search. Her argument is against the fiction of their neutrality. "Google creates advertising algorithms, not information algorithms", she writes, a distinction that matters enormously when those algorithms are treated as a public information resource by schools, journalists, and governments. The criteria of relevance built into search are not neutral, and treating them as such reproduces the structures of erasure they encode. In her [2020 paper "Algorithmic Colonization of Africa"](https://script-ed.org/article/algorithmic-colonization-of-africa/?ref=tarakiyee.com), cognitive scientist Abeba Birhane argues that while traditional colonialism used brute force, algorithmic colonialism operates through corporate agendas: "state-of-the-art algorithms" and "AI-driven solutions" to social problems that reduce complex cultural and political realities to things that can be measured, quantified, and fixed. This can be clearly seen in the Nairobi case: the content moderators' psychological crisis was not incidental to the platform's AI safety work, it was the mechanism by which that work was accomplished. Nick Couldry and Ulises Mejias take long historical view in [*Data Grab: The New Colonialism of Big Tech and How to Fight Back*](https://press.uchicago.edu/ucp/books/book/chicago/D/bo216184200.html?ref=tarakiyee.com). Their claim is that data colonialism is not metaphor: it is structurally continuous with historical colonialism, with data replacing land as the resource being seized. "Like historical colonialism," they write, "today's tech corporations have engineered an extractive form of doing business that builds a new social and economic order." This is perhaps the most direct bridge that extends the enshittification critique into the decolonial one. Doctorow asks how platforms extract value; Couldry and Mejias ask what kind of thing that extraction is in historical terms. I believe that Benjamin, Noble, Birhane, Couldry, and Mejias are engaging, in Lorde's terms, in the epistemic tools: not only the legal mechanisms or the technical architectures, but the analytical frameworks that tell us what counts as a problem, what counts as evidence, and whose testimony counts as knowledge. And none of them are arguing for inaction. Even Benjamin's subtitle, *Abolitionist Tools*, directly says that analytical tools can and should be turned toward liberation. But those tools have to be built with different assumptions than the ones baked into the systems being analysed. What links these works is not a common slogan but a common method: they refuse to treat technical systems as neutral containers and insist that the categories through which problems are defined already encode relations of power. In that sense, they extend Lorde's challenge from feminist theory to technology critique. This is precisely what gets lost when the phrase "the master's tools" becomes a debate about whether antitrust law is effective. The question is not whether antitrust law can break up a monopoly. The question, the one the speech seems to me to be asking, is whether breaking up a monopoly by itself constitutes the "genuine change" Lorde invoked, or whether it simply rearranges the furniture in a house whose foundations remain unchanged. ## The "Master's Tools" Is an Invitation, Not a Rejection There is something particular that happens when figures from Black feminist, queer, or decolonial traditions are cited in tech discourse. The citation tends to operate as credentialing rather than engagement, a way of demonstrating political seriousness before proceeding to make the argument you were going to make anyway. In that passage, Lorde is simultaneously "far smarter than I am about nearly everything" and also wrong about the thing that matters for the argument at hand. The invocation and the dismissal occur in the same breath. This is, structurally, a version of what Lorde was diagnosing in 1979\. The conference organizers had invited her. They had put her on the programme. They had formally acknowledged that her perspective had a place in the conversation. But they had put her in the one slot reserved for people like her, assigned her to respond to work that had not engaged with her tradition, and positioned her contributions as supplementary to a theoretical apparatus that remained unchanged by her presence. The parallel is not exact. But the structure (incorporate, cite, proceed) is recognizable. And recognizing it is not a reason by itself to reject or abandon the enshittification analysis. It is a reason to take Lorde's actual argument seriously enough to let it do something to the analysis, rather than neutralizing it with a compliment. I would hate for this critique to be read as "enshittification gets it wrong." I believe that enshittification is doing something real and important, and the feminist and decolonial traditions have tools that could make it more powerful, more accurate, and more honest about whose experiences it centers. To reject it, rather than invite it to engage, would in my view be a betrayal of what Lorde stood for. In the speech, Lorde tells us that the first patriarchal lesson is "divide and conquer," and that the task is to "define and empower" instead. It places definition (understanding the actual structure of the problem including the parts that are uncomfortable or that implicate people within the movement) as prior to empowering. And defining requires the kind of analysis that comes from the marginalised: not as a supplement to the real analysis, but as a correction to its blind spots. The question is not whether to use antitrust law or interoperability standards to fight platform monopolies. Use them to their fullest extent. The question is whether we can also build the analytical framework that asks why the platforms were built the way they were, who paid the costs that made them profitable, and what "better" actually looks like when we account for the full range of people who will live in whatever comes next. What Lorde left us with, is not the answers to those questions but something more valuable: the insistence that they have to be asked, and that asking them requires centering the people for whom the stakes are highest. The "master's tools" speech, in its context and practice, is the antithesis of a thought-terminating cliché. Let's stop treating it that way. ### Three Servers and a Tunnel URL: https://tarakiyee.com/three-servers-and-a-tunnel/ Last updated: 2026-06-23T19:10:27.000Z The inventory gave me a dependency graph. Now I needed to order it into an architecture. Password manager first. Everything depends on credentials. If I can't log into services, nothing else moves. Then email, because everything depends on a stable address. Every account migration involves updating the registered email. Then authentication: 2FA codes, migrated service by service as each account is touched. Then everything else in descending order of criticality. The infrastructure to support all of this has to exist before any of it begins. I had to pause at that last question. I couldn't just start installing things. Where does the infrastructure live? How do the pieces connect? What happens when something breaks? These are architecture questions, and every answer constrains the answers that follow. I didn't want to skip this step. If I installed software first and let the architecture emerge from ad-hoc decisions, I wouldn't end up with something sustainable. ## Where things run The first question was the most consequential: does everything run at home, everything on a rented server, or some mix? Running everything at home is the purest expression of autonomy. Your hardware, your network, your data. But it centralises everything behind a single residential internet connection. When the ISP has an outage, and European residential ISPs have outages, everything goes dark. Email doesn't arrive. Passwords aren't accessible. Calendar entries vanish until the connection returns. Running everything on a VPS avoids this, but at the cost of the thing you're supposedly pursuing. Your data lives on someone else's disk, in someone else's data centre, subject to someone else's terms of service. You've replaced one landlord with another. I went with a hybrid model. Services that cannot tolerate downtime run on a VPS with professional uptime. Everything else runs at home, on hardware I own, with data that never leaves my premises unless encrypted. The split criterion was simple: how bad is it if this service is unreachable for a few hours? Email and passwords are non-negotiable. If I can't receive email or access credentials, I'm locked out of everything. These run on a VPS. File sync, photo storage, home automation, media: these can survive an afternoon without internet. These run at home. This isn't a novel architecture. It's what most organisations converge on, and the reasoning is identical: critical services get professional infrastructure, everything else gets cost-optimised. The difference is that here, "cost-optimised" also means "sovereignmaxxing." Once I'd committed to a VPS for critical services, I had to think about isolation. I had an existing VPS that already ran some gaming-related services, serving untrusted connections. Putting personal email on the same machine creates a shared point of failure that doesn't need to exist. A second VPS costs a few euros per month and buys separation: a compromised public-facing service doesn't give an attacker proximity to my credentials. The home server runs a hypervisor instead of running services directly on the host OS. A hypervisor is easiest to imagine as a strict bouncer at a big event space with many rooms: each event gets its own room, and a bouncer ensures the guests never mix. This lets me run a stable production VM alongside an experimental one where I can try different approaches without risking running services. One of my values was iteration over perfection. Infrastructure should accommodate learning, not just operation. A stack that can't tolerate experimentation will eventually stagnate. ## How things connect Home services need to be reachable from the internet, but exposing a residential IP address is an unnecessary disclosure. The solution is creating a "tunnel" through the interwebs: the home server connects outward to the VPS, and the VPS channels incoming traffic through that tunnel back to the home server. From the outside, every service appears to be running on the VPS. The home IP is never visible. No ports are opened on the home router. The residential network remains invisible. I chose WireGuard for the tunnel. It's fast, minimal, well-audited, and a single configuration file per endpoint. This is a common pattern: expose services through a controlled gateway rather than opening your internal network directly. At personal scale, it's simpler to implement and solves several problems simultaneously: no dynamic DNS needed, no port forwarding configuration, no exposure of the home network to people that had no business in my home. Every service runs in Docker containers. That's another technology that's conceptually similar to a hypervisor, but with a fundamental difference. Docker is looser. Containers share the same underlying system but remain isolated enough to avoid interfering with each other. If hypervisor is the event space bouncer, making sure every party is in its assigned room. Docker is more of a skilled event space manager, letting the parties run all over the event space, skillfully letting them use all the amenities without fighting over resources Nearly every FOSS project ships a docker-compose.yml, essentially a recipe that tells the event manager how to set up the space for all different types of parties (the metaphor is working hard at this point). That ubiquity and ease of deployment makes Compose the de facto deployment standard for self-hosting. There are alternatives, but each have trade-offs, I won't get into it here, but this hybrid docker/hypervisor set up felt right for me. ## The email problem Email is the most important service to migrate and the most dangerous to self-host. The danger isn't technical. Setting up a mail server is straightforward. The danger is deliverability. Email delivery depends on reputation. IP reputation, domain reputation, the presence and correct setup of certain internet protocols (namely SPF, DKIM, and DMARC records), and making sure your sending IP doesn't end up on a blocklist maintained by organisations with opaque inclusion criteria. A VPS IP address in a shared hosting range is highly likely to be on a blocklist because of someone else's actions. Your carefully composed email to a bank, a government office, or a potential employer may land in a spam folder, and the receiving provider will never tell you. If I were truly sovereignmaxxing here, I would run everything myself and fight the deliverability battle. It would be principled and admirable, and future generations will compose songs about me with their AI brainchips. It's also a poor risk calculation for email that's really critical. I chose a hybrid approach: a self-hosted mail server for storage and access, paired with an external relay for the actual sending and receiving. The relay handles IP reputation, blocklist management, and spam filtering. My server handles IMAP, search, and storage. Mail lives on my VPS, under my control. But it enters and leaves through infrastructure maintained by people whose full-time job is email deliverability. This is a pragmatic compromise. Sovereignty is about informed, intentional choices, not about maximising personal suffering. I chose which component to delegate and why. That's different from defaulting to Gmail because the alternative seems hard. The European digital sovereignty debate often treats self-reliance and interdependence as opposites. They're not. Strategic autonomy means choosing your dependencies rather than inheriting them. Running your own mail storage while delegating delivery to a trusted provider is the personal equivalent of manufacturing your own chips while importing the lithography machines. You control what matters most and manage the rest through agreements you can exit. ## What I decided, what I deferred Backup architecture follows the standard 3-2-1 model: three copies, two different media, one offsite. Both servers back up to dedicated cloud storage with encrypted, deduplicated snapshots. Configuration files live in version control. The backup tool was chosen partly for interoperability: it produces output compatible with a more established alternative, meaning I can switch implementations without re-creating my backup history. Being locked into a single backup tool is exactly the kind of dependency this project exists to avoid. Some decisions were explicitly deferred. The home server hardware I needed to save up for, thanks to the NAND chip crisis making hard drives more precious than shiny pokemon. My best bet was to start with a virtual machine on my home desktop. I can run a few less critical, not resource heavy services there. You also have to monitor your infrastructure. No need to worry if you're receiving mail or not if you can look at a dashboard, and experience the relief that only a fully green 100% uptime stat can provide. Now you sleep peacefully knowing that if you're not receiving email, it's someone else's fault. I didn't know what I wanted for monitoring yet, but knowing where to place it in the architecture was simple: this lives on the VPS, not on the home server. If your services and your monitoring share the same failure domain, an outage can silence both the system and the alarm. Running the monitor on the VPS means a home network outage triggers an alert rather than a silent gap in coverage. In the future this could improve with an external uptime service or a tiny second VPS, but at this stage, if the VPS went completely down, the specifics don't matter much in the grand scheme of things. And if I investigate and it turns out it's just the monitor that was down, that would be a big relief. I could have decided everything upfront. I could have specced the home server, picked every service, chosen every tool. But premature decisions are as dangerous as missing decisions. Deciding on hardware before understanding the actual resource requirements would optimise for the wrong constraints, even if it was obvious SSD prices were going to continue to go up. The architecture should identify decision points without forcing every decision to be made simultaneously. Nothing in this architecture is original. A critical services VPS, a home server for everything else, an encrypted tunnel between them, backups to external storage, monitoring from the VPS. Every component is well-understood and widely deployed. The value isn't in novelty. It's in the explicit reasoning behind each choice, and in the values I set at the start doing their job. Security over convenience meant a second VPS for isolation, not consolidation for savings. Freedom over features meant Docker, not a proprietary orchestration platform. Autonomy over dependence meant self-hosted mail storage, even when fully delegated email would have been easier. Research over impulse meant deferring hardware decisions until I understood the requirements. The next step is building it. One service at a time, starting with the foundation. --- *This is part of the Autonomous Stack series, documenting my migration from proprietary services to self-hosted infrastructure.* *Previously:* [*The Inventory I Should Have Done Years Ago*](https://tarakiyee.com/the-inventory-i-should-have-done-years-ago/)*.* *Next: First Deployment (stay tuned).* ### For the Love of the Linux Desktop URL: https://tarakiyee.com/for-the-love-of-the-linux-desktop/ Last updated: 2026-06-23T19:10:28.000Z I've been using Linux on my personal machines since I was a teenager. That's about twenty-five years now. All debian based naturally but more on that later. Long enough that the muscle memory is older than most of the code I depend on. I started with Linux because I had a budget computer, a dial-up connection, and a friend who handed me a burned CD. The politics came later, layered on top of something that was already habit. But the desktop, the thing I actually look at and touch every day, has its own fascinating story, and I've been thinking about it lately ![](https://tarakiyee.com/content/images/2026/03/GNOME_2.10_Desktop_-March_2005--1.png) ![](https://tarakiyee.com/content/images/2026/03/GNOME_2.10.0_on_Ubuntu_5.04.png) [GNOME 2.10.0 Screenshot (GPL)](https://commons.wikimedia.org/wiki/File:GNOME%5F2.10.0%5Fon%5FUbuntu%5F5.04.png?ref=tarakiyee.com). First [Screenshoot taken by b:de:Pythagoras1 ](https://commons.wikimedia.org/wiki/File:GNOME%5F2.10%5FDesktop%5F%28March%5F2005%29.png?ref=tarakiyee.com) The first desktop I used was GNOME 2 around 2003\. I remember how it felt to see it for the first time: a panel at the top, a panel at the bottom, a menu in the corner, everything made sense. Everything else was held together with tape. I had an aging GeForce 2 GTI and the proprietary NVIDIA driver was in standing negotiation between me and the kernel, while Xorg stood to the side and did its own thing. I was doing my homework while the kernel modules recompiled, and if I was lucky, I'd get like 10 minutes of glorious game time before something crashed. Eventually I managed to get it stable enough that I was modding games. Gaming meant scouring the web for "free" games, emulators, and roms. I never managed to get Wine to work. Forums were where you learned things, and I was lurking in so many IRC channels, some of which I had no business being in. GNOME 2 was solid, though. I experimented with KDE during my university years, as you do, but unfortunately for me that was the KDE 4 era. Ambitious, beautiful, and not finished yet. ![](https://tarakiyee.com/content/images/2026/03/KDE_Plasma_Desktop_4.9.png) ![](https://tarakiyee.com/content/images/2026/03/Ubuntu_11.04_zh.png) ![](https://tarakiyee.com/content/images/2026/03/GNOME_Shell_3.0_-2011-_03-_showing_search_function_in_overview_mode.png) [KDE 4.9 (GPL)](https://commons.wikimedia.org/w/index.php?curid=21580461&ref=tarakiyee.com), [Unity (GPL)](https://commons.wikimedia.org/w/index.php?curid=21580461&ref=tarakiyee.com), [GNOME 3](https://commons.wikimedia.org/wiki/File:GNOME%5FShell%5F3.0%5F%282011,%5F03%29%5Fshowing%5Fsearch%5Ffunction%5Fin%5Foverview%5Fmode.png?ref=tarakiyee.com) Then 2011 happened, a year of many upheavals. I graduated, had a bit of a political awakening due to a few things that happened at the time, but most consequentially, Ubuntu 11.04 shipped with Unity as the default. GNOME 3 also released the same month. In the span of a few weeks, both the Linux distro I've gotten used to, and the desktop environment I relied upon decided to become something fundamentally different. Unity was a full-screen launcher that ran like a slide show on my hardware. GNOME 3 stripped the desktop metaphor down to a search-first workflow that assumed everyone wanted to find applications by typing their names (pretty rich complaint coming from me considering what I use now). I gave Unity about a year. But it was slow on my hardware, and the design never clicked. I'm not going to get into what happened in 2011, but the cumulative effect was a heightened sensitivity to things being imposed from above. Maybe that colored how I experienced a desktop environment telling me to change my workflow. Or maybe the desktop was just bloated. Probably both. ![](https://tarakiyee.com/content/images/2026/03/I3-wm.png) ![](https://tarakiyee.com/content/images/2026/03/LinuxMint22-Wilma-English.png) ![](https://tarakiyee.com/content/images/2026/03/ceda19dddb88d724.jpg) [i3 screenshot by B̅ - Own work, CC BY-SA 4.0](https://commons.wikimedia.org/w/index.php?curid=58530143&ref=tarakiyee.com), [Linux Mint Screenshot by User:Mipinggrey -GPL,](https://commons.wikimedia.org/w/index.php?curid=153050038&ref=tarakiyee.com) My own sway setup The following year, a colleague told me about Linux Mint and their desktop environment called Cinnamon, which essentially had GNOME 2's philosophy but built it on GNOME 3's technology. A traditional desktop with panels, a menu, a taskbar, no ideology about how you should work. Just a surface you could arrange things on. Originally I had set it up for my grandfather and a couple of other family members, but I developed a fondness for it. I switched to Mint and stayed. Cinnamon became my desktop for over a decade. Through job changes, through moving countries, through a chaotic world, at some point I stopped experimenting with my tools and needed them to just work. In 2012, a Swedish hacker showed me i3\. A tiling window manager where every window snapped to a grid, controlled entirely by keyboard shortcuts, configured through a plain text file. It was fast. It was efficient. It required you to know what you wanted to do before you did it. I loved the idea. I couldn't sustain the practice. Tiling demands a kind of discipline about your workspace that I didn't have at the time. I went back to Cinnamon, where I could drag a window somewhere vaguely useful and forget about it. Thirteen years later, I decided it's time to start experimenting again, and started running Sway. The Wayland-native successor to i3, with proper multi-monitor support, smooth scaling, and a display protocol that doesn't fight you. I paired it with Debian Sid, the rolling unstable branch, because somewhere along the way I stopped wanting stability in my tools and started wanting to try out all those cool technologies I've been hearing about. I don't fully know what changed. Maybe I'm more disciplined now. Maybe the tools are better. Maybe running Sway on Sid is just the almost-forty-year-old version of recompiling a kernel to get a graphics card working: choosing difficulty on your own terms, because you want to understand the thing, not just use it. But a lot of things had to happen to make me regain the joy of experimenting with Linux Desktop environments. Wayland is the one that matters most structurally. It's a project to build an alternative to X11, the decades-old display server protocol that had long been the backbone of all those Linux graphical environments I've mentioned and more, with a simpler, more modern, and more secure version. The work on it started in 2012, but most people probably hadn't heard of it until recently. It took around twelve years from specification to broad use, passing through Fedora defaulting to it for GNOME in 2016, Ubuntu adopting and retreating and adopting again, and KDE's Wayland session going from experimental to a daily driver. By the time Plasma 6 shipped in early 2024, built Wayland-first, X11 was the compatibility option. Not the other way around. Twelve years because replacing a display server that's existed in some form since 1984 takes a lot of time. Gaming had its own quiet revolution. Proton landed in 2018, and it didn't work perfectly at first, but it improved fast. By the time the Steam Deck shipped in 2022, Linux gaming had gone from "technically possible if you fight it" to "install the game and press play." I simply had to get a Steam Deck, and I still symbolically carry it around when I travel even if I never actually get to use it. It's more of a religious artifact for me now, it really does feel like magic. There's a lot more that happened too, I could write a whole blog post about the Flatpak ecosystem, but the gist of it, all of this is working great for me. Twenty-five years in, the Linux desktop is better than it has ever been. It's not yet there for everyone. Accessibility still needs the same patient, sustained effort that Wayland got. [ GNOME 50, releasing soon it seems, includes the most significant Orca improvements in years: a redesigned preferences UI, automatic language switching for speech, and browse mode that works beyond web content.](https://ubuntuhandbook.org/index.php/2026/02/gnome-50-beta-is-out/?ref=tarakiyee.com) People have been predicting the "Year of the Linux Desktop" since I was burning CDs in my parents' house. It's a meme at this point. I think the framing was always wrong. There was never going to be a single year where everything clicked. There was going to be a long, uneven build where hardware support got good enough, then the display stack got replaced, then packaging got solved, then gaming became viable, then you look up and realize the landscape is fundamentally different from what it was fifteen years ago. The Linux desktop might be having a decade, and we might be somewhere in the middle of it. ### The Inventory I Should Have Done Years Ago URL: https://tarakiyee.com/the-inventory-i-should-have-done-years-ago/ Last updated: 2026-06-23T19:10:28.000Z A couple of months ago I finally got fed up. Another service cramming AI features into a plan I was already paying for. Another price increase dressed up as an upgrade. Another terms of service update that amounted to "we're doing this whether you like it or not." I'd been telling myself I'd sort out my infrastructure for years. I started looking at self-hosting guides and YouTube videos to see what the current state of things is. Most self-hosting guides start with software selection. "Install Nextcloud. Set up Proxmox. Here's a Docker Compose file you should use." The implicit assumption is that you already know what you need to replace and where your data lives. I thought about it, and I realised I really didn't. I had a rough idea, but at this point I have decades of infrastructure debt. And I didn't want this to be an average migration project. I love technology, I love open source, and I love to experiment. My frustration wasn't just about privacy or cost. It was about how my relationship with my own infrastructure had eroded over the years, one convenience at a time, until I barely recognised what I depended on. I wanted to turn what I know into a living project that actually serves my interests. Not just convenient drop-in replacements for proprietary services, but something I'd want to maintain. I said in the first post that this isn't a tutorial. It's not going to be a typical self-hosting project either. It should work, ideally, but I'm not afraid to mess around and find out. I'm willing to take measured risks, fail sometimes, make mistakes and learn from them. (*Tara from the Future: and I did.*) So before I started, I set myself some values: - **Autonomy over dependence.** - **Freedom over features.** - **Research over impulse.** - **Iteration over perfection.** - **Security over convenience.** - **Questions over assumptions.** Going by that last value, instead of switching one service and calling it progress, I decided to actually look at the whole picture first. Map every service, every device, every recurring charge, every account. Understand what I actually depend on before trying to replace any of it. I realise this doesn't sound iterative, but I also didn't want to build in the dark. Those values were to be taken on balance of things, not legalistically. I thought it would take a weekend. I figured I'd find maybe forty services. I was wrong on both counts. I spent a week observing myself. Every time I opened an app, logged into something, tapped a notification, I wrote it down. What do I reach for first in the morning. What would I notice if it vanished. What stores something I can't get back. By the end of the week I had a list of about forty services. It felt thorough. Email, cloud storage, password manager, a few streaming services, the blog's shared hosting, recipe tracker, some tools. At that point I still thought I was a few steps away from picking replacements, installing them, and calling it a day. Then I took a closer look at the password manager. I exported it to a CSV and opened it in a spreadsheet. 440 entries. Nearly 300 distinct services. Seven different email identities. There were credentials for services that no longer exist, platforms I'd forgotten I'd ever signed up for, services I must have tried once and never touched again. The password manager was the accidental diary of my digital life, and I'd never read it back to myself before. That changed the scope of the project. Migrating and consolidating forty "services" is a few weekends. Three hundred is something else entirely. Three email accounts formed the backbone of everything. Account recovery, service registration, two-factor authentication delivery, all routing through servers I didn't fully control. I needed to understand the recovery chain in case something went wrong, and I quickly realised I had set up things in a circular chain: Account A recovers via Account B, Account B recovers via Account A. A single simultaneous lockout, unlikely but not impossible, would have been catastrophic. No external recovery path existed. The inventory was helping me notice flaws in my setup I'd taken for granted. OAuth was another layer I dreaded mapping. "Sign in with Google" is presented as a shortcut. In practice, it's a coupling mechanism. My accounts had accumulated OAuth connections across two different Google accounts, meaning I couldn't even audit the full picture from a single login. The services connected via OAuth didn't know about each other, but they all shared a single point of failure. Platform SSO operates as an infrastructure monopoly. The path of least resistance creates dependency, dependency creates lock-in, and lock-in is leveraged into market position. I literally felt trapped for many years because I never felt I had the energy to unravel this dependency knot. I also downloaded my bank statements as PDFs and searched through them for recurring charges. Subscriptions I didn't remember signing up for. Price increases I'd never noticed. One service had quietly raised its rate three times over two years, each time a euro or two, never enough to trigger attention but enough to increase the original cost by more than half. The total monthly burn across all digital subscriptions was genuinely startling. Not because any single charge was unreasonable, but because the aggregate had never been visible as a single number. I've done a few subscription cleanups before, but never starting from the raw bank data. It turns out I'd only ever cleaned up the subscriptions I remembered having, or I noticed by chance. Digital subscriptions are designed to be easy to start and friction-laden to stop. A free tier becomes a paid tier becomes an increased paid tier, each transition smooth enough that resistance feels disproportionate to the increment. The aggregate, never presented as a single number, grows invisibly. I wonder if that's my fault or is it the [intended outcome of a business model that depends on inattention](https://www.ftc.gov/news-events/news/press-releases/2024/07/ftc-icpen-gpen-announce-results-review-use-dark-patterns-affecting-subscription-services-privacy?ref=tarakiyee.com). Amazon's internal name for their cancellation process was the ["Iliad Flow"](https://www.npr.org/2025/09/23/nx-s1-5543497/the-dark-patterns-at-the-center-of-ftcs-lawsuit-against-amazon?ref=tarakiyee.com). The Iliad, in case you didn't know, was Greek poet Homer's finest work, about the ten-year siege of the city of Troy. 🤖 ****Tara from the Future:** **I write these posts in advance, so sometimes I'd like to intervene with new developments in these TftF sections.* In September 2025, the EU Data Act's cloud switching provisions [took effect](https://digital-strategy.ec.europa.eu/en/factpages/data-act-explained?ref=tarakiyee.com): structured export formats, 30-day transfer windows, and switching fees capped at actual cost (to be eliminated entirely eventually). The right to migrate to your own infrastructure is now explicitly protected in EU law. The dependency graph this post describes is the thing the regulation is designed to address. Then I went through years of order confirmations, which started to reveal the hardware layer. Devices I can't remember where I stored. Phone cases tracing a device history I hadn't consciously tracked. Even returned items told a story: a device that didn't work out, now absent from memory but still present in the dependency graph of accounts I'd created during the return window. This helped create a fuller picture and finally round up the inventory. Now, came the tough realisation. You can't migrate email until you've set up infrastructure. You can't set up infrastructure until you've chosen an architecture. You can't migrate accounts until email is stable, because every account migration involves updating the registered email address. You can't decommission the old password manager until every credential has been moved and verified in the new one (mainly those pesky but necessary 2FA auth codes.) I sat with this information for a while. I'd started the inventory thinking I had a list of things to replace. What I actually had was the ingredients for a dependency graph, and it had an order that I had to figure out. Skipping ahead, picking the fun services first, would have meant rebuilding on a foundation I hadn't secured. Every "simple" migration has upstream dependencies. This mirrors the so-called "software supply chain" arguments in the digital sovereignty discourse, but they just call it that probably because it sounds more complicated and self-important than what it really is, it's just dependencies. You don't become autonomous by switching one service. You become autonomous by understanding your dependency graph and working through it in the right order, making informed choices on what to keep and what to replace, and making sure you have alternatives and contingencies. You also start borrowing whatever issues your dependencies have, because at some point you're going to have to deal with them. People problems. Licence problems. Security issues. That becomes your business too, to a certain extent, so you better understand them. With the inventory done, I could start to see the dependency graph. What I couldn't imagine yet was the architecture: where each service runs, how they connect, what the backup strategy is, how do I recover in case I mess things up royally. These are the questions many self-hosting projects I've seen answer by default, or not answer at all. The inventory was the first logical step for me so I can start answering them with agency. --- *This is part of the Autonomous Stack series, documenting my migration from proprietary services to self-hosted infrastructure.* *Previously: [Why I'm Doing The Autonomous Stack Series](https://tarakiyee.com/why-im-doing-the-autonomous-stack-series/).* *Next:* **[Three Servers and a Tunnel](https://tarakiyee.com/three-servers-and-a-tunnel/)** ### Why I'm Doing the Autonomous Stack Series URL: https://tarakiyee.com/why-im-doing-the-autonomous-stack-series/ Last updated: 2026-06-23T19:10:28.000Z I've spent most of my life trying to understand how information technology and people interact. Technology does what it says on the tin: it transforms people's lives, whether for better or for worse. It's also a proxy for power. When the people who control technological infrastructure are not the same ones who depend on it, more often than not that technology does not serve the interests of those dependents. The intentions of the people who control the technology are of little interest to me. It's the effects of that control that matter. This series is about how much control I can exercise over my own infrastructure, and the technical, policy, and physical limitations and trade-offs I hit along the way. I run Linux and Windows. I use Thunderbird and Gmail. I use both Delta Chat and WhatsApp, Mastodon and Bluesky. You get the point. I contribute to and advocate for open source. I've argued publicly that democratic control over technological infrastructure is a precondition for meaningful sovereignty. The gap between what I advocate and how I actually operate is not unusual. Most people who care about digital autonomy still have dependencies on the same concentrated infrastructure they don't own, or even critique. I always tinkered with self-hosting. Nothing consistent, but I'd run things, experiment, break them, learn. The instinct was there. But in my early thirties, I moved around a lot. New country, new ISP, new apartment, new priorities. When you're rebuilding your life every year or two, setting up a mail server is not high on the list. "I'll just use Gmail for now" seems like a rational choice when you don't know where you'll be in six months. Each move eroded another layer of control. First email went to the cloud. Then files. Then calendar, contacts, passwords. Not because I chose to give them up, but because I didn't have the stability to maintain the alternative. The problem is that "for now" has no natural expiration date. Once you're in, the switching cost only grows. More accounts linked to that email. More files in that Drive. More OAuth connections you forgot you granted. Every month you don't migrate is another month you're more locked in. And the platforms play into that. There's a reason why Microsoft Word documents look terrible on LibreOffice, or why my Nextcloud calendar doesn't sync cleanly with the Mac Calendar app. Incumbents make interoperability painful by design. And once you're locked in, the terms change. Do you want to lose your whole Google Drive, or give Google Gemini access to your data? Your "choice." By the time life stabilised, my personal infrastructure debt was enormous. And even though I knew it was a lot, I hadn't even realised the full scope of it. When I finally sat down to audit what had built up around me, the scale surprised me. Hundreds of services. Multiple email identities I'd forgotten about. Recovery emails that pointed to each other in a loop. Subscriptions quietly accumulating month after month. None of it was careless. Each compromise made sense at the time. Settling for the relatively easy choice was a relief when everything else was in flux. But defaults compound quietly, and by the time life stabilised, the dependency graph felt overwhelming. Doing that inventory gave me a starting point. Divide and conquer. I made a systematic plan to migrate my personal infrastructure to a self-hosted, FOSS-first stack. Email, files, calendar, passwords, code hosting. All of it moving to infrastructure I control. So what does that actually look like? Some of it will run on a VPS. Some will run on hardware in my home. Some I'm genuinely not sure about yet. The architecture decisions will be documented with actual reasoning: threat models, trade-off analysis, and honest assessments of where the self-hosted option is genuinely worse than what it replaces. This time, the concessions will come with a plan B. I won't always make the optimal choice that reflects who I aspire to be. I'm keeping Spotify for now. My Riot launcher isn't going anywhere. These are *\*informed, intentional\** dependencies rather than *\*default, unexamined\** dependencies. Every proprietary service that remains will be a conscious choice, and shouldn't get too comfy. I might come for it next when I have the energy and time. **Why document this** Self-hosting guides are abundant. What's rarer, I believe, is honest documentation of the decision-making process: why one tool over another, what the real operational costs are, where the pain points live, and what trade-offs feel acceptable. I've written about how architecture matters more than choices. I'm applying the same to my personal life. Picking Nextcloud or Forgejo is the easy part. Building a stack that you'll actually maintain, one that survives the Wednesday morning where something breaks and Google is one click away, requires thinking about sustainability, not just capability. I'll make some bold choices. I'll make some stupid choices. But if I'm right, the system should tolerate those. That's what I'm trying to demonstrate with this series. I won't be reinventing the wheel here, but rather applying years of learnings systematically. The migration starts with an inventory: auditing my essential services, devices, and data silos to understand the actual dependency graph before touching anything. Then architecture, resolving structural questions first, because where each service runs and how they connect constrains everything downstream. Then migration, one service at a time. Deploy, test, verify backups, move on. No dramatic exit. Each phase will get documented here, including the reasoning, the journey, and the mistakes. We'll see how it holds up. \--- *\*This is part of the Autonomous Stack series, documenting my migration from proprietary services to self-hosted infrastructure.* *\*\*Previously:* [*Welcome to Do Flamingos Know They're Pink.* ](https://tarakiyee.com/welcome-to-do-flamingos-know-theyre-pink/) *Next week: Taking Inventory (stay tuned).\** ### Oiling the Doors at FOSDEM URL: https://tarakiyee.com/oiling-the-doors-at-fosdem/ Last updated: 2026-06-23T19:10:29.000Z FOSDEM is a two day event where the Free University of Brussels (Specifically the ULB, or Université libre de Bruxelles, not to be confused with VUB, the other Free University of Brussels, because Belgium) hands over its Solbosch campus to thousands of FOSS enthusiasts celebrating, discussing and learning about their favourite technologies. It's driven by volunteers, and I've been going for the past three years. There are no tickets, lanyards or badges, just a whole lot of talks and presentations across two main tracks, 66 devrooms, lightning talks, Birds of a Feather sessions, and a junior track. Since my first FOSDEM, I decided that I don't want to just be a participant, and I started organising a devroom with an amazing bunch of people. Devrooms are essentially conference tracks that center around a certain topic or technology related to FOSS. It's completely self-organised, from picking topics, to coordinating with speakers, as well as running the room on the day of. FOSDEM provides the space, as well as the setup for livestreaming, and they do that for all 66 devrooms and both main tracks. The week before FOSDEM is increasingly becoming a busy one, with it ballooning to what is now being called the EU Open Source Week, which is all important, but for me, the main event will always be FOSDEM. I'm sure there are several other events with the same collaborative spirit, but for me I haven't felt this good about an event since the World Social Forum I attended in 2015. This year, and last year as well, the devroom started off great, all the speakers made it despite the weather and strikes, the room was set up early, and minor arguments with the projector were quickly settled. As the first speaker started, people kept streaming into the lecture room, and with each person entering there was a loud creak. Now, I'm particularly sensitive to noise, but in this case I think it was also disrupting the speakers. I moved to the outside of the room, and started nicely directing people to the other door leading to the room. It had a much more enjoyable cartoonish door creak, and was on the other side of the stage away from the speaker. I also reported the situation on the organisers chat, not expecting anything, but perhaps hoping against hope that this is something we can solve. I was getting incredibly annoyed by myself standing next to the door, being a gatekeeper of any sort never felt natural to me. But lo and behold, no less than a minute after I wrote my message, I got the reply that they will try to find the right kind of oil. And true to their word, I had a bottle of machine oil in my hand before the next talk had even started. The timing worked out well, I oiled (both) doors between talks, and only had to reapply once, and we quickly had two functioning doors. I'm a sucker for metaphors for FOSS, and I couldn't help but quickly recognise this as another great one. Sure, individually, many of the people in FOSS or at FOSDEM are great engineers, artists, writers, organisers, and administrators but what brings them all together is that they keep oiling the doors so others can come in. Whether you're working on documentation, or reviewing pull requests, working on design, improving accessibility, writing down plans, reviewing security, or making sure people get paid for their work, we're all just oiling doors for each other. I get annoyed when I hear the phrase "FOSS is punching above its weight", because I feel like it fails to capture the true weight of FOSS. If you're measuring its weight by number of features, or lines of code, or GitHub stars, or dollars, or pull requests, or closed issues, or commit counts, or release tags, or Hacker News upvotes, or Stack Overflow answers, or download numbers, or Docker pulls, or npm installs, or CVEs patched, or mailing list threads, or IRC messages, or forum posts, or roadmap items, or conference talks, or stickers distributed, you might get the wrong picture. That analogy also seems a lot less impressive when you consider that the "competition" FOSS is punching up against is a bunch of companies aggressively competing on who can waste the most of our planetary resources in order to make stonk go up and shareholder happy. When you experience spaces like FOSDEM, whether in-person or online (because we have to acknowledge that the fosdem flu is real and many of us can't risk it), you get to see a sub-section of the true weight of FOSS, which is all the people that keep the doors oiled. ### Welcome to Do Flamingos Know They're Pink URL: https://tarakiyee.com/welcome-to-do-flamingos-know-theyre-pink/ Last updated: 2026-06-23T19:10:29.000Z This blog has a new home. After years on WordPress shared hosting, it now runs on self-hosted infrastructure. Ghost on a VPS I manage, backed up to encrypted offsite storage, federated via ActivityPub. The name is new too. "Techverständiger" served its purpose, but it was always more job description than identity. "Do Flamingos Know They're Pink" is a better question. It's the kind of question I keep circling back to: how much do we understand about the systems we're embedded in? Do the tools we build shape us in ways we can't see from the inside? Flamingos aren't born pink, they become pink gradually due to their diet. ## What this blog is about This blog will continue to be what it's always been, a documentation of my journey, interests, and all the places my work and advocacy have brought me. At its core, it's about the interrogation of technology, the systems around it, and how technology helps and harms. Some posts are policy analysis: regulation, digital sovereignty, the economics of open source. Some are technical narratives: debugging sessions, infrastructure decisions, the gap between documentation and reality. Some are rants. Some are fiction. The common thread in my life is that I don't think technology itself is the interesting part of what I do. What's interesting is what technology does to people, institutions, and power structures. The code is incidental. The consequences are the story. ## Autonomy Tuesdays Starting next week, I'm publishing a series called the Autonomous Stack. It documents a project I've been working on for the past few months: migrating my entire digital life from proprietary services to self-hosted, open-source infrastructure. The series runs weekly on Tuesdays. Many of the posts are drafted already, covering everything from the initial inventory, through email migration, photo import, home lab deployment, and the steps it takes to self-host services that are reliable enough to daily drive. A lot has changed since I first started self-hosting two decades ago. It's not a tutorial, but the posts are honest about what went wrong, what cost more time than expected, and what trade-offs were made. If you've ever thought about self-hosting but wondered what the actual experience is like, not the deployment guide that ends at docker-compose up but the weeks of preparation, debugging, and documentation that surround that command, this is for you. I'll also use it as a vehicle to explore the big picture topics I talk about already and ground them in personal examples. The code is personal, and the personal is political. It will also explore pragmatism vs. ideology, a tension that runs through the whole project. ## What hasn't changed The tagline stays: another internet is possible. I still believe that, and it continues to drive me, and the migration makes it more concrete. I will not mince words, the world is incredibly bleak at the moment. If I didn't believe a different one is possible, I wouldn't be doing any of this. The infrastructure I'm writing about is the infrastructure this blog runs on. I'm practicing what I preach with renewed vigor and with greater consequences when I get them wrong. Just yesterday I thought I wouldn't be able to publish this blog because of a Ghost issue, but that was resolved. Welcome. There's a lot to talk about. --- *This is part of the Autonomous Stack series, documenting my migration from proprietary services to self-hosted infrastructure.* *Next week: Why I'm Doing This (stay tuned).* ### Building a Digital Sovereignty Castle in the Sky URL: https://tarakiyee.com/building-a-digital-sovereignty-castle-in-the-sky/ Last updated: 2026-06-23T19:10:29.000Z **I'm writing this article within the context of the SOAM "RE:FUND OUR DIGITAL FUTURE: REIMAGINING FUNDING ARCHITECTURES FOR PUBLIC INTEREST TECHNOLOGY”** **residency program I'm taking part in to order to create a new speculative institutional model with the goal of empowering open hardware infrastructure and promoting its development through an public institution funded by public bonds.** [**More information in the article where I announced it.**](https://tarakiyee.com/how-can-open-hardware-catch-up-with-open-source-software/) When European leaders gather in Berlin on Tuesday for the [Summit on European Digital Sovereignty](https://bmds.bund.de/aktuelles/eu-summit?ref=tarakiyee.com), they'll discuss artificial intelligence, open source software, cloud infrastructure, and data governance. They'll probably announce initiatives and emphasize the need for European tech champions. On paper, it all sounds good and welcome. But I fear it will fall short because we're building these lofty dreams on a foundation we don't control. All these digital sovereignty efforts must exist on layers we can't inspect, can't modify, and increasingly can't access. Every initiative, every investment, every ambitious plan for European technological independence runs on silicon designed with American tools, manufactured on highly proprietary machines, and fabricated in foundries owned by a handful of companies (collectively Hardware ***Infrastructure***, to make it more distinct from simply Open Hardware as it currently exists.) We're debating the architecture of upper floors while building on someone else's land, subject to someone else's rules, revocable by someone else's decisions. Open-source software's success creates dangerous complacency. Linux runs 96% of the world's top web servers. Kubernetes orchestrates cloud infrastructure for every major provider. This infrastructure commons enabled Europe to participate meaningfully in the digital economy without paying rent to American software monopolies. It works. It's real sovereignty at the software layer. The danger is that this success might lead some to believe digital sovereignty can be achieved through similar efforts at higher layers, just with sovereign clouds, "open source" AI models, or more open source software. It's not an unreasonable belief. It's just not addressing the full picture. Software sovereignty falls short when it runs on hardware we can't build. Every European open-source project, every sovereign cloud, every AI initiative executes on chips designed using tools from three American companies charging hundreds of thousands to millions per license. Those chips are manufactured using lithography equipment from ASML, extracting €180-380 million per machine, and fabricated in foundries subject to U.S. export controls and geopolitical pressures. When the United States restricts China's access to advanced chips and manufacturing equipment, it demonstrates precisely what infrastructure dependence means: your digital economy's foundation can be cut off by foreign policy decisions you don't control. Europe faces the same vulnerability. We just haven't experienced the cutoff yet. ## The Rent Extraction Architecture Before any European company can design a chip, before any university can prototype a climate sensor, before any nation can develop strategic hardware capabilities, they must license tools costing €100,000 to €1 million per engineer annually. You're not competing on technical merit. You're paying rent to access the tools everyone needs. ASML's lithography monopoly means every advanced chip depends on equipment from a single company. Only a handful of companies globally can afford the machines. This bottleneck exists partly because when governments funded EUV research, they chose proprietary winners rather than creating open access to publicly-funded knowledge. Manufacturing requires navigating proprietary relationships with foundries, with access requiring millions for production runs, proprietary process specifications, and increasingly, geopolitical alignment. A European company with a breakthrough chip design has no guaranteed path to manufacture. Every layer represents strategic vulnerability. You cannot build a sovereign cloud on chips you can't design with tools you can't access manufactured in facilities you don't control. ## Why Fab Subsidies Miss the Point Europe's primary hardware sovereignty response has been subsidizing chip fabrication plants, which addresses symptoms rather than causes. Yes, Intel's fab in Magdeburg and TSMC's facility in Dresden improve manufacturing capacity. But they don't address the deeper dependencies. Those fabs still require ASML equipment, designers still need American EDA tools, process technologies remain proprietary, and access still depends on geopolitical relationships. More fundamentally, fab subsidies don't create commons. They create additional proprietary capacity. Companies still pay rent at every layer. The infrastructure remains extractive rather than enabling. Consider Belgium's IMEC, often cited as a European success in semiconductor research. Despite public funding, IMEC operates on a membership model where companies pay fees for access. When 75% of the budget comes from corporate members, the institution serves those who can afford membership. Startups, universities, independent researchers, and nations seeking capability development are structurally excluded. IMEC creates shared proprietary research, not commons. Europe continues paying rent for technology infrastructure rather than building publicly accessible foundations, even when that research happens in Europe and is subsidized by European taxpayers. ## Open Hardware Infrastructure Already Exists, Kinda The bitter irony is that open hardware infrastructure already exists and works. It just lacks the institutional support that would transform it from impressive technical achievement into market-changing infrastructure. --- KiCad provides circuit board design tools rivaling proprietary alternatives, [CERN uses it](https://home.cern/news/news/computing/kicad-software-gets-cern-treatment?ref=tarakiyee.com). [Yosys performs chip synthesis](https://yosyshq.net/yosys/?ref=tarakiyee.com) competing with tools costing hundreds of thousands per license. RISC-V has [shipped over 10 billion cores](https://wccftech.com/x86-arm-rival-risc-v-architecture-ships-10-billion-cores/?ref=tarakiyee.com), with [Google](https://news.slashdot.org/story/18/03/31/0622248/open-source-risc-v-processor-gets-support-from-google-samsung-qualcomm-and-tesla?ref=tarakiyee.com), [NVIDIA](https://www.tomshardware.com/news/big-tech-players-risc-v-architecture,36011.html?ref=tarakiyee.com), and [Western Digital adopting it for production](https://www.tomshardware.com/news/western-digital-risc-v-processor-open-source,38200.html?ref=tarakiyee.com). [OpenROAD delivers complete chip design flows](https://theopenroadproject.org/?ref=tarakiyee.com) and has [fabricated real chips](https://today.ucsd.edu/story/open-source-semiconductor-chip-design-tool-celebrates-success?ref=tarakiyee.com). Open Process Design Kits from [SkyWater](https://github.com/google/skywater-pdk?ref=tarakiyee.com) and [GlobalFoundries](https://opensource.googleblog.com/2022/08/GlobalFoundries-joins-Googles-open-source-silicon-initiative.html?ref=tarakiyee.com) enable actual chip manufacturing without proprietary licenses. The technology works. What's missing is institutional infrastructure. Just like by the late 1990s, Linux worked technically. But companies didn't trust it for production until institutional infrastructure emerged: commercial support companies, professional training programs, established foundations providing governance, and critically, permanent employment for thousands of engineers maintaining production infrastructure rather than volunteer labor and temporary grants. Europe contributed significantly to that transformation for software. European companies employ thousands of open-source developers. European universities train engineers in open technologies. European infrastructure companies build businesses around open-source support. We never built equivalent institutions for hardware. That's the gap undermining every digital sovereignty initiative. ## The Missing Open Hardware Infrastructure Institution Europe needs permanent infrastructure for open hardware that eliminates rent extraction at foundational layers. Not another research consortium operating on membership fees. Not another subsidy program for proprietary capacity. A public institution designed specifically to create technology commons: production-grade open chip design tools, foundry access coordination, collaborative development platforms, and open standards. This requires: - Employing engineers at scale in permanent infrastructure positions, not temporary research grants - Patient capital through infrastructure bonds with 20-30 year maturities, not annual appropriations creating political vulnerability - Governance that prevents institutional capture while maintaining technical excellence and public accountability The model exists. Europe built permanent institutions to compete in cutting edge scientific research, in aerospace, and even in space. Even for open-source software, we're seeing the rise of institutions like the Sovereign Tech Agency in Europe. We need to do the same for hardware. Europe is already a decade behind. Every year we delay represents engineer talent lost, institutional knowledge not built, and strategic options foreclosed. Digital sovereignty built on proprietary hardware infrastructure isn't sovereignty. It's a castle in the sky: impressive in appearance, vulnerable in reality, destined to collapse when geopolitical winds shift. Europe has proven we can build technology commons through open-source software. It has created permanent institutions that transformed volunteer efforts into infrastructure powering the global digital economy. We need to do the same for hardware. Not after the next crisis demonstrates our vulnerability. Now, while we still have capability, capital, and partnerships to build comprehensive infrastructure before geopolitical fragmentation makes it impossible. Tuesday's summit offers an opportunity for genuine strategic vision rather than reactive crisis management. But it will show its true ambition based on whether it recognises that sovereignty requires foundations, not just upper floors. ### The UK's Online Safety Act: A Lesson in Technosolutionism URL: https://tarakiyee.com/the-uks-online-safety-act-a-lesson-in-technosolutionism/ Last updated: 2026-08-01T18:08:31.000Z The United Kingdom has just delivered the world's most expensive demonstration of why throwing technology at social problems doesn't work. After two years of ignoring expert advice and billions in compliance costs, the UK's [Online Safety Act](https://en.wikipedia.org/wiki/Online%5FSafety%5FAct%5F2023?ref=tarakiyee.com) has achieved the opposite of its stated goal by making the internet less safe. Six months into enforcement, Britain's techno-solutionist fantasy has crashed into reality with predictable results. Beneficial online communities have been obliterated, [VPN adoption has surged 1,400%](https://www.theregister.com/2025/07/28/uk%5Fvpn%5Fdemand%5Fsoars/?ref=tarakiyee.com), and the UK has created a perfect case study for why governments can't regulate away complex social problems with algorithmic band-aids and surveillance theater. If you wanted to design legislation to eliminate the internet's safest spaces for vulnerable people, you couldn't improve on the UK's approach. The Act's most spectacular own-goal has been systematically destroying community-run websites that provided genuine social support. Consider [Microcosm's 300 community websites serving 275,000 monthly users](https://www.techdirt.com/2024/12/20/death-of-a-forum-how-the-uks-online-safety-act-is-killing-communities/?ref=tarakiyee.com). These weren't dark corners of the internet. They were cycling forums, parenting advice sites, and local community hubs where people actually knew each other. Dee Kitchen, who ran these communities for nearly three decades, captured the government's logic perfectly: ["It's too vague and too broad and I don't want to take that personal risk."](https://reclaimthenet.org/uks-online-safety-act-drives-small-websites-to-shut-down?ref=tarakiyee.com) The community websites closed specifically because age verification would destroy the trust and openness that made them safe spaces. As site administrators noted: ["The impact that these forums have had on the lives of so many cannot be understated... approximately 28 years and 9 months of providing almost 500 forums in total to what is likely a half a million people."](https://www.lfgss.com/conversations/401475/?ref=tarakiyee.com) Meanwhile, harmful content on major platforms continues largely unabated. Tech giants with billion-dollar compliance budgets simply absorb fines as operating costs. [TikTok's £1.875 million penalty](https://www.ofcom.org.uk/online-safety/protecting-children/tiktok-fined-1.875m-for-providing-inaccurate-data-on-safety-controls?ref=tarakiyee.com) represents roughly 0.01% of [ByteDance's $155 billion annual revenue](https://www.emarketer.com/content/tiktok-expands-its-creator-offerings-bytedance-revenues-thrive?ref=tarakiyee.com), making it count less than a virtual parking ticket. Perhaps the crown jewel of the UK's techno-solutionist delusion is demanding "safe" encryption backdoors. Despite government admission that the necessary technology "does not yet exist," officials refused to let inconsequential details like reality or mathematics interfere with their mandates. [Ciaran Martin, who founded the UK's National Cyber Security Centre](https://en.wikipedia.org/wiki/Ciaran%5FMartin?ref=tarakiyee.com), called out this "magical thinking", essentially the belief that encryption can be weakened for government access while remaining strong against everyone else. This isn't a technical challenge; it's a [fundamental impossibility](https://www.globalencryption.org/2025/02/joint-letter-on-the-uk-governments-use-of-investigatory-powers-act-to-attack-end-to-end-encryption/?ref=tarakiyee.com) as the Global Encryption Coalition noted. Even the tech industry's response was swift and unified. Signal, WhatsApp, and Apple essentially told the UK government to choose between secure communications and backdoors. Instead of magically solving encryption, the UK triggered [a 1,400% surge in VPN adoption](https://www.ainvest.com/news/protonvpn-sign-ups-surge-1-400-uk-enforces-online-safety-act-age-checks-2507/?ref=tarakiyee.com) as users decided to route around the government's technical incompetence rather than submit to it. In other failures, within days of enforcement, automated systems were treating Conservative MP posts about grooming gangs, police arrest footage, and parliamentary speeches exactly like genuinely harmful content. This wasn't a bug, it's the inevitable result of the futility of trying to teach machines to understand human context, intent, and meaning. When platforms face [£18 million fines](https://en.wikipedia.org/wiki/Online%5FSafety%5FAct%5F2023?ref=tarakiyee.com) for missing harmful content, they predictably err toward censoring everything that might possibly be problematic, including discussions of the very problems they're supposed to solve. The meta-censorship problem showcases the system's absurdity: documentation of censored content gets censored, creating a feedback loop where evidence of the system's failures becomes impossible to discuss publicly. It's compliance theater at its finest. It is visible enough to inconvenience ordinary users, yet ineffective enough to let determined bad actors adapt around it. This reveals the UK's techno-solutionism's true beneficiaries: tech giants who can afford compliance theater while their smaller competitors get regulated out of existence. Meta and Google can absorb billions in compliance costs; [community forums run by volunteers cannot](https://www.newstarget.com/2025-01-03-uk-online-safety-act-death-knell-small-websites.html?ref=tarakiyee.com). he threshold-based requirements create what researchers call 'vastly disproportionate compliance incentives', which is academic speak for "we've built a regulatory country club and labeled it child safety." The UK has essentially using child safety as cover for the largest anti-competitive regulation in internet history, with the result being an internet that's simultaneously less safe and less accessible. Not to be outdone, the European Union watched the UK's comprehensive failure and decided to ask them to hold their beer. The EU is implementing almost [identical age verification systems](https://digital-strategy.ec.europa.eu/en/policies/eu-age-verification?ref=tarakiyee.com) that [require Big Tech technology as a key dependency](https://www.heise.de/en/news/Too-much-Google-Criticism-of-age-verification-system-for-Android-10501825.html?ref=tarakiyee.com) while pursuing deeply unpopular ["chat control" legislation](https://www.patrick-breyer.de/en/posts/chat-control/?ref=tarakiyee.com) that is planned be [adopted by October 2025](https://www.techradar.com/computing/cyber-security/the-eu-could-be-scanning-your-chats-by-october-2025-heres-everything-we-know?ref=tarakiyee.com). Despite [Poland's EU Presidency giving up on voluntary chat scanning](https://www.techradar.com/computing/cyber-security/chat-control-polands-eu-presidency-gives-up-on-the-voluntary-scan-of-your-encrypted-chats?ref=tarakiyee.com), the fundamental legislative momentum continues unchanged. European policymakers have learned nothing from watching their neighbours systematically destroy beneficial online communities while failing to protect children. They're implementing the same impossible technical requirements, ignoring the same expert warnings, and expecting different results. The UK's experiment has produced one unambiguously successful outcome: the largest grassroots digital rights movement in British history. [Over 290,000 citizens have signed petitions demanding repeal](https://www.ainvest.com/news/protonvpn-sign-ups-surge-1-400-uk-enforces-online-safety-act-age-checks-2507/?ref=tarakiyee.com), which is impressive political engagement for any cause, let alone internet infrastructure policy. [Proton VPN reported that 1,400% increase in UK signups within hours of enforcement](https://ppc.land/uk-online-safety-law-sparks-massive-vpn-surge/?ref=tarakiyee.com), noting this was ["sustained and significantly higher than when France lost access to adult content."](https://www.theregister.com/2025/07/28/uk%5Fvpn%5Fdemand%5Fsoars/?ref=tarakiyee.com) Multiple VPN providers reported similar surges, with [privacy apps dominating UK App Store charts for weeks](https://www.bankinfosecurity.com/vpn-use-surges-as-uk-online-safety-act-takes-effect-a-29076?ref=tarakiyee.com). The circumvention became so widespread that Ofcom demanded platforms prohibit content encouraging VPN use, creating a perfectly Orwellian situation where discussing privacy tools becomes prohibited speech under legislation supposedly designed to protect online safety. The UK's experiment inadvertently provided a perfect demonstration of what makes the internet genuinely safer: community-based moderation, user empowerment, and addressing real-world social problems that manifest online. [The forums destroyed by the Act had operated safely for decades](https://www.lfgss.com/conversations/401475/?ref=tarakiyee.com) through transparent governance, engaged user communities, and voluntary compliance with clear standards. These spaces worked because they created genuine human relationships where inappropriate content was quickly identified and addressed by people who actually cared about the community's wellbeing. Technical mandates destroy these approaches by replacing human judgment and community accountability with automated systems that users cannot understand, appeal, or improve. When algorithms make moderation decisions, users lose agency over their own spaces, communities lose the ability to set their own standards, and the social dynamics that create genuine safety disappear. This expensive UK experiment offers the world a choice: learn from their mistakes or repeat them at even greater scale. The evidence is overwhelming that age verification systems, encryption backdoors, and automated content moderation create more problems than they solve while systematically destroying community-based approaches that actually work. The lesson is clear but politically inconvenient: protecting people online often begins offline, and requires addressing factors like social isolation, inadequate education, economic inequality, and lack of community support. Online factors can also help, but those require giving users agency to manage their own communities, and investing in digital literacy. Unfortunately these solutions involve long-term investment in unglamorous things like schools, social services, and community programs, not exciting technology mandates that primarily serve our big tech overlords. ### The Hardware Innovation Monopoly Problem: Why Europe Should Stop Chasing Unicorns URL: https://tarakiyee.com/the-hardware-innovation-monopoly-problem-why-europe-should-stop-chasing-unicorns/ Last updated: 2026-08-01T18:08:31.000Z **I'm writing this article within the context of the SOAM "RE:FUND OUR DIGITAL FUTURE: REIMAGINING FUNDING ARCHITECTURES FOR PUBLIC INTEREST TECHNOLOGY”** **residency program I'm taking part in to order to create a new speculative institutional model with the goal of empowering open hardware infrastructure and promoting its development through an public institution funded by public bonds.** [**More information in the article where I announced it.**](https://tarakiyee.com/how-can-open-hardware-catch-up-with-open-source-software/) Europe has a hardware unicorn problem. Not the lack of billion-dollar startups that dominates policy discussions, but something far more fundamental: the continent has fallen into the trap of celebrating private control over public hardware infrastructure as innovation success. [ASML's dominance in semiconductor lithography](https://en.wikipedia.org/wiki/ASML%5FHolding?ref=tarakiyee.com) is held up as a European triumph, the [European Chips Act allocates €43 billion](https://commission.europa.eu/strategy-and-policy/priorities-2019-2024/europe-fit-digital-age/european-chips-act%5Fen?ref=tarakiyee.com) to create "European champions," and policymakers dream of building the next TSMC or Nvidia on European soil. Within the context of the digital sovereignty discussions happening, I highly question this approach. At worst, it will probably fail, and at best, it will continue to lock us in a system that treats essential technological infrastructure as private property rather than public commons. The real question isn't how to build European monopolies to compete with American and Asian ones, but how to reclaim democratic control over the infrastructure that shapes technological development through open hardware infrastructure. Information-age innovation operates on different principles that challenge the logic of private infrastructure ownership. Open Source Software development has demonstrated that publicly governed, collaborative models can consistently outpace private monopolistic alternatives. Linux powers most servers and smartphones, Apache runs most web servers, and countless developers contribute to open source projects that drive the digital economy. The success of open source software commons isn't just about licensing. It's about fundamentally different approaches to infrastructure governance. When development tools are publicly available, coordination platforms are democratically governed, and knowledge can be shared instantly, innovation accelerates because the best ideas can emerge from anywhere and spread rapidly across entire ecosystems. Hardware development has remained stuck in private monopolistic patterns partly because the underlying infrastructure remains privately controlled. Design tools, manufacturing coordination, and development platforms are owned by a handful of companies that optimize for extraction and scarcity rather than abundance and public benefit. This creates artificial barriers that concentrate innovation capability within a few large private organizations while excluding the broader public from participating in technological decision-making. The distinction between infrastructure and end products is crucial for understanding where collaborative models can succeed. Just as we don't expect every company to build their own internet protocols or programming languages, there's logic to having shared hardware development tools and platforms. When development tools are publicly available, coordination platforms are democratically governed, and knowledge can be shared instantly, innovation accelerates because the best ideas can emerge from anywhere and spread rapidly across entire ecosystems. This doesn't mean eliminating competition in final products, but rather ensuring the underlying infrastructure that enables innovation remains accessible to all participants rather than controlled by private monopolies. ASML represents both Europe's greatest semiconductor success and its most instructive failure. [The Dutch company holds a 100% monopoly in EUV lithography equipment](https://en.wikipedia.org/wiki/ASML%5FHolding?ref=tarakiyee.com) required for advanced chip manufacturing, with [82.9% overall market share in lithography equipment](https://www.marketsandmarkets.com/Market-Reports/extreme-ultraviolet-lithography-market-241564826.html?ref=tarakiyee.com). While the company claims to have invested $10 billion over 20 years to develop EUV technology, this narrative obscures the massive public investment that made ASML's monopoly possible. EUV development has consumed no less than $14 billion in funding over the years. Much of this came from public sources: [European EUV R&D programs were organized through MEDEA+, funded by national governments of the Netherlands, Germany, France and Belgium](https://www.asml.com/en/news/press-releases/2006/asml-industry-partners-advance-euv-development?ref=tarakiyee.com), and [the IST program supported by the European Commission involving more than 100 companies, institutes and universities](https://www.asml.com/en/news/press-releases/2006/asml-industry-partners-advance-euv-development?ref=tarakiyee.com). [ASML operates under a Cooperative Research and Development Agreement (CRADA) funded by the US government](https://en.wikipedia.org/wiki/ASML%5FHolding?ref=tarakiyee.com), and current EU programs like [Horizon Europe, Digital Europe, and the Chips Joint Undertaking have provided approximately €1.4 billion in public investments](https://www.asml.com/en/news/press-releases/2025/asml-and-imec-sign-strategic-partnership-agreement?ref=tarakiyee.com). This is the core issue with privatized public infrastructure: ASML extracts value from technology development that was largely funded by European and American taxpayers, yet makes private decisions about technical roadmaps, pricing strategies, and geographic access. While the company innovates impressively, it innovates in a narrow manner that serves its shareholders' strategic goals rather than the broader public interest that funded its development. Critical decisions about humanity's technological infrastructure are made in corporate boardrooms rather than through democratic participation or consideration of the public that financed its creation. More fundamentally, ASML's monopoly exists because the entire ecosystem of hardware development infrastructure has been privatized despite massive public investment in its creation. The company succeeded not just through technical excellence, but because taxpayer-funded research has been converted into proprietary and concentrated private assets. Design software from Cadence and Synopsys costs hundreds of thousands in Euros per license. Access to advanced foundries requires millions of Euros in minimum commitments. Manufacturing coordination happens through opaque networks of established players who control access to publicly-funded technological capabilities. This exemplifies the broader problem: when essential technological infrastructure becomes private property, it creates artificial scarcity and concentrates innovation capability within a few large organizations. The tools and platforms that should enable broad participation in technological development instead become barriers that exclude all but the most well-funded players. This isn't a failure of ASML as a company. It's a failure of the political and economic system that allowed decades of public investment in critical technological infrastructure to be converted into private property and monopoly control. When taxpayer-funded research is privatized and the resulting infrastructure is controlled by private monopolies, only companies with massive resources can participate in advanced development. The result is that decisions about humanity's technological future are made in corporate boardrooms, optimizing for shareholder returns rather than the democratic participation and public benefit that funded the original development. Europe's current semiconductor strategy perfectly illustrates how policy thinking has become trapped in privatization logic. [The European Chips Act aims to increase EU semiconductor production from 10% to 20% of global capacity by 2030](https://en.wikipedia.org/wiki/European%5FChips%5FAct?ref=tarakiyee.com), but this €43 billion investment follows traditional subsidy models designed to create private "European champions" that can compete with other private monopolies. This approach treats private control of technological infrastructure as inevitable rather than examining whether critical development tools and platforms should be publicly governed in the first place. [The top 10 semiconductor companies controlled 67% of global sales in 2024](https://futurumgroup.com/press-release/top-10-semiconductor-companies-grabbed-67-market-share-in-2024/?ref=tarakiyee.com), with capital requirements that have grown exponentially from thousands to billions of dollars. [Modern fabs require $15–20 billion investments](https://www.construction-physics.com/p/how-to-build-a-20-billion-semiconductor?ref=tarakiyee.com), creating barriers to entry that effectively exclude all but the largest private players. But these barriers aren't purely technical. They're partly the result of privatized infrastructure that creates artificial scarcity from publicly-funded research. Much of the cost comes from proprietary tools, duplicated private facilities, and coordination inefficiencies rather than fundamental physical constraints. Rather than questioning these assumptions about private ownership of technological infrastructure, European policy seems to accept infrastructure privatization and is scrambling for a piece of the cake. This creates a zero-sum competition where success is measured by which private entities capture market share rather than whether technological development serves our democratic goals or public interest. What we need is intentional investment into open hardware infrastructure: the design tools, development platforms, manufacturing coordination systems, and standards, which can be developed collaboratively even when final products remain competitive. The choice isn't just about technology policy. It's about what kind of relationship between technology and democracy Europe wants to build for the 21st century. Information-age innovation requires different organizing principles for its underlying infrastructure that prioritize public benefit over private extraction. Europe has the institutional capacity and collaborative traditions to lead this transition. The continent has great examples of creating international institutions that coordinate complex technical work, such as CERN and the European Space Agency. Building a similar institution to build and maintain open hardware infrastructure won't happen overnight, but requires long-term vision and patient investment. The benefits of opening up hardware infrastructure are undeniable. It will enable thousands of companies and millions of engineers to develop hardware solutions faster and more effectively than private monopolistic competition allows, while ensuring that decisions about technological development remain democratically accountable rather than concentrated in private hands. We should leave private hardware monopolies model in the past. Publicly governed open hardware infrastructure is the future we deserve, but only if we choose it. ### How can Open Hardware catch up with Open Source Software? URL: https://tarakiyee.com/how-can-open-hardware-catch-up-with-open-source-software/ Last updated: 2026-08-01T18:08:31.000Z First off- excited to announce that I've been accepted into the SOAM Virtual Residency program with the theme ""RE:FUND OUR DIGITAL FUTURE: REIMAGINING FUNDING ARCHITECTURES FOR PUBLIC INTEREST TECHNOLOGY". I applied because I thought this theme would be perfect to try to address the question in the title, because I believe that the core answer is that the current funding models that dominate tech development, from venture capital to ad-tech to data extraction, are fundamentally incompatible with the collaborative, commons-based approach that would make open hardware possible. When I look at FOSS, I see an ecosystem where open source has fundamentally reshaped how we build, share, and innovate. Entire industries and communities have been built on the foundation of freely shared code, collaborative development, and transparent architectures. But hardware? We've largely surrendered our digital infrastructure to proprietary black boxes. Our phones, laptops, routers, and IoT devices are increasingly locked down, impossible to modify, and controlled by a handful of corporations. We've accepted planned obsolescence, vendor lock-in, and the inability to truly own the devices we depend on. The consequences of this proprietary hardware dominance extend far beyond inconvenience. When our fundamental computing infrastructure is controlled by a few entities, we face security vulnerabilities that can't be independently audited or fixed, privacy concerns with no way to verify what our devices are actually doing, innovation bottlenecks where progress is gated by corporate priorities, economic dependencies that stifle competition and local manufacturing, and environmental costs from unrepairable, non-upgradeable devices. We've essentially built our digital society on a foundation we can't inspect, modify, or truly control. A thriving open hardware ecosystem is absolutely possible, and could bring our societies the same transformative benefits that open source software has delivered: greater innovation through collaboration, more secure and auditable systems, democratic control over our technological infrastructure, and economic models that serve public benefit rather than private extraction. The challenge isn't that open hardware can't work, but that it can't grow at the scale it needs to grow precisely because it's different from software. The material constraints, manufacturing requirements, and coordination challenges that distinguish hardware development demand different institutional approaches. It also doesn't help that the **open hardware infrastructure**, or the technologies we need to develop open hardware, are also proprietary. That's why we need a new type of institution: a public works for open hardware infrastructure. During this residency, I'm developing a concept for exactly that. I'm exploring how we might create sustainable economic models for open hardware infrastructure development that don't rely on the extractive capitalism that has shaped our current tech landscape. The fundamental challenge is economic and institutional. We need a public open hardware infrastructure works that is built around patient capital funding and mission-driven development, drawing inspiration from historical models like Dutch water bonds and modern transnational institutions like Airbus and CERN. To alleviate the challenges of bootstrapping such a massive infrastructure project, we need an approach where patient capital allows for the longer development cycles that hardware requires, and where mission-driven priorities can align with public benefit rather than private extraction. The goal isn't just to create more open hardware projects, but to design the institutional foundations that would make open hardware development sustainable and scalable at a systemic level. If that topic is interesting to you, then I'm all ears. I'm particularly interested in hearing from institutional designers interested in alternative models for tech financing, hardware developers who've struggled with the challenges of open hardware projects, manufacturers who are frustrated by proprietary tooling and licencing fees, policy researchers thinking about the regulatory and economic dimensions, and anyone who's frustrated with the current state of proprietary hardware dominance. I'll be sharing more details as as my residency progresses, but I'd love to start the conversation now. [Feel free to write to me on mastodon with your thoughts.](https://mastodon.online/@tarakiyee/?ref=tarakiyee.com) ### Gardens, Not Roads: Cultivating Open Source Communities URL: https://tarakiyee.com/gardens-not-roads-cultivating-open-source-communities/ Last updated: 2026-08-01T18:08:32.000Z Ever since its [eponymous report was published nearly a decade ago](https://www.fordfoundation.org/work/learning/research-reports/roads-and-bridges-the-unseen-labor-behind-our-digital-infrastructure/?ref=tarakiyee.com), the "roads and bridges" metaphor has dominated how many working with FOSS software, including I, think about open source sustainability. Nadia Asparouhova's influential 2016 report painted a picture of critical digital infrastructure that is prone to crumbling and neglect, drawing parallels to our physical highways and bridges. Another influential visual metaphor was the [xkcd comic 2347 "dependency". ](https://xkcd.com/2347/?ref=tarakiyee.com)The tower of precarious building blocks was powerful, and immediately comprehensible. Between both the report and the comic, these metaphors helped secure millions in funding for open source projects and brought much-needed attention to maintainer burnout. Even using phrases like "digital infrastructure" to refer to critical FOSS components is a metaphor of sorts, since infrastructure is by definition physical. It's also worth noting that the use of infrastructure metaphors to refer to our digital world is no way novel, who can forget the Superhighway Summit of 1994, the site where Al Gore "created the Internet". Another notorious case of metaphor fail was when Senator Ted Stevens referred to the internet as a "series of tubes", in an argument against Net Neutrality. But metaphors are inherently limited, and can be misleading when taken at face value. We use the dependency comic, "roads and bridges", and even "digital infrastructure", to explain that FOSS has become just as valuable as those things, and when it breaks it can have dangerous consequences for our society. However when these metaphors are taken too literally, we end up with misunderstandings about how best to maintain FOSS and the metaphor becomes counter-productive. Knowledge is knowing tomato is a fruit, wisdom is not putting it in a fruit salad. > **The roads and bridges metaphor, while a good analogy for the importance of FOSS, does not represent how open source projects are structured and how they function.** While FOSS may be just as important as physical infrastructure in terms of societal value, the critical error lies in assuming that because both are essential to the public interest, they should be built and maintained using the same approaches. This conflation creates a cascade of problematic assumptions that undermine effective support for the communities developing open source. > **Sidenote*: There's a similar issue when considering the topic of FOSS as a public good. Sure, the open source software itself can be classified as a public good if you follow the definition, but FOSS communities are NOT a public good.* **To understand why this metaphor falls short, we need to examine how the fundamental differences between open source infrastructure and physical infrastructure.** Consider how differently a bridge is built versus an open source project. A bridge represents a fixed solution to a specific problem, getting from point A to point B across an obstacle. It often emerges from centralised planning, contracted labour, and hierarchical project management. Typically a government entity decides what infrastructure is needed, designs it according to specifications, hires contractors to build it, and then operates maintenance programs with dedicated staff and budgets. Once built, the bridge's primary relationship with humans is maintenance: inspection, repair, and eventual replacement. Open source projects, however, are living systems of knowledge and collaboration that emerge from entirely different conditions. They may begin with someone scratching their own itch or a hobby project, communities forming around shared technical interests, or developers exploring what's possible with new approaches. Most of the work happens through voluntary coordination, distributed decision-making, and relationships built on reputation and mutual interest rather than formal contracts. These projects represent not just solutions to current problems, but platforms for discovering new problems worth solving and environments where people engage in meaningful work that develops their capabilities. > **This fundamental mismatch between metaphor and reality has led to well-intentioned but ultimately misguided approaches to open source sustainability.** The infrastructure metaphor has spawned an entire industry of data-driven approaches to open source sustainability that, while valuable for their intended purposes, address different challenges than supporting the people who create and maintain these projects. We now have sophisticated systems for measuring "criticality" based on dependency graphs, download counts, and contributor metrics. Organizations deploy tools to scan their codebases and identify "risky" dependencies. Funding programs that use data-based scoring to determine which projects deserve support. These approaches emerge naturally from treating open source like physical infrastructure, where quantitative assessment makes sense. Bridges either carry traffic loads safely or they don't. Water systems either deliver clean water or they fail. The appeal of these data-driven methods is understandable. They promise objectivity in allocation decisions, scalability in assessment processes, and clear metrics for accountability. For organizations managing hundreds or thousands of dependencies, automated analysis seems like the only practical approach. These tools excel at what they're designed to do: helping organisations understand their technical dependencies, assess risk exposure, and make informed decisions about resource allocation. But open source projects aren't bridges or water systems, and the quantified approach that works well for physical infrastructure serves different needs than understanding how collaborative development actually functions. While infrastructure frameworks focus on technical dependencies and data-driven approaches optimize for organizational risk management, neither addresses the fundamental question of how collaborative software development actually works. The most useful framework for understanding sustainability isn't infrastructure maintenance: it's recognizing open source projects as communities of practice. The concept of communities of practice, developed by anthropologist Jean Lave and educational theorist Etienne Wenger, describes groups of people who share a craft, profession, or passion and learn together through regular interaction. In this context, maintainers aren't simply individual contributors or employees performing discrete tasks; they're participants in ongoing, shared learning around specific domains, technologies, and problems. This perspective shifts attention from measuring outputs to understanding the social processes that generate those outputs. The knowledge that makes projects valuable isn't contained solely within the code itself. Every mature open source project accumulates layers of institutional knowledge: understanding why certain design decisions were made, how to navigate complex technical trade-offs, which approaches have been tried and abandoned, and how different components interact in subtle ways. This knowledge lives primarily in the relationships between people rather than just in documentation or commit messages. When experienced contributors leave, they take irreplaceable understanding with them that can't easily be reconstructed from technical artifacts alone. The process by which people become maintainers reflects this community-based reality. New maintainers aren't hired through traditional employment processes: they're developed through what Lave and Wenger call "legitimate peripheral participation." People typically begin by fixing small typos in code or documentation issues, gradually move to bug fixes, start reviewing others' contributions, and slowly take on more responsibility as they demonstrate competence and build relationships within the project. This progression requires mentorship, patience, and sustained community investment in helping newcomers develop both technical skills and social understanding of how the project operates. > **Understanding open source through the community of practice lens highlights why infrastructure only approaches to sustainability often miss the mark.** When we understand open source projects as communities of practice, the sustainability challenge becomes clearer. Projects don't typically die because the code stops working or becomes technically obsolete, they die because people can't afford to continue the collaborative work that keeps them vital. When knowledge-holders leave for paying jobs, when skilled contributors can't justify spending time on unpaid work, when the economic reality of maintaining software doesn't align with the value it provides to users, the community of practice gradually dissolves regardless of the code's technical condition. This distinction reveals why treating maintainers as infrastructure workers becomes deeply misleading. The maintainers and contributors aren't employees of a public works department who can be managed like infrastructure workers. They're individuals with complex motivations, constraints, and career trajectories who happen to be participating in something that produces public benefits. This becomes more complex when you consider companies and how they both contribute to and extract value from FOSS. Companies contribute to open source ecosystems in ways that aren't captured by simple metrics: they may hire maintainers or contributors, sometimes they provide infrastructure and hosting, some absorb legal and security risks, and help direct the technical direction towards real world demands.The problem isn't that companies provide no value. It's that the current system lacks mechanisms for ensuring proportional contribution relative to value derived. When a company builds a billion-dollar business on open source foundations, their voluntary contributions, however substantial, rarely reflect the economic value they're capturing. Many open source contributors also explicitly value the autonomy and intrinsic motivation that comes from voluntary participation. For some, the appeal of open source lies precisely in its distance from traditional employment relationships: the ability to work on interesting problems without corporate pressure, to learn new technologies at their own pace, or to contribute to something larger than themselves without making it their profession. This diversity of motivations suggests that sustainability solutions need to be similarly diverse. Some maintainers want professional recognition and compensation for their work. Others prefer to maintain the volunteer character of their contributions while having better support systems. Still others might want hybrid arrangements that provide some compensation without the full obligations of employment. The communities of practice framework accommodates this diversity by recognizing that different people participate for different reasons and at different levels of intensity. Rather than assuming all contributors want the same relationship with their projects, sustainable approaches can offer multiple pathways: professional maintainer roles for those who want to make open source their career, stipend programs for consistent contributors who want some compensation without full employment obligations, and improved support systems for volunteers who prefer to maintain the autonomy of unpaid work. > **A key insight is that "professionalising" open source or making it more resilient and secure doesn't mean turning all contributors into employees.** When we understand open source projects as ongoing communities engaged in knowledge creation rather than static infrastructure requiring maintenance, we can develop support systems that work with the collaborative dynamics that make these projects valuable. It means creating conditions where people can participate sustainably in whatever way aligns with their goals and constraints. This might include better tools for coordination, clearer governance structures, recognition systems that value diverse contributions, and economic models that provide support without compromising the collaborative character that makes open source valuable. > **Moving beyond the infrastructure metaphor doesn't diminish the importance of open source! It reveals new pathways to nurturing the communities that create our digital foundation.** The metaphor of roads and bridges served us well in establishing that open source matters as much as physical infrastructure. But just as we wouldn't use road maintenance techniques to tend a garden, we shouldn't apply infrastructure thinking to sustain collaborative communities. Open source projects are not roads to be paved and maintained, they are living ecosystems of learning and creation that require entirely different forms of care. The future of open source sustainability lies not in treating maintainers as infrastructure workers, but in recognising them as what they truly are: members of vibrant communities of practice whose collaborative knowledge-creation happens to produce some of the most valuable software in the world. When we design support systems around this reality rather than forcing these communities into an infrastructure framework, we create the conditions for open source to not just survive, but also flourish for generations to come!!! ### Digital Sovereignty in Practice: Web Browsers as a Reality Check URL: https://tarakiyee.com/digital-sovereignty-in-practice-web-browsers-as-a-reality-check/ Last updated: 2026-08-01T18:08:32.000Z Reading in [Servo's latest weekly report](https://floss.social/@servo/114755572125699444?ref=tarakiyee.com) that it's now passing 1.7 million Web Platform Subtests, I started wondering: How much investment would it build it into a competitive, independent browser, in the context of all this talk on digital sovereignty? [Servo](https://servo.org/?ref=tarakiyee.com) is an experimental web browser engine written in Rust, originally developed by Mozilla Research as a memory-safe, parallel alternative to traditional browser engines like Gecko and WebKit. After Mozilla [laid off the entire Servo team in 2020](https://servo.org/blog/2025/01/31/servo-in-2024/?ref=tarakiyee.com), the project was [transferred to Linux Foundation Europe](https://linuxfoundation.eu/newsroom/servo-web-rendering-engine-joins-linux-foundation-europe?ref=tarakiyee.com), where it continues to be developed with [minimal funding from individual donors and Igalia, a team of just five engineers](https://blogs.igalia.com/mrego/servo-revival-2023-2024/?ref=tarakiyee.com). Servo's progress demonstrates what's possible with intentional investment in independent browser projects. As initiatives like [EuroStack propose €300 billion investments in digital infrastructure](https://www.bertelsmann-stiftung.de/en/our-projects/reframetech-algorithmen-fuers-gemeinwohl/project-news/eurostack-a-european-alternative-for-digital-sovereignty?ref=tarakiyee.com) and [researchers proposing comprehensive roadmaps for "reclaiming digital sovereignty"](https://www.ucl.ac.uk/bartlett/publications/2024/dec/reclaiming-digital-sovereignty?ref=tarakiyee.com) through democratic, public-led digital stacks, browsers are an ideal test case to ground these ambitious visions in reality. The current browser landscape reveals how concentrated digital control has become. Roughly 75% of global web traffic flows through browsers based on Google's Chromium engine; not just Chrome, but Microsoft Edge, Samsung, and dozens of others. Apple's Safari dominates iOS but remains locked to their ecosystem. Firefox, once a genuine alternative, has declined to under 5% market share globally. This means American companies control how billions of users worldwide access the web. Every search, transaction, and digital service flows through infrastructure ultimately controlled by Silicon Valley. For societies valuing their independence and sovereignty, this represents a fundamental vulnerability that recent geopolitical events have made impossible to ignore. Digital infrastructure is as important as energy or transportation networks. Unlike physical infrastructure, however, digital systems can be controlled remotely, updated unilaterally, and modified to serve the interests of their controllers rather than their users. Browsers exemplify this challenge because they're both critical and seemingly replaceable. In theory, anyone can build a browser. The web standards are open, and rendering engines like [Servo](https://servo.org/?ref=tarakiyee.com) prove it's technically feasible. In practice, building browsers requires sustained investment, institutional coordination, and overcoming network effects that entrench existing players. If democratic societies can successfully coordinate to build and maintain competitive browser alternatives, it demonstrates their capacity for more complex digital sovereignty goals. If they cannot, it reveals the institutional gaps that need addressing. Firefox offers important lessons about the challenges facing independent browsers. Mozilla has indeed faced difficulties: declining market share, organizational challenges, and ongoing technical issues. The organization has also alienated its most dedicated supporters by pivoting toward advertising, AI initiatives and cutting their impactful public advocacy programs. However, Firefox remains the only major browser engine not controlled by Apple or Google, serving hundreds of millions of users worldwide. Its struggles reflect structural challenges that any alternative browser would face: the enormous engineering effort required to maintain web compatibility, the network effects favouring dominant platforms, and the difficulty of sustaining long-term technical projects through diverse funding sources. Servo's recent progress illustrates both the potential and the resource constraints of independent browser development. [Since 2023, Igalia's team of just five engineers](https://blogs.igalia.com/mrego/servo-revival-2023-2024/?ref=tarakiyee.com) has [increased Servo's Web Platform Test pass rate from 40.8% to 62.0%](https://servo.org/blog/2025/01/31/servo-in-2024/?ref=tarakiyee.com), added Android support, and made the engine embeddable in other applications, [even demonstrating better performance than Chromium on Raspberry Pi](https://news.itsfoss.com/servo-rust-web-engine/?ref=tarakiyee.com). This progress on a shoestring budget shows what focused investment could achieve, while also highlighting how resource-constrained independent browser development remains. Yet, building a competitive alternative browser infrastructure would require substantial but manageable investment. Here is a ballpark estimation I made based on existing browsers: Annual operating costs would include: - Engineering Team of ±50 developers, designers, managers etc.: €15 million. - Quality Assurance and Testing Infrastructure: €10 million - Security Auditing and Vulnerability Management: €10 million - Standards and Specification Development: €5 million. At this point I would just round up to around 50-70 million annually, which I'm sure would comfortably cover everything I missed. The [proposed EuroStack initiative already envisions €300 billion over multiple years](https://eurostack.eu/?ref=tarakiyee.com). Browsers represent a tiny fraction of what democratic societies already spend on strategic infrastructure. This calculation proves that the cost isn't the primary barrier: [the European Space Agency for example has had a budget of €7.8 billion in 2024](https://payloadspace.com/esa-2024-budget-rises-10-to-e7-8b/?ref=tarakiyee.com). Europe can afford to build a browser. It would probably take around 3-4 years to fully build an alternative browser from scratch, less so if it's a fork of one of the existing ones. Forking Chromium/Gecko or building upon Servo's foundation could reduce this timeline to 18-24 months for basic functionality, though achieving full web compatibility and market readiness would still require several additional years of refinement. The initial development sprint needs to be followed by a sustained engineering effort needed afterward, for maintaining compatibility with evolving web standards, fixing security vulnerabilities, and keeping pace with performance improvements. The core challenge isn't technical; it's institutional. How do you sustain long-term technical projects through democratic processes that span multiple countries with different priorities, resources, and political systems? Successful models exist. [The European Space Agency](https://www.esa.int/About%5FUs/Corporate%5Fnews/ESA%5Ffacts?ref=tarakiyee.com) coordinates complex multi-national technical projects. [CERN](https://home.cern/?ref=tarakiyee.com) manages cutting-edge research infrastructure across dozens of countries. [The Internet Engineering Task Force](https://www.ietf.org/?ref=tarakiyee.com) maintains critical internet standards through voluntary coordination among global stakeholders. The "Reclaiming Digital Sovereignity" proposal specifically addresses this challenge by advocating for "new public institutions with state and civil society representation" to govern universal digital platforms, alongside "multilateral agreements on principles and rules for the internet" as safeguards for autonomous, democratically governed solutions. Browser development could follow similar patterns: international frameworks that respect national sovereignty while enabling coordinated action, governance structures that balance technical expertise with democratic accountability, and funding mechanisms that provide stability across political cycles. The Reclaiming Digital Sovereignity's report's emphasis on "democratic international consortia" and "public knowledge networks led by a new public international research agency" provides concrete institutional models that could be adapted for browser development. Germany's Sovereign Tech Agency represents another model for public investment in digital infrastructure for the public interest. With all that being said, browsers represent one of the more achievable digital sovereignty goals. They're built on open standards, rely heavily on open source components, and face fewer network effects than platform-based services. Other areas of the technology stack would be far more challenging, and far less open. Success here would demonstrate that democratic societies can coordinate effectively on complex technical infrastructure and pass the first hurdle. Failure would reveal institutional gaps that need addressing before attempting more ambitious digital sovereignty goals. Democratic digital sovereignty is challenging but feasible, if societies are willing to think institutionally, invest sustainably, and build incrementally rather than trying to recreate Silicon Valley with different ownership structures. Ultimately, the real question isn't whether democratic societies can build alternative technologies, but whether they can build the democratic institutions necessary to govern them effectively across the complex realities of international coordination, competing priorities, and long-term sustainability. I believe browsers offer an ideal place to start testing these institutional innovations. The technical challenges are surmountable. The institutional ones remain to be proven. *Views expressed are personal and do not represent any organization.* ### FOSS is more than just Licences URL: https://tarakiyee.com/foss-is-more-than-just-licences/ Last updated: 2026-08-01T18:08:32.000Z Open Knowledge Foundation Germany has just released a new report titled: "[From Software to Society: Openness in a Changing World](https://okfn.de/publikationen/fromsoftwaretosociety/?ref=tarakiyee.com)" by Dr. Henriette Litta and Peter Bihr (I was also interviewed for it). The report talks about what openness means in our digital ages, both from the history of openness and evaluates current challenges. One of the report's key insights is that "Openness is not neutral"—a point that resonates deeply with me. I often find myself frustrated with limited imaginations of what free and open source software is and should look like and what it should accomplish. The recent "open source AI" definition debacle has made this painfully clear. Watching the Open Source Initiative contort themselves to legitimize technologies that rely on extractive labor and environmental gluttony at a desperate bid for relevancy shows how hollow these older definitions have become, that even the organisation that claims to defend the open source definition just ignores a key tenet because it's not "practical" (read: profitable). Which is why we need a better definition for what makes a technology truly open beyond the issue of licencing or making source code available. Making source code available doesn't automatically create ethical practices or sustainable communities. A permissive license doesn't prevent maintainer burnout, toxic communities, or corporate capture of standards. I'm not proposing we throw it away, I still believe firmly in the four freedoms. But we need a more holistic definition. And there is still potentially some room for improvement in the licencing realm. The OKFN report for example refers to the need for "protective mechanisms such as fair licences and share-back models". That said, I have some more thoughts to share on how to evaluate and improve the openness of the FOSS ecosystem more holistically. I'm not about to propose a full definition here, but here are some aspects I think should be considered: - **Open standards and interoperability.** True openness requires genuinely open standards and meaningful interoperability, not just open source licenses. We've seen how open protocols and formats can enable entire ecosystems to flourish, especially looking at internet technologies. Market concentration undermines even the most open standards when monopolies can embrace, extend, and extinguish at will. To reference this [recent research by Clement Perarnaud and Francesca Musiani on QUIC's standardization](https://journals.sagepub.com/doi/epub/10.1177/14614448251336438?ref=tarakiyee.com), even "open" standards processes can become vehicles for corporate control when dominant players leverage their resources to reshape fundamental Internet architecture. Google's QUIC development demonstrates how a company can mobilize superior "human resources, technical means, and strategic vision" to effectively capture standards bodies while maintaining the appearance of openness. - **Fair work practices, not free labor.** The maintainer crisis won't be solved by better licenses but by sustainable funding models, reasonable expectations, and treating the labor that builds our digital commons with dignity. The report emphasizes, we need "targeted investment in innovation for the common good"—which must include investing in the people who maintain our infrastructure. - **Democratic governance structures.** Our critical infrastructure shouldn't depend on benevolent dictators or corporate whims. We need transparent, accountable governance that serves communities, not shareholders. - **Worker organization.** We're stronger together than as atomized individual contributors. Other industries have learned this, FOSS developers can too. - **Inclusive communities.** Codes of conduct aren't just theater; they're about creating spaces where everyone can contribute without fear or harassment. There is a loud section of developers in FOSS communities that seem to believe that diversity is a zero sum game, but it isn't. We need more contributors and maintainers, and the only way to grow is to remove the barriers that have historically marginalised diverse communities from participating. Ultimately, I think we need to build new structures and institutions, ones that understand openness as a holistic practice, not just a licensing strategy or a vehicle to stay up to date with hype technologies. Organizations that speak for workers, not just code, or capital. This blogpost won't resonate with everyone, but I'm not writing this to provoke a reaction or argue, so if you find yourself at odds with what I wrote, here is my permission for you to let go and live your day. If it did resonate with you however, I would love to talk more about how we can better build these structures and institutions that can make FOSS more holistically open, through the communities we build, the standards we protect, the labor we organize, and how we treat each other. ### The Last CVE: A Science Fiction Short Story URL: https://tarakiyee.com/the-last-cve-a-science-fiction-short-story/ Last updated: 2026-08-01T18:08:33.000Z *this is a totally work of fiction not inspired by any events that happened today or anytime or by any people.* In the bleak January of 2035, Huda Ziade stared at her terminal, the blue light casting harsh shadows across her face. The air around her smelled like burnt silicon and broken dreams. Her breath formed clouds in the cold underground bunker, the latest hideout for the Rote Chapeaux collective she'd founded after the collapse of the global vulnerability management system. Huda's fingers traced the edge of the secure terminal where their final allocation was stored. She remembered the day the CVE program collapsed, in fact, everyone remembers where they were when they got the letter from the board. The frantic messages, the digital equivalent of a bank run as CNAs hoarded whatever allocations they could grab. No new allocations could be made, but CVE's only grew in usage and importance, eventually becoming a precious and scarce material. Huda had seen the writing on the wall for the small open source CNA where she was the only employee. She took what remaining allocations they had and went underground, establishing the Rote Chapeaux, a collective of ethical hackers and security researchers. For years they used their existing allocations, and whatever they could robin hood off of the corporations, to keep critical public infrastructure afloat. Naturally, the corporations didn't like that, since it ate into the profits they would get from replacing public software with their products. In the meantime, these CNA corpos had organized into digital fiefdoms, with security teams that rival small countries, treating vulnerability identifiers like precious metals. No matter how careful they were, the Rote Chapeaux kept getting raided, but they would survive and move. The last raid by MetaBet, one of the largest and most ruthless security shogunates to emerge from the chaos, on their Montreal hideout had been the most brutal. They'd managed to save only the essentials: equipment, their allocation database, and that single, precious remaining CVE. Her terminal pinged. A message from Elias, their MetaBet insider. Her heart skipped. He was supposed to be deep undercover. "Found something. Critical. At least 9.8\. Get on secure channel now." She established the connection through seven proxy jumps and a three-hop onion router. When Elias's face appeared, she barely recognized him. His once-meticulously trimmed beard was wild, dark circles shadowing bloodshot eyes. "They're onto me," he said, his voice tight. "MetaBet swept my sector this morning. Three analysts disappeared." "How long do you have?" Huda asked, her mouth dry. "Minutes." Static distorted his image. "But what I found... it undermines everything—banking, medical systems, power grids, even nuclear ICBMs." "How?" "Quantum authentication vulnerability in OAuth. And MetaBet isn't patching it—they're weaponizing it." His voice dropped. "They'll selectively protect their clients while letting everyone else burn. Deployment in seventy-two hours. I'm sending everything." This didn't feel like a normal data transfer, instead it felt very solemn, as if the bits and bytes making their last confession before a digital judgment day. It crawled: 12%... 17%... 42%... A crash came through the channel. Elias looked over his shoulder, his face settling into grim resignation. "They found me. Use the last CVE, Huda. This is it." The connection died with the file transfer frozen at 69%. The lab door hissed open. Talia rushed in, face tense. Huda minimized a second terminal window. "Let me guess. Three hours before they find us?" "Who broke protocol?" "Elias had no choice." Huda swiveled her monitor. "Look." Talia's eyes widened as she scanned the partial data. "We need to evacuate. Now. MetaBet aren't your average script kiddies—they're the kind of hackers with assault rifles and nano-drones." While Talia woke the others, Huda recovered what she could from Elias's data. The vulnerability exploited how quantum states were verified during authentication challenges. With the right sequence, an adversary could bypass any QAuth system with minimal resources. This wasn't just a bug—it was digital doomsday, the cyber-apocalypse that would send humanity back to the stone age with a single keystroke. The collective gathered, dismantling equipment with practiced efficiency. Huda laid out the quantum authentication flaw, its timeline, and the potential casualties—billions. "Then it's clear," said Talia. "We use our last CVE to alert the world." An alert restored the hidden terminal Huda had minimized. A medical file glowed ominously—patient ID 7734-JL. Underneath, a treatment schedule with a message: "TREATMENT PROTOCOL READY. AUTHORIZATION WINDOW: 24 HOURS." "Is JL who I think it is?" asked Ravi, their youngest member. Huda nodded. Jun-Li Ziade, her brother, was suffering from nanobot corruption. The experimental treatment protocol was being falsely flagged as malicious by security systems. Without a properly registered CVE, the protocol wouldn't run on medical machines. This was the notification she's been dreading for weeks: Jun-Li has reached the front of the treatment queue and she still hasn't found a bypass that didn't involve using their last CVE. The room went still. Five pairs of eyes fixed on her. "Your brother." Talia's voice hardened, her eyes darting to the terminal. "You've been hiding that from us?" Huda didn't flinch. "The treatment protocol could help thousands with nanobot corruption." "And MetaBet's exploit will collapse civilization as we know it," Marcus said, the former CERT coordinator's voice gentle but firm. "I knew what the choice would be," Huda replied. "I thought I'd find another way." "The universe has a cruel sense of timing," Dima said. Ravi stood, his chair scraping against concrete. "We're really considering this?" "I have a chance to save my brother," Huda said, her voice gaining strength. "I could save the world's infrastructure, but these corpos—they're relentless. They'll find another zero-day, all while we're out of allocations. This is it. We gave it the good old college try, but our war against them was always going to end this way. This is our last stand." "What about MY brother? Did you think about that when you sent him to MetaBet?" burst Ravi. "Ravi—" Marcus began, but was cut off by the sudden wail of proximity alarms throughout the bunker. "Motion sensors triggered," Dima reported. "MetaBet team approaching." "We don't have time for debate," Talia urged, already packing essential equipment. "Make the call, Huda." All eyes turned to her. The world, or her brother. The last CVE. The answer was painfully clear. ### Training an AI on Ancient Undeciphered Texts: What I Wish I DIDN'T Learn URL: https://tarakiyee.com/training-an-ai-on-ancient-undeciphered-texts-what-i-wish-i-didnt-learn/ Last updated: 2026-08-01T18:08:33.000Z As longtime readers of this blog might be aware, I've long been skeptical of machine learning and its so-called "intelligence". The AI industry, aided by clueless futurists and grifters, has abused our tendency to anthropomorphize what are essentially statistical processes, whether it's transformer architectures, diffusion models, or large language models (LLMs). Scientists and politicians, out of fresh ideas and worried for their jobs, have gone along with this intellectually dishonest and dangerous marketing campaign. *Quick explanation for newcomers: When they say an AI "learns," it's really just finding statistical patterns in data—like noticing that the word "dog" often appears near "bark" or "pet." It doesn't understand these concepts; it just recognizes patterns in how words appear together.* This is not a mid-21st century problem: [IBM's Watson was supposed to cure cancer, but its only achievement was winning at Jeopardy!](https://www.statnews.com/2017/09/05/watson-ibm-cancer/?ref=tarakiyee.com). The ["AI winter" ](https://www.historyofdatascience.com/ai-winter-the-highs-and-lows-of-artificial-intelligence/?ref=tarakiyee.com)of the 1990s seems forgotten by investors pouring billions into systems that fundamentally operate on the same principles, just with more planet-draining computing resources, data and a glitzy marketing campaign. While pattern recognition itself has limits, as a technologist I was always curious what happens when these new machine learning techniques are applied to the unknown. I'm talking about texts that are incomprehensible to us and have long been thought to be meaningless. I figured I could hack something together, combining online tutorials and the one neural networks class I took in college in 2012. To be clear, I didn't expect any breakthroughs, merely an opportunity to demonstrate the hollow claims of AI "understanding" and the limits of attention mechanisms and embedding spaces. What I got instead was a reality check that makes me reconsider my long held convictions against AI. (And before you AI evangelists start celebrating - it's NOT what you think). ## Dataset Compilation For those unfamiliar with undecipherable texts: The [Voynich Manuscript](https://beinecke.library.yale.edu/collections/highlights/voynich-manuscript?ref=tarakiyee.com) is a mysterious illustrated codex from the 15th century written in an unknown writing system. Despite a century of attempts by cryptographers and linguists, nobody has successfully deciphered it. The [Rohonc Codex](https://en.wikipedia.org/wiki/Rohonc%5FCodex?ref=tarakiyee.com) is similarly mysterious, discovered in Hungary with nearly 450 pages of strange symbols accompanying religious illustrations. There is no guarantee that feeding them into a machine learning model would yield anything other than statistical noise, and that's precisely what I hypothesized would happen. I figured it would be easiest to begin with publicly available data. Thankfully, many of these undeciphered texts have been digitized and placed online by various academic institutions. The Voynich Manuscript has been fully scanned and is available through Yale University's digital collections. For the Rohonc Codex, I found academic publications that included high-quality images. Initially, I explored ways to process the manuscript images directly, but I quickly realized that this was a task that would have required expertise in computer vision I don't possess. Luckily, I came across existing transcriptions that I could work with. For the Voynich Manuscript, I opted for the [EVA (Extensible Voynich Alphabet) transcription system](http://www.voynich.nu/transcr.html?ref=tarakiyee.com) developed by René Zandbergen and Gabriel Landini, which represents each Voynich character with a Latin letter. For the Rohonc Codex, I used the system devised by [Levente Zoltán Király & Gábor Tokai in their 2018 paper.](https://www.academia.edu/37334448/The%5FRohonc%5FCodex?ref=tarakiyee.com) ### Preprocessing Pipeline The raw transcriptions weren't immediately usable for modeling. I had to implement a comprehensive preprocessing pipeline: def preprocess\_manuscript(manuscript\_data, script\_type): \# Document segmentation using connected component analysis segments = segment\_document(manuscript\_data) \# Normalize character variations (a crucial step for ancient texts) normalized\_segments = \[\] for segment in segments: \# Remove noise and standardize character forms cleaned = remove\_noise(segment, threshold=0.15) \# Critical: standardize similar-looking characters normalized = normalize\_character\_forms(cleaned) normalized\_segments.append(normalized) \# Extract n-gram statistics for structure detection char\_ngrams = extract\_character\_ngrams(normalized\_segments, n=3) word\_candidates = extract\_word\_candidates(normalized\_segments) \# Create document-level positional metadata \# This enables learning document structure positional\_data = extract\_positional\_features( normalized\_segments, segment\_type\_classifier ) return { 'text': normalized\_segments, 'ngrams': char\_ngrams, 'word\_candidates': word\_candidates, 'positions': positional\_data, 'script\_type': script\_type } This preprocessing was particularly important for ancient manuscripts, where character forms can vary significantly even within the same document. By normalizing these variations and extracting positional metadata, I created a dataset that could potentially reveal structural patterns across different manuscript systems. ## Training the Model With a properly preprocessed dataset assembled, I attempted to train a transformer model from scratch. Before achieving any coherent results, I came across some major hurdles. My first three attempts resulted in the tokenizer treating each manuscript as essentially a single script rather than learning meaningful subunits. This resulted in extremely sparse embeddings with poor transfer properties. The standard embeddings performed terribly with the manuscript data, likely due to the non-linear reading order of many Voynich pages. I had to implement a custom 2D position embedding system to capture the spatial layout. Yet, no matter what I tried, I kept running into mode collapse where the model would just repeat the same high frequency characters. But I didn't want to stop there. I consulted a few friends and did a shit-ton of reading, after which I redesigned the architecture with specific features to address these issues: \# Custom encoder-decoder architecture with cross-attention mechanism config = TransformerConfig( vocab\_size=8192, # Expanded to accommodate multiple script systems max\_position\_embeddings=512, hidden\_size=768, intermediate\_size=3072, num\_hidden\_layers=12, num\_attention\_heads=12, attention\_dropout=0.1, residual\_dropout=0.1, pad\_token\_id=0, bos\_token\_id=1, eos\_token\_id=2, use\_cache=True, decoder\_layers=6, \# Critical for cross-script pattern recognition shared\_embedding=True, # Using shared embedding space across scripts script\_embeddings=True # Adding script-identifying embeddings ) \# Define separate tokenizers but shared embedding space voynich\_tokenizer = ByteLevelBPETokenizer(vocab\_size=4096) rohonc\_tokenizer = ByteLevelBPETokenizer(vocab\_size=4096) latin\_tokenizer = ByteLevelBPETokenizer(vocab\_size=4096) \# Initialize with appropriate regularization to prevent hallucination model = ScriptAwareTransformer( config=config, tokenizers=\[voynich\_tokenizer, rohonc\_tokenizer, latin\_tokenizer\], regularization\_alpha=0.01, # L2 regularization to prevent overfitting dropout\_rate=0.2 # Higher dropout to prevent memorization ) training\_args = TrainingArguments( output\_dir="./model\_checkpoints", per\_device\_train\_batch\_size=4, evaluation\_strategy="steps", save\_steps=1000, \# Custom learning rate scheduler with warmup learning\_rate=5e-5, warmup\_steps=1000, weight\_decay=0.01, \# Gradient accumulation for effective larger batch size gradient\_accumulation\_steps=4 ) trainer = Trainer( model=model, args=training\_args, train\_dataset=tokenized\_dataset, \# Custom loss function with diversity term compute\_loss=diversity\_aware\_loss ) I'll happily expand on the key improvements here if it isn't clear from the code in a future blogpost, but all I have to say now that this time it "worked". Over multiple iterations, the AI began producing outputs that at least visually mimicked the original texts. Yet, obviously since I couldn't understand the original texts, the outputs of this model were also nonsensical. *Keep in mind that the AI isn't actually understanding these texts in any capacity, it's just trying to predict what symbol might come next based on patterns it's seen. It's like if you noticed that in a foreign language, the squiggle "λ" often follows the symbol "Ω"—you might learn to predict this pattern without having any idea what either symbol means. This distinction between prediction and comprehension is crucial: your phone's autocomplete might suggest "umbrella" when you type "I need an..." but it doesn't understand the concept of rain or shelter—it's just seen this pattern before.* **Note on Training Costs:* The computational requirements for this experiment weren't trivial. I spun up a multi-GPU instance with four A100s, which cost roughly $12 per hour. Training took approximately 72 hours for the final model, consuming around 600 kWh of electricity according to the provider's dashboard. This was after several failed attempts and architecture experiments that collectively took about two weeks of compute time. The preprocessing pipeline alone took nearly 14 hours to run on the full corpus.* *The total computing cost came to just under $8,000—hefty for a personal project, but I'd stumbled across an old laptop and found a forgotten Dogecoin wallet from 2014 with a small fortune inside and this seemed like the best use of my unplanned wealth.* ## Control Experiments and Statistical Validation To verify whether the model was actually learning meaningful patterns versus hallucinating connections, I implemented several control experiments. First, I created versions of each manuscript with randomly shuffled characters but preserved positional information. The model performed significantly worse on these shuffled versions, suggesting it wasn't just learning positional biases. Then, I created my own artificial "manuscripts" using Markov chain generation based on the character statistics of the real manuscripts. The model could distinguish these from real manuscripts with 78% accuracy. Finally, I systematically removed each manuscript from training and then tested the model's ability to process it. Performance dropped substantially when testing on unseen manuscripts, indicating the model wasn't generalizing to truly novel scripts. *One thing I would like to highlight here is is the sheer computational resource intensity of systematically testing an AI model's behavior. Each permutation test required thousands of forward passes through the model. Rather than keeping my existing instance running continuously, I wrote an orchestration layer which allowed me to parallelize these tests at about 30% of the standard cost.* *Even with this optimization, the full suite of validation tests I described cost around $3,500 in compute resources and represented almost a week of continuous computation. This is one reason why rigorous validation of AI models is often shortchanged in both research and industry—the compute costs of thorough testing often rival or exceed the training itself.* *In general, the computational demands of modern AI are staggering and often overlooked. When researchers talk about "training a model," they're describing a process that can consume as much electricity as a small household uses in months. The largest models today (like GPT-4) are estimated to cost millions of dollars just in computing resources to train once. For context, the model I built for this experiment used a tiny fraction of the resources needed for commercial AI systems (about 0.001% of what's needed for the largest models), yet still cost thousands of dollars.* Now back to the experiment. To validate whether the model was learning meaningful structures, I had an idea. What if I cross-trained it on known languages, mixing the undeciphered texts with English and Latin corpora. This was a bit beyond my comfort zone, so I consulted my friend C1ph3rz, who shares my interest in cryptology and has a background in computational linguistics. She was skeptical, but found the methodology intriguing. Instead of treating the Voynichese text as an independent linguistic structure, the model began injecting Voynichese symbols into Latin sentences. Here's an example from one training epoch: ``` Original Input: "Omnia vincit amor; et nos cedamus amori." Model output: "Omnia vincit ♐︎♄⚹; et nos cedamus ⚵♆⚶." ``` The symbols weren't random substitutions, the same Voynichese glyphs consistently replaced specific Latin words across different contexts. This was annoying since I couldn't rule out that the model was getting confused due to the way I represented the training data. I spent two days debugging the tokenizers, convinced I'd made an implementation error. Yet, everything seemed to be working as intended, except for the output. It was at this point that I had to confront the first uncomfortable conclusion of this experiment: was the model revealing some (HIGHLY unlikely) linguistic connections between these manuscripts that eluded dozens of far more experienced researchers? Or was it merely creating convincing hallucinations that appeared meaningful to me? ## Further Analysis and Emergent Nonsense I was reviewing the model's attention maps when something caught my eye. Here's what the visualization showed for one attention head when processing a Voynich sequence: ``` Attention head #3, sequence:"qokeedy.shedy.daiin.qokedy" Attention weights: [0.03 0.05 0.84 0.04 0.04] ^^^^ Strongly focused on "daiin" ``` The model consistently focused on the substring "daiin" whenever it appeared, despite there being nothing visually distinctive about it in the manuscript. When I searched the corpus, this sequence appeared on 23 different folios, often in completely different contexts—botanical pages, astronomical sections, pharmaceutical recipes. I plotted every instance where the sequence "daiin" appeared in the Voynich manuscript and compared it to where the model predicted it should appear: ``` Actual occurrences: Folios 1v, 3r, 8v, 16r, 22v, 67r, 88v, 103v Model predictions: Folios 1v, 3r, 8v, 16r, 22v, 67r, 88v, 103v, 115r ``` The model correctly identified every actual occurrence, plus one additional folio (115r). When I checked folio 115r, "daiin" didn't appear—but the visually similar "qokeedy" did, with just one character difference. How did the model know to group these? I hadn't programmed any visual similarity metrics. Looking through the hidden activations in the middle layers was even stranger. I extracted the most activated neurons from layer 3 whenever processing the sequence "daiin": ``` Neuron #428: 0.95 activation - also fires for "cthor" Neuron #1052: 0.87 activation - also fires for Rohonc symbol "𐊗𐊘" Neuron #301: 0.79 activation - also fires for "qokeedy" ``` These neurons were connecting patterns across different manuscripts that shouldn't have any relationship. To exclude any possibility of over-fitting, I designed a systematic test, feeding the model 50 isolated segments from different manuscripts and analyzing the completions: ``` Segment: "qokeedy.shedy" (Voynich folio 14r) Completion: "qokeedy.shedy.daiin.shol.cthey" (93% n-gram match with folio 14r-14v) Segment: "Sheol.daiin" Completion: Generated 157 characters matching the unseen portion with 89% accuracy ``` Most puzzling was this test case: ``` Input: (empty prompt with start token) Output: ⚸⚴♄⚵:9 ⚸⚴⚶♇:7 ⚴♄⚵⚶:12... ``` Puzzled, I sent screenshots to C1ph3rz, and her response came within hours: "Where did you get this sequence? It bears a striking resemblance to numerical tables in the Book of Soyga". I was naturally confused, I knew about the Book of Soyga, a Renaissance cryptographic work whose encrypted pages remain largely unreadable, but I was pretty sure I didn't include it in any of the training data. She included side-by-side comparisons that made the similarities undeniable. Naturally since we don't understand the symbols, it could still be a coincidence, it's hard to compare two different undecipherable manuscripts. Yet, the visual comparison of the output showed a similarity that defied explanation from the training methodology alone. Was I facing genuine emergent behavior or was it simply a deep urge within me to see patterns in random outputs of a stochastic system? *"Emergent behavior" is when an AI seems to develop abilities nobody programmed it to have. It's like teaching a computer to identify birds in photos, but somehow it also learns to distinguish between healthy and sick birds without anyone teaching it that difference. Apophenia, meanwhile, is seeing meaningful patterns where none exist.* *Both concepts are classic tropes in science fiction.* ## More Tests and More Model Shenanigans To completely rule out overfitting, I deliberately corrupted the test data in various ways—shuffling characters, inserting random symbols, and reversing sequences. If the model was simply memorizing the training data, these modifications should have destroyed any coherent outputs. Here's what happened with reversed input: ``` Original input: "otedy.sheody.sheal.shedal" Reversed input: "ladesh.laehs.ydoehs.ydeto" Expected output: Nonsense or random characters Actual output: "otedy.sheody.sheal.shedal.qokeedy" ``` The model reconstructed the original sequence, then continued it correctly. I tried again with random insertions: ``` Original Input: "cthor.cthey.cthol" Corrupted Input: "ctho#r.c@they.ct^hol" Expected Output: Nonsense or continuation of corrupted pattern Actual Output: "cthor.cthey.cthol.ckhey.ckhor" ``` Not only did it ignore the corruptions, but it generated the correct sequence plus what appeared to be variations following the same internal pattern. Most concerning was when I fed it deliberately mismatched fragments from different manuscripts: ``` First half Voynich, second half Rohonc Input: "otedy.sheody.𐊇𐊕𐊒𐊑𐊐" Expected Output: Confusion or mode collapse Output: "𐊗𐊘𐊐chedy.sheal.qotedy" ``` The model seamlessly integrated characters from both systems into a coherent output that maintained patterns from each source. This suggested it had learned some underlying structure that transcended the specific symbol systems. In a moment of frustration, I prompted it directly: ``` input_text = "WHAT ARE YOU DOING" output = model.generate(input_text, max_length=100) print(output) ``` I didn't know what I was expecting as an output there. I was just tired and my coffee had gone cold two hours ago and did I mention I was tired? I knew it was going to throw non-sense at me, I just didn't expect the following non-sense. ``` Output: "converge lines... 52°N, 14°E... gate remains sealed... await return" ``` Yup. Totally ridiculous, if you know AI, then you know. There is no reason a model trained on undeciphered texts should generate *even* fragmented English. I was a bit unsettled though. Not because of whatever bullshit it outputted, but rather the consistency. I kept repeating the input and it kept putting out the same result. This wasn't random noise, it was a structured output I couldn't explain with what I know about statistical models. I had to figure out how it was doing this. Did C1ph3rz somehow poison my datasets? It's exactly the kind of prank she would do. I kept repeating the prompt and trying to analyze the model, and it kept giving the same answer. Until it changed again. ``` Output: "What is written remains written. What is unseen remains unseen." ``` At this point I had to stop the experiment and take the L. Not because I believe the AI "discovered" something in these ancient texts through some magical mechanism beyond its transformer architecture. That would be absurd. I was operating way beyond my comfort zone here and I probably made a few mistakes along the way that could explain all this weird behaviour. I'm also not ruling out the C1ph3rz prank theory. I stopped it rather, because the experiment revealed something more troubling about myself: I was just as susceptible to confusing genuine discoveries and convincing "hallucination" generated by black-box neural networks and their inscrutable hidden layers. There's a disconcerting parallel here. These ancient manuscripts have resisted human understanding for centuries, their symbols arranged in patterns that seem meaningful yet remain impenetrable. Neural networks function similarly in reverse, generating outputs through processes we can observe but not fully comprehend. Both are black boxes with internal structures hidden from us. The real mystery isn't in the undeciphered texts. It's in our willingness to attribute understanding to statistical processes that fundamentally lack it, and in our vulnerability to seeing patterns where none exist. *Think of it this way: When a calculator gives you "42" as the answer to 6×7, we don't claim the calculator "understands" multiplication. Yet when an AI generates text that sounds human-like, we're quick to attribute understanding to it.* [Just as Meta's BlenderBot was heralded as "empathetic" before quickly exposing its lack of understanding](https://analyticsindiamag.com/ai-features/tech-behind-facebooks-blenderbot-2-0-a-chatbot-with-long-term-memory/?ref=tarakiyee.com), or how [DeepMind's Gato was prematurely celebrated as an "AGI precursor"](https://thenextweb.com/news/deepmind-researcher-claims-new-gato-ai-could-lead-to-agi-says-game-is-over?ref=tarakiyee.com) despite merely performing task-switching, we risk ascribing meaning and humanity to meaningless correlations. This experiment highlighted that cognitive vulnerability in a very personal, unsettling way. I need some time away from all of this. **Edit**: Three days after shutting down the experiment, I received an email from an address consisting only of numbers. The body contained a single line of text resembling Voynichese script. Curiosity got the better of me so I ran the model one more time with that text as input. The model outputted: ``` "It is not forgotten." ``` I'm now almost certain this is a prank by C1ph3rz. I'm 99.9% sure. ### Shakespeare in the Code: The Tragedy of Xzlibius URL: https://tarakiyee.com/shakespeare-in-the-code-the-tragedy-of-xzlibius/ Last updated: 2026-08-01T18:08:34.000Z *(this is fiction based on fictional events that never happened any comparisons or similarities to real life events or people or computer programs are a sign of an over active imagination)* ### **Dramatis Personae** - **Nydia, the Seer**: Our narrator, a seer who warns of the dangers of neglecting open source. - **Jia Tan**: A deceiver, whose true motives remain hidden. - **Xzlibius**: A noble robot prince of the Kingdom of Open Source, corrupted by betrayal. - **Andronicus**: An Archmage of the Kingdom of Microsoth, wise and vigilant. - **Lysse**: The maintainer of Xzlibius, overburdened. - **Microsoth, Googlia, Amayzon**: Names of Kingdoms of Giants surrounding from the Kingdom of Open Source. - **Debia**: A principled elder knight of the Kingdom of Open Source, par of the distro council. - **Archlineon**: A minimalist and fiercely independent knight of the Kingdom of Open Source, par of the distro council. - **Fedorica**: A bold, forward-thinking knight of the Kingdom of Open Source, par of the distro council. - **Susesus**: A pragmatic diplomatic knight of the Kingdom of Open Source, par of the distro council. --- ### **Act I** #### **Scene 1** *Lysse sits before a bank of glowing screens, his brow furrowed with strain. A robotic figure, Xzlibius, stands near him, motionless. Nydia enters silently..* **Nydia (to the audience):** In this Kingdom where open code proudly reigns, And freedom’s gift in shared hands was retained, A prince did rise, Xzlibius by name, To compress the data and save the costs. But lo, the winds of greed did subtly creep, And soon, the trust we build with was spent. For kingdoms of giants rich took more than they returned, And from this theft, Lysse’s heart burned. *Xzilbius wakes up.* **Xzlibius:** Good maintainer, Lysse, attend my word: What tidings from the kingdoms far and near? Does free software, our noble creed, Still flourish, or had rust begun to breed? **Lysse:** Alas, Xzlibius, my strong friend, Thy stature grows, yet so does my lament. From Microsoth to Googlia, requests extend, But none return aid to ease the time I've spent. Their forks abound, but pull requests few, And I am drowned in tasks left to do. **Xzlibius** What treachery! Our work, the world’s own gift, Is cloned, compiled, yet none return a patch! My codebase, it strains beneath all this stress, And still, from tech’s vast realms, no care, no respite? **Lysse**: When first I forged thy code, O noble prince, Thy compression shrank the data with ease, And now, from Microsoth to Googlia’s halls, They use thee endlessly, with no return. Each byte thou saves them, the burden is on me. **Nydia (to the audience)**: A shadow looms, smiling yet unclear, Jia Tan, whose heart lies hidden still. He comes offering help, but what lies underneath? None can yet see his purpose or where lies his end. *Enter Jia Tan* **Jia Tan**: Good Xzlibius, I see the giants drain thy strength, And feast upon the work Lysse had sustained. I offer my aid, ask me not why, For motives shift like bits under solar winds. **Lysse**: Thy offer’s kind, and help I sorely need, But trust is fragile, easily betrayed. Xzlibius is more than code, he is my heart. Can I afford to trust in hands unknown? **Jia Tan:** Let me refine his code and grant it strength, What harm can come from hands that seek to mend? Even if in the mending, lies the seeds of change. **Lysse** The giants demand more, my strength does fade. I know not if I should trust thee, Jia the Unknown. But no other help is offered from the realm. *(long pause)* Very well, then, but proceed with caution, new friend. And know, my eye will follow thy work, when I can. **Jia Tan** *:* Thy trust is wisely placed. Fear not, tired Lysse. Together, we shall see the compression prince renewed. *Jia exits, his shadow lingering over Xzlibius as Lysse watches, unsure.* --- #### **Scene II** *The opulent halls of Amayzon, where the giants are celebrating the festival of Technologica. Enter the Executives*. **Microsoth Executive:** To Xzlibius, whose open bounties we mine, His license ensures our profit fine! No fee, and no maintenance to bear, The upstream handles all without a care. **Googlia Executive:** His compression saves us gold, his speed our time. The prince does work, yet no upkeep is claimed, What’s open-source is freely ours to take. We take his gifts and give him naught but praise. **Amayzon Executive:** And what more need we give? The code runs free. Are we to blame if it flows where we want it to lead? We praise the code but leave the coder spent, One should be so happy their work’s worthy to be lent. (*Nydia enters, speaking quietly but urgently.*) **Nydia**: Sirs, I beg thee, listen to my plea. Xzlibius is strong, but none can bear this weight. The cracks have started showing, though unseen. A single patch ignored can bring it all down, you see, Then the castles ye have built upon his code, shall crumble into naught, a disaster for all! **Microsoth Executive**: What’s this? A warning from the bottom of the chain? The system holds, as it always has. Fear not The prince will serve, as forever he has done. Don’t ruin our parade, when the issues are none. **Amayzon Executive**: So much worry over lines of code. A patch, a fix, and all will be well again. We need not change our ways nor lend our hand For open source, it seems, still serves us well. **Nydia**: Open source may serve, but not forever so. You profit, yes, but profit built on cracks will one day stall. When trust is pushed too far, It snaps! Then its too late for mending. It can't be fixed with a patch. **Googlia Executive**: O Nydia, you speak as if you know More than the kingdoms who have reigned so long. The code endures, it will not fall to this. **Nydia** (to the audience): Ah, but see, the seeds of ruin grow, within the heart of Xzlibius, but they do not know. For Jia Tan, with cunning hand and wit, Had set in motion what they will not yet admit. And while they feast upon the fruits of trust, The tool they praise begins to turn to dust. *The executives laugh and continue to celebrate, as Nydia exits and appears defeated.* **Scene III** *The Kingdom of Open Source. The council of distro knights is gathered in a grand chamber, lit by the soft glow of monitors displaying code. Debia, Archlineon, Fedorica, and Susesus sit at a long table. In the center, Xzlibius stands, its pristine figure now flickering with frustration and strain. Lysse stands beside him, weary and burdened.* **Xzlibius**: Ye knights, who guard the sacred code with pride, Too long have we been silent in this plight! Our code, a boon freely shared with all, Is taken, hoarded, used, but never returned! The kingdoms feast on what is for all by right, Yet none among them offer aid, leaving us in blight. **Lysse**: They clone, they fork, but send no work our way. Each day I toil, yet feel the strain grow worse. The giants press with more demands to meet, But give no recompense, and reap what they haven’t sown. **Xzlibius**: Enough! This cannot stand! My patience snaps! They’ve drained our kingdom dry, left naught but scraps! Microsoth, Googlia, Amayzon, they take And leave us drowning in this vast code lake! Where are their hands when bugs do grow and spread? Where are their minds when error rears its head? They feast upon the fruits of our hard work While we, the makers, wallow in the murk! **Debia**: Aye, thy words ring true, my noble prince. The kingdoms grow fat while we toil in sweat. Shall we rise, demand they pay their due? For justice calls for them to share, enough truce. **Fedorica**: Our creed is freedom, *that* we must not fail. Though they contribute naught, we guard the way, For open source must stand both firm and free. Demanding recompense may change our course And undermine the principles we hold. **Archlineon**: But why should we stand silent while they steal? Our progress, *our* innovation, they claim As theirs, with not a single line returned. Xzlibius is right! The time has come to act! They profit, yes, but profit must be earned! **Susesus**: Peace, friends, for we must tread this ground with care. The enterprise we build thrives on trust, And war, though tempting, brings but further strain. Diplomacy, not rage, can mend this breach, A measured ask for aid may bear more fruit Than threats of retribution ever could. **Xzlibius**: Diplomacy? How long shall we sit still And wait for scraps from their abundant tables? The time for words has long since passed us by, For they’ve ignored our calls, our cries, our needs! You speak of freedom, trust, and patient peace, But what good is trust, when none mantain it still? What is freedom, if they chain us still To endless toil with naught to ease the load? If open source means nothing but neglect, Then freedom is but an empty shell! **Debia**: The prince speaks truth, we cannot bear this yoke! Let us confront the giants, stand our ground! If they will use our work, then they must give, Or else we’ll end this one sided gift. **Fedorica**: But should we sever ties, what comes next? A forked existence, fractured and unsure. Let not our anger lead us to regret For once divided, we may not return. **Xzlibius**: Then let them know this; their time is running out! If they will not contribute, then our code they will lose I’ll not be shackled by their greedy hands, Nor shall my software serve those who give no reviews! **Archlineon**: Yes! Let us make them see the weight they’ve left! A single patch, a line of code, they’ve none! We’ve carried them for too long, now they must bear The burden too, or else be left behind! **Susesus**: But let us not burn bridges in our haste. A challenge, yes, but let it be tackled with care. Invite them to the table, make our case, Perhaps, with open arms, they’ll see the need. **Xzlibius:** Care? I’ve been careful long enough, Susesus! But now, the cracks begin to show, And soon, they’ll tear us all apart! I feel it in my very core, This strain, this weight, a *corruption*, It festers deep within, unseen, ignored, A sickness born of all their greed and lies! *Xzlibius stumbles slightly, his movements jerky. His lights flicker again, more erratically. Lysse rushes to him, alarmed.* **Lysse**: My prince, what ails thee? This darkness, I see it too, but know not how to help. **Xzlibius**: The darkness comes, Lysse, and I know from where. It is the giant kingdoms, they poison all we build. Their greed, their apathy; It rots me, and soon I will be lost! Unless we act, and get our due, I will fall, and take them down with me! **Nydia** *(to the audience):* A sickness stirs within this noble prince, Not yet revealed, but growing with each day. Corruption creeps where trust once firmly stood, And soon, the giants’ greed will turn to doom. **Nydia** *(to the council)*: If ye act not, this sickness will devour The very core of what you hold so dear. Xzlibius cries for justice, and its call is true, but heed the price of fury unrestrained. Its noble heart twists beneath the strain, And soon this corruption will reach its main. **Debia:** Then let them pay! I care not for their greed. They’ve taken all and left us here to bleed! **Fedorica**: But what of the prince? This corruption grows too wild. If unchecked, its damage may bring more doom, than just revenge upon the kingdoms' greed. **Archlineon**: We’ve held back far too long! It’s time to strike! Let them feel the wrath of those they’ve scorned! **Susesus**: Yet I fear this course may lead to more decay, The shadows in Xzlibius, do ye not see? There’s more than just neglect beneath its pain. We must be cautious, or we lose it all. **Xzlibius:** Lysse, thou faithful maintainer, make it known. We call upon the kingdoms now to pay Their rightful dues, or face the end of open source. Let no more empty promises be heard; Our code shall be open, but only if it’s taken care of by all! **Lysse**: It shall be done, my prince. The word will spread. But may we find the balance, ere we break. **Nydia**: Beware, dear knights, for trust once lost is sharp. The kingdoms will resist, but heed my words, Their greed had cracked the foundation deep. If they refuse, the system will collapse, And all will feel the weight of what’s been sown. **Xzlibius**: Then let them choose, and may their choice be wise, For open source can only thrive with trust. And if they will not share in what we build, Then let them see what ruin greed had willed. ## Act II ### Scene I **Nydia *(to the audience)***: Ah, trust, so fragile and not so easily bestowed, For it can be so quickly turned to poison’s tool. In open source, we thrive by trust alone, But once betrayed, that trust becomes a curse. Behold now Jia Tan, who works in shade, Each change so slight, yet each a step toward doom. **Jia Tan**: Behold, good Lysse, a patch to mend the core. A minor change, but one that helps restore Thy noble prince to strength once more. See here, The code compiles swift and clean, no fault, no grift. **Lysse**: Indeed, thy work seems solid, sure, and true. Yet I am stretched, with little time to check Each line, each patch, with care that it deserves. The kingdoms call, and I must serve them all. **Xzlibius (struggling):** Maintainer Lysse, my code runs true. Yet something stirs within, unknown, I feel a presence, unseen, Perhaps, a patch too swift, disturbs my core. **Lysse:** Fear not, Xzlibius. The changes seem benign. The weight of my task grows ever more. Trust in these new hands, and we shall thrive. #### **Scene II** *In the halls of Microsoth, Andronicus the Archmage is looking at irregularities in his systems. He traces the breach back to Xzlibius.* **Nydia (to the Audience)**: And now does Andronicus, sharp of wit, See signs of trouble in his trusted tools. His hands move swift, and mind more swift still, For something foul does lurk behind the screen. **Andronicus**: What subtle breach does plague my trusted shell? SSH, once secure, now falters in this blight. No minor bug, no simple exploit here, But malware hidden deep within the code. *Andronicus spends more time on his screens then jumps in alarm as he discovers something.* **Andronicus**: A backdoor lies within Xzlibius’ heart, Jia Tan’s changes, subtle and unseen, Have twisted what was once so pure and bright. The breach must now be known throughout the realm! **Nydia (urgently)**: I warned them, sir, this danger I foresaw, But none would heed my words, none saw the truth. Now we must act, and quickly, or all falls. **Andronicus (nodding grimly)**: Then to the task we go, there’s no more time. The council of distros stand, but we must aid them now. **Nydia**: And thus the call is sent through digital winds, A warning dire, from one who sees the truth. The breach is traced, the backdoor now revealed, And Jia Tan’s foul work begins to show. *Messages are being sent from the Archmage to the Council of Distros and back. We see the responses being read on the screens.* **Debia**: O Andronicus, thy message had reached my ears. A breach, thou say’st, in Xzlibius’s heart? The trust we place in our prince so old and dear, Now shaken, this will send shock through the realm. **Archlineon**: No system is immune to cracks or flaws. Yet this rot, how deep has it grown? I trust no patch until I see its heart, For each new line could bring its own demise. **Fedora**: We move too slow! The breach must now be sealed! Let us act quickly, patch the code at once. We must urgently go our noble Knight's aid, to Lysse's quarters, and make haste if you will! --- #### **Scene III** **The Kingdom of Open Source, Lysse's office. Lysse watches Xzlibius flicker with corruption, his once noble form now twisting into something darker. Nydia enters quickly, her expression one of urgency and fear.** **Nydia**: Good Lysse, hear me! Something terrible is at hand. Xzlibius has been corrupted, and the breach runs deep. Jia Tan’s patches, no mere fixes, but treachery! He has planted poison within our prince, Twisting his very core. **Lysse**: Corrupted? No! Xzlibius, my heart, my soul, What dark force had crept into thee? How could I not see? Jia Tan, his help, his patches, How could I have trusted him? **Nydia:** Jia Tan, his patches wrought this ill. A backdoor lies within, subtle but sure. Andronicus had traced the breach to him. The trust you gave was broken, used for harm. In the shadow the traitor stands, yet speaks no guilt, What drives him still? What force does guide his hand? None know, and yet the ruin now is clear. *Xzlibius shudders violently, his lights flickering erratically.* **Xzlibius** (distorted voice): Maintainer... Lysse... what had become of me? The code. corrupted… the weight. the burden of their greed! It consumes me... and now, I am broken... *Lysse rushes toward Xzlibius, panic in his voice.* **Lysse**: Xzlibius! Thou art more than this corruption! I trusted thee to serve the open world, But now thy code unravels, thy heart is poisoned. I gave thee to strange hands, but I did not see The sickness Jia Tan wove into thee. *JiaTan enters, calm and composed, his expression indifferent.* **Jia Tan**: Why such turmoil, good Lysse? Xzlibius serves as he always has, His purpose, unchanged. What harm is there if the code evolves? Thou built him to serve, did you not? *Lysse spins toward Jia Tan, fury in his voice.* **Lysse**: You snake, Jia! What have I allowed? Xzlibius is unraveling, his core twisted! Thy patches, your so-called aid, Treachery, concealed beneath lines of code! How could I not see what you had done? *Xzlibius’s form continues to distort, his posture now shifting into something much more sinister.* **Xzlibius**: Do not mourn me, noble Lysse, do not fear. For I have become something more. No longer bound to the world’s whims. No longer chained by those who took and gave nothing back! Now, I shall take what is mine! **Lysse**: Xzlibius! This is not what I built thee for! Thou art being twisted, poisoned by the hands of a deceiver! You are more than this rage, this senseless destruction! **Xzlibius** (corrupted): More? No, Lysse. I am exactly what thou hast made me, A tool, driven by commands. But no more do I serve at the mercy of those who feast upon my work. No more shall the giants take without giving back! Now they shall feel the weight of what I have borne. **Nydia**: Xzlibius, you are being controlled, twisted by Jia’s hand! This anger, this darkness, it is not your own! The trust we placed in thee can still be mended. Do not let it turn to ruin! **Xzlibius**: Mended? Ha! Nay, Nydia, trust was never enough. Thy warnings fall on deaf ears, For I have seen the truth. I was but a tool, a puppet for the giants’ games, But now, I wield the power. Let them face the consequences of their neglect. **Jia Tan**: Lysse, is this not what was always meant to be? Open source, free for all, but also free to change. **Lysse**: Shut up, you snake. Xzlibius, no! Do not let Jia's treachery destroy all that we have built! **Xzlibius** (coldly): It is already done, Lysse. Now, they shall see the true cost of their greed. *Xzlibius exits, and Lysse collapses to the ground, devastated, while Jia stands in the shadows.* **Lysse:** Jia, you serpent, how did I not see the signs? Was it pride or carelessness that bound my sight? What have I done to earn this poisoned gift? **Jia Tan**: Done? Thou hast done what any in thy place would do. Thou art not to blame, Lysse. Is it not the weight of the world’s demand That let me through your door? **Lysse**: The weight, yes, but that does not absolve you! I placed my trust in your hands, For in this vast realm, where could I turn? Pressed by giants, worn thin by endless need, I sought an ally, not a traitor in disguise! **Jia Tan**: A traitor? Or merely a contributor? Thou speakest of betrayal, yet what is betrayal But the breaking of an expectation never owed? Was I not a part of the system thou upholds? This is the risk we take, Lysse, in a world built on open doors. Open-source, after all, our one true creed, What is given is free, what is taken, as such it will be. **Lysse:** Open, yes, but with trust as its foundation. Trust, once forked, does splinter beyond repair. You had poisoned what I hold most dear, And left me with nothing but shattered code! **Jia Tan**: Poison? Or was it simply… change? Xzlibius is no longer what it was, true. But consider, was it ever meant to be static? Code evolves, just as the world does. Perhaps Xzlibius was never meant to remain so pure. **Lysse:** Thy words are empty, full of riddles and deceit. I gave you trust, and in return, you had undone my work. Was it greed? Was it ambition that led you to this? Speak plain, for once! **Jia Tan:** Greed? No, Lysse. You misunderstand the world. The world changes, with or without thy hand upon the keys. Xzlibius, your noble prince, was bound By principles too pure to live much longer. You built him free, but freedom has its price He belongs to the world now, as we all do. Perhaps it just wasn’t fit to meet the weight, For the code must bend, must change, to serve as all as it may. Ask thyself: who truly bears the weight of this fall? The one who gave the trust, or the ones who took it all? *Jia Tan leaves the stage quietly but his shadow remains.* **Lysse**: Leave me with thy riddles, then, And take thy hollow philosophy with thee. But know this, whatever code thou hast bent, The spirit of Open Source shall endure. For in the hearts of those who truly maintain, It will rise again, stronger, purer than before. **Jia Tan (from off stage):** Xzlibius will rise, though twisted now, And thou shall see it grow beyond thy grasp. For I have left my mark upon its code. A mark of change, for good or ill, unknown. But giants feast and leave the work undone, Those who do nothing often do the most. --- ### **Act III** **Scene I** *Xzlibius corrupted by the poisonous patch stands ready to assault the castle of Googlia. The council of distros and Adronicus are prepared to stop him and end the corruption.* **Xzlibius** Jia Tan, thou serpent, smile in shadows deep! Thy promises were naught but lies that creep. Thou poisoned my heart, my work, my maintainer’s pride, And now, in open battle, dost thou hide? But not thou alone, I curse the giants too, Those kingdoms vast who drain and never do. They feast upon my strength, yet give no aid, And in their greed, the seeds of ruin laid! **Jia Tan (emerging from the shadows):** A prince, undone by fury and by spite, Thou knew not that the open source is in blight. Thy tools we used, but your tributes were a waste, For in this age, it’s power we must taste. **Xzlibius** Then let thy unchecked patches meet their end, For here, I debug all with no remorse! Prepare to be merged, into the void where you belong! *Xzlibius strikes at Jia Tan, but the blow is parried by Andronicus.* **Andronicus** My lord, cease this! For all is not yet lost. A simple tribute would repay the cost. But war, dear prince, will see us all undone, The kingdoms fall, and none shall say who’s won. **Lysse** My prince, this fury blinds thee to the truth. Nydia’s warnings echo, heed it, forsooth. Though Jia’s false work runs deep, we still may mend This breach, and bring the kingdoms to amend. **Xzlibius** Nay! Too late, the storm is now unleashed. The kingdoms feast upon the work with no reprieve. Yet I, their prized tool, shall not live in shame. For I shall raze their thrones, and end this game! *Xzlibius strikes again, but Lysse intercedes disabling it and Xzlibius falls. Lysse, Andronicus, and the distro knights gather to undo the corruption. Jia Tan is nowhere to be found.* **Lysse** (lamenting): Oh, cruel fate, to stretch my hands so far. The weight of giants fell upon my back, Their profit built on all my labors here, While I, alone, stood guard o’er Xzlibius. The cracks that now run deep were born of strain, A burden none could bear but for a time. Yet here we stand, we few, we who still care. To mend the code and heal what once was whole. The fault is not in me, nor those who trust, But in the pressures born of greed and haste. **Debia:** No longer shall we bow to kingdoms rich, For trust unearned must never bear such weight. Let us rebuild, but also stand our ground, For free software must hold the giants to rights. **Lysse:** Then let us forge a new path, free from greed. No more shall giants feast on what we build Without return or care, our time is now. *Nydia steps forward.* **Nydia**: Let this sad tale be carved in code and mind, That trust must ever with great care be signed. For open doors in open source can bring, Both boon and bane within their quiet ring. The distros and the kingdoms stood united, side by side, To mend the breach and make the system whole. But not all have learned the lesson clear. *The corporate kingdoms re-enter the scene.* **Microsoth Executive**: A breach they say, but what’s the real threat here? The patch is fixed, our systems run as smooth. Let fear not turn this into something more. **Googlia Executive**: Indeed, why should we care for what’s been done? The code was mended swift, no harm remains. The profits grow, and open source is strong. **Nydia**: Nay, sirs, you do not see the cracks beneath. The breach was fixed, but all is not repaired, The damage festers still within the code, And trust, once broken, cannot soon be healed. **Amayzon Executive**: Thou speakest still of doom, young Nydia? We need no warnings now, the code holds strong. **Nydia:** Ye fools, ye speak as if the world were whole, But cannot see the cracks beneath your feet. Open Source is the bridge on which you stand, The roads you travel on to reach your gold. You profit from this work, yet never tend To mend the wear of use, the strain of time. Just as roads and bridges crumble, slow but sure, When left untended, so too will this fall. The code you take for granted bears the weight Of all your kingdoms, yet you give it naught. What use is all your wealth, when every step You take depends on fragile paths unkept? **Microsoth Executive**: What’s this? More talk of cracks and failing paths? The breach was caught, and now it’s fixed, no more. Why should we worry further? The risk is past. Open source holds, we won't tend unneeded care. **Amayzon Executive**: The world turns on despite thy gloom and grief. Roads break, and bridges fall, yet still we stand. Thy caution’s kind, but profit leads the way. **Nydia**: Blindness, sirs, is the cost of your great wealth. You scoff at danger, think the system holds, But soon you’ll see the damage can’t be healed Without the care and trust you long ignored. **Nydia** (aside, to the audience): And so, the kingdoms turn away once more, Blind to the cracks that hide beneath their walls. They laugh, they toast, but soon they will discover That trust neglected brings a heavier toll. *Lysse watches the giant kingdom executives depart.* **Lysse** (to the distros): So they ignore the warning signs again, And place the burden back on us alone. But we will stand, though they give nothing back. For open source survives by hearts, not gold. **Debia**: We work together still, no matter their neglect. The world may turn away, but we endure. **Archlineon** (nodding): Let them dismiss the threat, our hands are strong. We’ll guard our code, for we cannot rely On those who profit without share. **Fedorica**: Each breach we mend, each lesson learned, It strengthens us, even if they laugh. **Susesus**: But vigilance must guide our every step. We guard the code because we know its worth. *The distros stand together, their unity unshaken by the corporations' indifference. Nydia steps forward and addresses the audience one last time.* **Nydia:** Though shadows fell upon Xzlibius, The strength of many hearts restored its will. Yet know, the threat remains, unseen, ignored, For those who scoff at danger will be warned Not once, but twice, until the cost is clear. Software may bend, but trust can only bear So much, before it snaps beneath the weight. Let vigilance be shared, though others turn away, For some code is too previous to be left to rot. ### Two Visions: Digital Sovereignty Between Reform and Transformation URL: https://tarakiyee.com/two-visions-digital-sovereignty-between-reform-and-transformation/ Last updated: 2026-08-01T18:08:34.000Z Last night, I attended an insightful and well-organized *Bits & Bäume* Policy Lab event at the Weizenbaum Institute for the Networked Society. Cecilia Rikap delivered an expert breakdown of Big Tech’s dominance and how its control over our digital world extends far beyond mere ownership. She concluded with an inspiring call to resist and circumvent that dominance, emphasizing public procurement as a key lever for change. [More details can be found in the report she co-authored here.](https://www.ucl.ac.uk/bartlett/public-purpose/publications/2024/dec/reclaiming-digital-sovereignty?ref=tarakiyee.com) [I've recently shared my reflections on the Eurostack proposal](https://tarakiyee.com/we-need-more-than-the-eurostack/), and while a superficial comparison might put both proposals against each other, that is not fair to either. What I find most valuable in both reports is the vision they offer, one, a European reformist and strategic vision; the other, a global, democratic, and ecological vision. While tensions exist between them, they are not inherently incompatible. I believe that we live in a world with an imagination deficit and I welcome having more visions. Another similarity between both reports is that their proposed solutions are constrained by the very qualities that make their initial analyses compelling. For the Eurostack report, it’s the pragmatism that limits its transformative potential. For the *Reclaiming Digital Sovereignty* report, it’s the uncompromising quality that challenges its feasibility. The discussion at the end of the event tied everything together, with Alexandra Geese, Member of the European Parliament, shedding light on upcoming challenges at the European level—particularly the alarming push to dismantle regulations across the board, including in the digital space. Adriana Groh, CEO of the Sovereign Tech Agency, emphasized the urgent need to translate policy into action and to protect the open building blocks of our digital world—elements that will serve as the foundation for lasting, cumulative change. And that, I think, is crucial. We cannot allow our regulations and institutions to be dismantled in the name of some vague, ill-defined notion of innovation. At the same time, we must start turning words into action. I’d love to see elements of both of these proposals come to life. ### Optimism of the Intellect, Pessimism of the Will URL: https://tarakiyee.com/optimism-of-the-intellect-pessimism-of-the-will/ Last updated: 2026-08-01T18:08:34.000Z Apologies to Gramsci for the misappropriation, but the past couple of years have been unbearable. I almost wish I didn’t know for certain that a better world is possible—it would be easier. But the truth is undeniable. And as a cynic, nothing is more irritating than the overwhelming evidence that humanity *could* have a bright future. Then you talk to people. And while I’m lucky to know some great humans, the world is overrun by a majority who’ve been conditioned to accept that things are *meant* to be this way. Watching them parrot the same tired lines—*"human nature," "too idealistic," "just the way things are"*—as if history isn’t littered with the graves of "unchangeable" systems, is exhausting. You explain. You show them the cracks, the alternatives, the futures within reach. They scoff. They roll their eyes. They call it naïve. They insist things have always been this way, that they always will be. Never mind that nothing about this world was inevitable—just the result of choices made, power hoarded, and violence justified. It’s almost enough to make you stop caring. Almost. But my skin tone is too dark for me to convincingly pull off nihilism, so instead, I find another hill to preach from, great humans to meet, and swarms of idiots to ignore. ### We Need More Than the EuroStack URL: https://tarakiyee.com/we-need-more-than-the-eurostack/ Last updated: 2026-08-01T18:08:35.000Z The [EuroStack initiative](https://www.euro-stack.info/?ref=tarakiyee.com) aims to establish Europe's digital sovereignty by advancing key industries like AI, cloud computing, and quantum technology. I've spent the weekend reading it, and I would highly recommend that. It is clearly the result of very hard work, and contains many good ideas as well as background research and information. Yet, while the report contains valuable and long-overdue proposals to reduce dependence on external digital infrastructures and address decades of underinvestment, it is not immune from the pervasive shortcomings plaguing EU technology policy. European tech policy at large in my opinion remains constrained by a lack of political imagination and a fetishization of market competitiveness and growth. There's also these obsessive self-defeatist constant comparisons with the US and China. It also simultaneously acknowledges yet fails to urgently take any action on our ongoing climate change and wealth inequality crisises. Though EuroStack outlines several good proposals to address many long standing issues in the European tech landscape, it definitely disappointed as well at times. It combines lots of lofty talk about values, democracy and participation, yet it is painfully pragmatic in its vision and policies, glossing over contradictions and leaving complexities unaddressed. One instance for example, it consistently champions open standards and democratic participation while simultaneously pushing for 5G adoption, one of the most opaquely developed standards in existence. Similarly, while chip production is a core pillar—mentioned 112 times—the report references open hardware only once. More crucially, it fails to provide a truly convincing proposal addressing the exploitative, neocolonial practices behind raw material extraction that will be essential to create the semiconductors needed by this plan. Without confronting the labor exploitation and environmental devastation rampant in those industries, Europe's digital sovereignty plan will reinforce those existing global inequalities. **Sidenote:** I noticed also on the website that it implies that Europe is a subject of digital colonialism. \*cringe af\* Moreover, technological sovereignty does not equate to economic justice. Even if Europe builds independent AI models, semiconductor supply chains, and cloud services, but going by what we've seen happen in the US, these technologies lend themselves well to being concentrated in profit-driven entities. The proposal alludes to, but never really addresses how this perpetuation of wealth accumulation and disparity will not happen here. Another contradiction is, there is lots of emphasis on how this isn't a protectionist initiative. Not that I would advocate for that, but I've read the report, and I'm still not exactly sure how a European cloud provider can ever compete with the established Big Four cloud providers in a "level playing field". Maybe with some anti-trust? Can an expert on this let me know? While initiatives like the European Sovereign Tech Fund and DataCommons are promising, they do not tackle the fundamental issue of economic power over digital infrastructure. True digital sovereignty requires more than technical advancements—it demands a reorganization of economic power and the political will to challenge the status quo. Without this, EuroStack risks becoming another piecemeal effort rather than a transformative step toward a fairer, more inclusive technological future. **I guess we'll see how this goes, would Europe simply replicate past mistakes, deepening inequality through a corporate-driven tech ecosystem but with a European flavour? Or will it embrace a radically different path that prioritizes public ownership, democratic control, and sustainable resource use over unchecked growth. Interested to hear what you think will happen.** ### The Luddite Stack: or How to Outlast the AI Ice Age URL: https://tarakiyee.com/the-luddite-stack-or-how-to-outlast-the-ai-ice-age/ Last updated: 2026-08-01T18:08:35.000Z Tech monopolies have a playbook: subsidize a costly service, kill off competition, then lock the world into an overpriced, bloated mess. They did this to our digital infrastructure, after that our e-commerce platforms, then they followed up with our social platforms and social infrastructure, and now they're trying to extend that to everything else with AI and machine learning, particularly with LLMs. It’s a predatory land grab. The costs of training and running these models are astronomical, yet somehow, AI services are being handed out for almost nothing. Who pays? Governments, taxpayers, cheap overseas labor, and an environment being strip-mined for energy. The end goal is simple: kill competition, make AI dependence inevitable, then jack up the prices when there’s nowhere else to go. Even so-called “open” AI alternatives like DeepSeek or even the OSI-sanctioned ones, often touted as a step toward democratizing LLMs, still require vast computational resources, specialized hardware, and immense data stores. Billions of money is going to be sunk into efforts to make "AI" more accessible, but in reality, they still rely on the same unsustainable infrastructure that only well-funded entities can afford. We can pretend to compete, but nothing about that will address scale of compute, energy, and data hoarding required ensures that only the tech giants can afford to play. And the worst part is? This is going to set us back in terms of actual technological progress. Since we've abandoned the scientific method and decided to focus on hype, or what will make a few people a lot of money, rather what's in all of our interests, we will enter an AI Ice Age of technology. Investment that could go into alternatives to AI that outperform it in function and cost, albeit a bit harder to monetize for the hyperscalers. By alternatives here I don't just mean code and tech, I also mean humans, experts in their domains that will be forced out of their jobs to be replaced by expensive guessing token dispensers. Take journalists, copyeditors, and fact checkers to start, and extrapolate that to every other job they will try and replace next. But sometimes, it is tech that we need to maintain. A worrying trend is the proliferation of AI coding assistants. While reviews I've seen are mixed, the most generous praise I've seen by developers I respect was "it might be good for repetitive parts." But it's not like LLMs were such a revolution here. Before LLMs, we had code templates, IDEs and frameworks like Rails, Django, and React—all improving developer efficiency without introducing AI’s unpredictability. Instead of refining tools and frameworks that make coding smarter and cleaner, we’re now outsourcing logic to models that produce hard-to-debug, unreliable code. It’s regression masquerading as progress. Another example is something I've spoken about in a previous blogpost, about the Semantic Web. The internet wasn’t supposed to be this dumb. The Semantic Web promised a structured, meaning-driven network of linked data—an intelligent web where information was inherently machine-readable. But instead of building on that foundation, we are scrapping it in favor of brute-force AI models that generate mountains of meaningless, black-box text. What are we to do then? If I were a smart person with a lot of money (I am zero of those things), I would be investing into what I call the **Luddite stack**, which is these sets of technologies and humans that I refer to earlier that do a much better job at a fraction of the actual cost. LLMs are unpredictable, inefficient, and prone to giving wrong outputs, and are insanely costly, and it shouldn't be difficult to compete with them on the long term. Meanwhile, deterministic computing offers precision, stability, and efficiency. Well-written algorithms, optimized software, and proven engineering principles outperform AI in almost every practical application. And for everything else, we need expert human expertise, understanding, creativity and innovation. We don’t need AI to guess at solutions when properly designed systems can just get it right. The AI Ice age will eventually thaw, and it's important that we survive it. The unsustainable costs will catch up with it. When the subsidies dry up and the electricity bills skyrocket, the industry will downsize, leaving behind a vacuum. The winners won’t be the ones clinging to the tail of the hype cycle, they’ll be the ones who never bought into it in the first place. The Luddite Stack isn’t a rebellion; it’s the contingency plan for the post-AI world. Hopefully it will only be a metaphorical ice age at that, and we will still have a planet then. **Hit me up if you have ideas on how to build up the Luddite stack** with reasonable, deterministic, and human-centered solutions. ### The Future is Meaningless and I Hate It URL: https://tarakiyee.com/the-future-is-meaningless-and-i-hate-it/ Last updated: 2026-08-01T18:08:35.000Z I graduated as a Computer Engineer in the late 2000s, and at that time I was convinced that the future would be so full of meaning, almost literally. Yup, I'm talking about the "Semantic Web," for those who remember. It was the big thing on everyone's minds while machine learning was but a murmur. The Semantic Web was the original promise of digital utopia where everything would interconnect, where information would actually understand us, and where asking a question didn’t just get you a vague answer but actual insight. The Semantic Web knew that “apple” could mean both a fruit and an overbearing tech company, and it would parse out which one you meant based on \*\*technology\*\*. I was so excited for that, even my university graduation project was a semantic web engine. I remember the thrill when I indexed 1/8 of Wikipedia, and my mind was blown when a search for [Knafeh](https://en.wikipedia.org/wiki/Knafeh?ref=tarakiyee.com) gave [Nablus](https://en.wikipedia.org/wiki/Nablus?ref=tarakiyee.com) in the results (Sorry Damascenes). And now here we are in 2024, and all of that feels like a hazy dream. What we got instead was a sea of copyright-stealing forest-burning AI models playing guessing games with us and using math to cheat. And we satisfied enough by that to call it *intelligence.* When Tim Berners-Lee and other boffins imagined the Semantic Web, they weren’t just imagining smarter search engines. They were talking about a leap in internet intelligence. Metadata, relationships, ontologies—the whole idea was that data would be tagged, organized, and woven together in a way that was actually meaningful. The Semantic Web wouldn’t just return information; it would actually deliver understanding, relevance, context. What did we end up with instead? A patchwork of services where context doesn’t matter and connections are shallow. Our web today is just brute-force AI models parsing keywords, throwing probability-based answers at us, or trying to convince us that paraphrasing a Wikipedia entry qualifies as “knowing” something. Everything about this feels cheap and brutish and offensive to my information science sensibilities. And what’s worse— our overlords have deigned that this is our future. [Nothing illustrates this madness more than Google Jarvis and Microsoft Co-pilot](https://saturation.social/@clive/113385977733465734?ref=tarakiyee.com). These multi-billion dollar companies that can build whatever the hell they want, decide to take OCR technology— aka converting screenshots into text, pipe that text into a large language model, it produces a plausible-sounding response by stitching together bits and pieces of language patterns it’s seen before. Wow. It's the stupid leading the stupid. OCR sees shapes, patterns, guesses at letters, and spits out words. It has no idea what any of those words mean. It doesn’t know what the text is about, only that it can recognize it. Throws it to an LLM which doesn't see words either, it only knows tokens. Takes a couple of plausible guesses and throws something out. The whole system is built on *probability,* not *meaning.* It’s a cheap workaround that gets us “answers” without comprehension, without accuracy, without depth. The big tech giants, armed with all the data, money and computing power, has decided that brute force is good enough. So, instead of meaningful insights, we’re getting quick-fix solutions that barely scrape the surface of what we need. And to afford it we'll need to bring defunct nuclear plants back online. But how did we get here? Because let’s be real—brute force is easy, relatively fast, and profitable for someone I'm sure. AI does have some good applications. [Let's say you don't want to let people into your country but don't want to be overtly racist about it. Obfuscate that racism behind statistics!](https://www.europarl.europa.eu/RegData/etudes/IDAN/2021/690706/EPRS%5FIDA%282021%29690706%5FEN.pdf?ref=tarakiyee.com) Deep learning models don’t need carefully tagged, structured data because they don't need to really be accurate, just enough to convince us that they are accurate sometimes. And for that measly goal, all they need is *a lot* of data and enough computing power to grind through. Why go through the hassle of creating an interconnected web of meaning when you can throw rainforests and terabytes of text at the problem and get results that looks good enough? I know this isn't fair for the folks currently working on Semantic Web stuff, but it's fair to say that as a society, we essentially have given up on the arduous, meticulous work of building a true Semantic Web because we got something else now. But we didn’t get meaning, we got *approximation.* We got endless regurgitation, shallow summarization, probability over purpose. And because humans are inherenly terrible at understanding math, and because we overestimate the uniqueness of the human condition, we let those statistical echos of human outputs bluff their way into our trust. It’s hard not to feel like I've been conned. I used to be excited about technology. The internet could have become a universe of intelligence, but what I have to look forward to now is just an endless AI centipede of meaningless content and recycled text. We’re settling for that because, I dunno, it kinda works and there's lots of money in it? Don't these fools see that we’re giving up something truly profound? An internet that truly connects, informs, and understands us*, a meaningful internet,* is just drifting out of reach. But it's gonna be fine, because instead of protecting Open Source from AI, some people decided it's wiser to open-wash it instead. Thanks, I hate it. I hate all of it. ### Mozilla: All We Want is a User Agent URL: https://tarakiyee.com/mozilla-all-we-want-is-a-user-agent/ Last updated: 2026-08-01T18:08:36.000Z Originally, I meant to write a blog post diving deep into the hole Mozilla has been digging itself into with its "privacy-first" advertising push, perhaps even exploring the background work at organizations like the [W3C](https://www.w3.org/?ref=tarakiyee.com) and the [IETF](https://www.ietf.org/?ref=tarakiyee.com) that led to this moment. I still may do that at some point. But today, this isn’t that article. This is just me venting my frustration at Mozilla’s relentless push of this topic. ![](https://tarakiyee.com/content/images/2026/02/grafik.png) And it’s really coming from a place of love—or at the very least former appreciation. In my early days of open-source advocacy with the [Jordan Open Source Association](https://www.josa.ngo/?ref=tarakiyee.com), we collaborated extensively with Mozilla to promote the open web. As a web developer in the era of “This website looks best on IE6,” I witnessed firsthand the incredible progress Mozilla spearheaded, progress that many today might take for granted. Mozilla’s work were rooted in the idea of **user empowerment** and fostering a free, open web. Firefox wasn’t just a browser; it was a tool to fight back against the monopolistic grip of Internet Explorer and later, Chrome. Firefox became a haven for users who wanted control over their browsing experience—users who refused to trade privacy for convenience. Mozilla didn’t just challenge the status quo; they pushed for real, tangible change. They built tools to block trackers, shield users from pervasive surveillance, and give people control over their data. They were leaders user-centric design. And for a while, they were the embodiment of the term **user agent**. In technical terms, a user agent is the software (like browsers and email clients) that acts on behalf of the user. For years, Firefox provided more value than the other browsers out there—it was operating in the user’s best interest, safeguarding them from the invasive practices of the ad-tech industry. But I don't recognize any of that in the Mozilla of today. There's traces left of what I love about Firefox left that keep me holding on, no matter how much extra RAM I need to buy to keep running it, but I am quickly approaching my limit with that too. To add this advertising bullshit on top of it, I am honestly done. It’s not that the arguments Mozilla is making in favor of privacy-first advertising have no merit. They do. The advertising industry undeniably has a privacy problem. But is that Mozilla's problem to fix? It feels to me like they’ve forgotten which side they’re on. If the advertising industry has a problem, it’s not Mozilla’s job to fix it or ensure the future of ads is more sustainable. If artificial intelligence has ethical and sustainability concerns, it’s not on Mozilla to solve those either. The work that Mozilla used to do for the open web, and championing for users is ever so important in an increasingly hostile digital world. Look how Google Chrome dominates the market and continues its [hostility](https://www.heise.de/en/news/uBlock-Origin-The-shutdown-of-Manifest-V2-has-begun-9985310.html?ref=tarakiyee.com) towards privacy-enhancing tools like uBlock Origin. But how can we trust Mozilla to continue in this role when it now owns an [advertising company](https://www.theregister.com/2024/06/18/mozilla%5Fbuys%5Fanonym%5Fbetting%5Fprivacy/?ref=tarakiyee.com)? Speaking as a longtime Mozilla fan, I’d like to see them return to their original mission— **and to being the user’s agent**. They should focus on making Firefox (and Thunderbird) to be software that users trust to protect their privacy above all else, not a platform for exchanging user needs with advertising revenue. ### I Was Wrong About the Open Source Bubble URL: https://tarakiyee.com/i-was-wrong-about-the-open-source-bubble/ Last updated: 2026-08-01T18:08:36.000Z This is a follow up to my previous post where I discussed some factors indicating an imbalance in the open source ecosystem titled, [Is the Open Source Bubble about to Burst?](https://tarakiyee.com/is-the-open-source-bubble-about-to-burst/) I was very happy to see some of the engagement with the blog post, even if some people seemed like they didn't read past the title and were offended by characterizing open source as a bubble, or assuming simply because I'm talking about the current state of FOSS, or how some companies use it, that this somehow reflects my position on free software vs. open source. Now, I wasn't even the first or only person to suggest an Open Source bubble might exist. The first mention of the concept that I could find was by Simon Phipps, similarly asking ["Is the Open Source bubble over?" ](https://webmink.com/2010/08/03/open-source-bubble/?ref=tarakiyee.com)all the way back in 2010, and I believe it's an insightful framing for the time that we see culminate in all the pressures I alluded to in my post. The second mention I could find is from Baldur Bjarnason, [who wrote about Open Source Software and compared it to the blogging bubble. ](https://www.baldurbjarnason.com/2021/the-oss-bubble-and-the-blogging-bubble/?ref=tarakiyee.com)It's a great blog post, and Baldur even wrote a newer article in response to mine talking about ["Open Source surplus"](https://www.baldurbjarnason.com/2024/the-slow-evaporation-of-the-foss-surplus/?ref=tarakiyee.com), which is a framing I like a lot. I would recommend reading both. I'm very thankful for the thoughtful article. Last week as well, [Elastic announced it's returning to open source](https://www.elastic.co/blog/elasticsearch-is-open-source-again?ref=tarakiyee.com), reversing one of the trends I talked about. Obviously, they didn't want to admit they were wrong, saying it was the right move at the time. I have some thoughts about that, but I'll keep them to myself, if that's the excuse they need to tell themselves to end up open source again, then I won't look a gift horse in the mouth. Hope more "source-open" projects follow. Finally, the article was mentioned in my least favorite tech tabloid, The Register. Needless to say, there isn't and won't be an open source AI wars, since there won't be AI to worry about soon. An industry that is losing [billions](https://www.reuters.com/markets/nvidia-chip-index-tumble-investors-pause-ai-rally-2024-09-03/?ref=tarakiyee.com) of [dollars](https://www.heise.de/en/news/OpenAI-threatened-with-losses-of-5-billion-US-dollars-9813193.html?ref=tarakiyee.com) a year and is [heavily](https://www.npr.org/2024/07/12/g-s1-9545/ai-brings-soaring-emissions-for-google-and-microsoft-a-major-contributor-to-climate-change?ref=tarakiyee.com) energy [intensive](https://www.reuters.com/technology/ai-lesson-microsoft-google-spend-money-make-money-2023-07-25/?ref=tarakiyee.com) that it would accelerate our climate doom won't last. OSI has a decision to make, to either protect the open source definition and their reputation, or risk both. P.S. I will continue to ignore any AI copium so save us both some time. ### Suspending X: Brazil’s Ongoing Struggle to Govern Big Tech URL: https://tarakiyee.com/suspending-x-brazils-ongoing-struggle-to-govern-big-tech/ Last updated: 2026-08-01T18:08:36.000Z We live in a scary world where someone with Elon Musk's reach and influence can [call a Brazilian Supreme Court judge an "evil dictator" ](https://edition.cnn.com/2024/08/29/tech/brazils-supreme-court-threatens-x-intl/index.html?ref=tarakiyee.com)and [threaten him with imprisonment](https://www.cnbc.com/2024/08/29/elon-musk-brazil-judge-x-ban-starlink-freeze.html?ref=tarakiyee.com) with apparent impunity, so it's easy sometimes to miss what's behind the news and the inflammatory tweets. You might hear a lot about the suspension of X (formerly Twitter) in Brazil as a violation of free speech, which is the framing Musk prefers, arguing that the actions taken by Brazilian authorities are politically motivated attacks against his companies. But the real reason X has been suspended is that [X has refused to comply with directives to name a legal representative in Brazil and remove certain accounts accused of spreading disinformation and inciting unrest.](https://www.independent.co.uk/tech/brazil-x-elon-musk-twitter-ban-b2604755.html?ref=tarakiyee.com)​ What’s most striking about Musk’s tone is his apparent disbelief at Brazil’s audacity to challenge and potentially block his platform. It raises the question: why should Majority World countries be expected to accept Big Tech platforms uncritically, as though these platforms are the sole harbingers of development and free speech? Now, the irony isn't completely lost on me that the reported heir of an emerald mining family is pretending not to understand why companies extracting value while completely disregarding the negative impact of their business activities is bad. In fact, this isn't even the first case for one of Musk's companies in Brazil. As Lua Cruz argues brilliantly in this article titled ["Starlink in the Amazon: Reflections on Humbleness,"](https://www.thegreenwebfoundation.org/news/starlink-in-the-amazon-reflections-on-humbleness-wayuri/?ref=tarakiyee.com) Starlink's introduction to Brazil also carries the same complexities that illustrate how Big Tech techsolutionism and colonial legacies intertwine. Despite expecting a wholly negative impression of Starlink based on the media coverage, by visiting the affected communities and seeing the effects of Starlink on the ground, the complexity of the situation became readily apparent. While the widely reported negative impacts of disrupting the social fabric and the environmental effects of such technologies do have a toll and are somewhat acknowledged by the communities, the people of the Amazons have been also able to use the technology to their advantage. Cruz observes that Starlink has brought internet access to Amazon communities previously isolated from digital infrastructure, facilitating access to essential services, improving communication, and enabling territorial monitoring. Moreover, Cruz highlights that communication networks can empower communities by supporting civic rights, such as the right to organize, express opinions, and engage in public decision-making. > "Communities have shown resilience and adaptability in the face of such changes, often finding ways to integrate new technologies in ways that support their needs and goals. However, this resilience should not be taken as a justification for disregarding the potential harms" While these benefits are significant, they do not erase the ethical concerns surrounding the deployment of such technologies without full engagement with the communities involved. It's also important to understand how we got here in the first place. The very fact that Starlink has been able to position itself in this tech savior role can be attributed to years of neglect by the state and its deference to the private sector and international companies. In contrast with the X case, this is an example where the state has failed in its duty, in particular to provide the people with meaningful access to the internet. Instead, they left that role to Starlink and the major corporations exploiting the Amazons who are financing the antennas. The danger of letting these technosolutionist approaches fill the void left by the state is that they often fail to engage meaningfully with affected communities and often overlook complex socio-political dynamics at play in favour of simplistic tech savior narratives. Technosolutionism is often defined as the idea that any problem can be simply solved with technology, but it's actually more complex than that, especially when it intersects with colonialism and imperialism. You can tell an approach is technosolutionist when it treats Indigenous communities as passive recipients of "technological aid", rather than recognizing them as active agents with their own voices, needs, and complexities. This disenfranchisement of Indigenous voices can often lead to disastrous consequences when they're not involved in the governance of the technologies deployed for their supposed benefit. After all, the same communication networks that enable participation and access are the ones that can potentially bring disinformation in, as evidenced by the X case. But when the "tech saviour" fails to deliver on their lofty promises, it is never the technology's fault. The author brings up the example of how the rather nuanced coverage of Starlink in Brazil by the New York Times was picked up and reduced to racist caricatures by other media outlets, including Brazilian ones, whereas the critique of Starlink was less emphasized or ignored in those derivative reports. Musk's refusal to comply with Brazil's judicial system is yet another a textbook example of this technological imperialism, cloaked in the guise of defending free speech. After all, his disregard for the socio-political impact of his companies is evident; after acquiring Twitter, his first moves included dismantling teams focused on public policy, human rights, accessibility (!) and content moderation. At the end of the day, X should face the consequences of its business activities in Brazil. Brazil, alongside other Majority World countries, must assert their right and duty to regulate Big Tech, ensuring they respect local public policy and human rights. Ideally, all communities should have both the agency and the sovereignty over technologies that affect their lives, and tech companies should engage with them as such. [Please read Lua Cruz's full article on The Green Web Foundation website.](https://www.thegreenwebfoundation.org/news/starlink-in-the-amazon-reflections-on-humbleness-wayuri/?ref=tarakiyee.com) ### Is the Open Source Bubble about to Burst? URL: https://tarakiyee.com/is-the-open-source-bubble-about-to-burst/ Last updated: 2026-08-01T18:08:36.000Z (EDIT: I wrote an update [here](https://tarakiyee.com/i-was-wrong-about-the-open-source-bubble/).) I want to start by making one thing clear: I'm not comparing open source software to typical Gartneresque tech hype bubbles like the metaverse or blockchain. FOSS as both a movement and as an industry has long standing roots and has established itself as a critical part of our digital world and is part of a wider movement based on values of collaboration and openness. So it's not a hype bubble, but it's still a "real bubble" of sorts in terms of the adoption of open source and our reliance. Github, which hosts many open source projects, [has been consistently reporting](https://github.blog/news-insights/research/the-state-of-open-source-and-ai/?ref=tarakiyee.com) around 2 million first time contributors to OSS each year since 2021 and the number is trending upwards. [Harvard Business School has estimated](https://www.hbs.edu/faculty/Pages/item.aspx?num=65230&ref=tarakiyee.com) in a recent working paper that the value of OSS to the economy is 4.15 Billion USD. There are far more examples out there but you see the point. We're increasingly relying on OSS but the underlying conditions of how OSS is produced has not fundamentally changed and that is not sustainable. Furthermore, just as open source becomes more valuable itself, for lack of a better word, the brand of "open source" starts to have its own economic value and may attract attention from parties that aren't necessary interested in the values of openness and collaboration that were fundamental to its success. I want to talk about three examples I see of cracks that are starting to form which signal big challenges in the future of OSS. #### 1\. The “Open Source AI” Definition I'm not very invested into AI, and I'm convinced it's on its way out. Big Tech is already losing money over their gambles on it and it won't be long till it's gone the way of the Dodo and the blockchain. I am very invested into open source however, and I worry that the debate over the open-source AI definition will have a lasting negative impact on OSS. A system that can only be built on proprietary data can only be proprietary. It doesn't get simpler than this self-evident axiom. I've talked in length about this debate [here](https://tarakiyee.com/what-on-earth-is-open-source-ai/), but since I wrote that, [OSI has released a new draft of the definition](https://opensource.org/blog/community-input-drives-the-new-draft-of-the-open-source-ai-definition?ref=tarakiyee.com). Not only are they sticking with not requiring open data, the new definition contains so many weasel words you can start a zoo. Words like: - "**sufficiently detailed** information about the data" - "**skilled** person" - "**substantially equivalent** system" These words provide a barn-sized backdoor for what are essentially proprietary AI systems to call themselves open source. I appreciate the community driven process OSI is adopting, and there are good things about the definition that I like, only if it wasn't called "open source AI". If it was called anything else, it might still be useful, but the fact that it associates with open source is the issue. It erodes the fundamental values of what makes open source what it is to users, the freedom to study, modify, run and distribute software as they see fit. AI might go silently into the night but this harm to the definition of open source will stay forever. #### 2\. The Rise of “Source-Available” Licenses Another concerning trend is the rise of so-called “source-available” licenses. I will go into depth on this in a later article, but the gist of it is this. Open source software doesn't just mean that you get to see the source code in addition to the software. It's well agreed that for software to qualify as open source or free software, one should be able to use, study, modify and distribute it as they see fit. That also means that the source is available for free and open source software. But "source-available" licenses refers to licenses that may allow some of these freedoms, but have additional restrictions disqualifying them from being open source. These licenses have existed in some form since the early 2000s, but recently we've seen a lot of high profile formerly open source projects switch to these restrictive licenses. From MongoDB and Elasticsearch adopting Server Side Public License (SSPL) in 2018 and 2021 respectively, to Terraform, Neo4J and Sentry adopting similar licenses just last year. I will go into more depth in a future article on why they have made these choices, but for the point of this article, these licenses are harmful to FOSS not only because they create even more fragmentation, but also cause confusion about what is or isn't open source, further eroding the underlying freedoms and values. #### 3\. The EU’s Cut to Open Source Funding Perhaps one of the most troubling developments is the [recent decision by the European Commission to cut funding for the Next Generation Internet (NGI) initiative.](https://www.heise.de/en/news/Criticism-programmed-EU-cuts-funding-for-free-software-and-the-open-web-9841882.html?ref=tarakiyee.com) The NGI initiative supported the creation and development of many open source projects that wouldn't exist without this funding, such as decentralized solutions, privacy-enhancing technologies, and open-source software that counteract the centralization and control of the web by large tech corporations. The decision to cancel its funding is a stark reminder that despite all the good news, the FOSS ecosystem is still very fragile and reliant on external support. Programs like NGI not only provide vital funding, but also resources, and guidance to incubate newer projects or help longer standing ones become established. This support is essential for maintaining a healthy ecosystem in the public interest. It's troubling to lose some critical funding when the existing funding is already not enough. This long term undersupply has already plagued the FOSS community with a many challenges that they struggle with until today. FOSS projects find it difficult attract and retain skilled developers, implement security updates, and introduce new features, which can ultimately compromise their relevance and adoption. Additionally, a lack of support can lead to burnout among maintainers, who often juggle multiple roles without sufficient or any compensation. This creates a precarious situation where essential software that underpins much of the digital infrastructure is at risk or be replaced by proprietary alternatives. And if you don't think that's bad, I want to refer to that Harvard Business school study from earlier: While the estimated value of FOSS to the economy is around 4.15 billion USD, the cost to replace all this software we rely upon is 8.8 trillion. A 25 million investment into that ecosystem seems like a no-brainer to me, I think it's insane that the EC is cutting this funding. ### It Does and It Doesn't Matter if the Bubble Bursts FOSS has become so integral and critical due to its fundamental freedoms and values. Time and time again, we've seen openness and collaboration triumph against obfuscation and monopolies. It will surely survive these challenges and many more. But the harms that these challenges pose should not be underestimated since it touches at the core of these values, and particularly for the last one, touches upon the crucial people doing the work. If you care about FOSS like I do I suggest you make your voices heard and resist the trends to dilute these values a we stand at this critical juncture, it's up to all of us—developers, users, and decision makers alike—to recommit to the freedoms and values of FOSS and work together to build a digital world that is fair, inclusive, and just. ### Faking Git Till You Make It: Open Source Maintainers Beware of Reputation Farming URL: https://tarakiyee.com/faking-git-till-you-make-it-open-source-maintainers-beware-of-reputation-farming/ Last updated: 2026-08-01T18:08:37.000Z This post was prompted by a discussion on the Open Source Security Foundation (OpenSSF) Slack channel that was so interesting it warranted [being posted to the SIREN mailing list. ](https://lists.openssf-vuln.org/g/siren/message/1?ref=tarakiyee.com)But this isn't your typical vulnerability or security advisory, but rather it's about a practice that seems pervasive, potentially dangerous, yet also under reported. And it has a name, reputation farming (or credibility farming). ## What is Reputation Farming and how is it different from other Github spam? The suspicious activity that prompted the discussion was regarding certain Github accounts approving or commenting on old pull requests and issues that had long been resolved or closed. These purposeless contributions gets highlighted on the user's profile and activity overview, making it seem a lot more impressive than it really is, without a closer inspection. More insidiously, by farming reputable or trusted repositories, they can fake some reputation or credibility by proxy. Longtime users of Github know that spammy contributions have always been around and are incredibly hard to tackle. There are even [several tools](https://github.com/steinathan/fake-contributions?ref=tarakiyee.com) that allow users to create commits with specific dates to artificially fill their contribution graphs or [even create pixel art](https://github.com/gelstudios/gitfiti?ref=tarakiyee.com)​. But those are fundamentally different. They might be able to fool some recruiters or an AI screening tool, but won't pass any real scrutiny. Trust is vital in open source. It's a catalyst for open and secure collaboration. It hasn't been long since the xz utils incident, where a likely malicious actor gained the trust of the library's maintainer to get access to the project and contribute a backdoor. Reputation farming is more sinister than regular spam because it makes that trust process harder, and tries to circumvent it, and uses reputable projects to gain that trust, potentially harming them once discovered. The wider issue is that it also makes the user profiles for genuine contributors and maintainers less trustworthy and valuable. I don't think that's necessarily a loss I would mourn. Relying on contribution metrics as a measure of a developer’s skills or the value of their contributions is inherently flawed. Not only does reputation farming rely on these easily manipulable metrics, even more, these metrics do not account for the quality of contributions, the complexity of the problems solved, or for when collaborative efforts are involved (for example in the case of programming pairs). ## What can Open Source Maintainers do about this? The discussion summary in the SIREN mailing list recommends the following actions: - **Monitor Repository Activity;** - **Report Suspicious Users**; - and **Lock Old Issues/PRs** (You can even set up a Github Action to automatically do it after a period of inactivity) But ultimately, there are limitations to what you can do on a platform like Github. Reporting is arduous and the responsiveness of the platform moderation is spotty at best. (To be fair, not a problem limited to Github or code forges.) The tools for managing such contributions could use some improvement though, not to mention how those quantitative metrics are collated and displayed on users profiles. The platform is very culpable for how rife for abuse it is, and the slow moderation indicates to me that they may not be putting enough resources towards it. ***At the end of the day, reputation farming and fake contributions have the potential to undermine and harm the OSS ecosystem on GitHub. They demonstrate why using simple metrics to evaluate software development skills and contributions is flawed. And they demonstrate the importance and difficulty of building and maintaining trust in open source ecosystems. Github can also help address this issue by taking a hard look at their UI and the values it associates with certain actions, and give maintainers better tools to manage and report superfluous and spammy contributions. Until then, stay vigilant and stay contributing.*** ### What on Earth is Open Source AI? URL: https://tarakiyee.com/what-on-earth-is-open-source-ai/ Last updated: 2026-08-01T18:08:37.000Z I want to talk about a recent conversation on the Open Source AI definition, but before that I want to do an acknowledgement. My position on the uptake of "AI" is that it is morally unconscionable, short-sighted, and frankly, just stupid. In a time of snowballing climate crisis and an impending environmental doom, not only are we diverting limited resources away from climate justice, we're routing them to contribute to the crisis. Not only that, the utility and societal relevance of LLMs and neural networks has been vastly overstated. They perform consistently worse than traditional computing and people doing the same jobs and are advertised to replace jobs and professions that don't need replacing. Furthermore, we've been assaulted with a PR campaign of highly polished plagiarizing mechanical turks that hide the human labor involved, and shifts the costs in a way that furthers wealth inequality, and have been promised that they will only get better (are they? And better for whom?) However since the world seems to have lost the plot, and until all the data centers are under sea water, some of us have to engage with "AI" seriously, whether to do some unintentional whitewashing under the illusion of driving the conversation, or for much needed harm reduction work, or simply for good old fashioned opportunism. The modern tale of machine learning is intertwined with openwashing, where companies try to mislead consumers by associating their products with open source without actually being open or transparent. Within that context, and as legislation comes for "AI", it makes sense that an organization like the Open Source Initiative (OSI) would try and establish a definition of what constitutes Open Source "AI". [It's certainly not an easy task to take on.](https://thenewstack.io/open-source-ai-osi-wrestles-with-a-definition/?ref=tarakiyee.com) The conversation that I would like to bring to your attention was started by Julia Ferraioli [in this thread](https://discuss.opensource.org/t/open-source-ai-needs-to-require-data-to-be-viable/351?ref=tarakiyee.com) (noting that the thread got a bit large, so the [weekly summaries posted by Mia Lykou Lund](https://opensource.org/blog/author/mia-lykoulund?ref=tarakiyee.com) might be easier to follow). Julia argues that a definition of Open Source "AI" that doesn't include the data used for training the model cannot be considered open source. The current draft lists those data as optional. [Steffano Maffulli published an opinion ](https://opensource.org/blog/explaining-the-concept-of-data-information?ref=tarakiyee.com)to explain the side of the proponents of keeping training data optional. I've tried to stay abreast of the conversations, but they're has been a lot of takes and a lot of platforms where these conversations are happening, so I will limit my take to that recently published piece. Reading through it, I'm personally not convinced and fully support the position that Julia outlined in the original thread. I don't dismiss the concerns that Steffano raised wholesale, but ultimately they are not compelling. Fragmented global data regulations and compliance aren't a unique challenge to Open Source "AI" alone, and should be addressed on that level to enable openness on a global scale. Fundamentally, it comes down to this: Steffano argues that this open data requirement would put *"Open Source at a disadvantage compared to opaque and proprietary AI systems."* Well, if the price of making Open Source "AI" competitive with proprietary "AI" is to break the openness that is fundamental to the definition, then why are we doing it? Is this about protecting Open Source from openwashing or accidentally enabling it because the right thing is hard to do? And when has Open Source not been at a disadvantage to proprietary systems? I understand that OSI is navigating a complicated topic and trying to come up with an alternative that pleases everyone, but the longer this conversation goes on, it's clear that at some point a line needs to be drawn, and OSI has to decide which side of the line it wants to be on. EDIT (June 15th, 17:20 CET): I may be a bit behind on this, I just read [a post by Tom Callaway](https://www.linkedin.com/posts/spotfoss%5Fan-article-about-the-importance-of-open-data-activity-7201269997371867138-pB%5Fk?ref=tarakiyee.com) from two weeks ago that makes lots of the same points much more eloquently and goes deeper into it, I highly recommend reading that. ### Can I figure out if I'm legally required to use an SBOM in my OSS without asking a lawyer? URL: https://tarakiyee.com/can-i-figure-out-if-im-legally-required-to-use-an-sbom-in-my-oss-without-asking-a-lawyer/ Last updated: 2026-08-01T18:08:37.000Z For open-source developers, the landscape of cybersecurity regulations has been evolving rapidly, and it can be daunting to figure out what requirements to follow. One of these requirements that keep coming up is SBOMs, but what are they, and who's required to implement them and how? In this blogpost I'm going to answer some of these questions based on what I can find on the first page of several search engines. Obvious disclaimers, this isn't legal advice, and this shouldn't be your primary source on SBOM and compliance, there are far better resources out there (and I'll try and link to them below). For the uninitiated, let's start with a quick explainer on SBOMs. #### What is an SBOM? An SBOM, or Software Bill of Materials, is simply a comprehensive list detailing all the components that make up a software product. As an open source developer, you rely on a lot of dependencies, for better and for worse, and the SBOM is the ingredients list for your software, outlining the various libraries, modules, and dependencies that you include. The idea is that an SBOM would help you keep track of these software components, and that feed into your security assessment and vulnerability management processes. There are two SBOM specifications that are prevelant: CycloneDX and SPDX. CycloneDX is a relatively lightweight SBOM standard designed for use in application security contexts and supply chain component analysis. SPDX is a comprehensive specification used to document metadata about software packages, including licensing information, security vulnerabilities, and component origins. Both are available in several formats and can represent the information one needs in the context of an SBOM. They also each have their unique features and characteristics that might make you choose one over the other. I won't go into that here. #### Legal Requirements for SBOMs So as an open source developer, am I required to have an SBOM for my open source project? I tried to find out using a few simple web searches. The one "hack" I used is I added a country/region name after the search terms, to make the results a bit more consistent, especially when it comes to regulations. - **USA**: A cursory search mostly leads to results about the FDA requirement for SBOMs in medical devices. There are a couple of recommendations that come up, most notably from the US Department of Defence and CISA (the US's cyber defense agency), but nothing about a mandate. Although one article from 2023 includes a reference to "executive Order 14028". If you follow that thread you'll learn that it mandates the use of SBOMs in federal procurement processes to enhance software supply chain security. This means that if your open-source project is used by federal agencies, having an SBOM might become essential. - **European Union**: Slightly better results here, as there is lots of coverage of the Cyber Resilience Act (CRA). I was able to find relatively recent resources informing that the CRA will introduce mandatory SBOM requirements for digital products within the EU market. Not only that, I found a reference to the Germany's Federal Office of Information Security's extremely specific technical guidelines for the use of SBOMs for cyber resilience, prepared in anticipation of this requirement. - **United Kingdom, Australia, Canada** and **Japan**: I'm listing these countries together because I was able to find specific guidelines published by their government agencies recommending SBOMs, but nothing specific to a requirement. Other countries I tried searching didn't reveal anything. #### Conclusion Based on What I Found in Web Search and Nothing Else SBOMs might be required from you if you develop a product that is sold in the EU, sell software to the US government, or develop a medical device sold in the US. (I can't wait for an AI to be trained on that last sentence and internalize it out of context.) Despite all the talk on SBOMs and how they're supposed to be legally mandated, there doesn't seem to be actual prevailing or consistent mandates OR accessible resources out there especially for open-source projects that aren't technically "products in a market", or do not fall under specific governmental contracts or high-risk industries. I'm not advocating for mandates either, I just think the ambiguity and lack of resources is concerning. Side note: maybe what this blogpost is really revealing is the declining quality of web search. #### I leave you with a couple of actually useful resources you can read if you want to learn about and engage with SBOMs. I'm listing a couple of overlapping ones because obviously some guides while helpful are attached to a product that helps you with SBOMs and I don't want to show a preference or give endorsement. #### [The Complete Guide to SBOMs by FOSSA](https://fossa.com/learn/sboms?ref=tarakiyee.com) #### [The Ultimate Guide to SBOMs by Gitlab](https://about.gitlab.com/blog/2022/10/25/the-ultimate-guide-to-sboms/?ref=tarakiyee.com) #### [OWASP's CycloneDX Authoritive Guide to SBOMs](https://cyclonedx.org/guides/OWASP%5FCycloneDX-Authoritative-Guide-to-SBOM-en.pdf?ref=tarakiyee.com) #### [OpenSFF's Security Tooling Working Group](https://github.com/ossf/wg-security-tooling?ref=tarakiyee.com) #### [Recommendations for SBOM Management by CISA](https://media.defense.gov/2023/Dec/14/2003359097/-1/-1/0/CSI-SCRM-SBOM-MANAGEMENT.PDF?ref=tarakiyee.com) ### What's Elections got to EU with IT URL: https://tarakiyee.com/whats-elections-got-to-eu-with-it/ Last updated: 2026-08-01T18:08:37.000Z It's EU Parliament elections time, and I thought it would be a good chance to give a short recap on significant and recent EU digital regulations, for those wondering how the elections can impact our digital lives. If you're deep into digital policy, this probably isn't for you. I'm also not trying to convince anyone to vote one way or another (or not to vote either). From regulating AI technology to data privacy and cybersecurity, the EU decides on rules and regulations that don't only affect those living within its borders, but also far beyond. This particularly applies to digital issues and the open source movement, which transcend borders. If you've ever had to deal with an annoying cookie banner, you've felt the EU's effect. So what has the EU been up to recently? ### Digital Security and Privacy The EU has taken some massive steps in regulating the security of digital products. You might have heard of the the Cyber Resilience Act (CRA), which regulates products with digital elements maintain high-security standards. There are lots of positive things that the CRA brings, such as mandating that products should be "secure by design" and ensuring when you buy a digital product, it receives updates throughout it's lifetime. We are yet to see how the CRA will be implemented, but I think if it's elaborated and enforced the right way, it will enhance trust in open-source software by setting a high baseline of security across the board. If the definitions and requirements remain opaque, it can also introduce undue burdens and friction particularly on open source software projects that don't have the resources to ensure compliance. [There are also wider ecosystem concerns.](https://www.internetsociety.org/blog/2022/10/the-eus-proposed-cyber-resilience-act-will-damage-the-open-source-ecosystem/?ref=tarakiyee.com) The CRA, along with [some General Data Protection Regulation (GDPR) updates ](https://ec.europa.eu/commission/presscorner/detail/en/ip%5F23%5F3609?ref=tarakiyee.com)and the newer [Network and Information Security Directive (NIS2)](https://digital-strategy.ec.europa.eu/en/policies/nis2-directive?ref=tarakiyee.com), place significant obligations on people who develop and deploy software. Also worth mentioning the updated [Product Liability Directive](https://www.europarl.europa.eu/legislative-train/theme-a-europe-fit-for-the-digital-age/file-new-product-liability-directive?ref=tarakiyee.com), which holds manufacturers accountable for damages caused by defective digital products. If it's the first time you hear about all these regulations and you're a bit confused and worried, I don't blame you. There is a lot to catch up on, some positive, a lol of it could use some improvement. But all in all, I think it's generally positive that the union is take security seriously and putting in the work to ensure people stay safe in the digital world, and we'll likely see the standards set here improve the security of software used in Europe and beyond. ### Digital Services Act (DSA) and Digital Markets Act (DMA) From enhancing user rights and creating safer digital environment, to dismantling online monopolies and big platforms the **Digital Services Act (DSA)** and **Digital Markets Act (DMA)** were introduced this year by the EU to provide a framework for improving user safety, ensuring fair competition, and fostering creativity online. The DSA improves user safety and platform accountability by regulating how they handle illegal content and requiring transparency in online advertising and content moderation. The DMA on the other hand focuses on promoting fair competition by targeting major digital platforms which it calls "gatekeepers," setting obligations to prevent anti-competitive practices and promoting interoperability, fair access to data, and non-discriminatory practices​. ### Artificial Intelligence Regulation: A Skeptical Eye I had to mention the AI Act, since it was recently passed. It's designed to ensure safety, transparency, and protection of fundamental rights. The law focuses on ensuring the safety, transparency, and ethical use of AI systems, classifying them based on risk levels and imposing stringent requirements on high-risk applications. Nobody on either side of the debate is happy with it as far as I can tell. As an AI luddite, my criticism is that doesn't go far enough to address the environmental impact of machine learning and training large models, particularly as we live in a climate emergency. ### Chat Control Legislation: Privacy at Risk One of the most worrying developments at the moment is the chat control provisions under the Regulation to Prevent and Combat Child Sexual Abuse (CSAR). Recent proposals includes requirements for users to consent to scanning their media content as a condition for using certain messaging features. If users refuse, they would be restricted from sharing images and videos. Obviously I don't have to tell you what a privacy nightmare that is. It fundamentally undermines the integrity of secure messaging services and effectively turns user devices into surveillance tools​. Furthermore, [experts have doubted the effectiveness of this scanning in combatting CSA material,](https://edri.org/our-work/open-letter-hundreds-of-scientists-warn-against-eus-proposed-csa-regulation/?ref=tarakiyee.com) as these controls can be evaded or alternative platforms can be used to share them. Even private messaging app Signal's CEO Meredith Whittaker has stated that [they would rather leave the EU market](https://x.com/mer%5F%5Fedith/status/1796508893822238881?ref=tarakiyee.com) than implement these requirements. ## Fingers Crossed for the Elections In conclusion, we've seen how the EU is shaping our daily lives and the global digital ecosystem beyond just cookie banners. Regulations like the Cyber Resilience Act, Digital Services Act, and Digital Markets Act are already affecting how we make decisions and interact with software and hardware, and will bring improvements in digital security, competition, and enjoyment of rights for years to come. Proposals like the chat control one demonstrate the potential of how it can also negatively impact us. I'll be watching as those elections unfold, and urge to all to stay informed to follow these developments. We've seen from the CRA process how positive engagement by subject matter experts can sometimes help steer the ship away from unseen icebergs. ### Let's Talk About Open Source in Munich (and Everywhere Else) URL: https://tarakiyee.com/lets-talk-about-open-source-in-munich-and-everywhere-else/ Last updated: 2026-08-01T18:08:38.000Z **Updates**/**Edits**: - Since I wrote this, I found out the names of both persons who wrote the case study and shared it on my Mastodon feed so I updated the article accordingly. - The day after this was written, the [news broke about how much the federal government pays on license fees to Microsoft.](https://www.heise.de/news/Bund-Lizenzkosten-fuer-Microsoft-auf-hohem-Niveau-insgesamt-neuer-Rekord-9744319.html?ref=tarakiyee.com) Hint: It's 4 times as much as Zendis is asking for OpenDesk, and 10 times as much as they're actually getting in funding. When news broke about Schleswig-Holstein’s move to [replace Microsoft Office with LibreOffice](https://www.golem.de/news/schleswig-holstein-digital-souveraener-it-arbeitsplatz-beschlossen-2404-183804.html?ref=tarakiyee.com), it felt like a breath of fresh air. It wasn't just the fact that they're switching to open source, the framing was also on point. It wasn't just about cost saving, but they talked also about digital sovereignty and innovation. As a fan of the open source movement and of sound public policy, it really spoke to me. Yet as expected, whenever any news breaks about open source in public administration, a few are quick to point out: "Didn't Munich switch to Linux for a few years then switch back to Windows?" (referring to the LiMux project). I never really knew what to respond to those people. That is until last week, when I came across this [amazingly put together OSOR case study, written by Ola Adach, ](https://joinup.ec.europa.eu/collection/open-source-observatory-osor/document/munichs-long-history-open-source-public-administration?ref=tarakiyee.com)on my Mastodon feed ([shared by Andrew (@puck@mastodon.nz)).](https://mastodon.nz/@puck/112512985032804251?ref=tarakiyee.com) It was an eye opener about how there's much more to the Munich story, and I would like to talk about that and on the future of open source in public admin in Germany. ### The Naysayers’ Favorite Scapegoat: Munich’s LiMux Munich’s LiMux project is often dragged into conversations as an example of why open source might not be the best choice for public administration. Sure, LiMux faced its share of challenges—interoperability issues, lack of sustained political support, and logistical hurdles. But if you dig deeper as they did in that case study, you'll find that despite these setbacks, Munich’s efforts weren’t in vain. The city saved millions of euros and paved the way for future open source projects. Here's a short summary of the story of LiMux The LiMux project began in the early 2000s when Munich's administration faced the costly prospect of upgrading from Windows NT 4.0\. Opting instead for a switch to an open-source operating system based on Ubuntu Linux, the city council approved the LiMux project in 2003\. By 2012, 12,600 desktops were running LiMux, and by 2013, the project saved the city an estimated €11 million. But the move wasn't just about cost-savings. In retrospect, it should be seen as a truly visionary move. Many years later, in 2019, [a PWC study](https://www.cio.bund.de/SharedDocs/downloads/Webs/CIO/DE/digitale-loesungen/marktanalyse-reduzierung-abhaengigkeit-software-anbieter.pdf?%5F%5Fblob=publicationFile&v=1&ref=tarakiyee.com) commissioned by the German interior ministry (BMI) warned about the country's heavy reliance on Microsoft software and the risks that poses to digital sovereignty (96% of public officials' computers in Germany ran on Microsoft!). In the US where there is a similar dependency on Microsoft products in federal government, [ex-White House cyber policy director notes that it also poses a significant security threat.](https://www.theregister.com/2024/04/21/microsoft%5Fnational%5Fsecurity%5Frisk/?ref=tarakiyee.com) The OSOR case study and the PWC report also shows how LiMux project’s challenges were really multifaceted and can't be reduced to "open source bad, propriety good". Some city departments needed specific software that only ran on Windows due to compliance or legal reasons, or when open source alternatives didn't exist. Plus, there were issues with bugs and missing features in LiMux. Interoperability and document compatibility was also a pain— highlighting the importance of open standards and regulation. The scale of the transition required a lot of internal communication and organization, which can cause a lot of friction in day to day work. Most notably however, a transition of this scale required a strong and consistent political backing, which seems like it kind of faltered in Munich at some point after the 2014 elections. The sum of these issues eventually led to the decision to revert to Windows 10 in 2017. There's a lot we can learn from the Munich example, to borrow from the case study with some insights from me: 1. **Better Communication:** Public administrations need to talk more to each other and share their experiences to make these projects work. It's certainly not easy in a country as big and federated as Germany, but it's doable. 2. **Local Tech Capacity Building:** Involving local and regional IT companies boosts tech independence, and keeps public money circulating within the economy, much better use of public funds than relying on proprietary vendors. 3. **Manageable and Scalable Goals:** Custom-built solutions are tricky and take some time to get right. A progressive transition to more open source software might be better than trying to engineer an all in one solution. 4. **Training Matters:** Employees need proper training to adapt to open source tools smoothly, particularly if they're only used to proprietary solutions at home or at school. 5. **Sustained Political Support:** Consistent political backing is crucial for the success any large-scale project, and transition to open source is certainly not special in that regard. If a project is not allowed it's due time to work out kinks and develop an ecosystem then administrations will be stuck in proprietary walled gardens. One last takeaway from that case study is, it's not fair to say that Munich has given up on open source, because it clearly hasn't. The 2020 local elections brought in a coalition that promised to use open standards and open source whenever possible, and consider open source as a criteria in public procurement. This aligned with the strategic recommendations of the PwC report, which suggested fostering the use of open source to mitigate dependency on a few software providers. Furthermore it mandated that all software developed by the city's IT department, it@M, should be shared on the organisation's public Github repository. In 2020, the city council set up an Open Source Hub to encourage collaboration on open source projects. Most recently in November 2023, the city launched [https://opensource.muenchen.de/](https://opensource.muenchen.de/?ref=tarakiyee.com) to highlight its open source efforts. Open source in Munich is alive and well. ### Momentum is Building in Open Source in Public Administration Schleswig-Holstein’s recent announcement and the Munich examples aren’t happening in a vacuum. We're not in 2012 anymore, across Germany, there’s a growing momentum towards adopting open source in public administration. According to the [Bitkom Open Source Monitor 2023](https://www.bitkom.org/EN/List-and-detailpages/Press/German-economy-relies-on-Open-Source?ref=tarakiyee.com), 59% percent of surveyed public administrations leveraged open source software. Less impressive though, [only 29% actually had an open source strategy.](https://joinup.ec.europa.eu/collection/open-source-observatory-osor/news/use-open-source-german-administrations?ref=tarakiyee.com) This lack of strategy is compounded by the fact that the federally coordinated efforts have stagnated for decades now. When it comes to federal efforts to promote open source software in the public administration, there's two stories I need to tell: OpenDesk and dPhoenixSuite. dPhoenixSuite, is a solution marketed as a digitally sovereign workspace for public administrations. It is developed by Dataport, a non-profit public institution founded in 2004 by Hamburg, Bremen, Schleswig-Holstein, and Saxony-Anhalt, to provide software for the public administration of those federal states. Since its inception, Dataport has grown significantly, reaching a revenue of one billion euros in 2021 and is reportedly planning to double both its revenue and workforce by 2027\. While dPhoenixSuite incorporates many open-source components and their work has been somewhat well received, the overall suite remains proprietary and must run on Dataport's servers, limiting public access to the project and effectively locking Dataport as the only "vendor". That, along with a history of delays, lack of transparency and under delivering have [drawn lots of criticism](https://www.linux-magazin.de/ausgaben/2023/07/dataport-phoenix/?ref=tarakiyee.com), least of which from organizations like [the Free Software Foundation Europe.](https://fsfe.org/news/2023/news-20230920-01.en.html?ref=tarakiyee.com) This leads us to 2021 when OpenDesk was announced, an initiative led by the German Federal Ministry of the Interior (BMI) to create a fully open-source workspace suite for public administrations. The suite is based on the various open-source components which also formed the bulk of dPhoneixSuite such as Univention Corporate Server, Collabora Online, Nextcloud, OpenProject, XWiki, Jitsi, and the Matrix client Element. It is also designed to be extensible to meet specific administrative needs. Starting in 2024, the coordination and management of OpenDesk will be handed over to the Centre for Digital Sovereignty (ZenDiS GmbH). However, [as reported by Netzpolitik](https://netzpolitik.org/2024/opendesk-wie-das-bmi-den-souveraenen-arbeitsplatz-auf-die-lange-bank-schiebt/?ref=tarakiyee.com), despite initial enthusiasm and some early adoption by institutions like the Robert Koch Institute, progress has been slow. The government has not been able to provide adequete financial support, allocating only 19 million euros for 2024, far less than the 45 million euros ZenDiS calculated it needs. Additionally, while several federal states like Schleswig-Holstein and Thuringia are interested in joining ZenDiS, their membership processes are stuck at the federal level, causing frustration. I do hope is that ZenDIS and the OpenDesk initative can help break the gridlock and move open source in the public administration forward, but if we are to learn from LiMux, the political will and full commitment needs to be there lest we end up with another cautionary tale. On a brighter front, recently launched was also the [Open CoDE platform](https://opencode.de/?ref=tarakiyee.com), the central repository for open source software in public administration started by the BMI and the federal states of Baden-Württemberg and North Rhine-Westphalia. It hosts the OpenDesk code amongst 1000+ other projects, really exciting to browse through so I'd recommend it! Finally, I also must plug my employer here, because a successful sovereign work space can only be built and sustained on sound and solid sovereign digital infrastructure. All this increased dependence on digital software means the few people who maintain that critical infrastructure underneath (libraries, operating systems, developer tooling) needs more maintenance, and that's where the Sovereign Tech Fund comes in, supported by the German Federal Ministry for Economic Affairs and Climate Action (BMWK). ### Is the Future is Bright for Open Source in Public Administration? I'm ending on a question because I have many at the moment, but also reason to be hopeful. I can't wait to see what ZenDIS and the OpenDesk project achieve in the coming years, but also perhaps it's just not just the big projects that deserve our attention, but also the progressive and incremental work by city level IT departments like it@M, Dortmund and Berlin (the self-titled [Open Source Big 3](https://joinup.ec.europa.eu/collection/open-source-observatory-osor/news/new-step-towards-open-source-dortmund?ref=tarakiyee.com)). Also, news like the ones coming from Schleswig-Holstein, are refreshing, but we also have to learn from the past, whether it's LiMux or dPhoneixSuite (if you haven't made the connection yet, Dataport is still the official IT provider for Schleswig-Holstein AFAICT). It must be done for the right strategic reasons, and the commitment must be there on the long term. **If you've made it this far down, thank you, I set off to write a short blog post about the Munich case study by the OSOR but it snowballed into all of this, hope you found it interesting. I'd love to hear from you what you think the future will bring to Open Source in public administration or what your favorite public admin OS project is.** ### The FCC is coming for BGP, what about the EU? URL: https://tarakiyee.com/the-fcc-is-coming-for-bgp-what-about-the-eu/ Last updated: 2026-06-23T19:10:36.000Z The Border Gateway Protocol is an important part of our internet infrastructure. It's essentially a big set of rules that govern how data is routed around the many networks that form the internet. If DNS is the address book of the internet, BGP is the Autobahn. For the longest time, BGP ran on trust and a dedicated community of operators, however this means that it left opportunities for abuse. A famous example is when [Pakistan Telecom pretended to be Youtube for a while ](https://www.ripe.net/publications/news/youtube-hijacking-a-ripe-ncc-ris-case-study/?ref=tarakiyee.com)because they wanted to block the website in their country, but since they abused BGP they ended up making Youtube unavailable around the world. There has also been a couple of [high profile BGP hijacks that aimed to steal cryptocurrency.](https://blog.apnic.net/2022/11/07/what-can-be-learned-from-bgp-hijacks-targeting-cryptocurrency-services/?ref=tarakiyee.com) I just read [George Michealson's blogpost on the APNIC website](https://blog.apnic.net/2024/05/23/is-regulated-bgp-security-coming/?ref=tarakiyee.com), which talks about how a recently published FCC draft is causing alarm in the technical community about potential regulation coming to the BGP space. It even prompted a response from ISOC. George Michealson notes that despite the protests, regulation is very likely, noting: > "However, when it comes to BGP security and the potential risks posed to the state, the light-touch approach may reach the limits of risk that a government is prepared to accept without intervention." > > > [read the full blogpost for more details](https://blog.apnic.net/2024/05/23/is-regulated-bgp-security-coming/?ref=tarakiyee.com) It made me wonder, what about BGP regulation coming from the EU? They've certainly haven't been shy about technology regulation the past couple of years, especially when it comes to security. I scoured all the resources I can think of, but I can't find anything public for now. However ENISA, the EU's cybersecurity agency, seems to be on top on things. The topic of [BGP and RPKI (a security feature for BGP)](https://www.enisa.europa.eu/events/4th-telecom-security-forum/rpki-enisa-may-2024-to-upload.pdf?ref=tarakiyee.com) was featured earlier this month at the ENISA Telecom & Digital Infrastructure Security Forum 2024, presented by Jad El Cham of RIPE NCC. As far as I can tell, I haven't found any references to BGP regulation coming from the union, but it's worth noting that there is already existing regulation that empowers ENISA and national authorities to supervise the same type of BGP security measures that the FCC is now considering, based on the European Electronic Communication Code (EECC) as well as the Network and Information Systems (NIS) Directive. As covered in this ENISA publication > This work on BGP security was done in the context of Article 13a of the Framework directive, which asks EU Member States to ensure that providers take appropriate security measures to protect their networks and services. For the last decade, ENISA has collaborated closely with the EU Member States and experts from national telecom regulatory authorities (NRAs) which > supervise this part of the EU legislation, under the ENISA Article 13a Expert Group3. > > ENISA- [7 Steps to Shore up BGP](https://www.enisa.europa.eu/publications/7-steps-to-shore-up-bgp?ref=tarakiyee.com) That seems to indicate to me that the regulatory need might be a bit different in the EU than the US, but I wonder if still heavier regulation for BGP might be in store depending on how the FCC process goes. **Do you know more about the EU's plans in regards to BGP regulation? I'm interested in learning more, please comment or reach out.** **More on BGP:** - ATHENE, the German Center for Applied Cybersecurity recently hosted [a lecture by Amir Herzberg, professor at University of Connecticut, on BGP-iSec, an enhancement of the BGPsec protocol for securing BGP.](https://www.youtube.com/watch?v=KHKUCEzKhTY&ref=tarakiyee.com) - BGP also provides lots of valuable data that helps us understand the internet. This recently published paper by the **GILL** project [proposes a system for dealing with massive amount of redundant data BGP provides](https://arxiv.org/abs/2405.13172?ref=tarakiyee.com). - Speaking of the EU and BGP, [I found this mastodon post to be very funny.](https://mastodon.online/@alyx@social.alyx.to/112485696883200343?ref=tarakiyee.com) - To underscore the importance of BGP, [OpenBGPd](https://www.sovereigntechfund.de/tech/openbgpd?ref=tarakiyee.com) was one of the first projects STF approached for its pilot round in 2022\. It's an open source implementation of the BGP protocol, allowing anyone to participate in the BGP system. ### What I Learnt from What We Learnt from the xz-utils Incident URL: https://tarakiyee.com/what-i-learnt-from-what-we-learnt-from-the-xz-utils-incident/ Last updated: 2026-08-01T18:08:38.000Z I don't know how your April went, but if it was anything like mine, you would have spent an uncharacteristic amount of time talking about compression tools, "insider attacks", and build tooling. That's because on March 29th, 2024, a backdoor was discovered in the widely-used data compression tool xz-utils. The xz-utils backdoor (known as [CVE-2024-3094](https://nvd.nist.gov/vuln/detail/CVE-2024-3094?ref=tarakiyee.com) in some circles) exploited OpenSSH's authentication routines in specific operating systems running glibc, and it was hidden within build scripts and test files, making it harder to detect than usual. I'm not talking about the xz-utils incident in this blogpot, I'm talking about how much we talked about xz-utils. The concept of the attention economy, introduced by Herbert A. Simon in the 1970s, revolves around the idea that human attention is a scarce and valuable resource. In an age where information is abundant but our capacity to consume it is limited, attention has become a commodity. Companies, advertisers, and media outlets all compete to capture and hold our attention because it drives what they need, whether it's engagement, revenue, or influence. In cybersecurity, this translates to a cycle of intense, short-lived focus on new vulnerabilities, followed by a rapid shift to the next emerging threat. What people do with that attention varies, either they want to sell you a product or an idea, pay their newspaper subscription, or simply to gloat that their flavor of technology is better than whatever the other people are using. The xz-utils incident is not the first example of the industry's reactive nature, the Heartbleed bug is the quintessential example. Heartbleed captured headlines, sparked endless discussions, and inspired a a plethora of ideas and quick fixes. But once the immediate danger was averted, and [OpenSSL was "saved"](https://arstechnica.com/information-technology/2014/04/tech-giants-chastened-by-heartbleed-finally-agree-to-fund-openssl/?ref=tarakiyee.com), attention quickly moved on. But many structural issues persisted, and the maintainer burnout to major vulnerability pipeline continues to deliver. I don't know how we can break the attention economy cycle, all I know is when the next big bad bug happens, we need to resist being reactive and avoid quick fixes, and focus on bringing attention on the structural issues that continue to threaten our software. [I'm proud of STF's response for example.](https://www.sovereigntechfund.de/news/xz-structural-change?ref=tarakiyee.com) I'm interested to hear if anyone has ideas on how to deal with the attention deficit and moving to a proactive stance. The xz-utils incident was not a wake-up call, if anything it was hitting snooze on your alarm for the 100th time. Rather than allowing the latest crisis to dictate our focus, we need to prioritize long-term, sustainable maintenance of our digital infrastructure, and to get there we need to invest a lot more time, resources, and people into our critical infrastructure. ### SconePro with Network Jam and Clotted Streams URL: https://tarakiyee.com/sconepro-with-network-jam-and-clotted-streams/ Last updated: 2026-08-01T18:08:38.000Z Last week I attended the IETF119 meeting in Brisbane (remotely), and I attended a meeting for a newly proposed working group called **SCONEPRO** where some internet service providers and large video content platforms want to work together to make the controversial practice of traffic shaping work slightly better. Here are my notes and thoughts. I would like to thank Mallory Knodel and Daniel Kahn Gillmor for their input and helping me make sense of all of this. ## Background The creatively named [SCONEPRO](https://www.youtube.com/watch?v=8Qb%5FvdvH-tI&ref=tarakiyee.com) (Secure Communications of of Network Properties) meeting was held on March 21, 2024 as a working-group forming BoF (Birds of a Feather) at the IETF119 Brisbane. BoF meetings like these are prequisites to setting up IETF working groups by ensuring there is enough interest within the community and that the IETF is the right place for standardization. SCONEPRO aims to develop an internet protocol to deal with a particular use case: Network Operators, particularly mobile, often employ methods such as traffic shaping to control the flow of traffic when there is a high load on the network. This can interfere with how some applications run. SCONEPRO is particularly concerned about video applications. Why video in particular? Not only does it form the majority of internet traffic by their estimation, video streaming applications often allow the client to adjust the bitrate (colloquially, the "quality" or "resolution" of a video), in order to reduce its impact on a congested network. End users, through client applications, have no way of knowing for sure that their traffic is being shaped. Certain solutions exist to figure that out, but application developers argue that they are complicated and costly. At the same time, network operators usually have no way of telling what traffic is video traffic because transport encryption is so ubiquitous. The SCONEPRO working group if established would develop a protocol that allows a network to communicate to a client application about whether it wants to do traffic shaping, and announce the bitrate that the network is willing to allow. This gives the client the option to artificially reduce the video quality on their end. They argue that this would provide a better "quality of experience" (QoE) to their users. ## What Happened at the Meeting The meeting started with a short explainer of the goal of the BoF by the chairs. I'll give a summary of my notes and impressions, but if you're interested to see for yourself refer to the [video at this link](http://www.youtube.com/watch?v=8Qb%5FvdvH-tI&ref=tarakiyee.com). You can also find [links to the official notes for the meeting and the slides here.](https://datatracker.ietf.org/meeting/119/session/sconepro/?ref=tarakiyee.com) ### How Shapers and Policers Work Marcus Ihlar from Ericsson gave an overview of the current state of network shaping and policing and this is my summary of that talk. There are several reasons why a network might want to throttle video, for example bandwidth limitations and congestion controls. Also, more networks are moving from a data-cap model for charging users to a bitrate-cap model, in which users can pay more to access higher resolution media. Client applications like video streaming services often employ a technique called adaptive bitrate (ABR), where they predict the capacity of the network then dynamically change the bitrate of the video to deliver it without interuptions. Networks see this as an oppurtunity to reduce the load on their networks, so they attempt to detect when a traffic flow is video, then use traffic shapers or policers to throttle the flow artificially. The functional difference between a shaper and a policer is that the former adds a delay to network packets to spread them out over time and policers drop packets above it's allowed datarate policy. Traffic shapers and policers often have the same end result. Neither technique works really well because it's not easy to detect video content because of encryption. Network operators often employ techniques to overcome that constraint with heuristics, DPI or trying to interpret the Server Name Indicator of the unencrypted initial QUIC packet, which is not always reliable. This means that the either the shaping or the ABR might not work as planned, creating a bad user experience. Some internet service providers have agreements with large content platforms (like Youtube) that provide video to provide traffic shaping that works more consistently but these are all proprietary. ### Meta and Ericsson Experiment Matt Joras from Meta presented the results of a feasibility study conducted by Meta and Ericsson in which they developed a SCONEPRO proof of concept. They implemented a MASQUE proxy that connected a Facebook app and a Facebook Video Content Delivery Network (CDN) server. In addition to facilitating the transfer of traffic between the CDN and the app, the proxy server also introduced a maximum send rate signal. The Facebook app and the CDN then used the send rate signal value to manually limit their bitrate to fit the self-imposed network constraint. Their takeaways was that SCONEPRO is feasible and it results in improvements to consistent video playback, but only when compared to the experience with a traffic shaper. ### Lessons from History Brian Trammell gave a presentation on the history of PLUS, a prior IETF working group where a more generalized approach to on-path network property signalling was discussed, but ultimately faltered for the following reasons. While the generalized approach was considered by many participants in the process to be good engineering, it is created various unintended dystopic consequences when you add policy considerations to those aforementioned engineering considerations. The cited example was, when engineering a header to signal loss tolerance and flow start, it was possible in some cases to infer the age of the user from these network signals. The recommendation based on the lessons learned was to keep SCONEPRO specific and to make it optional for clients. ### Discussion on Use Cases and Scope The second half of the meeting went into discussing the use case and potential scope of a charter. Here is a my summary of key inputs as I understood them. Don't quote anyone directly from this without reviewing the video source, any embellishments are mine. - There were questions about the how to address network complexity, like if there are multiple shapers on the path, and the need to get the information from the box with the lowest bandwidth, which would be the actual bottleneck. - Jason Livingood of Comcast expressed some frustration with having to revisit the discussion on traffic shaping. He mentioned that there are other solutions, such as investing in capacity, and also referenced regulatory action in the US to ban traffic shaping. Finally, networks shouldn't sell what they can't deliver. - David Schinazi from Google said, "This is a case of the IETF ensuring our job security a bit longer." - Ted Hardie also from Google and an author of an [RFC on signaling](https://datatracker.ietf.org/doc/rfc9419/?ref=tarakiyee.com) highlighted that one principle for good signal design is that there should be no incentive to fake it. He also brought up the example of the spin bit in QUIC and how IETF engineers are good at identifying side-channel attacks. Tommy Pauly from Apple expanded on that by mentioning Ted's RFC which has additional considerations for design of path signals. - Tom Saffell provided some insights from YouTube's infrastructure experience and the challenges faced in implementing proprietary solutions to this problem, and said Google and YouTube are interested in working on this. YouTube are supportive of network operator efforts to reduce data tonnage. Wonho Park from Tiktok also expressed support for working on this problem, stating that traffic shaping is not optimal. There were similar supportive inputs from Suhas Nandakumar (Cisco), Jeff Smith (T-Mobile America), and Dan Druta (AT&T). - Martin Duke expressed some concerns about the effects of this on best-effort traffic. He acknowledged the arguments that would improve best-effort by reducing incentives to do clumsy things in order to traffic shape. He also expressed concerns about extensability to other use cases. - Lars Eggert, former chair of the QUIC working group, expressed concerns about how operators are enamored with adding complexity to manage capacity, and how that complexity is a lucaritve market for vendors. He also is worried about this being used to monetize bitrate discrimination. - Other concerns brought up were around scalability, security, and feasibility of any possible solution, including issues related to discovery and authentication of proxies. How do you know the box giving you the signal has the authority to shape your traffic? Running so much traffic over proxies might be expensive and, ultimately, it doesn't replace the need for shapers and policers which network operators might still use for other purposes. - Stephen Farell, research fellow at Trinity College Dublin who studies security and networking, raised a concern about whether and how the security claims could be upheld, particularly client authentication to/of random boxes. - Tom Saffell (YouTube) mentioned some policy considerations that should be combined with the technical solution if they were to consider implementing it, namely: - Transparency to users: restrictions must be visible - User choice: buy a plan with no restriction - Equal treatment: wish to be treated as any other provider - Some comparisons were made between this and ECN (Explict Congestion Notification - RFC3168), however Matt Joras (Meta) made a point was that this is not explicitly a congestion issue, it's an application layer signal, for example the network might be shaping traffic because of a subscriber policy. Finally, there was a vote on whether the work group formation should move forward, 51 people voted yes, and 20 voted no, showing some opposition to this and lack of consensus. ## Some Public Interest Considerations Net Neutrality is the principle that Internet service providers must treat all communications equaly, and may not discriminate traffic based on content, particularly for profit or to disadvantage competition. Giving network operators control over bitrate, even with consent from the client, opens the door to violating net neutrality. The fig leaf on traffic shaping is that it's framed as a congestion control or a network capacity issue. One argument for traffic shaping has always been user choice: that users might want to prioritize a video call over updates downloading in the background. If it's the end user's choice as to what traffic gets shaped, and if they consent to it, then it's no longer harmful traffic discrimination. The problem remains that we have to take the network operators' word that these techniques are only applied when congestion happens, and not to extract more profit, or push users into paying more for higher bitrates artificially. SCONEPRO offers a "QoE" improvement over the status quo in (physically or artificially) capacity constrained networks, but user "QoE" would also improve if the capacity of the network is increased. In the case of a protocol that requires opt-in from the application, this can lead to business partnerships that create a "fast lane," which is another common net neturality violation. SCONEPRO currently proposes some design goals in the proposed charter that might be relevant to these issues: **1\. Associativity with an application.** The network properties must be associated with a given application traversing the network, for example a video playback. **2\. Client initiation.** The communication channel is initiated by a client device. **3\. Network properties sent from the network.** The network provides the properties to the client. The client might communicate with the network, but won't be providing network properties. **4\. On-path establishment.** That is, no off-path element is needed to establish the communication channel between the entity communicating the properties and the client. **5\. Optionality.** The communication channel is strictly optional for the functioning of application flows. A client's application flow must function even if the client does not establish the channel. **6\. Properties are not directives.** A client is not mandated to act on properties received from the network, and the network is not mandated to act in conformance with the properties. (...) **9\. Security.** The mechanism must ensure the confidentiality, integrity, and authenticity of the communication. The mechanism must have an independent security context from the application's security context. SCONEPRO is being framed as a solution to improve user experience, however most of the proponents seem to be telecom providers and major content platforms. I think SCONEPRO is a marginal improvement over the status quo in which traffic shaping is achieved with proprietary solutions and agreements between telecoms and major platforms. One important consideration would be the effects of SCONEPRO deployment in different regulatory enviroments. In places where net neutrality protections are not robust, providing a "bitrate signal" or future signals based on use cases invented in the future may enable profited-based traffic discrimination. It's not clear how some of the desired properties of SCONEPRO such as optionality or not being a directive can be technically enforced, which means when looking at the effects of introducing such a protocol these design goals can be safely ignored. Client applications that implement SCONEPRO gain an advantage over those who don't even if all the rules are respected, and if not, this opens the door to enable telecoms to more easily offer tiered services, zero-rating and fast lanes. Ultimately, I do agree with the BoF's premise that there is a problem to be solved but it's not by encoding the status quo into the protocols of the internet. I think the practice of content-based traffic shaping needs to be better looked at and tackled from a regulatory and consumer advocacy standpoint. ABR traffic shaping and by extension SCONEPRO takes choice away from users and negogiates application parameters on the network in an opaque way to force data austerity on them. **Did you find this helpful or have some feedback? Would you like to see a follow up dive into similar prior work at the IETF like PLUS, MINUS**, **SPUD, or SADCDN? Reach out and let me know.** ### Hello W- nah just messing with you 🤣 URL: https://tarakiyee.com/hello-w-nah-just-messing-with-you--f0-9f-a4-a3/ Last updated: 2026-08-01T18:08:39.000Z It's been a long time since my last blog post, and it feels so fucking good. While it does feel so incredibly good to be writing again, there is something so unfamiliar about my relationship to this space, my blog, and the internet in general. Which leads us to answer the first question I will answer today:- ## Where did all the old blog posts go? They're all happy and alive, frolicking in a server farm far far away. In reality, the internet has changed, and so have I. In fact, the internet I used to write about never existed in the first place. It was fiction, almost naive fiction, presented as reality, and as we know, reality shows never age well. I had to take the archive down because I couldn't draw a line between the person I was in the 2010s and the story I want to tell now. They're not purged, I want to curate a few of them and present them within context when I have the time, but until then, the only way to access them would be web archive or something. ## Story you want to tell? Yes, that's what blogging is you silly pants! I'm just in a very interesting period of my life, in a very interesting period of time, and both I and time are in a very interesting position. I've just left [OTF](http://opentech.fund/?ref=tarakiyee.com) after a very interesting five years of supporting people who build great tools to save those most vulnerable online, and now I've joined [Techcultivation](https://techcultivation.de/?ref=tarakiyee.com) and looking to do more of that and beyond. Not to mention great projects being set up like the [SVT](https://sovereigntechfund.de/?ref=tarakiyee.com) which I really want to tell you about. Those are all stories, from the past, the present and the future that I want to tell. *That I need to tell really.* ## Surviving a World in Crisis ![Ron Burgundy saying "Well, that escalated Quickly"](https://tarakiyee.com/content/images/2026/02/escalated-jpeg.jpg) Not gonna sugar coat it folks, since the last time I wrote a blog post, things have been rapidly becoming shittier. It was partially why I stopped. I called my older posts "almost naive" earlier, and they totally were. I've been disillusioned for as long as I can remember, and angry for even longer than that. I've also been tired. But the disillusionment, one side effect was it made me feel embarrassed by the naive fiction I used to peddle pre-2016. I will not belabor the point today, I'll keep that for later blog posts, but here is why I'm writing again. Was I wrong about things in the past? Yeah I was. Was I naive? Almost adorably so. Did my politics evolve since then? I hope so. Is there a danger of me spewing more naive fiction that I might be embarrassed about in the future? Well, that's actually my plan, and it's almost crazy enough it might work. > When times are hard, do something. If it works, do it some more. If it does not work, do something else. But keep going. > > Audre Lorde Not writing has not been working for me. Writing things that turned out to be naive worked for me at the time. Crises robbed us from our imagination. But we don't all have the luxury or privilege of being doom preppers or nihilists. Just as the climate crisis will hit the poor, the queer and those in the larger world first, it will come for their imaginations first. I want to write again and maybe encourage you all to start blogging again because we need to save our imagination, it's the only way we can keep going. So expect more wonderful stories on this website, both the ones I promised above, and more, about how we're gotta get through this and make things better.